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

Requirement

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

Planning 과정

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

Why / What / How / When

• 기획자는 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 과정

Self-Management & Self-Development

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

Planning Meeting

• 일반적으로 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 모델 등 요구사항에 대한 수행 방법에 대한 고민은 필요할듯.

Daily stand-up Meeting

• 이때의 스크럼 마스터는 아주 중요한 책임임.
• 팀원들의 진행 경과를 업데이트 하며, 팀의 운영 모델을 수립하고 관계를 구축 해야 한다.
• 신생팀은 서로 협력하는 방식을 스스로 찾아야 하고, 성숙해져야 한다.
• 리더는 Top-Down 방향으로 명령을 내리는 사령관이 아닌, 제안과 조언을 통해 팀원들 스스로 운영 모델을 찾도록 도와주는 사람임.
• 두달이라는 시간동안은 좌충우돌 우합지졸이라는점. 명심하자, 라인도 그랬음.

Live Demo

• 매 스프린트 종료 시점마다 live demo 를 통해, 기획자, 주요 관계자에게 사용자 관점에서의 user sotry를 설명한다.
• 이 활동은 개발자의 스킬과 실력 향상을 위해 중요함.
• 어째서 본인들의 예상보다 더 많은 개발 시간이 필요한 것인지 이해할 수 있기 때문에 기획자와 개발자 사이에 신뢰를 샇는데에도 도움이 됨.

Retrospective

• 자율적인 관리와 개발이 가능한 팀을 만든느데 중요한 활동임.
• 이를 통해 주요 개선점을 파악.
• 모든 문제를 시정하는ㄱ ㅔ목적이 아닌, 조금씩 매일 스스로를 개선하는것을 목표로 함.
• 초기 몇번의 스프린트 동안은 협력 개발 ( co-development ) 프로세스 개선에 초점이 맞춰짐.
• 이는, 스크럼 팀이 성숙한 시스템 개발 모델을 수립하기 ㅜ이해 필수적인 개선사항들이엇음.
• 어떤 점이 잘되었고, 어떤 부분이 개선되어야 하며, 감사하고 싶은자가 누구인지 말함.
• 마지막으로 스크럼 마스터의 주도 하에 팀원들은 다음 스프린트에서 노력할 주요 개선점을 한 두 개 정함.
• 스크럼 마스터는 이를 상기시키고, 다음 retrospective에서 결과를 검토함.