Shape Up : 한국어 요약

느린 저울

31 min readAug 16, 2020

[Shape Up이란? ]

Shape Up은 생산성 소프트웨어를 만드는 Basecamp에서 사용하는 개발 방법론을 담은책입니다. 흔히 2주 스프린트로 대표되는 Lean한 방법론과 다르게, Shape Up 에서는 다음 사이클을 통해 제품을 개발합니다 : Shaping(6주), Betting(2주), Building(6주)
개인적으로 경험한 스프린트 방법론은 너무 정신 없었고, 작업자를 지치게 만들고, 깊이있게 문제를 파고들지 못했습니다. 본 방법이 더 깊은 검토와 사고를 거쳐 더 좋은 제품을 만들어 주게 해줄 수 있다는 점에 공감했습니다.
Shape Up은 단순 개발 방법론 뿐만 아니라, 프로젝트 진행에 도움이 될 유용한 개념도 전달합니다. 프로젝트의 층위를 프론트와 백엔드가 결합된 하나의 조각으로 나누라든지 하는 조언이 대표적입니다.
다만 책이 총 길이가 120페이지가 넘고 아직 한국어 요약본이 없어,더 많은 사람이 보았으면 하는 바람에 이를 한글로 요약했습니다. 직역을 많이하여 오역이나 이해 안가는 부분이 많을 수 있으니, 적극적으로 의견 주세요.
원문 : Shape Up: Stop Running in Circles and Ship Work that Matters

[영상요약]

[책 요약]

Chapter1 : Introduction & Summary

본인은 Basecamp의 디자이너이며, 이 책이 탄생한 배경을 간단히 설명하자면

일반적으로, 팀이 커질수록, 사람들은 일이 끝이 없다고 느끼고, PM은 전략적으로 생각할 시간이 부족하고, 창업자들은 초창기처럼 일을 해내지 못한다 생각하게 되었다
Basecamp 첫 프로토타입 당시(2004년) 세 명이 만들었고, 그 중 프로그래머 David은 일주일에 10시간 밖에 일을 못하는 상황이어서 정말 필요한 것만 골라서 개발해야만 했다. 본인은 디자이너였지만, 프로그래밍을 하게 되면서 프로그래머가 복잡도를 다루는 스킬을 익히게 되었다. 이 과정에서 깨달은 원칙이 이 있었는데 , 이를 더 많은 사람에게 적용하면 좋겠다 생각하게 되었다
이후 2009년 시스템 통합 당시 해당 원칙을 적용했는데 좋은 결과를 내었다. 이후 2012년에 Basecamp 2.0 런칭시 적용하기로 했고 역시 개발 과정이 엄청 스무스했다.
이후 신규입사자들에게 위 개발원칙을 보다 스케일러블하게 전수 및 확장하기 위해, 내재된 개발원칙을 시스템화 하기 시작했다. 이를 위해 기존의 용어 대신 새로운 용어를 고안하는 것이 필요했다.

책의 내용을 미리 요약하자면,

주기는 6주가 적합 : 6주는 뭔가를 만들기까지 충분한 시간이면서도 데드라인의 적절한 긴장감을 주기에 적절하다. 매니저는 6주동안 뭘 할지에 대해서만 집중하고, 매일 무엇을 해야할지 마이크로매니지하지 않는다. 예를 들어, 2주마다 로드맵을 살펴보지 않고 데일리 미팅도 안한다.
Shape the work : 개발팀에게 일감을 주기 전에 반드시 Shaping을 한다. Shaping은 문제를 정의하고, 해결책으로 적절히 추상적인 key element를 정의하는 프로세스이다. 이 때 뭔가를 하기까지 얼마나 시간이 소요될지 예측하지 않는다. 대신 어느 정도 시간을 쏟을지, 해당 아이디어가 얼마나 가치있을지를 생각한다. 이 프로세스는 소수의 2~3명의 시니어가 리드하며, 본 작업이 끝나면 해당 프로젝트를 진행할지 말지 정한다.
Making teams responsible : 소수의 디자이너/프로그래머에게 전권을 준다. 이들이 목표 하에서 태스크를 정의하며, 최종 결과물을 만들어낸다. 전통적으로 매니저가 일을 나누던 방식과 다르다. 이는 선순환이 된다. 마이크로 매니징이 적어짐에 따라, 매니저들은 전략을 더 많이 생각할 수 있게 되고, 더 좋은 프로젝트를 생각할 수 있게 된다
Targeting risk : 본 책은 주어진 사항을 제 시간에 달성하는 방법만 다룬다. 제 시간에 달성하기 위해 다음과 같은 방식으로 리스크를 줄인다. : 1)프로젝트 구현 전, 얽혀있는 의존성이나 구멍들로 인한 리스크를 미리 파악 2)계획과 구현 시간을 둘다 6주로 제한. 6주 안에서 독립적인 부분을 개발함으로써 그 이상의 시간 투입으로 인한 리스크를 제한 3)디자인과 개발을 미리 통합하여 진행하여, 통합과정 중 생길 리스크 방지

본 책의 구성은 1)Shaping(=쉽게 말해 기획) 2)Betting(=뭘 할지 정하기) 3)Building(=디자이너/개발자가 구현하기)로 나누었다

Part1 : Shaping

