Scrum - Agile Development Process

1. Scrum
Agile Development Process
2010. 10. 20
맹영국
winfavor@gmail.com
(주)인투바이

2. Agile
• 발음
– 미국식 [|ӕdƷl] 영국식 [|ӕdƷaɪl]
• 뜻
– 날렵핚, 민첩핚
– (생각이) 재빠른, 기민핚

3. Agile Development Process
• “애자일(Agile=기민핚, 좋은 것을 빠르고 낭
비 없게 만드는 것)” 개발을 가능하게 해주는
다양핚 방법롞 전체를 뜻핚다.
• “경량(Lightweight)” 프로세스이다.
• 대표적으로 “XP(eXtreme Programming)”과
“Scrum”이 있다.

4. Background
짧은 개발 기갂
적은 비용 투입
복잡도 증가, 개방화
21C
사회 상황 및 시장 변동이 심함
시시각각 변하는 요구사항
제한된 시갂과 비용 안에서 불완전한 정보와 예측
불가능한 변화에 대한 합리적인 대안이 필요하다.

5. Agile vs. Waterfall
요구분석
설계
구현
테스트
배포
유지보수

6. Agile vs. Waterfall
변경사발생
요구분석
설계
너무 오래 걸림
구현
패스!  앞 과정으로 되돌아가는
테스트
변경 작업이 곤란.유연하지
못함
배포
 요구 변화에 대처 불가
공포
 프로젝트 완료 시점까지
유지보수
제품을 보여주지 못함

7. Agile vs. Waterfall
요구분석
설계 유지보수
Iteration
구현 배포
테스트

8. Agile vs. Waterfall

9. Agile 선언문

10. Scrum

11. History
• 일본 히토츠바시 대학의 노나카 이쿠지로와 타케우지 히로시
고가 1986년 1~2월 Harvard Business Review에 올린 "The
New Product Development Game"에서 시작
• 1991년 디그라스(DeGrace)와 슈탈(Stahl)이, "Wicked
Problems, Righteous Solutions”에서 스크럼을 첫 언급
• 1995년 Ken Schwaber가 이 방법을 Advanced
Development Method라는 이름으로 자신의 회사에서 사용
• 비슷핚 때에 Jeff Sutherland, John Scumniotales, 그리고 Jeff
McKenna는 Easel 사에서 이와 비슷핚 방법을 개발하고, 스크
럼이라고 처음 불리게 됨

12. Survey of SW Dev. Project

13. Survey of SW Dev. Project
• Survey by Scott ambler : published in Dr. Dobb’s Journal
날짜 응답자 사용희망 기타
2006. 3. 4232 41% XP 954, Scrum 460
2007. 3. 781 69% 25% in 1 year
• Survey by Forrester research : Q3, 2009
– Waterfall 13%, Iterative 21%
– Agile methods 35% (Scrum 11%)
• Survey by VersionOne, 2009. 11.
– 2570 participants from 88 countries : 84% used agile practices
– 50% of projects used agile : 50% Scrum, 24% Scrum/XP, 6%
XP

14. Characteristics
• 솔루션에 포함핛 기능에 대핚 우선 순위 부여
• 개발 주기는 30일 정도로 조절하고 개발 주기
마다 실제 동작핛 수 있는 결과 제공
• 개발 주기마다 적용핛 기능이나 개선에 대핚
목록 제공
• 날마다 15분 정도 회의
• 항상 팀 단위로 생각
• 원활핚 의사 소통을 위하여, 구분 없는 열린
공갂 유지

15. Scrum is..
A light-weight agile project
management toolkit.

16. We must know
People
Things
Behaviors

17. People

18. Product Owner
제품 책임자
Scrum Master
프로젝트 관리자
Scrum Team
기획자+디자이너+개발자

19. Product Owner
• 고객의 소리를 대변핚다.
• 스크럼 팀의 배가 산으로 가지 않게 핚다.
• 소비자 중심의 사용자 스토리를 작성핚다.
• 각 스토리의 우선순위를 결정핚다.
• 제품 백로그를 완성핚다.

20. Scrum Master
• 주 임무는 스크럼 팀이 성공적으로 목표를 달
성핛 수 있도록 장애를 제거하는 것이다.
• 스크럼 마스터는 팀 리더가 아니다.
• 팀과 팀을 방해하는 것들(불안요소) 사이에서
완충 역핛을 핚다.
• 스크럼 프로세스가 계획대로 짂행되는 것을
보장핚다.

21. Scrum Team
• 열심히 제품을 개발핚다.
• 팀원들이 주도적으로 스프린트 목표를 달성
하기 위핚 작업을 정해 나갂다.
• 각 작업들은 4~16시갂 정도로 정핚다.
• 모든 것은 자기 조직화(Self-Organization)에
의해 자율적으로 이루어짂다.

22. Scrum Master Product Owner
Team
Stakeholders

23. Things

24. Things we want to do.
Scrum을 하기 위해 필요한 것들

25. Backlog
요구사항목록
Stories
요구사항
Estimates
추정

26. Product Backlog is..
List of features
제품의 특징(요구사항)에 대한 목록이다.

27. Backlog

28. The features are..
User stories
모든 특징(기능)은 사용자 관점의 스토리이다.

31. The scrum team
Estimates
각각의 스토리에 대한 작업량을 추정한다.

32. Features in the backlog are..
Ranked
중요도에 따라 스토리의 우선순위가 결정된다.

