Page History
...
- 첫째 우리는 워터폴, 애자일, 스크럼같은 프로세스에 얽매이지 않았다.
- 둘째, 우리는 벽에 포스트잇을 줄세우지 않았다.
- 셋째, 우리는 데일리 스탠드업, 스프린트, 백로그, 칸반, 벨로시티 체킹등 어느 것도 하지 않았다.
우리는 우리의 길을 만들었다.
| Info |
|---|
경영철학 기반으로 경험하며 만든 개발방법론(Shape UP) 인점이 인상적이여서 연구하기 시작하였으며연관된 스몰비즈니스대상으로 B2B SaSS를 10년간 운영하면서 만든 개발방법론인점이 여타 다른 실리콘밸리의 성공 문화와 차별성이 있으며 경영철학인 경우 Rework번역본및 저자인 제이슨 프라이어드의 개인 블로그내용에서 일부 발췌를 하였습니다. 오역과 경험에의한 추가적인 개인 해석본이 있을수있으며 ShapeUp에대한 자세한 내용은 참고링크에 있는 원문 아티컬을 권장합니다.-
|
|
|
|---|
기존 일하는 방식의 한계
소프트웨어팀이 성장하면서 유사한 문제점들이 생겨난다.
...
처음에는 애자일 방법론중 하나인 스크럼을 도입하여스프린트를 2~3주 정하고 백로그를 관리하면서 릴리즈하고릴리즈하였고
소규모일때는 잘작동하는것으로 보여 졌지만 4명에서 50명으로 늘어나면서 다음과같은 문제에 직면했다.이렇게하면 우리의 프로덕트가 긴민하게 발전할것으로 생각했다. 우리의 일하는 방식의 문제이며 다음과 같은 문제들이 있었다.
- 관리
- PM은 관리하느라 바빠서 전략적 생각 못함
- 기획
- 치밀하지 못한 기획으로 지연됨
- 개발
- 제대로 한경우 : 끝없는 행군으로 느껴짐
- 제대로 하지못한경우 : 의미없는것을 반복하게 됩니다.
- 종합
- 정신없고 일이 끝없다 느낌
- 2주는 의미있는 것을 구현하기 기간이 짧음
...
사람 수가 늘어나면서창업자들의 직관을 전달하기가 어려워졌다. 그래서 새로운 스케일에 맞는 구조가 필요했으며
다음과 같은것을 원칙을 세우고 개발방법론을 조금씩 개선을 시도 하였다.
- 기한 내에 리스크 최소로 구현을 완료하자
- 집중과 휴식을 번갈아가며 6주-2주 주기로하자
- 기한 내 못할 것은 현명하게 포기하고 필수적인 것을 만들자
- 개발자, 디자이너가 자율성 높게 일할 수 있게하자.
...
- .
그리고 이것은 Shpe UP이란 우리만의 방법론을 출시하고 공유하기 시작했다.
BaseCamp가 만든 ShpeUP을 요약하여 살펴보겠습니다.
Shpe UP Life Cycle
| draw.io Board Diagram | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
이것은 단순하게 사이클을 조정하는 것이아닌 우리가 완벽하지 않고 불안정하다라는것을 인정하고 의미 있는일만을 할수 있는 사이클을 찾는것입니다.Shpe UP의 사이클
SHAPE를 지속적으로 하는팀과 Build를 지속적으로 해야하는 팀이 있습니다.
- Out Of Cycle : Shape에 대한 아이디어를 지속 발굴해야하는 제너럴리스트(PM/기획)및 벳팅을 결정하는 C레벨이 포함될수 있습니다. 또한 핵심문제발견시 해결방법을 찾아야하는 스페셜리스트(아키텍트/DBE)가 포함될수도 있습니다.
- In Cycle : 사이클에 직접 영향을 받는 팀이며 개발 실무진이 해당할수 있습니다. Build로 진입하면 방해요소가 최대한 없고 완성된 Shape는 홀이 없어야합니다. ( 토끼굴 Risk 라고 이후 설명됨 )
우리의 결정은 시간을 세세하게 관리하는 것이 아니라 향후 6주 내에 제품을 발전시키는 것을 기반으로 합니다. 이 기능이 6주후 출시되면 행복한것이며 , 못했을때 가장 큰 리스크역시 6주입니다.
...