Chapter2 : Principles of Shaping

Shaping하는 것은 : 1)범위를 제한할 수 있게 적절히 구체적이면서도, 2)문제를 해결하며, 3)창의력을 발휘할 수 있게 적절히 추상적이어야 한다.
이 때 와이어프레임은 너무 구체적이어서 상상력을 제한한다. “이거는 예시일 뿐이고 알아서 생각해”라고 해도 자유로워지기는 어렵다. 반면 단어는 너무 추상적이다.
Shape의 예시로서 Basecamp에서 캘린더 기능이 있다. 당시 캘린더 만들어달란 요청이 많았고 그거 해달라는 대로 다 구현하려면 시간이 오래 걸렸다. 우리는 6주 안에 구현할 수 있는 핵심적인 유즈 케이스가 무엇인지 고민해봤고, 해당 기능을 ‘Dot Grid’ 기능이라 도출했다. Dot Grid는: 2달치 달력만 보이고, 보기기능만 있고, 이벤트는 날짜 밑에 점(Dot)으로만 표시하고, 이벤트 리스트는 표시. 그 외 수많은 기타 기능(예:캘린더 드래그 기능)은 무시한다.
Shape된 시안과 실제 구현된 사안은 각각 다음과 같다.

Shape된 사항은 다음과 같은 요건을 충족한다 : 1)적절히 추상적이면서 2)문제가 해결되었고 3)범위가 제한되었음
Shape 작업은 1)유저 입장에서 러프하게 스케치를 해야 하고 2)개발을 이해해야 하며 3)전략적인 생각도 필요하다. Shape를 하는 사람은 이 조건을 충족시키는 제네럴리스트 와 1~2명의 협업자가 필요하다. 이 때 Shaping은 불확실성이 크기 때문에 스케쥴링을 할 수 없다.
Shape의 순서를 대략적으로 설명하자면, 1)Set Boundaries(=바운더리 정하기) 2)Rough out the elements(필수요소 나열) 3)Address risks and rabbit holes(=리스크 파악) 4)Write the pitch(=피치덱 작성) 으로 된다.

Chapter 3 : Set Boundaries

범위(Boundary)를 정하는 것은 Shaping의 첫번째 스텝이다.
어떤 아이디어는 엄청 재밌다. 어떤 아이디어는 지루하고 원하지 않는 챌린지처럼 느껴진다 (예: 사용자가 캘린더 기능을 원함). 아이디어가 나왔을 때, 잠깐 멈춰서서 이게 얼마나 가치있는지 생각하지 않으면, 너무 빨리 아이디어를 실행하거나 너무 솔루션을 오래 생각하게된다. 좋은 것에 곧바로 돌입하거나, 별로 좋지 않게 들리는 것을 무시하는 것보다, 아이디어에 대해 포커페이스를 지을 필요가 있다.
우리는 각각의 아이디어에 어느 정도의 가치가 있는지를 판단해야 하며, 이를 appetite라고 부른다. appetite는 small batch(1~2주 동안 할 일)과 big batch (6주동안 할 일)로 나눈다. 이 기준은 1명의 디자이너와 1~2명의 프로그래머가 하는 것이 전제하이다. appetite는 정해진 일을 완수하는 데에 얼마나 걸릴지 예상하는 것이 아니다. 정확히 그 반대로서, 일자를 정하고, 그 안에서 할 수 있는 범위를 정하는 것이다. 이런 방식으로 하면 1)해결책의 종류를 정할 수 있고 2)무엇이 중요하고 무엇을 버릴지 생각할 수 있게 된다. 솔루션에 best는 없다. 시간 제약이 있는 상황이므로, 우리는 무엇이 ‘good’인지만 판단할 수 있다.
본 과정에서는 “무엇이 진짜 잘못되고 있는거야?”라는 질문을 던지며, 문제에 대해 더 narrow down , 포커스할 필요가 있다. 위 캘린더 뷰의 예시로, 모든 캘린더 기능을 넣는 대신, 가장 핵심적인 dot grid 기능으로 파고 든 것처럼 말이다.
이를 위해서는 사용자의 구체적인 베이스라인(baseline), 즉 현재 소프트웨어가 제공하고 있지는 않지만 이용자가 이미 하고 있는 것을 파악해야 한다. 예를 들어 한 사용자가 ‘캘린더가 필요하다’ 라고 말했다. 하지만 캘린더는 너무 범위가 넓기에, 조금 더 구체적인 상황을 살펴보니, 그녀는 캘린더의 빈 스케쥴을 확인하려 사무실을 간 것으로 파악하였다. 결국 ‘computerize calendar’가 가장 중요한 것이었고, 모든 캘린더 기능을 제공할 필요는 없었다.
애매모호한 용어 사용하지 말라. 예)refactoring, refactoring, File 2.0. 대신, ‘Better file previews’처럼 구체적으로 해야 한다.

Chapter 4 : Find the Elements