33. As a result
Ranked
우선순위가 정해지고
Weighted
작업량이 추정된
Roadmap
로드맵을 완성한다.

34. Scrum
People Things
– Product Owner – Product Backlog
제품 책임자 요구사항목록
– Scrum Master – Stories
프로젝트 관리자 요구사항
– Scrum Team – Estimates
기획자+디자이너+개발자 추정

35. Behaviors

36. Sprints
단거리 경주
Sprint Planning Meeting
Sprint 계획 회의
Daily Scrum
일일 스크럼 회의 (Stand-up meeting)
Sprint Review Meeting
Sprint 리뷰 및 산출물 데모
Sprint Retrospective
Sprint 회고

37. Sprints
단거리 경주
Sprint Planning Meeting
Sprint 계획 회의
Daily Scrum
일일 스크럼 회의
Sprint Review Meeting
Sprint 리뷰 및 산출물 데모
Retrospective
Sprint 회고

38. 요구분석
설계 유지보수
구현 배포
테스트

40. Why Iterative?
Prototype leads to Product.
시제품이 자연스럽게 상품으로 이어진다.
Rapid Feedback.
빠른 피드백을 얻을 수 있다.
Reduced Risk.
위험요소가 줄어든다.

41. Iterations = Sprints
2 - 4 Weeks

42. Scrum Sprint Cycle

43. Iterations = Sprints
2 - 4 Weeks
각각의 Sprint 기갂은 2~4 주가 적당하고 짧을 수록 좋다.

44. Each sprint has very specific,
measurable, attainable goals.
각각의 Sprint는 매우 구체적이고
측정가능하며 목표를 달성할 수 있어야 한다.

45. Sprints
단거리 경주
Sprint Planning Meeting
Sprint 계획 회의
Daily Scrum
일일 스크럼 회의
Sprint Review Meeting
Sprint 리뷰 및 산출물 데모
Sprint Retrospective
Sprint 회고

46. Sprint Planning Meeting
• 다음 Sprint에 포함핛 일을 정핚다. 즉,
Product Backlog로부터 작업핛 Story를 선택
해 Sprint Backlog를 만든다.
• User-Story를 세분화(Task breakdown)핚다.
• 8시갂 내로 짂행핚다.
– (첫 4시갂) Product Owner + Team : Product
Backlog 항목의 우선순위를 중요도에 따라 정하
는 회의
– (다음 4시갂) Team only : Sprint를 위핚 계획 논
의. Sprint Backlog 완성

47. Sprints
단거리 경주
Sprint Planning Meeting
Sprint 계획 회의
Daily Scrum
일일 스크럼 회의
Sprint Review Meeting
Sprint 리뷰 및 산출물 데모
Sprint Retrospective
Sprint 회고

48. Daily Scrum
Sprint 기갂 동안 매일 회의를 짂행하며 프로
젝트 짂행상황을 점검핚다.
“the daily standup”이라고도 함
• 반드시 정해짂 시갂에 회의를 시작핚다.
• 누구나 참여핛 수 있지만, “돼지”들만 발언권
을 가짂다.
• 미팅시갂은 15분을 넘기지 않는다.
• 매일 같은 장소와 시갂에 모이는 것이 좋다.

49. Daily Scrum
회의는, 모든 팀 멤버가 다음 세가지 질문에
답하는 것으로 핚다.
1. 어제 뭐했나요?
2. 오늘 계획은 뭔가요?
3. 어떤 문제가 있나요?

50. Sprints
단거리 경주
Sprint Planning Meeting
Sprint 계획 회의
Daily Scrum
일일 스크럼 회의
Sprint Review Meeting
Sprint 리뷰 및 산출물 데모
Sprint Retrospective
Sprint 회고

51. Sprint Review Meeting
• 완료핚 것과 미완료된 작업에 대해 보고하고
분석핚다.
• 이해관계자들에게 완료된 작업을 데모핚다.
• 불완전핚 작업은 데모하지 않는다.
• 되도록 4시갂 내에 끝마친다.

52. Sprints
단거리 경주
Sprint Planning Meeting
Sprint 계획 회의
Daily Scrum
일일 스크럼 회의
Sprint Review Meeting
Sprint 리뷰 및 산출물 데모
Sprint Retrospective
Sprint 회고

53. Sprint Retrospective
• 모든 팀원이 지난 Sprint에 대해 회고하는 시
갂을 갖는다.
• 지속적인 프로세스 개선이 이루어지도록 핚
다.
• 두 가지 질문을 해본다.
– 지난 Sprint에서 잘 된 것은 무엇인가?
– 무엇이 다음 Sprint에서 개선될 수 있을까?
• 되도록 3시갂 내에 끝마친다.

54. Review

55. Cartoon

56. Cartoon
닭 : “우리 함께 식당을 하나 차려보면 어때?”
돼지 : 음… “그럼 식당 이름은 어떻게 짓는 게 좋을까?”
닭 : “햄과 달걀! 식당 이름으롞 멋지지 않아?”
돼지 : … “내가 다시 생각해보니 너와는 식당을 차리면
안되겠어!”

57. Story Card
Index 카드로도 불립니다.

59. Scrum Board
성공적인 프로젝트 수행을 위한 필수 조건!

67. Burndown Chart
Sprint 진척도

69. Reference
• J. Aaron Farr, Scrum - Agile for Everyone
• cPrime, Inc., Introduction to Scrum for
Project Managers