4. 스크럼에서의 역할
• 제품책임자
고객을 대변하면서 팀이 개발할 기능에 대한 백로그를 작성하고, 우선 순위를 결정
한명만 존재해야 함.
• 스크럼마스터
팀에 스크럼을 소개하고 제대로 수행 할 수 있도록 장애를 제거해 나가는 조력자
외부의 간섭으로 부터 팀을 보호하는 역할을 하며, 개발에 깊이 참여해서는 안된다.
• 팀
스크럼을 수행하면서, 기능을 개발하는 조직
7 ± 2 명으로 구성
높은 수준의 자율권과 책임감을 가지며, 스스로 해야 할 일을 결정.
상호보완 기능팀으로 구성하며, 제품 구현이 필요한 모든 일을 수행. ( 분석, 설계, 코
딩, 테스팅, 문서화 )
5. 제품 백로그
• 스크럼의 핵심
• 우선순위가 매겨진 요구사항 목록으로 제품당 한개의 목록만 존재함. ( 여러팀이
구성되어 있어도 제품 백로그는 하나만 존재 )
• 스토리나 기능 혹은 다른 어떤 이름도 상관 없음.
• 고객이 원하는 것을 고객의 용어로 설명한 것이면 됨.
• 스토리 또는 백로그 아이템 이라고도 함.
6. 제품 백로그
• 중요도 (Value Point) 및 추정치 (Story Point) 는 Planing Poker 를 통해 산출
• 우선순위는 중요도/추정치 로 계산하여 산정함.
절대적이지 않으며, 제품책임자의 결정이 가장 중요함.
우선순위로 Planing Board를 작성함.
7. 플래닝 포커
• 모든 사람들은 카드를 한 벌씩 나누어 가짐.
모든 팀원들이 같이 추정을 함.
이해하기 전에는 추정할 수 없습니다.
• 추정할 작업을 가장 잘 이해하는 사람이 작업에 대해 설명함.
보통 제품책임자가 작업에 대해 추정이 가능한 만큼만 설명함.
• 다른 사람들은 추정을 위해 필요한 질문을 하고 의논을 함.
추정하는 사람들은 구현하기 위해 확인할 내용을 질문할 수 있음.
주로 제품책임자가 답을 하겠지만 누구라도 질문에 대한 답을 할 수 있음.
팀원1: 이 작업의 키워드 검색기능의 범위가 어떻게 되나요? 자연어 검색도 되어야 하나요?
제품책임자: 자연어 검색까지는 필요하지 않습니다. 키워드로 제목과 본문내용이 검색되는
수준이면 충분합니다.
팀원2: 검색을 위해 검색엔진 구현이 필요한 부분일까요?
팀원3: 우리는 이미 사용할 수 있는 검색엔진이 있습니다. 검색엔진 구입이나 구현은
필요없어요.
8. 플래닝 포커
• 질문이 끝나면 각자 자신이 추정한 점수를 선택하고 동시에 카드를 뒤집어 확인.
모든 팀원들이 각자 자기가 이해한 수준에서 결정.
다른 사람의 눈치를 볼 필요는 없음.
• 모두 같은 점수가 나오면 그 점수로 작업의 점수를 결정.
• 가장 낮은 점수 또는 가장 높은 점수를 제시한 사람부터 그 점수를 제시한 이유를
설명.
예를 들어 모두 3점을 제시했는데 누군가 1점을 제시했다면 다른 사람이 모르는 중요한
정보를 알고 있을 가능성이 있음.
반대의 경우 아무도 모르는 작업의 위험을 알고 있을 가능성이 있음.
9. 플래닝 포커
• 모든 사람이 자신이 제시한 점수에 대해 논의한 후 다시 점수를 제시.
모든 사람이 자신의 점수를 제시한 이유를 논의함으로써 작업에 대한 이해를 공유할 수
있음.
이 때 제품책임자가 작업에 대한 중요한 의사결정을 내릴 수도 있음.
작업카드 뒷면에 중요한 내용을 기입할것!
팀원1: 로그인을 하지 않은 상태에서 장바구니의 내용을 다시 접속할 때 기억하려면 특별한
장치가 필요합니다. 이를 위해서는 이틀의 시간이 더 필요합니다.
제품책임자: 아 그렇다면 로그인을 한 상태에서만 장바구니 내용을 보관하도록 하죠.
10. 플래닝 포커
• 모두 동일한 점수를 제시할 때까지 반복.
모두의 점수가 합의될때까지 반복.
익숙해지면 보통 2~3회 반복으로 점수가 합의됨.
이러한 과정을 통해 작업의 내용을 더 구체화되고 공유됨.
이러한 의논을 통해 반드시 확인할 내용이 나오면 카드 뒷면에 테스트케이스로 기록할것.
11. 실전! 제품백로그 & 플래닝 포커
• DEMO - http://www.youtube.com/watch?v=0FbnCWWg_NY
• 제품을 정해서 5가지 정도의 제품 백로그를 만들어 보세요.
• 만들어진 백로그를 플래닝 포커를 통해 우선순위를 산정해 보세요.
12. 스프린트 계획 회의
• 1차
스프린트 계획회의 이전에 제품 백로그를 깔끔하게 정리해야 함.
매 스프린트 마다 제품 백로그의 우선순위를 제 정의해야 함.
제품 책임자는 각 스토리를 이해하고 있어야 함.
• 2차
재 정의된 제품 백로그를 기준으로 스프린트를 진행할 항목 검토
매 스프린트시 개발할 항목에 대해 구현할 내용 구체화 ( 스프린트 백로그 )
구체화된 구현항목에 대해 추정치(Story Point) 를 Planing Poker 를 통해 산출
13. 스프린트 요점
• 하나의 스프린트 목표
• 팀원의 목록
• 스프린트 백로그
• 확정된 스프린트 데모 날짜
• 확정된 일일 스크럼을 위한 시간과 장소
14. 스프린트 백로그
• 할일: 아직 아무도 하지 않고 있는 작업
• 진행중: 누군가 하고 있는 작업
• 완료: 완료한 작업
• 소멸차트: 일일 스크럼을 마친 뒤 바로
소멸차트에 새로운 점을 찍는다.
• 계획에 없던 일: 스프린트 백로그에 없으
나, 추가 요청이 들어온 항목. 다음 스프
린트 시작전 이 항목을 가지고 제품 백로
그 정의를 다시 해야 함.
• 다음에 할 일: 스프린트가 끝나기 전에
백로그 항목을 모두 완료하면, 다음 스프
린트 항목에서 할 일을 가져와서 진행한
다.
15. 스프린트 백로그
• 제품 백로그에서 하나를 선정하여, 스프린트를 진행할 구체화된 항목을 5개 정도
로 뽑아주세요.
• 플래닝 포커를 사용하여 구체화된 항목의 추정치를 산정해 주세요.
16. 일일 스크럼 진행
• 정시에 매일 같은 장소에서 15분 이하로 서서 진행.
• 한 사람씩 자신이 어제 한 일과 오늘 할 일을 말하면서 현황판을 직접 업데이트 한
다.
• 토론은 금지이며, 추가적으로 할 말이 있을 경우 스크럼 회의가 끝난 후 개인적으
로 한다.
• 일일 스크럼 진행 후 소멸차트를 업데이트 한다.
17. 스프린트 데모하기
• 성취감.
• 다른 사람에게 일한 것을 알림.
• 이해 당사자들로부터 아주 중요한 피드백을 이끌어 낸다.
• 여러 다른 팀들이 교류하며 서로의 일에 대해 토론할 수 있는 사회적 이벤트이고
또 그렇게 운영되어야 한다(가치있는일).
• 릴리즈를 유도하는 데모를 하므로써 일이 정말로 마무리 된다.(쌓아두지 않게 된
다)
18. 스프린트 회고하기
• 스크럼에서 두번째로 중요한 행사. 개선을 할 수 있는 최고의 기회.
• 아이디어 개진. 같은 실수를 반복하지 않기 위해.
• 예상되는 토론 분량에 따라 1 ~ 3시간을 잡는다.
• 참석자는 모두 (팀)
• 밀폐된 방보다 아늑한 소파, 옥상 테라스등 오랫동안 토론에 방해 받지 않을 장소
로 이동
• 팀방에서하면 집중이 분산됨.
19. 스프린트 회고하기
• 도우미 역할을 한명 정한다.
• 스크럼 마스터는 스프린트 백로그를 보여주고, 팀원들의 도움을 받아 가며 스프
린트 동안 어떤 중요한 사건과 결정사항이 있었는지 요약한다.
• ‘한 명씩 돌아가면 이야기’ 한다. 모든 사람들은 방해 받지 않고 말할 기회를 가진
다. 각자 좋았던 것과 더 잘할 수 있었던 것, 다음 스프린트에서 다르게 해보고 싶
은 것들을 이야기 한다.
• 추정 속도와 실제 속도를 살펴본다. 크다면 왜 그런지 분석해 본다.
20. 스프린트 회고하기
• 마칠 즈음에 스크럼 마스터는 다음 스프린트를 더 잘하기 위해 우리가 무엇을 할
수 있을지 구체적인 제안을 요약해 본다.
형식에 얽매이지 않고, ‘다음 스프린트를 더 잘하기 위해 우리가 무엇을 할 수 있는지’가
주제다.
• 만족, 반성, 개선 으로 스프린트를 평가한다.
개선안들 중 다음 스프린트 기간에 집중할 것들을 ‘점 투표(dot voting)’로 결정하곤 한다.
집중할 5개의 프로세스 개선안을 선택했고, 다음 회고 때까지 지켜나가 보도록 한다.
욕심 내지 말고, 소수의 개선안에만 집중하라.
• 회고가 끝나면, 팀원에게 쉬면서 재충전할 수 있는 시간을 줘라. 1일정도.