appetite를 정하고 문제를 정의하면, 해결하는 방안을 찾아야 한다.문제를 해결하는 방법은 수없이 많기 때문에 빨리 최대한 많은 해결책을 탐색해야 한다.
알맞은 속도로 문제를 탐색하기 위해 1)같은 배경을 가졌으며 쉽게 대화할 수 있는 사람들이 있어야 하고 2)스케치에서 불필요한 세부 요소들을 다루지 않아야 한다. 이를 위해선 다음 두 가지 방법을 사용한다.
1)Breadboarding : Breadboard(aka 빵판)는 전자 회로의 프로토타입을 만드는 데 사용할 수 있는 장치로서, 전기회로가 작동하기 위한 모든 요소가 있으며, 실제 제품 디자인이 제외된 것이다. Breadboarding, UI 아이디어를 빵판처럼 단순화하여 1)Place 2)Affordance 3)Connection Line만 나열하는 방식이다. 예를 들어 invoice를 결제까지하는 화면을 디자인할 때, 다음과 같이 단순화하여 표현 및 정리해 나가면서 발전시켜 나간다.

2)Fat marker sketch(마커 스케치) : Breadboarding이 다루지 못하는 시각적인 요소배치를 고려할 때 사용한다. 굵은 선을 이용함으로써, 세부적인 디테일을 의도적으로 고려하지 않게 한다. 예를 들어 TO DO List에서 그룹 TO DO LIST기능을 만들 때 아래와 같이 스케치한다. (자세한 과정은 원문 참조) 이 방식으로 하면 breadboarding보다 제약사항이 적어져서 핵심이 아닌 레이아웃 요소에 발목이 붙잡힐 수도 있지만, 그 점을 유의한다면 와이어프레임을 지나치게 일찍 그려서 디테일에 빠지는 것보다는 나을 수 있다.

위 과정을 거치면 Elements(핵심요소)가 결과물로 나온다. 예를 들어 캘린더의 Dot grid 기능의 경우 다음과 같은 Elements가 도출되었다. : 1)2달짜리 캘린더이고 2)점(dot)은 이벤트만 표시하고 3)달력 하단에 해당 날짜의 이벤트 리스트가 표시됨

위 과정이 끝난다고 해서 Shaping이 끝난 것이 아니다. 사람들에게 공유할 수준이 아니다. 다양한 리스크를 검토해야 한다.

Chapter 5 : Risks and Rabbit Holes

만약 프로젝트를 실행 후 예측하지 못한 문제를 부딪치고, 이를 해결하는 데에 2주가 걸린다면, 6주 중 1/3을 날리는 것이다.
잘 Shape된 프로젝트는 연기될 확률이 적어 다음과 같은 그래프를 나타낸다.

하지만, 만약 shape과정에서 rabbit hole(토끼구멍)이 많다면 (예: 알려지지 않은 기술적 문제, 해결되지 않은 디자인 관련 사항, 잘못 이해된 연관성 등) 이는 다음과 같은 그래프를 나타낸다.

우리의 Shape내용 중 놓친 것이 있는지 살펴봐야 한다. 이를 위해서는 유즈케이스(use case)를 슬로우 모션처럼 살펴가며, 사용자가 처음부터 끝까지 경험 중 빠진 부분을 봐야 한다. 이와 함께 “처음 해보는 기술적 일인가? “ “미리 내려야 할 어려운 결정은 없는가?” 등의 질문을 자체적으로 해야 한다.
위에 예시로 든 Grouped TO DO List의 경우, 완료된 아이템을 어떤 그룹에 넣을지 빠뜨렸을 수 있다. 이를 제대로 정의하지 않고 개발 단계로 들어가게 되면, 까다로운 디자인 문제를 뒤쪽에 떠넘기게 된다. 이를 막기 위해 솔루션을 제한해서 제시할 필요가 있다. 본 예시에서는 완료된 task를 하단에 label을 붙여서 해결할 수 있다.

팀원들은 최선을 다하고 싶어하기 때문에 커버하고 싶은 더 다양한 유즈 케이스를 찾을 수 있다. 하지만, 이번에 포함하지 않을 범위를 명시하고 발라내는 것도 중요하다.
이정도 까지 왔으면, 확신이 들지 않는 범위를 엔지니어들에게 의견을 받는 것이 좋다. 당신이 검증해야 할 기술적 가정들이 있을 수 있다. 이 때 “이거 가능하나요?” 라는 질문 대신, “이게 6주 안에 가능할까요?” 라고 물어보라. 엔지니어와 대화할 때에는 문서나 슬라이드쇼로 공유하기보다, 화이트보드 앞에서 컨셉을 공유하라.
본 과정이 끝나면 피치덱을 쓸 차례다.

Chapter 6 : Write the Pitch

피치덱의 목적은 베팅(part2)을 위한 프리젠테이션 준비다. 다음 다섯가지 요소가 피치덱에 포함되어야 한다
1.Problem : 문제를 정의하는 것이다. 좋은 문제 정의는 왜 현재 상태가 잘 작동 안하는지 보여주는 구체적인 스토리로 구성된다. 또한 이는 나중에 솔루션이 얼마나 나아졌는지 알 수 있는 대조군이 되어준다.
2.Appetite : 해당 문제를 해결하는 데에 얼마나 많은 시간을 사용할지에 대한 사항으로서, 왜 6주가 아니라 2주인지, 왜 3개월이 아니라 6주인지 설명하는 것이다.
3.Solution : 문제정의만 되고 솔루션이 없다면 의미가 없다. 적절한 스케치나 디테일을 포함하면서 솔루션을 그려야 한다. 다음과 같은 예시가 있을 수 있다.

