Download - Scrum - Agile Development Process

Scrum

Agile Development Process

2010. 10. 20

맹영국[email protected]

(주)인투바이

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 선언문

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 회고



Daily Scrum일일 스크럼 회의


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는 매우 구체적이고

측정가능하며 목표를 달성할 수 있어야 한다.

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 완성

Daily Scrum

Sprint 기갂 동안 매일 회의를 짂행하며 프로젝트 짂행상황을 점검핚다.

“the daily standup”이라고도 함

• 반드시 정해짂 시갂에 회의를 시작핚다.

• 누구나 참여핛 수 있지만, “돼지”들만 발언권을 가짂다.

• 미팅시갂은 15분을 넘기지 않는다.

• 매일 같은 장소와 시갂에 모이는 것이 좋다.

Daily Scrum

회의는, 모든 팀 멤버가 다음 세가지 질문에답하는 것으로 핚다.

1. 어제 뭐했나요?

2. 오늘 계획은 뭔가요?

3. 어떤 문제가 있나요?

Sprint Review Meeting

• 완료핚 것과 미완료된 작업에 대해 보고하고분석핚다.

• 이해관계자들에게 완료된 작업을 데모핚다.

• 불완전핚 작업은 데모하지 않는다.

• 되도록 4시갂 내에 끝마친다.

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

Download - Scrum - Agile Development Process

Top Related