Shape up 방법론

Vision
Mission
Grow together to Change the world
Spread Rewards, Spark Engagement
Shape Up Method
작은 조직에서 효과적으로 일하기
Joel Lim
2022. 2. 25
Copyright ⓒ All Right Reserved by Buzzvil

View Slide

들어가기 전에

View Slide

What is the Shape Up method
Basecamp에서 사용하는 개발
방법론
6주 주기의 사이클로 제품을 개발 생산성 소프트웨어을 만드는
회사

View Slide

배경
팀이 성장하며 몇 가지 어려움이 발생
1. 팀원들은 끝이 안보이는 프로젝트가 계속되는 것처럼 느낌
2. 제품 관리자는 제품에 대해 전략적으로 생각할 시간이 없음
3. 초기 시절처럼 빠르게 기능을 출시할 수 없음
4. 창업자들의 직관을 전달하기 점점 어려워짐

View Slide

그래서 만들게 된 일하는 방식 - Shape Up
1. 6주 주기로 일한다.
2. 할 일을 Shaping 한다.
3. 실무자에게 전권을 위임한다.
4. 리스크를 사전에 추적해 줄인다.

View Slide

목차
1. Shaping
○ 원시 아이디어를 다듬고, 위험요소를 찾고, 얼마나 시간을
투입할지 결정하는 단계
2. Betting
○ Shaping 된 과제 중 다음 주기에 무엇을 할지 결정하는
단계
3. Building
○ 실제 제품 개발 단계

View Slide

Shaping

View Slide

Shaping
Shaping 이란?
- 문제를 정의하고, 해결방법을 찾고, 다듬는 일련의 작업

View Slide

Shaping
Shaping 원칙
● 팀의 창의력을 저해하지 않도록 너무 구체적이면 안된다.
○ 와이어 프레임은 너무 구체적이다.
● 반대로 너무 추상적이면 안된다…
○ e.g. 캘린더 보기 만들기, 그룹 알림 추가, 시스템
리팩토링 등
● 그러면서 반드시 문제를 해결해야 한다.

View Slide

Shaping - case study
Shape 예시 - Basecamp의 캘린더 기능
캘린더 기능 추가을 만들어달라는 고객요청이 많았음
제대로 된 캘린더를 만드려면 6달정도의 시간이 소요됨.
우리는 6주의 시간만 들여 고객의 문제를 해결하고 싶었음.
그래서 캘린더가 고객에게 전달해야 할 핵심가치에 집중하기로 함.
고객은 캘린더를 통해, 일정을 쉽게 확인할 수 있기를 원함
고객이 원하는 핵심 기능은 ‘Dot Grid’라는 결론 도달
2달치 달력만 보이는 읽기전용 캘린더를 고안. 이벤트는 날짜 밑에 점으로만 표시
그 외 캘린더로서의 기능은 모두 무시

View Slide

Shape된 스케치
실제 결과물

View Slide

1. 적절히 추상적인가? Yes
2. 문제가 해결됐는가? Yes
3. 경계가 있는가? Yes

View Slide

Shaping - steps to shaping
1. 경계를 정한다 (Set Boundaries)
2. 필수요소들을 다듬는다 (Rough out the elements)
3. 리스크를 파악한다 (Address risks and rabbit holes)
4. 피치를 작성한다 (Write the pitch)

View Slide

Shaping - Set Boundaries
문제의 범위를 좁히고, 얼만큼의 시간을 투입할지 결정한다.

View Slide

멀리서 보기(포커페이스 유지)
아이디어가 나왔을 때, 잠깐 멈춰서 이 아이디어가 얼마나 가치 있는지
생각하자.
- 너무 빨리 아이디어를 실행하면, 자칫 리소스를 낭비할 수 있다.
- 너무 솔루션을 길게 생각하면 쓸모없는 아이디어에 너무 긴 논의 할
수 있다.
appetite: 아이디어가 어느정도 가치가 있는지 판단하는 기준
appetite는 팀의 시간 리소스로 생각할 수 있으며 두 가지 크기로
설정한다.
small batch(1~2주짜리 프로젝트)

View Slide

appetite != estimate
“Estimates start with a design and end with a number.
Appetites start with a number and end with a design”
일자를 먼저 정하고, 그 안에서 할 수 있는 일의 범위를 정하는 것
장점
1. 설계하는 솔루션의 종류를 제한한다.
2. 고정시간은 팀에게 정말 중요한것과 불필요한 것을 걸러내는 것을 강요할 수 있다.
절대적인 best solution은 없다. 여러개의 상대적인 good 만 있을 뿐.. 우리는
시간제약을 걸어 더 나은 ‘good’을 찾을 수 있다.

View Slide

narrow down - 문제 범위 좁히기
캘린더 사례
1. 실제 고객과 컨택
2. 고객은 캘린더를 통해 팀 일정과 회의실 사용여부를 확인하고
싶었음.
3. 캘린더의 모든 기능 -> 날짜별 빈 스케줄을 확인할 수 있는
기능으로 범위를 좁힘

View Slide