4.Rabbit holes : Ch.5에서 다룬 예외사항 및 리스크들에 대해 어떻게 할지에 대해 담아야 한다.
5.No-gos : 이번 해결책에서 다루지 않는 사항들을 언급하는 것도 좋다
베이스캠프에서는 pitch가 다 작성되면 message 내에 pitch라는 카테고리를 만들어서 공유한다. 이미지가 필요할 경우 스크린샷을 문서에 첨부한다. 이후 서로 코멘트를 통해 공유한다.

Part2 : Betting

Chapter 7 : Bets, Not Backlogs

백로그(Backlog) 쓰지 마라. 백로그는 가지고 다니기에 너무 무겁다. 백로그에는 수많은 일들이 쌓여있는데 그 일들을 다 할 수 없다는 것은 누구나 다 안다. 백로그에 점점 일이 쌓이면 항상 일 뒤에 뒤쳐져 있는 느낌을 받게 된다. 게다가 백로그에는 오래된 아이디어라 나중에 다시 보면 재검토하는 데에만 시간이 오래 걸리게 된다.
백로그 대신 무엇을 해야 할까? 모든 6주 사이클에 진입하기 전, 우리는 베팅 테이블(betting table)을 가진다. 베팅테이블에서는 다음 6주동안 할 일을 고른다. 이 때 수많은 일이 담긴 백로그를 보지 않는다. 잘 shaped된 피치덱 몇개를 본다. 베팅을 하면 그 일을 하는 것이고, 베팅을 하지 않는 일들은 하지 않는다. 만약 채택되지 않으면? 다음 베팅 테이블에 기회를 봐서 다시 발의한다.
모든 것을 다 적는 백로그와 아무것도 적지 않는 것 중에 하나를 선택할 필요 없다. 공통 백로그(central backlog)를 쓰지 않더라도, 버그나 요청사항, 피치덱은 각자 분산된(decentralized) 리스트를 만들어서 추적할 수 있다. 또한 다른 부서간 조금 텀을 두고 정기적인 1:1 미팅을 하면 신선하고 좋은 아이디어를 얻을 수 있다. 사람과 목적을 가지고 대화를 하면서 생겨난 것이기에, 항상 관련있고 시의적절하다.
아이디어는 과대평가 하기 쉽다. 사실 아이디어는 쉽게 나온다. 중요한 아이디어는 다시 나온다. 반면 한번 듣고 잊어버리는 것은 그렇게 중요한 문제가 아닐 수 있다.

Chapter 8 : Bet Six Weeks

사람들이 가능한 시간이 제각각이라면, 프로젝트를 계획하는 일은 캘린더 테트리스처럼 된다.
흔히 ‘스프린트’ 라고 하여 2주 주기로 일을 하는 곳도 있다. 하지만 직접 해보니 2주는 의미있는 일을 하기엔 너무 짧았다. 2주 주기마다 스프린트 플래닝을 하고 일의 모멘텀을 끊는데, 그렇게 잃은 기회비용 만큼 2주 동안 해내는 일은 그다지 많지 않다.
표준화된 주기에 맞춰 일하는 것은 이런 문제를 해결한다.
우리는 프로젝트를 시작부터 끝날 때까지 충분히 길면서, 데드라인이 적절히 쪼아줄 수 있는 적절히 짧은 주기를 찾으려 했다. 실험 끝에 6주가 가장 적절한 주기라는 결론을 내렸다.
6주의 Shaping이나 Build 기간이 끝나면, 2주간의 쿨다운 기간을 갖는다. 스케쥴된 일이 없고 숨쉴 수 있는 시기이다. 쿨다운 기간에는 어떤 일이든 해도 좋다. 버그를 고치거나, 새로운 아이디어를 찾거나, 새로운 기술적 가능성을 찾을 수도 있다.
우리는 팀 크기도 표준화 했다 : 디자이너1+개발자2(또는 개발자1). 이 팀은 6주 동안 하나의 빅 배치(big batch)라 부르는 큰 프로젝트를 하거나, 1~2주라고 부르는 스몰 배치(small batch)를 여러개 한다.
베팅테이블(betting table)은 쿨다운 기간에 열리는 미팅으로서, 의사결정권자들이 다음 주기에 할 일을 정하는 시간이다. CEO, CTO, 시니어 개발자 등이 참석한다. C급의 시간은 소중하기에 2시간을 넘기지 않는다. 해당 미팅이 끝나면 다음 주기에 할 일들이 정해진다.
‘베팅’이라는 용어를 쓰는 이유는 다음과 같은 기대감을 주기 위해서다 :1)6주라는 시간을 명백히 실질적인 결과물을 위해 투자 2)완벽한 위임을 하고 맡김 3)손해를 규격화함(최소 2주, 최대 6주)
베팅에 중요한 것은 시간을 방해하지 않는다는 것이다. 우리는 베팅 기간에는 다른 새로운 일이 들어와도 절대 방해받지 않도록 한다. ‘한 시간만’ ‘하루만’ 하는 것에 유혹되서 다른 일을 하면 단지 그 시간만 잃어버리는 것이 아니라, 모멘텀을 잃어버리게 되기 때문이다. 만약 새로운 일이 발생한다면? 기다린다. 아무리 많이 기다려봐야 최대 6주다. 이후로도 중요한 일로 남아있으면 다음 6주에 베팅하도록 한다.
우리는 6주 내 출시를 하지 못하는 기능이라면 더 이상 연장하지 않는 터프한 규칙을 만들었다. 이를 이를 써킷 브레이커(circuit breaker)라 부른다. 이렇게까지 강력하게 설정한 이유는 다음과 같다 : 1)설계시, 6주라는 시간을 염두에 두도록 하여, 이를 넘어서는 프로젝트가 없도록 한다. 2)실패했을 경우, 6주라는 시간 내 할 수 있도록 잘못 설계되었다는 깨달음을 주고 다시 생각하게 한다 3)무엇을 넣고 뺄지에 대한 오너쉽을 갖게 한다.
만약 6주라는 기간 동안 버그가 발생한다면? 모든 버그를 고칠 필요는 없다. 문제는 그 버그가 얼마나 치명적이냐는 것이다. 진짜 위기로 이끄는 버그는 극소수다. 대부분은 6주까지 기다릴 수 있는 버그다.
해당 버그들은.. 1)버그가 작다면, 쿨다운 기간을 이용한다. 2)버그가 크다면, 베팅테이블에 가져가 6주 주기에 편입시키도록 한다. 3)버그 고치는 기간(bug smash)을 1년에 한 번 정도 편성하고 버그만 고친다.
모든 사이클마다 이전에 쌓여있는 일이 없도록 하라 (keep the slate clean). 한 사이클에 하나의 일만 베팅하고, 이전 일을 끌고 오지 마라. 일을 진행해 나가는 6주 동안 무슨 일이 생길지 모르기 때문에, 주어진 일에 집중할 수 있도록 모든 옵션을 열어놓아야 한다.
베팅 테이블에서는 다음과 같은 질문을 던지라 : 1) 진짜 그 문제가 중요한가? 꼭 해결해야 하나? 2)6주 내에 할 만한 일인가? (is the appetite right?) 3) 해결책이 매력적인가? 4) 해결책을 실행하기에 적절한 시기인가? 5)적절한 사람들이 일을 할 수 있는가?

