애자일 적용 0x0002

Epic : 큰 틀 Story : [As: 누구로서, I want: 무엇이 필요한데, So That: 어디에 사용할 예정이다 ] Sub Task : 수행 방법에 따라 이를 분활

Requirement

스크럼 마스터는 개발자와 개발자 사이, 개발자와 기획자 사이, 기획자와 사업 담당자 사이의 신뢰 구축에 최선의 노력을 기울여야 합니다. 이를 위해 개발자가 스케줄을 산정하고 실행 계획을 수립하는 과정에 적극 참여하였습니다.
매니지먼트 팀이 일방적으로 의사 결정을 내리지 않았습니다.
개발자들은 본인들이 스스로 약속한 스케줄을 지키기 위해 최선을 다했습니다.
개발자가 약속한 기한에 맞춰 완수한 덕분에 기획자는 개발자를, 주요 담당자들은 기획자를 믿는 신뢰가 형성되었습니다.

개발자는 창의적인 아이디어를 통해 프로세스의 속도와 품질을 향상시키는 창조적인 과정을 진행시키는 존재여야함.
Pros/Cons 분석을 통해 아이디어를 함께 검토함. 이과정은 planning meeting 에서 실행 계획을 논의하고, 태스크를 분할할때 이루어짐.
예를 들어, 데이터베이스 프레임워크의 선택 / 데이터 스키마를 정할 때 모든 개발자가 Pros / Cons 분석에 참여하고 의견을 내었다.

기획자는 planning meeting / backlog.grooming 에서 "What To do ( 해야 할 일 )" 과 " Why To Do ( 해야 하는 이유 ) " 를 개발자에게 설명했습니다.
개발자가 user story ( 요구 사항 ) 에 대한 중요성을 이해하는 과정
개발자는 planning meeting 에서 기획자에게 "How To Do ( 어떻게 할 것인지 ) " 와 " When To Do ( 언제까지 할 것인지 ) " 를 알려줌. 이는 그 user story ( 요구사항 ) 을 구현하는데 얼마의 시간이 필요한지 알리는 과정 ( complexity estimation ), 기획자는 비용 효율을 분석해서 우선순위를 조정함.
기획자와 개발자가 상호 합의한 우선순위를 바탕으로 개발자는 이번 스프린트에서 어떤 user story ( 요구사항 ) 을 완료할 것인지 알리고, 어떻게 구현할 것인지 정함. task breakdown 과정

뛰어난 팀 스프릿을 가지고 있는 경우에 가능함. 이런 경우에, 팀 리더는 팀원과 자신의 자율적인 관리와 개발을 추구하면서 스크럼 활동을 수행하는 팀으로 이끌 수 있음.

일반적으로 1,2 단계로 나뉜다.
Planning Meeting 1: 기획자가 개발자에게 product backlog에 작성한 user story 와 epic 에 대한 설명을 진행
Planning Meeting 2: 개발자가 user story를 선택하고, 태스크를 분할하는 과정
필요한경우, backlog.gromming 미팅을 열어, 기획자가 상위 user story / epic 에 대한 상세하게 설명하는 시간을 가짐을 통해 이해를 바탕으로 개발을 들어감.
또한, daily stand-up meeting 이 30분을 넘지 않는 범위 내에서 하위 user story에 대한 설명을 진행함.
King and Servant 모델 등 요구사항에 대한 수행 방법에 대한 고민은 필요할듯.