초간단 스크럼 정리

1. 초간단 스크럼
2009.06.21 altprog.com

2. 스크럼과 XP의 일부를 요약했음

3. 1. 프로젝트를 시작합시다
●필요한 사람
○ 제품 책임자
○ 스크럼 마스터
○ 팀

4. 제품 책임자
●비즈니스 관점에서 우선순위 결정
●뭘 만들어야 되는지 알고 있다
●닭

5. 스크럼 마스터
●스크럼 이벤트들의 진행자
●팀과 제품책임자를 돕는다

6. 팀
●개발하고 테스트할 사람들
●뭐든 할 수 있는 교차기능팀
●일정이나 속도를 추정한다
●돼지

7. 2.제품 백로그를 준비합시다
●제품 백로그란?
○제품의 기능을 스토리 단위로 정리

8. 제품 백로그는 이렇게 생겼음
ID 이름 중요도 추정치 데모 방식 참고
1 입장 30 5 이래저래
한다.
이런
2 아이템
구매
10 8 요렇게 한
다.
저런
제품책임자가 정한다
값이 겹치지만 않을 정도로
팀이 정한다. 스토리점수
(보통은 이상적인 맨데이)
절대적인 정확도가 아닌 값사
이의 상대적인 정확도가 중요

9. 3.스프린트 계획회의를 준비합시다
●스프린트 = 2~4주간의 열혈개발 기간
●스프린트 계획회의 준비
○백로그 하나, 제품 책임자 한 명
○제품책임자가 각 스토리를 이해하고, 서로 다
른 중요도 값을 부여해놓는다

10. 4.스프린트 계획을 세웁시다
●스프린트 계획의 산출물
○하나의 스프린트 목표
○팀원의 목록 (필요하면 참여수준)
○스프린트 백로그
○확정된 스프린트 데모 날짜
○확정된 일일 스크럼 시간/장소

11. 참석자
●제품관리자
●스크럼마스터
●팀

12. 스프린트 길이 결정
●보통은 3주가 적당
○짦으면 피드백 주기가 빨라서 시간낭비 감소
○길면 팀이 추진력을 얻고, 문제들을 해결할 충
분한 여력이 생김
●일정하게 유지하면 심장박동같이 된다

13. 스프린트 목표 결정
●‘제일 중요한 스토리 3개 완료’와 같이 억
지스럽더라도 세워두면 좋다
●위키페이지 하나에 사내 모든 팀의 목표를
한눈에 볼 수 있으면 좋다

14. 스프린트에 구현할 스토리 고르기
●우선순위가 높은 스토리부터
●팀이 결정한다
○방법1. 직감으로
○방법2. 속도계산

15. 직감으로 추정하기
●A,B,C를 이번 스프린트에서 구현 가능하
겠습니까?
●네, 될 것 같은데요

16. 속도계산으로 추정하기
●이전 스프린트의 초기추정치를 기준으
로 팀의 속도를 계산한다
●이전 스프린트 들의 평균을 구할 수 있으
면 더 좋다

17. 집중도
●추정치는 이상적인 맨데이 기준이므로, 집
중도를 곱해서 현실적인 속도를 계산한다.
●이번 스프린트의 추정 속도:
○(가능한 맨데이) x (집중도) = (추정속도)

18. 집중도 구해서 속도 계산하기
●최근 스프린트의 초기추정치와 실제 속도
를 가지고 구한다
●최근 스프린트의 집중도 구하기
○18스토리점수 / 45맨데이 = 40%
●이번 스프린트의 추정속도
○50맨데이 x 40% = 20스토리점수

19. 거의 완료한 스토리는?
●완료한 것으로 인정하지 않는다
●정말 완전히 출시 가능한 형태로 완료한
것만 인정한다는 사실을 강조!

20. 인덱스카드
●스프린트 계획회의를 하면서, 엑셀을 보면
서 하기보다는, 인덱스카드를 벽에 붙여가
면서 하면 좋다
백로그 아이템 #12
아이템 구매
웹인증 사용.
어쩌구 저쩌구
주목
빈 아이템 가방 확인. 아이템 구매.
코인 삭감 확인. 게임에서 아이템 사
용. 어쩌구 저쩌구
데모 방법
30
중요도
추정치

21. 인덱스카드가 좋은 점
●서서 걸어다녀야 하니 졸지 않는다
●모두가 더 적극적으로 참여하는 느낌
●여러 스토리를 동시에 수정
●우선순위 수정이 쉽다
●그대로 가져다가 작업 현황판에 사용가능

22. 플래닝 포커
●추정 포인트가 적힌 카드로 추정하기
○0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, ?, coffee
●동시에 보이지 않게 내려놓는다
●모두의 의견이 수렴될때까지 토론
●대략적인 추측값이다
○왜 18, 21이 아니라 20인지 논의할 필요 없음