Part3 : Building

Chapter 9 : Hand Over Responsibility

우리는 task를 쪼개는 사람을 따로 두고, 이것을 실행자들에게 나누어주지 않는다. 이것은 마치 피치덱 종이를 나뉘어진 조각으로 각자 받는 것과 같다.
우리는 믿음을 전제로 피치덱에 설정된 범위 안에서 프로젝트 전체를 맡게 한다. 팀 스스로 task를 나눈다. 피치덱 사항을 자율성을 가지고 구현한다. 재능있는 사람은 코드 몽키가 되고 싶어하지 않는다.
주의할 사항은 우리는 모든 권한을 위임하지 않았다는 점이다. 이미 앞선 Shaping 과정에서 이미 문제상황과 경계, 솔루션을 정의해 놓았다. 적절한 추상적인 레벨로 정의해 놓았기에, 미리 세부사항을 정한 것보다 더 좋은 결과물을 낼 수 있다.
이 때 일을 끝내는 것은 바로 배포(deploy)를 하는 것을 뜻한다. 테스트와 QA까지 포함되어야 하는 것이다. (documentation이나 고객에게 쓰는 공지사항은 포함하지 않는다.) 만약 일이 완료되지 않은 일은 기한을 연장하기 보다도 써킷 브레이커(circuit breaker), 즉 취소시킨다. 6주라는 기간 내에 완료되지 않는 것은 의미가 없기 때문이다.
Kickoff는 피치덱을 공유하면서 시작된다. 이후 며칠 동안은 아무 일도 벌어지지 않는 것처럼 보이는데, 사람들이 현 시스템을 파악하고 어디서부터 시작하면 좋을지 파악하고 있기 때문이다. 매니저는 이 기간을 존중하는 것이 중요하다.
팀이 처음 일을 시작할 때는 상상한(imagine) task들의 리스트가 있지만, 일을 더 진행해 나갈 수록 하기 전에는 몰랐던 실제 task들을 발견(discover)하게 된다. 그렇다고 아무 일부터 시작하면 안되고, 프로젝트의 가장 핵심부분이지만 작은 부분을 골라서 시작해봐야 한다.

Chapter 10 : Get One Piece Done

대략적으로 프로젝트의 층위를 나누자면 프론트와 백엔드, 또는 디자인과 코드로 나눌 수 있다. 만약 프론트부터 짜고 백엔드가 연결 안되면 의미가 없다. 반대의 상황도 마찬가지이다.

실제 업무가 완료되었는 것을 알기 위해서는 실제로 버튼을 눌렀을 때 작동이 되는 것을 뜻한다. 즉, 다음과 같이 프론트와 백엔드가 결합되어야 한다. 이렇게 완료하는 것이 진짜 특정 범위가 완료되는 것을 뜻한다.

