Agile
• 발음
– 미국식 [|ӕdƷl] 영국식 [|ӕdƷaɪl]
• 뜻
– 날렵핚, 민첩핚
– (생각이) 재빠른, 기민핚
Agile Development Process
• “애자일(Agile=기민핚, 좋은 것을 빠르고 낭비 없게 만드는 것)” 개발을 가능하게 해주는다양핚 방법롞 전체를 뜻핚다.
• “경량(Lightweight)” 프로세스이다.
• 대표적으로 “XP(eXtreme Programming)”과“Scrum”이 있다.
Background
짧은 개발 기갂
적은 비용 투입
복잡도 증가, 개방화
사회 상황 및 시장 변동이 심함
시시각각 변하는 요구사항
제한된 시갂과 비용 안에서 불완전한 정보와 예측불가능한 변화에 대한 합리적인 대안이 필요하다.
21C
Agile vs. Waterfall
요구분석
설계
구현
테스트
배포
유지보수
Agile vs. Waterfall
앞 과정으로 되돌아가는변경 작업이 곤란.유연하지못함
요구 변화에 대처 불가
프로젝트 완료 시점까지제품을 보여주지 못함
요구분석
설계
구현
테스트
배포
유지보수
변경사발생
너무 오래 걸림
패스!
공포
Agile vs. Waterfall
요구분석
설계
구현 배포
유지보수
테스트
Iteration
Agile vs. Waterfall
Agile 선언문
Scrum
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 사에서 이와 비슷핚 방법을 개발하고, 스크럼이라고 처음 불리게 됨
Survey of SW Dev. Project
Survey of SW Dev. Project
• Survey by Scott ambler : published in Dr. Dobb’s Journal
• 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
날짜 응답자 사용희망 기타
2006. 3. 4232 41% XP 954, Scrum 460
2007. 3. 781 69% 25% in 1 year
Characteristics
• 솔루션에 포함핛 기능에 대핚 우선 순위 부여
• 개발 주기는 30일 정도로 조절하고 개발 주기마다 실제 동작핛 수 있는 결과 제공
• 개발 주기마다 적용핛 기능이나 개선에 대핚목록 제공
• 날마다 15분 정도 회의
• 항상 팀 단위로 생각
• 원활핚 의사 소통을 위하여, 구분 없는 열린공갂 유지
A light-weight agile project
management toolkit.
Scrum is..
People
Things
Behaviors
We must know
People
Product Owner제품 책임자
Scrum Master프로젝트 관리자
Scrum Team기획자+디자이너+개발자
• 고객의 소리를 대변핚다.
• 스크럼 팀의 배가 산으로 가지 않게 핚다.
• 소비자 중심의 사용자 스토리를 작성핚다.
• 각 스토리의 우선순위를 결정핚다.
• 제품 백로그를 완성핚다.
Product Owner
• 주 임무는 스크럼 팀이 성공적으로 목표를 달성핛 수 있도록 장애를 제거하는 것이다.
• 스크럼 마스터는 팀 리더가 아니다.
• 팀과 팀을 방해하는 것들(불안요소) 사이에서완충 역핛을 핚다.
• 스크럼 프로세스가 계획대로 짂행되는 것을보장핚다.
Scrum Master
• 열심히 제품을 개발핚다.
• 팀원들이 주도적으로 스프린트 목표를 달성하기 위핚 작업을 정해 나갂다.
• 각 작업들은 4~16시갂 정도로 정핚다.
• 모든 것은 자기 조직화(Self-Organization)에의해 자율적으로 이루어짂다.
Scrum Team
Team
Scrum Master Product Owner
Stakeholders
Things
Things we want to do.Scrum을 하기 위해 필요한 것들
Backlog요구사항목록
Stories요구사항
Estimates추정
Product Backlog is..
List of features제품의 특징(요구사항)에 대한 목록이다.
Backlog
The features are..
User stories모든 특징(기능)은 사용자 관점의 스토리이다.
The scrum team
Estimates각각의 스토리에 대한 작업량을 추정한다.
Features in the backlog are..
Ranked중요도에 따라 스토리의 우선순위가 결정된다.
As a result
Ranked우선순위가 정해지고
Weighted작업량이 추정된
Roadmap로드맵을 완성한다.
Scrum
People– Product Owner
제품 책임자
– Scrum Master프로젝트 관리자
– Scrum Team기획자+디자이너+개발자
Things– Product Backlog
요구사항목록
– Stories요구사항
– Estimates추정
Behaviors
Sprints단거리 경주
Sprint Planning MeetingSprint 계획 회의
Daily Scrum일일 스크럼 회의 (Stand-up meeting)
Sprint Review MeetingSprint 리뷰 및 산출물 데모
Sprint RetrospectiveSprint 회고
Sprints단거리 경주
Sprint Planning MeetingSprint 계획 회의
Daily Scrum일일 스크럼 회의
Sprint Review MeetingSprint 리뷰 및 산출물 데모
RetrospectiveSprint 회고
요구분석
설계
구현 배포
유지보수
테스트
Why Iterative?
Prototype leads to Product.시제품이 자연스럽게 상품으로 이어진다.
Rapid Feedback.빠른 피드백을 얻을 수 있다.
Reduced Risk.위험요소가 줄어든다.
Iterations = Sprints
2 - 4 Weeks
Scrum Sprint Cycle
Iterations = Sprints
2 - 4 Weeks
각각의 Sprint 기갂은 2~4 주가 적당하고 짧을 수록 좋다.
Each sprint has very specific, measurable, attainable goals.
각각의 Sprint는 매우 구체적이고
측정가능하며 목표를 달성할 수 있어야 한다.
Sprints단거리 경주
Sprint Planning MeetingSprint 계획 회의
Daily Scrum일일 스크럼 회의
Sprint Review MeetingSprint 리뷰 및 산출물 데모
Sprint RetrospectiveSprint 회고
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 완성
Sprints단거리 경주
Sprint Planning MeetingSprint 계획 회의
Daily Scrum일일 스크럼 회의
Sprint Review MeetingSprint 리뷰 및 산출물 데모
Sprint RetrospectiveSprint 회고
Daily Scrum
Sprint 기갂 동안 매일 회의를 짂행하며 프로젝트 짂행상황을 점검핚다.
“the daily standup”이라고도 함
• 반드시 정해짂 시갂에 회의를 시작핚다.
• 누구나 참여핛 수 있지만, “돼지”들만 발언권을 가짂다.
• 미팅시갂은 15분을 넘기지 않는다.
• 매일 같은 장소와 시갂에 모이는 것이 좋다.
Daily Scrum
회의는, 모든 팀 멤버가 다음 세가지 질문에답하는 것으로 핚다.
1. 어제 뭐했나요?
2. 오늘 계획은 뭔가요?
3. 어떤 문제가 있나요?
Sprints단거리 경주
Sprint Planning MeetingSprint 계획 회의
Daily Scrum일일 스크럼 회의
Sprint Review MeetingSprint 리뷰 및 산출물 데모
Sprint RetrospectiveSprint 회고
Sprint Review Meeting
• 완료핚 것과 미완료된 작업에 대해 보고하고분석핚다.
• 이해관계자들에게 완료된 작업을 데모핚다.
• 불완전핚 작업은 데모하지 않는다.
• 되도록 4시갂 내에 끝마친다.
Sprints단거리 경주
Sprint Planning MeetingSprint 계획 회의
Daily Scrum일일 스크럼 회의
Sprint Review MeetingSprint 리뷰 및 산출물 데모
Sprint RetrospectiveSprint 회고
Sprint Retrospective
• 모든 팀원이 지난 Sprint에 대해 회고하는 시갂을 갖는다.
• 지속적인 프로세스 개선이 이루어지도록 핚다.
• 두 가지 질문을 해본다.
– 지난 Sprint에서 잘 된 것은 무엇인가?
– 무엇이 다음 Sprint에서 개선될 수 있을까?
• 되도록 3시갂 내에 끝마친다.
Review
Cartoon
Cartoon
닭 : “우리 함께 식당을 하나 차려보면 어때?”
돼지 : 음… “그럼 식당 이름은 어떻게 짓는 게 좋을까?”
닭 : “햄과 달걀! 식당 이름으롞 멋지지 않아?”
돼지 : … “내가 다시 생각해보니 너와는 식당을 차리면안되겠어!”
Story CardIndex 카드로도 불립니다.
Scrum Board성공적인 프로젝트 수행을 위한 필수 조건!
Burndown ChartSprint 진척도
Reference
• J. Aaron Farr, Scrum - Agile for Everyone
• cPrime, Inc., Introduction to Scrum for Project Managers