Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • 첫째 우리는 워터폴, 애자일, 스크럼같은 프로세스에 얽매이지 않았다.
  • 둘째, 우리는 벽에 포스트잇을 줄세우지 않았다.
  • 셋째, 우리는 데일리 스탠드업, 스프린트, 백로그, 칸반, 벨로시티 체킹등 어느 것도 하지 않았다.

우리는 우리의 길을 만들었다. 

...

경영철학 기반으로 스몰비즈니스대상으로 B2B SaSS를 10년간 운영하면서 만든 개발방법론인점이 여타 다른 실리콘밸리의 성공 문화와 차별성이 있으며

...


draw.io Board Diagram
bordertrue
diagramNamerework
simpleViewerfalse
width
linksauto
tbstyletop
lboxtrue
diagramWidth446
revision1

경영및 제품철학 기반으로 경험베이스로 개발철할및 방법론이 태생하였으며 개발방법론과 연관된 경영철학인 경우 Rework(번역본)에서 발췌하였습니다.

오역과 경험에의한 추가적인 개인 해석본이 있을수있으며  ShapeUp에대한 자세한 내용은 참고링크에 있는 원문 아티컬을 권장합니다.

  • 지속 연구중에 있으며 B2B 비즈니스 대상, 중소 IT기업규모 인점을 참고하면 좋을것같습니다.


Image Added

Image Added

Image Removed

Image Removed


기존 일하는 방식의 한계

...

  • 기한 내에 리스크 최소로 구현을 완료하자
  • 집중과 휴식을 번갈아가며 6주-2주 주기로하자
  • 기한 내 못할 것은 현명하게 포기하고 필수적인 것을 만들자
  • 개발자, 디자이너가 자율성 높게 일할 수 있게하자.


BaseCamp가 BaseCamp(37signals)가 만든 ShapeUP을 요약하여 살펴보겠습니다.

Shape UP Life Cycle

draw.io Board Diagram
bordertrue
diagramNameshape-cycle
simpleViewerfalse
width
linksauto
tbstyletop
lboxtrue
diagramWidth1155
revision11

...

그런 다음 솔루션을 스케치하는 창의적인 작업이 시작됩니다. 우리는 빠르게 움직이고 충분히 넓은 범위의 가능성을 탐색하기 위해 와이어프레임보다 더 높은 수준의 추상화에서 이를 수행합니다.

이 단계의 결과는 세부적인 세부 사항이 모두 해결되지 않은 채 식욕 내에서 않지만 우리가 하고싶은것(식욕)에 대한 문제를 해결하는 아이디어입니다. 

Address risks and rabbit holes

위험과 토끼굴을 해결하세요. 해결책이 있다고 생각되면, 팀을 혼란에 빠뜨릴 수 있는 허점이나 답이 없는 질문을 찾기 위해 열심히 조사합니다. 우리는 팀이 막히거나 시간을 낭비하는 것을 방지하기 위해 솔루션을 수정하고, 내용을 잘라내고, 특정 까다로운 부분에 세부 사항을 지정합니다.

피치를 작성합니다. 잠재적으로 베팅할 수 있을 만큼 충분히 구성되었다고 생각되면 이를

피치라는 공식 문서로 패키지화합니다. 

Write the pitch

피치에는 문제문제해결방법, 제약, 솔루션, 토끼 구멍 및 한계가 요약되어 있습니다. 피치는 단점에 대한 피치까지 완성되면 베팅 테이블로 이동합니다


DDD(도메인 주도 개발)에서 보편언어로 이벤트 스토밍을 통해 도메인을 발견하고 경계(Bounded)를 나누고

컨텍스트를 맵핑하는 방식과 비교해도 도움될것 같습니다. 

접근방식과 순서에는 약간 차이가 있습니다.


백로그를 선택하고 시간을 러프하게 추정하고 그 이후 해결방법을 찾는 일하는 방식과의 차이가 있습니다.

...