사례) 베이스캠프 버젼3에서 클라이언트를 초대하고 이들과 to do list나 문서 등을 공유하는 기능을 만든 적이 있다. 이는 크게 3가지 기능으로 나뉘었다 : 1)클라이언트의 접속 정의 2)클라이언트 관리 3)클라이언트에게 특정부분을 보여줄지 말지 설정하기. 이는 디자이너1명과 개발자 1명이 맡았는데, 3)이 가장 핵심적이기에 이를 먼저 구현하기로 하였다. 디자이너는 완벽한 목업 대신 html 템플릿으로 대략적으로 위치를 잡았다. 그 사이 개발자는 버튼 등이 눌렸을 때 상태변화를 DB와 연동시키도록 개발했다.이후 작동이 확인되자, 디자이너는 조금 더 디자인 고도화를 시켰고, 프로그래머는 빠지고 다른 영역으로 이동했다. 3일 뒤 매니저는 해당 영역을 확인하고 ‘done’으로 체크했다.
Shaping 단계에서 중요한 부분이 이미 정의되었기 때문에, 프로그래머는 디자인이 끝날 때까지 기다릴 필요가 없다. 프로그래머에게 가장 중요한 것은 endpoint이다 : 입력 요소, 버튼, 위치 정도. 색상이나 레이아웃 등은 이후 해결될 수 있다. 아래는 초기단계의 디자인 예시로서, 이 정도면 프로그래머가 작업이 가능하다.

프로젝트를 시작할 때 첫 시작하는 지점을 찾는 것이 중요하다. 다음과 같은 세 가지 요소를 고려하라. : 1)핵심적이어야 한다. (=core) 핵심 적인 필수 기능을 제외하면 다른 부분들이 의미가 없다. 2)충분히 작아야 한다(=small). 만약 충분히 작지 않으면, 나머지 대비 미리 시작해보는 것의 이점이 없을 것이다. 3)이전에 하지 않았던 부분(=novel)부터 구현하는 것이 좋다. 미리 불확실한 것들에 대해 알아야 한다. 쉽고 익숙한 것부터 하면 프로젝트에 관해 아무것도 새로운 것을 얻지 못하기 때문에 불확실성을 제거하지 못할 것이다.

Chapter 11 : Map the Scopes

사람 단위가 아닌, 구조 단위로 업무를 나누라. 만약 사람 단위로 나누면 (예:디자이너를 위한 task, 프로그래머를 위한 task 등) 각자가 task를 끝내도 한 파트가 끝나있지 않을 것이다.
우리는 프로젝트의 통합된 단위를 scopes라고 부른다. 처음에는 좌측 그림처럼 불확실성이 큰 상태로 있지만, 일을 하다보면 task를 발견하게 되고, task끼리 연결된 것을 확인하게 되며, 프로젝트의 전체 구조를 파악하게 되며, 우측 그림처럼 프로젝트를 별도의 지역으로 구분할 수 있게 된다.

scope는 단순히 프로젝트의 부분이 아니라, 소통하는 언어다. 예를 들어 위에 언급한 클라이언트 프로젝트 진행단계를 공유할 때, 팀은 “‘Bucket Access’가 끝나면 ‘Invite Clients’를 구현할 거에요. “ 등의 단어를 씀으로써 무엇이 완료되었는지 더 명확히 공유할 수 있었다.
예를 들어 설명해보자. 디자이너와 개발자가 message draft 기능을 개발한다고 가정한다. 킥오프 이후 다음과 같은 task를 발견한다 .

첫 주에 하나의 영역을 완료하기 위하여(get one piece done) 새로운 글을 적는 ‘start new’ 기능에 집중하여 구현하였다.

나머지 일들을 보니 각각 다음과 같이 묶을 수 있는 것을 발견하고 다음과 같이 영역을 나누었다.

save/edit 기능을 구현 중 이는 3가지 영역으로 나눌 수 있음을 알게 되었다 : 1)send 2) store 3)reply

이후 일을 해가면서 다음과 같이 일을 완료해 나간다.

scope 를 나누는 것은 단순 계획이 아니다. 각각의 영역이 다른 곳과 어떻게 연결되어있는지를 알아야 실제 일을 나누어 완료할 수 있다. 잘 설계된 scopes는 프로젝트의 해부도(anatomy)와 같아서 어떤 부분이 어떤 부분과 얽혀 있고 분리되어 있는지 알 수 있다. :
scope가 잘 정의되어 있을 경우의 현상들 : 1)scope만 보면 전체 프로젝트가 보임. 불안하게 하는 숨겨진 영역이 안보임 2)프로젝트에 대한 대화가 자유롭게 흐름 3)새로운 task가 생겼을 때 어디에 넣을지 앎
scope가 잘 정의되어 있지 않을 경우 현상들 : 1)scope의 완료 여부를 판단하기 어려움 2) 이름이 해당 영역에 고유하지 않음 (예: 프론트엔드 / 버그가 여러 영역에 나옴 ) 3)task 단위가 너무 방대함. 각각을 짧은 시간 내에 완료하기 어려움
scope를 나눌 때 몇 가지 팁: 프론트엔드에서 작동하는 것이 백엔드와 바로 대응되는 경우의 일은 다음과 같은 모양을 띤다. (layer cake) 이 경우는 scope를 나누기 어렵지 않다.

반면 프론트엔드는 일부이고, 실제로는 백엔드작업이 더 많을 때도 있다. 마치 빙산처럼 보인다.