23. 스토리를 작업 단위로 나누기
●스토리란?
○제품책임자가 관심을 갖는, 전달 가능한 것
●작업이란?
○전달할 수 없는 것
○제품책임자가 관심을 갖지 않는 것
●인덱스 카드로 하면 효율적이다

24. 인덱스카드를 사용한 작업나누기
입장
아이템
구매
이런 저런 성능
테스트
더 중요 덜 중요
인증
커넥터
DB
커넥터
이런
실패하는
테스트
작성
저런
이런
실패하는
테스트
작성
저런
아까 그 스토리
(백로그아이템)
인덱스카드
작업들

25. 작업으로 나누기 주의점
●스크럼을 새로 시작하는 팀을 이것을 폭포
수 모델과 같은 접근법이라 느끼지만
●사전에 작업을 나누는 것이 용이
●추가적으로 할일이 드러나서 좀 더 정확한
시간추정이 가능
●일일스크럼 회의를 효과적으로
●잘못 나누더라도 위의 장점은 유효

26. 기술스토리(비기능적 항목)
●일반적인 스토리처럼 제품 책임자가 우선
순위 관리하기 어려움
●1. 기술스토리를 피하려고 노력한다
●2. 다른스토리의 하위작업으로 놓는다
●3. 별도의 목록으로 모아 관리

27. 5.스프린트를 알립시다
●위키에 스프린트 정보 페이지를 만든다
○스프린트 목표 : 어쩌구 저쩌구
○스프린트 백로그
■ 입장(5), 아이템구매(10), 이런(8), 저런(3)
■ 추정속도 : 26
○일정
■ 스프린트 기간 : 2009-07-01 ~ 2009-07-21
■ 일일스크럼 : 9:30~9:45, 팀방
■ 스프린트 데모 : 2009-07-21, 13:00, 카페테리아
○팀
■ 개똥이, 새똥이(스크럼마스터), 이춘복(50%), 황새

28. 그리고
●위키주소와 함께 회사 전체에 스팸 메일을
보낸다
●정보페이지를 인쇄해서 팀방 바깥에 붙여
놓는다
●데모 전에 다시 메일을 보내 상기시킨다

29. 6.스프린트 백로그를 만듭시다
할 일 진행 중 완료^^ 스프린트목표: 알파 버전출시
입장
아이템
구매
이런
소멸차트
계획에 없던 항목 다음
저런저런
저런

30. 첫번째 일일스크럼을 마치고
할 일 진행 중 완료^^ 스프린트목표: 알파 버전출시
입장
아이템
구매
이런
소멸차트
계획에 없던 항목 다음
저런저런
저런

31. 며칠이 지나고
할 일 진행 중 완료^^ 스프린트목표: 알파 버전출시
입장
아이템
구매
이런
소멸차트
계획에 없던 항목 다음
저런저런
저런

32. 7.일일스크럼을 진행합시다
●15분이 넘지 않도록 서서 진행
●작업 현황판 업데이트
○한사람씩 어제한일과 오늘할일 이야기하며,
○포스트잇을 옮긴다
○필요하면 새로운 추정치를 포스트잇에 적기
●시간추정치를 모두 합해 소멸차트에 새 점
을 찍는다

33. 8.스프린트데모를 합시다
●스프린트가 데모로 끝나야 하는 이유
○팀은 성취에 대해 인정받고 기분이 좋아진다
○다른 사람들은 팀이 무얼하는지 알게된다
○피드백을 이끌어낸다
○여러팀이 교류하며 토론할 수 있는 사회적 이
벤트이며, 그렇게 운영되어야 한다
○일을 끝내고 릴리스하도록 유도

34. 9.스프린트회고를 합시다
●1~3시간
●참석자: 제품책임자, 스크럼마스터, 팀
●오랫동안 토론에 방해받지 않을 장소

35. 그리고
●스크럼마스터가 스프린트 백로그를 보여
주고, 어떤 중요한 사건과 결정사항등이
있었는지 요약
●한명씩 돌아가며 이야기
○전원 방해받지 않고 말할 기회를 갖는다
○좋았던 것
○잘 할 수 있었던 것
○다음 스프린트에서 해보고 싶었던 것

36. 또 그리고
●추정속도와 실제속도를 비교
○차이가 크다면 왜 그런지 분석해본다
●스크럼마스터가 개선을 위한 구체적인 제
안들을 요약

37. 화이트보드 사용하기
만족 반성 개선안

38. 개선안 중에 투표하기
만족 반성 개선안
한 사람당 자석 3개로
투표

39. 그러나
●바꾸는 것만 능사는 아니다
●단지 문제를 명확하게 식별하는 것만으로
도 다음 스프린트에서 문제가 저절로 해결
되기에 충분
●변화에는 비용이 따르기 마련

40. 10.쉽시다
●전력질주(스프린트) 사이엔 휴식이 필요
●스프린트 회고와 다음 스프린트 계획회의
를 같은 날 하지 않는다
●이왕이면 토/일요일을 사이에 두면 좋다
●랩데이(lab day)를 하루 둬도 좋다