Shaping - Find the Elements
BreadBoarding
- Place: 화면, 대화 상자, 팝업 메뉴 같은 탐색할 수 있는 항목
- Affordance: 사용자가 작업할 수 있는 항목(버튼이나 필드 등)
- Connection Line: 어포던스로 사용자가 이동하는 것
Place
Affordance
Connection Line

View Slide

Before
After

View Slide

Fat marker sketches

View Slide

Shaping - Risks and Rabbit Holes
잘 shape된 프로젝트 Rabbit hole이 많은 경우
(기술적 문제, 잘못된 디자인, 미스
커뮤니케이션…)

View Slide

Shaping - Risks and Rabbit Holes
토끼굴 찾는법
- 빠진 부분이 없는지 사용자 경험을 처음부터 끝까지
따라가본다.
- 처음 해보는 기술적일인지 자문해본다.
- 미리 내려야 할 결정이 없는지 자문해본다.
- 포함하지 않을 범위를 명시하고 발라낸다.
- 엔지니어들에게 의견을 구한다.
- 구체적인 피피티나 문서보단, 화이트보드로 컨셉을
공유
- “X를 할 수 있습니까?” 라고 묻지 말고 “6주 안에
가능합니까?” 라고 물어보자
- 아이디어의 가능성이 아니라 위험요소를 찾고
있다는 점을 강조하자
- “
we’re really hunting for time bombs that might blow up
the project once it’s committed to a team.”

View Slide

Shaping - Write the Pitch
피치의 목적은 잠재력있는 내기(프로젝트)를 베팅 때 제시하는
것
피치에 포함되야 할 다섯가지
1. Problem
2. Appetite
3. Solution
4. Rabbit holes
5. No-gos

View Slide

Shaping - Write the Pitch

View Slide

Betting

View Slide

Betting - Bets, Not Backlogs
No Backlogs
- 백로그는 시간낭비다.
- 백로그에 쌓인 수많은 일들을 다 할 수 없다는 걸 모두가 안다.
- 백로그에 일이 쌓이면 항상 뒤쳐진다는 느낌을 받게 된다.
- 오래된 아이디어를 다시 검토하고, 정리하는데 소요되는 시간은 지금 당장
중요하고 적절한 프로젝트를 진행하는데 방해가 된다.

View Slide

Betting - Bets, Not Backlogs
Betting table
잘 shaped된 피치 몇 개만 가지고 와, 그 중에서 다음 6주동안 할 일을 고른다.
베팅된 일을 진행하고, 선택받지 못한 피치는 하지 않는다.
꼭 해야 한다면 다음 베팅 테이블 때 다시 제안한다.
“Important ideas come back”
아이디어는 과대평가하기 쉽다. 하지만 사실 아이디어는 값싸다. 정말 중요한 아이디어라면
다시 나온다. 한번 듣고 백로그로 가는 아이디어는 별로 중요한 문제가 아닐 수 있다.

View Slide

Betting - The Betting Table
6주 주기 프로젝트 사이클
프로젝트 계획이 캘린더 테트리스가 되지 않도록, 표준 프로젝트 크기를 제공해야 한다.
왜 6주인가?
- 의미 있는 일을 하기에 2주(스프린트)는 너무 짧다. 플래닝 오버헤드 대비 2주동안 해내는 성과는
그다지 많지 않다.
- 실험을 거쳐, 프로젝트를 마무리하기까지 충분히 길면서 데드라인이 적절히 쪼아줄 수 있는 주기가
6주라고 결론지었다.

View Slide

Cool-down
6주 주기 후에 2주의 쿨다운 기간을 갖는다.
이 때는 팀원들이 원하는 어떤일이든 해도 좋다.
버그를 고치거나, 기술을 공부하는 등 자신이 통제할 수 있는 시간을 즐긴다.
쿨다운 기간에 다음 6주 주기에 어떤 일을 진행할지 결정하는 Betting이 진행된다.

View Slide

전체 사이클

View Slide

베팅의 의미
1. 모든 베팅에는 지불금이 있다. 우리의 경우엔 6주라는 시간이다.
2. 베팅은 약속이다. 우리가 6주를 베팅한다면, 팀이 방해 없이 오로지 그 일에 전념할 수 있도록 전체
6주를 보장해주기로 약속한다.
a. 모든 인터럽트에서 자유로워야 한다. 인터럽트에 한 시간을 쓰면 그것은 한시간만 쓴게
아니다. 모멘텀을 잃어버리기 때문이다.
3. 베팅에 실패시 지불금 만큼으로 손해를 통제한다.
a. 서킷 브레이커를 통해 프로젝트가 예상시간 이상으로 소요되는 것을 막는다. 우리는
appetite를 통해 프로젝트가 6주의 가치가 있다고 정의했다. 프로젝트가 늘어진다고 해서
2배, 3배를 투자하는건 어리석은 일이다.
b. 실패했을 때 shaping이 잘못됐다는 걸 깨닫게 하고, 다음 shaping때 개선할 수 있게 한다.
c. 서킷 브레이커를 통해 팀원들은 정말 중요한 일에만 집중하게 된다.

