Page History
과거 몇년간 어떻게 작은 팀으로, 높은 품질의 소프트웨어를 그렇게 빨리 개발해내는지 물어보곤 했다. 또, 개발자들을 오랫동안 유지하는지도.
- 첫째 우리는 워터폴, 애자일, 스크럼같은 프로세스에 얽매이지 않았다.
- 둘째, 우리는 벽에 포스트잇을 줄세우지 않았다.
- 셋째, 우리는 데일리 스탠드업, 스프린트, 백로그, 칸반, 벨로시티 체킹등 어느 것도 하지 않았다.
우리는 우리의 길을 만들었다.
베이스캠프에서 직접사용하고 공유하는 공유하고 있는 개발방법론인 Shape UP에 대해 알아보겠습니다.
최초 제품출시가 아닌 제품출시후 기능추가때 참고할수 있는 개발방법론입니다.
기존 일하는 방식의 한계
소프트웨어팀이 성장하면서 유사한 문제점들이 생겨난다.
...
처음에는 애자일 방법론중 하나인 스크럼을 도입하여스프린트를 2~3주 정하고 백로그를 관리하면서 릴리즈하고
우리의 프로덕트가 지속 발전한다고 느꼇다. 하지만 다음과 같은 문제들이 있었다.
- 관리
- PM은 관리하느라 바빠서 전략적 생각 못함
- 기획
- 치밀하지 못한 기획으로 지연됨
- 개발
- 제대로 한경우 : 끝없는 행군으로 느껴짐
- 제대로 하지못한경우 : 사일로 문제에 직면할때 스프린트내에 아무런 일이 없을수 있습니다.
- 종합
- 정신없고 일이 끝없다 느낌
- 2주는 의미있는 것을 구현하기 기간이 짧음
...
draw.io Board Diagram | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
우리의 결정은 시간을 세세하게 관리하는 것이 아니라 향후 6주 내에 제품을 발전시키는 것을 기반으로 합니다.
이 기능이 6주후 출시되면 행복한것이며 , 못했을때 가장 큰 리스트역시 6주입니다.
일감을 측정하기 - 언제까지 되나요?
draw.io Board Diagram | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
- Estimate : 이것이 언제까지 될까요? 러프하게 추정
- Appetite : 시간을 정해놓고 우리가 꼭해야할것이 무엇인가? 조정
ShapeUp에서는 Appetite방식을 Appetite방식을 사용하여 해야할 일을 조정합니다.실제 Calendar View의 예를 들어서 Estimate와 Appetite를 사용한 방식의 예시이다.
Calendar View 기능을 출시하기
고객이 캘린더 뷰를 원했다. 구글캘린더 처럼 만들면 되겠지하고 하고 접근하였다.
구글캘린더에는 좋은 기능들이 많았고 참고하여 리스트업을 하였습니다다음과 같은 예상기능들이 있었다.
- 등록 이벤트를 드래그앤 드랍으로 이동하기
- 스케쥴을 월별 주별 비교하기
- 스케쥴의 기간을 보기
- 이벤트마다 색상을 입히기
- ...... 그리고 차별성을 위한
구글캘린더처럼 만들지도 못하는데 이것을 만드는데는 6개월이상이나 측정이 되었고
여기서 우리는 이것을 또 할지 말지결정합니다.
- 6개월의 개발기간만큼의 가치가 없으니 고객의 요구사항은 폐기합니다.
- 또는 강행해서 개발하여 고객에게 좋은 경험을 선사합니다.6개월동안이나 만들어야하는가? 우리는 구글캘린더와 경쟁을 하나?
우리는 6주라는 시간을 정해놓고 진짜 필요한것만 하기로 하였습니다. 그러다보니 고객이 진짜 원했던것은 자신이 등록한 스케쥴을 확인하는 것이였으며 우리는 이 기능만 추가하였습니다.
불필요한 나머지를 모두 제거하여 6주내에 출시하였습니다.
...
기획여정
draw.io Board Diagram | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
단어는 문장은 아이디어를 빠르게 던질수 있지만 너무 추상적이고 Wireframe은 이 기능을 만들지 말지
결정하지도 못했는데 엄청난 시간을 들이며 결정적으로 결정적으로 최종으로 만들어야할 제품과 일치하지 않습니다.
Shape 주요 3단계 속성
- Rough
- 러프한것은 누구든 미완성이란것을 알고 있습니다. 이것으로 충분합니다.
- 미완성인 내용으로 얼마나 소요될지 추정하지 않습니다. 그래서 이단계는 구체적이여서도 안됩니다.
- Sloved
- 완성된 SHPAE는 해결가능한것이여야하기때문에 우리가 만드려는 기능의 핵심기능에 대해 먼저 해결방법이 나와야합니다.
- WireFrame단계에서 가능한지 안가능한지 검토하는것이 아닌 그 이전에 해결방법을 찾아야함을 의미합니다.
- Bounded
- 우리의 시간은 제약적입니다. 이것을 시간내에 해야할 경계를 정하는것이 중요합니다.
- 하지말아야할것을 정리합니다.
BreadBoarding
BreadBoarding
...