이 경우는 UI를 별도의 scope로 할당하고, 백엔드를 더 세부적으로 나누는 것이 낫다. 반면 빙산모양이 반대로 되어, UI는 엄청 복잡한데, 백엔드는 심플할 수도 있다. 이런 상황이 닥칠 때마다, 더 심플한 UI나 더 심플한 백엔드 정책이 있을 수 있는지 알아봐야 한다.

scope에 들어가지 않는 일은 차우더(chowder)라 부르는 곳에 넣는다. 단, 이곳에 5개 이상의 task가 쌓이는 것은 뭔가 문제가 있는 것이다 : 적절한 scope가 정의되지 않았거나 scope에 task를 넣지 않았거나
필수 사항(must-haves)이 아니라하면 좋을 사항들(nice-to-haves)이 계속 발견될 것이다. 이 경우는 물결표시(~)를 앞에 넣어서 구분되게 하면 좋다. (예: ~메시지보내기)

Chapter 12 : Show Progress

좋은 매니저는 프로젝트의 진행상황을 파악하려고 자꾸 묻지 않는다. 오히려 자주 묻는 것은 상황을 악화시킬 수도 있다. 가장 좋은 방법은 진행상황을 원할 때마다 매니저가 파악할 수 있게 구축해놓는 것이다.
이론적으로는 처음 설정한 task가 변하지 않는다. 하지만, 앞서 말했듯이, 실제 일을 진행하면 다음과 같이 새로운 task가 발견되며(discovered) to do list는 확장된다. 만약 아래 t2시점에서 프로젝트가 얼마나 진행되었는지 판단하려 한다면 잘못 판단할 수밖에 없을 것이다. 예측은 불확실한 것을 담을 수 없다.

모든 일의 단계에는 두 단계가 있다 : 1)무엇을 해야 하는지 알아내는 단계(unknown)와 2)이를 마무리하는 단계(known). 언덕(hill)에 비유해서, 알아내는 단계를 언덕을 오르는 단계, 마무리하는 단계를 내려가는 단계로 비유하면 다음과 같은 힐차트(hill chart)로 표현 가능하다.

디너파티를 준비하는 것을 예로 들자. 어떤 메뉴를 고를지 결정하는 단계에 있다면, 이 때 진행율을 묻는 것은 의미가 없다. 다음 그림처럼 unknown 단계에 있는 것이다.

이후 무슨 요리를 할지 결정이 되면 그때서야 장을 보고, 요리를 하고, 정리하면 마무리가 될 것이다.

Scope도 hill에 있는 것과 같다. 각 scope의 status를 알기 위해 각각의 scope를 다른 색으로 하여 힐차트에 표시하면 다음과 같다. basecamp에서 이 기능을 제공한다.

만약 시간이 지나도 변하지 않는 것처럼 보이는 scope이 있을 수 있다.

해당 scope를 조금 더 살펴보면, 실제로는 다음과 같이 각각의 영역을 나눌 수 있고, 영역마다 진행상황이 다를 수도 있다.

종종 언덕을 올라가기 보다도 거꾸로 내려가는 경우도 있다. 이는 처음에 범위를 설정할 때 직접 알아보지 않고 머리로 생각해서 그렇다. 이를 방지하기 위해 언덕을 오르는 과정을 다음과 같이 세 단계로 나누는 것도 좋다. 1)아이디어 단계(I’ve thought about this,) 2)검증 단계(I’ve validated my approach,) 3)알아보기 마무리 단계(I’m far enough with what I’ve built that I don’t believe there are other unknowns.)
scope를 처리할 때에는 올바른 순서로 처리하는 것이 중요하다. 다른 사항보다 불확실성이 높은 것을 먼저 대고, 이전에 해봐서 확실한 것은 나중에 하는 것이 좋다.

Chapter 13 : Decide When to Stop

주기가 끝날 때 즈음, 해당 기능에 대한 출시여부를 결정해야 한다. 만약 이상적인 목표와 비교하면 출시일은 계속 연기될 것이다. 하지만 그렇다고 스탠다드를 낮출 수도 없다. 이 때 관점을 바꿔 베이스라인(baseline), 즉 해당 기능이 없었을 때와 비교하는 것이 좋다.