토끼굴에 빠지지 않기~ 이상한 나라 엘리스에의 토끼굴을  의미하며 한번빠지면 나오는데 너무 오랜 시간이 걸림을 의미합니다.


우리가 원했던것예측한시간

실제


실제작동되는 시간

토끼굴을 찾지 못하면 우리의 릴리즈는 더 늘어나게됩니다. 예상된 문제들은 벳팅테이블에서 고려할수 있게 함께 올라갑니다.

...

팀은 우리가 베팅한 시간 내에 배포를 해야합니다. 이것이 지켜지지 않으면 우리는 더이상 프로젝트를 확장하지 않습니다.

프로젝트의 가치를 6주로 생각하고 시작하였는데 그 2배~3배~10배로 소비하는것은 어리석은 일입니다.

"어떤 대가를 치르더라도 이 프로젝트를 수행해야해"와 같은 유형의 프로젝트는 대부분 없으며

이것을 계속 연장하는것은 우리의 프로덕트개발에  과부하를 주는것입니다.

중단하지 못하는경우 새로운 프로젝트를 못할수도 있고더 중요한 일을 못하게 할수도 있기때문입니다.

...

여기 저기 몇 가지 참고자료 외에 Shape Up의 쿨다운에 대한 전체 설명은 다음과 같습니다. 6주 주기를 연속으로 실행한다면 숨을 쉬고 다음 단계에 대해 생각할 시간이 없을 것입니다. 주기의 끝은 회의를 하고 계획을 세우기에 최악의 시간입니다. 왜냐하면 모두가 제 시간에 맞춰 배송하기 위해 프로젝트를 끝내고 막판 결정을 내리느라 너무 바쁘기 때문입니다. 따라서 각 6주 주기가 끝나면 2주간의 휴식 시간을 계획합니다. 정해진 일 없이 숨을 쉬고, 필요에 따라 만나고, 다음에 무엇을 할지 고민할 수 있는 기간입니다. 휴지 기간 동안 프로젝트 팀의 프로그래머와 디자이너는 원하는 작업을 자유롭게 수행할 수 있습니다. 6주간의 프로젝트를 출시하기 위해 열심히 일한 후 그들은 자신이 통제할 수 있는 시간을 보내는 것을 즐깁니다. 버그를 수정하고, 새로운 아이디어를 탐구하거나, 새로운 기술적 가능성을 시험하는 데 이를 사용합니다.

Shape Up에는 와일드 사이클 길이를 위한 공간이 많지 않으므로

4주 주기마다 1주간의 쿨다운 또는 6주 주기마다 2주간의 쿨다운이 합리적으로 보입니다.

회복 시간은 사이클의 에너지 출력 기대치와 일치해야 합니다.

8주간의 주기를 가지지만 휴지 기간은 1주일뿐이라면 팀은 대신 해변에서 시간을 보내는 것이 좋습니다!


BaseCamp의 일하는방식인 ShapeUp에 대해 간략하게 알아보았습니다.   작은기업을 사랑한다는 문구가 홈페이지 있으며

중소기업규모 정도이며 B2B 스몰비즈니스 대상 Sass제품의 개발방법론인점을 참고하면 더 도움될것같습니다.

B2B Small비즈니스에 성공경험을 가진 방법론으로 규모및 환경과 성장에따라 적합한 방식이 각각 있을것으로 여겨지며

유니콘이 등장하면 성공방적식인것처럼 유행처럼 따라가게 되는데  다양한 규모, 다양한 비즈니스 타켓에 대한 개발방법론이 등장해

선택지가 다양해졌으면 좋겠습니다. 선택지라기보다 성장하면서 우리만의 방식을 찾아가는것이 더 어울릴것같습니다.

도메인은 발명이 아니라 발견이다. -  DDD중

좋은팀이 오래가는것이 아니라, 오랫동안 성장한 팀이 좋은팀이다. - 애자일중


Part 3 Building단계에 대한 세부적인 내용은 제외되었으며 자세한 내용은 참고링크에 있는 원문 아티컬을 권장합니다권장하며 마칩니다.  

원문링크 :

...