View Slide

그러면 버그는 어떻게 처리해야 할까
모든 버그를 고칠 필요는 없다. 문제는 얼마나 심각한 버그인가이다.
정말 중요한 버그라면 당장 고쳐야 겠지만 그런 위기는 드물다. 대다수의 버그는 6주를 기다릴 수 있다.
버그 처리 전략
1. 작은 버그는 쿨다운 기간을 이용한다.
2. 중요한 버그라면 베팅 테이블로 가져와 다른 피치들과 경쟁한다.
3. 버그 스매시 기간을 가진다.
a. 1년에 한 번 버그 수정만 6주간 할애하는 기간을 만든다.

View Slide

베팅 테이블에서 논의해야 할 사항들
● 진짜 그 문제가 중요한지
● 6주 내에 완료하기 적절한지
● 솔루션이 매력적인지
● 문제를 해결하기 적절한 시기인지
● 문제를 해결하기에 적합한 사람이 있는지

View Slide

Building

View Slide

Building - Hand Over Responsibility
태스크를 나눠 분배하지 마라 - 알아서 하게 둬라
팀 스스로 태스크를 나눈다. 세부사항은 자율적으로 구현한다.
재능있는 사람은 코드몽키가 되고 싶어하지 않는다.

View Slide

며칠간의 침묵을 존중하라
팀 내부적으로 세부구현에 대한 방향성을 잡기 위한 시간이 필요하다.
이 기간동안 아무일도 하지 않은 것 처럼 보일 수 있으나,
관리자는 이 기간을 존중해 줘야 한다.

View Slide

일의 완료시점은 배포를 뜻한다.
6주안에 배포가 되지 않으면 의미가 없는 것이다.
이 경우 기간을 연장하지 말고, 프로젝트를 취소한다. (circuit breaker)

View Slide

Building - Get One Piece Done
통합된 하나의 기능단위로 작업을 해 나가라
첫 시작지점 찾기
1. 핵심적이고
2. 충분히 작으면서
3. 이전에 하지 않은 부분

View Slide

Building - Map the Scopes
Scope map
프로젝트 시작
단계
작업 발견 단계 Scope 정의단계

View Slide

Building - Map the Scopes

View Slide

Building - Show Progress

View Slide

Building - Decide When to Stop
주기가 끝날 쯤에 릴리즈 여부를 결정해야함.
이 때 베이스라인과 비교해 릴리즈를 결정하자.
- 현재보다 나아진다면 릴리즈

View Slide

Scope는 항상 자란다.
모든 프로젝트는 불필요한 scope로 가득 차 있다.
scope가 계속 자라지 않도록 팀에서 조정할 수 있는 권한을
주자
scope를 줄여도 품질은 낮아지지 않는다. 중요한 것에
집중해 오히려 좋은 제품을 만든다.

View Slide

circuit breaker를 사용하기 애매할 때
정말 부득이하게 6주 이상으로 프로젝트를 연장해야 할
경우 쿨다운 기간까지만 프로젝트 연장을 허용한다.
이 때는 몇 가지 조건이 있다.
1. 남은 작업이 모두 필수사항이어야 한다
2. 불확실한 과제가 없어야 한다. (well-known 상태)

View Slide

Key concept
1. Shaped versus unshaped work
2. Setting appetites instead of estimates
3. Designing at the right level of abstraction
4. Concepting with breadboards and fat marker sketches
5. Making bets with a capped downside (the circuit breaker) and honoring them with uninterrupted time
6. Choosing the right cycle length (six weeks)
7. A cool-down period between cycles
8. Breaking projects apart into scopes
9. Downhill versus uphill work and communicating about unknowns
10. Scope hammering to separate must-haves from nice-to-haves

View Slide

Review
좋았거나 인상깊었던 부분
1. appetite
2. 6주간의 완전한 몰입. (싱글 스레드 팀)
3. “베팅”이 가지는 비장함
4. 러프한 피치와 전권위임
5. 정말 중요한 아이디어는 알아서 돌아온다

View Slide

Review
별로거나 동의하지 못한 부분들
1. 실무진이 참여하지 않는 shaping이 좋은 솔루션을 제시할 수
있을까?
2. 프로젝트 회고에 대한 내용이 없었다. 쿨다운 기간동안 챙기는
것인지 궁금
3. 프로젝트 시작 전엔 Rabbit hole을 절대 다 알지 못할 것
4. 모든 팀에 적용하기 어려워보임

View Slide

Review
1. user side 제품보단 내부제품을 만들 때 도입 할 것 같음
2. 적용했을 때 놀라운 제품 보단 무난한 제품이 나올 것 같다
3. appetite, marker sketches 같은 컨셉이 개인적으로 좋았고,
적용해 볼 만할 것 같다.

View Slide

Thank you
Joel Lim
2022. 2.25

View Slide

Shape up 방법론

Shape up 방법론

Buzzvil

More Decks by Buzzvil

Other Decks in Programming

Featured

Transcript