베팅 프로세스에는 써킷 브레이커(circuit breaker, 완료되지 않은 일은 취소)가 존재한다. 이를 통해 우리는 팀에게 트레이드오프와 다양한 엣지케이스를 커버하는 것과 출시를 아예 못하는 것의 트레이드오프를 적극적으로 생각하도록 한다.
Scope는 잔디와 같아서 알아서 계속 자라난다. 모든 유즈케이스의 중요성은 동일하지 않기 때문에, 어떤 프로젝트든 항상 불필요한 scope가 있다. scope가 계속 자라나게 하는 대신, 팀에게 scope를 조정할 수 있는 권한을 줘야 한다.
scope를 줄인다고 해서 퀄리티를 낮추지는 않는다. 선택과 집중을 하는 것은 오히려 제품을 더 좋게 만든다.
scope를 줄이는 것을 각인시키기 위해 우리는 ‘scope hammering(망치질)’이라는 강력한 말을 쓴다. 그리고 다음과 같은 여러가지 질문을 스스로 던지게 한다. 여기서 6주라는 정해진 주기와 데드라인은 이런 질문을 더 하도록 강제한다. : “꼭 해야 하는 것인가?” “이것 없이 출시할 수 있나?” “이거 안하면 무슨 일이 벌어지는가?” “이 일이 발생할 케이스가 얼마나 되는가?”
우리는 초창기에는 QA가 없었고 서비스가 점점 커지고 영향받는 유저가 늘어나자 QA를 채용했다. QA는 업의 특성상 필수 사항(must-haves)보다도 선택사항(nice-to-haves)의 task를 발견해낸다. 우리는 QA를 별도 리스트로 두고, 정말 중요한 사항일 경우에 필수사항으로 승격시킨다. 코드리뷰도 마찬가지라서, 시니어가 코드를 쭉 본 후 꼭 고쳐야 할 사항이라면 필수사항으로 승격시킨다.
아주 가끔, 우리는 6주 동안 마무리 못한 일들을 2주 정도 쿨다운기간까지 프로젝트를 연장한다. 이를 써킷 브레이커(circuit breaker)해야 할 것과 어떻게 구별하는가? 우선 남은 일들 대부분이 scope hammering 이후에도 필수사항으로 남아 있어야 한다. 둘째, 해야 할 일들이 모두 알려진 일들(known)이어서 힐차트에서 내리막에 있어야 한다. unknown이 많으면 불확실성이 너무 높다. 하지만 이런 기간연장이 습관이 되지 않도록 경계한다. 쿨다운기간을 침범하는 것은 다른 문제를 야기할 수 있기 때문이다.

Chapter 14 : Move on

출시는 새로운 일을 발생시킨다. 버그가 나오고, 사용자로부터 다양한 불만과 제안이 나온다. 특히 기존 플로우를 변경했을 때에는 원래대로 돌려놓으라는 피드백도 강하게 나온다. 이에 대해서 바로 반응하는 대신, 며칠간 지켜보며, 확고한 태도로 그 기능을 왜 만들었는지 생각해보는 것이 좋다.
다양한 피드백을 들으면 바로 반영하고 싶은 유혹이 들 수도 있다. 하지만 그렇게 하면 다음 사이클때까지 깨끗한 상태로 있지 못하게 될 것이다. 부드럽게 “no”라고 말하라. 안된다고 말하는게 그것에 대해 생각하지 못하게 막지 않는다. 반대로, ‘yes”라고 말하여 해당 피드백을 반영하게 되면, 미래의 자유를 앗아간다. 이는 부채처럼 남게 된다. 당신이 6주에 걸쳐 출시한 것을 당신이 ‘베팅’했다는 점을 인지하라. 만약 피드백이 진짜 중요한 것이라면, 다음 shaping때 반영하라.

Conclusion

shape up 내용은 서로 긴밀하게 엮여 있기에 당신 팀에 적용하려면 생각과 실험이 필요할 것이다.
단, 다음과 같은 컨셉은 바로 도움이 될 수 있을 것
shaped와 unshaped의 차이
appetite와 estimate의 차이
적절한 레벨에서의 추상화
breadboarding과 마커 스케치를 이용한 개념화
써킷브레이커를 고려한 베팅
적절한 주기의 선택
쿨다운 기간
프로젝트를 scope로 나누기
known과 unknown을 언덕을 오르고 내려가는 것으로 비유하기
필수사항과 선택사항을 구분하기 위한 scope hammering

Appendices

Adjust to Your Size

두 세 명의 팀이라면 위와 같은 구조의 대부분을 생략할 수 있을 것. 6주라는 주기에 맞춰서 한다거나 쿨다운 기간, 베팅테이블 등이 필요 없을 것. shape와 build의 기간을 나누기 보다도 같은 기간에 shape와 build를 해도 될 것. 상황에 맞게 어떤 모자를 쓰고 있는지 어떤 단계에 있는지 사려깊게 생각할 것. 단, 주기나 shaping process를 따르지 않더라도, 일의 단계는 여전히 다음과 같이 적용될 것임

조직이 점점 더 커져가면, 주기와 관계 없이 일하는 경우(예:Dev Ops, 보안 등)도 있을 수 있음. 주기 내에서 일하는 경우 다음과 같이 일할 수 있음.

How to Begin to Shape Up

옵션A : 첫 6주 실험을 해보기. 6주 내에 끝낼 수 있는 프로젝트를 하나 Shaping한 후, 1명의 디자이너와 2명의 개발자가 6주 동안 방해받지 않고 해당 프로젝트를 끝낼 수 있도록 함.
옵션B : Shaping부터 시작해보기. 다른 일이 진행되는 도중에 Shaping을 한번 해보는 것이다. 잘 shaped된 일은 엔지니어링 팀에게 도움이 될 것이다.
옵션C : 6주라는 주기부터 시작해보기. 2주 스프린트를 했던 팀에게는 지속적인 플래닝 미팅에 대한 오버헤드를 없애줄 것이다.
팀이 출시를 하는 것에 익숙해지게 하라. 아무리 대단한 인사이트가 있어도 출시하지 못하면 꽝이다.
6주 동안 전권을 주었는데 디자이너와 프로그래머가 놀까봐 불안할 수도 있다. 이 때는 최종 결과에 집중하라. 마이크로한 것을 보지 말고 매크로한 것을 생각하라. 제 시각에 제품이 출시되고 사람들이 개선되었다고 느낀다면, 그것이 성공이다.