과거 몇년간 어떻게 작은 팀으로, 높은 품질의 소프트웨어를 그렇게 빨리 개발해내는지 물어보곤 했다. 또, 개발자들을 오랫동안 유지하는지도.
첫째 우리는 워터폴, 애자일, 스크럼같은 프로세스에 얽매이지 않았다.
둘째, 우리는 벽에 포스트잇을 줄세우지 않았다.
셋째, 우리는 데일리 스탠드업, 스프린트, 백로그, 칸반, 벨로시티 체킹등 어느 것도 하지 않았다.
우리는 우리의 길을 만들었다. 베이스캠프 Shape UP에대해 알아보겠습니다.
기존 일하는 방식의 한계
소프트웨어팀이 성장하면서 유사한 문제점들이 생겨난다.
- 팀원들은 프로젝트가 끝없는 행군처럼 느껴진다.
- 프로덕트 매니저들은 프로덕트에 대해 전략적으로 생각할 시간을 낼 수가 없다.
- 창업자들은 자문한다. 왜 우리는 예전에 했던 것처럼, 신속하게 기능을 출시할 수가 없을까?
우리는 4명에서 50명으로 늘어나면서 이런 문제에 직면했다.
사람 수가 늘어나면서, 창업자들의 직관을 전달하기가 어려워졌다. 그래서 새로운 스케일에 맞는 구조가 필요했다.
- 관리
- PM은 관리하느라 바빠서 전략적 생각 못함
- 기획
- 치밀하지 못한 기획으로 지연됨
- 개발
- 끝없는 행군으로 느껴짐
- 종합
- 정신없고 일이 끝없다 느낌
- 2주는 의미있는 것을 구현하기 기간이 짧음
Shpae UP 개발 사이클
- 기한 내에 리스크 최소로 구현을 완료하자
- 집중과 휴식을 번갈아가며 6주-2주 주기로하자
- 기한 내 못할 것은 현명하게 포기하고 필수적인 것을 만들자
- 개발자, 디자이너가 자율성 높게 일할 수 있게하자.
EstiMate VS Appetite
- Estimate : 이것이 언제까지 될까요? 러프하게 추정
- Appetite : 시간을 정해놓고 우리가 꼭해야할것이 무엇인가? 조정
ShapeUp에서는 Appetite방식을 사용하여 해야할 일을 조정합니다.
실제 Calendar View의 예를 들어서 Estimate와 Appetite를 사용한 방식의 예시이다.
고객이 캘린더 뷰를 원했다. 구글캘린더 처럼 만들면 되겠지하고 하고 접근하였다. 구글캘린더에는 좋은 기능들이 많았고
참고하여 리스트업을 하였습니다.
- 등록 이벤트를 드래그앤 드랍으로 이동하기
- 스케쥴을 월별 주별 비교하기
- 스케쥴의 기간을 보기
- 이벤트마다 색상을 입히기
구글캘린더처럼 만들지도 못하는데 이것을 만드는데 6개월이상이나 측정이 되었다.
여기서 우리는 이것을 할지 말지 또 결정할것입니다.
- 6개월의 개발기간만큼의 가치가 없으니 고객의 요구사항은 폐기합니다.
- 또는 강행해서 개발하여 고객에게 좋은 경험을 선사합니다.
우리는 6주라는 시간을 정해놓고 진짜 필요한것만 하기로 하였습니다.
그러다보니 고객이 진짜 원했던것은 자신이 등록한 스케쥴을 확인하는 것이였으며 우리는 이 기능만 추가하였습니다.
Words VS Wireframe
단어는 아이디어를 빠르게 던질수 있지만 너무 추상적이고 Wireframe은 이 기능을 만들지 말지
결정하지도 못했는데 엄청난 시간을 들이며 결정적으로
약간의 오역과 경험에의한 추가적인 개인 해석본이 있을수있으니 원문 아티컬을 권장합니다.
원문링크 : https://basecamp.com/shapeup