User Stories Applied

2010-01-26http://xguru.net

User Stories Applied

Presentation by 권정혁

for agile software development

Book by Mike Cohn

Based on Mike‟s SDWest 2006 Conference Presentation

Twitter @xguru

User Stories for Agile Requirements 2

What problem do stories address ?

- 소프트웨어 요구사항은 의사소통(communication)의 문제다.

- 소프트웨어를 사용하거나 팔기를 원하는 사람은 그것을 만드는 사람들과 의사소통을 해야 한다.


Balance is Critical !

어느 한쪽이 의사소통에서 우위를 차지 한다면(dominates),

프로젝트는 실패(business loses)한다.

비즈니스쪽 사람들이 우위를 차지한다면…

그들은 기능과 마감시한을 동시에 요구할것이다. 개발자들이 요구사항을 이해했는지, 이 두가지 목표를 달성할수 있는지는 고려하지 않은채로..

개발자들이 우위를 차지한다면…

비즈니스 언어대신 기술적인 용어들이 난무하게 될것이고, 개발자들은 정작 필요한것이 무엇인지 알수 없게 될것이다.(고객으로 부터들을 기회를 잃어 버린다.)


Resource allocation

- 우리에게 필요한것은 함께 일하는 방법이다. 이를 통해 감정적으로 흐르거나 정치적일수 있는 자원할당의 문제를 공동의 문제로 공유하는것이다.

- 자원 할당 문제를 어느 한쪽에만 떠맡기는 프로젝트는 실패한다.


Responsibility for resource allocation

1. 개발자에게 짐을 씌운다면...

A. 추가기능구현을 위해 품질은 뒤로 미룰지도 모른다.

B. 기능을 일부만 구현할수도 있다.

C. 고객과 사용자들이 참여해서 결정해야할 사항을 독단적으로 처리하는경우가 발생할지도 모른다.

2. 고객과 사용자에게 자원 할당 문제의 짐이 맡겨진다면…

A. 프로젝트의 초기에 지루한 논의만 계속하다가 기능들을 점차 제거하게 될것이다.

B. 결국 완성된 소프트웨어에는 이렇게 줄어든 기능목록 보다도 훨씬 적은 기능만 구현되어 있을것이다.


Imperfect Schedules

1. 소프트웨어 스케쥴을 완벽하게 예측하는 것은 불가능하다.

A. 사용자들은 소프트웨어 초기버전을 보고 새로운 아이디어를 말한다.

B. 계속 생각(요구사항)이 변한다.

C. SW의 무형성 때문에 프로젝트가 얼마나 걸릴지 추정하기가 어렵다.

2. 스케줄을 정확하게 예측할수 없다면,

정확히 어떤 제품이 완성(Deliver)될지도 말할수 없다.


So what do we do ?

당장 손에 잡히는 정보를가지고 결정을 내려야 한다.

프로젝트 착수시점에 모든것을 포괄하는 결정을 하기

보다

..그리고 자주 그렇게해야한다.

…프로젝트 전 기간에 걸쳐의사를 결정해야 한다.

사용자 스토리는이를 위한것이다.

가능한 자주 , 신속하게필요한 정보를 가져다 주는

프로세스가 필요


Steps

스토리란 무엇인가 ?

스토리 작성하기

사용자 역할 모델링

스토리 수집하기

Do & Don‟t

사용자 스토리 추정

릴리즈 / 이터레이션 계획

왜 사용자 스토리인가 ?


Ron Jeffries‟ Three Cs

Card

Conversation

Confirmation

- 스토리는 전통적으로 인덱스카드에 작성 된다.

- 고객(제품 소유자)에 의해 작성된다.

- 카드에는 추정치 또는 메모 같은것도 첨부될수 있다.

- 스토리에 들어있는 세부사항은 사용자와의 대화를통해 도출된다.

- 테스트는 스토리가 정확히 개발(코딩)되었는지를 확인한다.

„카드’ 는 스토리의 본문을 담고 있지만, 세부사항은 ‘대화’를 통해 결정되며구현을 ‘확인’ 하기 위한 테스트를 포함한다.


Sample User Stories : BigMoneyJobs

사용자는 자신의 이력서를 웹 사이트에 게시할수 있다

사용자는 채용 정보를 검색할수 있다.

기업은 채용 정보를 게시할수 있다.

사용자는 자신의 이력서를 열람할사람을 제한할 수 있다.

* 사용자 스토리는 사용자에게 가치를 평가받을수 있도록 기능을 표현

소프트웨어는 C++ 로 작성한다.프로그램은 커넥션풀을 통해 데이터베이스에 연결한다.


Where are the Details ?

스토리는 한두 명의 개발자가 반나절~2주일 안에 구현하고 테스트 할수 있는 정도 크기가 적당

사용자는 자신의 이력서를 웹 사이트에 게시할수 있다

EPIC

사용자는 위치,급여 수준,직업 명, 회사 명, 게시날짜 등의 속성값으로 채용정보를 검색할수 있다.

사용자는 검색 조건과 일치하는 채용 정보를 볼 수있다.

사용자는 채용 정보를 게시한 기업에 대한 세부 정보를 볼 수 있다.

스토리는 계약과 같은 구속 이 아니라, 대화하기 위한 수단이다


Details as conditions of satisfaction

사용자는 검색 조건과 일치하는 채용 정보를 볼 수 있다.

주) 마르코는 설명,급여,위치 정보를 보여 주어야 한다고 함.

채용 정보를 입력하지 않고 시도해 본다.

채용 정보를 아주 길게 넣어 본다.

급여 정보가 빠진 경우를 확인해 본다.

여섯 자리 급여로 시도해 본다.

좀더 자세한 충족 조건이 스토리에 추가될수 있다. ( 주석 / 테스트 )


Steps





Do & Don‟t





What makes a good story?

Independent

Negotiable

Valuable

Estimatable

Small

Testable



Independent

Negotiable

Valuable

Estimatable

Small

Testable

기업은 채용공고를 게시할때 비자카드로 결제할수 있다.

가능하면 스토리 간에 의존성을 배제해야 한다.

기업은 채용공고를 게시할때 마스터카드로 결제할수 있다.

기업은 채용공고를 게시할때 아메리칸익스프레스카드로 결제할수 있다.

첫 카드는 3일다른카드는 1일

의존성은 추정을 어렵게 한다.

의존성이 있는 스토리들을 합쳐 좀더 큰 하나의 독립적인 스토리로 만든다 기업은 채용공고를 게시할때 신용카드로 결제할수 있다(5일)

스토리들을 다른방식으로 분리한다. 고객은 한종류의 신용카드로 결제할수 있다. 고객이 결제할 수 있는 신용카드는 두 종류가 더 있다.

각각의 스토리에 작업추정치를 두가지로 부여한다.



Independent

Negotiable

Valuable

Estimatable

Small

Testable

협상가능 : 스토리는 계약서/SRS처럼 꼭 구현해야 한다는 기록이 아니다.

대화를 이끌기 위한 단서지, 그 자체로 완성된 상세한 요구사항이 아니다.너무 상세하게 적는다면 그것은 완성된것으로 추측하게되어 대화의 단절을 가져온다.

기업은 채용공고를 게시할때 신용카드로 결제할수 있다.

주) 비자,마스터,아멕스카드를 지원한다. 디스커버는 검토


주) 비자,마스터,아멕스카드를 지원한다. 디스커버는 검토100달러 이상 구매시 카드 뒷면의 ID 번호를 확인한다. 시스템은 카드번호의첫 두자리로 카드의 종류를 알수 있다. 시스템은 다음 사용에 대비하여 카드번호를 저장해 두어야 한다. 카드의 유효기간 연/월을 수집한다.


주) 디스커버 카드도 지원해야 하나 ?내 주) 카드 종류를 고르는 항목은 필요없다(카드 번호 첫2자리로 알수있음)

비자,마스타카드,아멕스 카드 테스트 (통과)다이너스 클럽 테스트(실패)정상/비정상 카드 ID 테스트, 분실카드 ID 테스트.유효 기간 만료된 카드 테스트100달러 이상/이하 테스트



Independent

Negotiable

Valuable

Estimatable

Small

Testable

사용자와 고객 혹은 구매자에게 가치가 있어야 한다.

사용자

구매자

직책과 연봉에 따라 채용정보를 검색할수 있다.

ISO 9001 감사에 적합한 문서를 작성한다.CMM 레벨 3에 부합하게 소프트웨어를 개발한다.

관리자 프로그램 설정 정보를 중앙 저장위치에서 읽어와야 한다.

모든 데이터베이스 연결은 커넥션 풀을 통해 이루어 져야 한다.

모든 에러 처리 및 로그 생성은 공통 클래스들을 통해 이루어 져야 한다.

사용자 라이센스 5개로 50명까지 데이터베이스에 연결하여 사용할수 있어야 한다.

모든 에러는 사용자에게 보여야 하며, 일관된형태의 로그로 기록되어야 한다.



Independent

Negotiable

Valuable

Estimatable

Small

Testable

각 스토리의 크기 혹은 작업 소요 시간을 추정(추측)할수 있어야 한다.

해당분야의 지식(Domain Knowledge)

이 부족

기술적인 지식이 부족

스토리가 너무 크다

작성한 고객과 직접 의논

스파이크(Spike)를 수행

스파이크와 실제구현의 두개 스토리로분리 (서로 다른 이터레이션에 배치)

좀더 작은 단위로 나누거나큰 추정치를 부여하고 일단 마감



Independent

Negotiable

Valuable

Estimatable

Small

Testable

너무 크거나 너무 작으면 사용하기 어렵다

Compound Story - 복합적인 스토리

Complex Story - 복잡한 스토리

사용자는 자신의 이력서를게시할수 있다.

사용자는 학력/업무경력/희망급여/단체활동/향후 목표를 포함하는이력서를 만들수 있다.

사용자는 이력서를 활성화/비활성화 할수 있다.

사용자는 이력서를 여러 개 만들수 있다.

사용자는 이력서를 수정/삭제할 수 있다.

문제 조사 스토리와 기능개발 스토리로 분리

기업은 채용 공고를 게시할 때신용카드로 결제할 수 있다.

웹에서 신용카드를 처리하는 방법을 조사한다. (Spike)

( 개발자 한두명이 최대허용시간을 정하고 연구/조사 해본다 )

사용자는 신용카드로 결제 할수 있다.



Independent

Negotiable

Valuable

Estimatable

Small

Testable

스토리는 테스트 가능하도록 작성해야 한다.

테스트는 스토리가 고객의 요구를 만족시키게 개발되었다는것을 확인할수 있게 한다.

테스트는 자동화가 가능하도록 작성해야 한다.

사용자가 소프트웨어를 쉽게 사용할 수 있어야 한다.

어떤 화면도 사용자를 오래 기다리게 해선 안된다.

신규 사용자가 별도의 교육없이 작업을 완료할 수 있어야 한다.

새 화면은 95%의 경우에 2초안에나타나야 한다.


Steps





Do & Don‟t





The User

- 많은 프로젝트들이 한종류의 사용자만 있다고 가정한다.

- 모든 스토리들을 한명의 사용자 관점에서 작성한다.

- 모든 사용자가 같은 목표(Goal)를 가지고 있다고 가정한다.

- 이에 따라 스토리를 빼먹는 경우가 발생한다.


BigMoneyJobs – Who‟s the User ?

Mario이제 막 졸업하고직장을 구하는 중

Carrie현재 직장이 있지만항상 더 나은 일자리를 염두에 두고 있음

Allan

마우이에서 윈드서핑만 즐길수 있다면 어떤일자리라도 상관없음

Scott

현재 일자리가 싫지는않지만 이직할때가 되었다고 생각중

Kindra6개월전 해고당하고 일자리가 없어이젠 어떤곳이라도취직하고 싶음

Chris인사팀 담당자로구인 공고를 게시하려고 함

PeterXX사 인사팀이력서 검토 담당자

Richard일자리와 인력을 모두 찾는 헤드헌터

매달 한번정도 접속하여 자신이 선택할수 있는 일자리들을 검색

마우이에 있는 일자리가 게시되면 자동으로 통보해주기 바람

하루에 4시간 이상 필요인력 충원을 위해 사이트 이용

역 할 사 용 자

구직자

최초 구직자

해고 피해자

지역 선호자

관찰자

채용 공고 게시자

이력서 조회자

Scott

Mario

Kindra

Allan

Carrie

Chris , Richard

Peter , Richard

* 또는 상근 , 비상근 , 게약직 , 인턴 등등으로도 구분


User Role Modeling Steps

1. 브레인 스토밍

2. 목록 초안 조직화

3. 역할 통합하기

4. 역할 다듬기

1. 고객과 한께 가능한 많은 개발자가 한방에 모두 모여 회의를 시작한다.

2. 각자 카드를 한 묶음 가지고 간다.

3. 각자 생각나는 사용자 역할을 적어 테이블/칠판에 놓는다.

- 평가는 하지 않는다.- 적고 내려놓으면서 단지 역할의 이름만을 말한다.- 새로 적을수 없을때까지 계속한다. ( 보통 약 15분이면 충분하다 )

역 할 사 용 자

구직자

최초 구직자

해고 피해자

지역 선호자

관찰자

채용 공고 게시자

이력서 조회자

Scott

Mario

Kindra

Allan

Carrie

Chris , Richard

Peter , Richard






4. 역할 다듬기

비슷하거나 중첩되는 역할끼리 모아 놓는다.* 중복되면 겹쳐 놓는다. 완전히 같다면 카드를 포개 놓는다.

대학 졸업자

최초 구직자

해고 피해자

지역 선호자

구직자

관찰자

채용공고 게시자 이력서 조회자

채용 담당자

관리자






4. 역할 다듬기

최초 구직자

해고 피해자

지역 선호자

구직자

내부 채용 담당자

외부 채용 담당자

채용 담당자 관리자

- 각 역할이 의미하는 바를 토론한다.- 역할을 합치거나 좀더 Generic 한 카드로 교체한다.- 프로젝트의 성공에 상관없다고 생각하는 카드는 버린다.






4. 역할 다듬기

- 역할 속성들을 정의한다. - 소프트웨어를 사용하는 빈도- 해당 분야에 관한 전문 지식 수준- 컴퓨터 및 소프트웨어에 대한 일반적인 숙련도- 개발 대상 소프트웨어에 대한 숙련도- 소프트웨어에 대한 일반적인 사용 목적

(어떤 사용자들은 편리함, 어떤사용자들은 다양한 기능선호)

사용자 역할 : 내부 채용 담당자

특별히 컴퓨터를 잘 사용하지는 못하지만, 웹을 이용하는 데 꽤 능숙하다. 자주는 아니지만 시스템의 세부 기능까지 모두 사용할 것이다. 채용공고를 작성하기 위해 다른 기업의 채용 공고를 참고할것이다. 사용하기 쉬워야 한다. 하지만 더욱 중요한 것은 그가 익힌 내용을 몇 달 뒤에 다시 떠올리기 쉬워야 한다는 것이다.

도움 1) 등장인물(Persona) 만들기

마리오는 SpeedyNetwoks라는하이엔드 네트워크 컴포넌트제조 회사의 인사 부서에 6년째근무하고 있는 채용 담당자다. 마리오는 자유 시간 근무제에따라 금요일에는 재택근무를 한다. 마리오는 컴퓨터를 아주 잘 사용하며 자신이 사용하는 프로그램에 대해서는 스스로 파워유저라고 생각한다. 마리오의 부인, 킴(Kim)은 스탠포드 대학에서 화학 분야 박사 과정을 곧 마칠 것이다. SpeedyNetworks가 지속적으로 성장하고 있기 때문에 마리오는 언제나 좋은 기술자들을 찾고 있다.

도움 2) 극단적 인물 만들기

- 양다리를 걸치는 아가씨의 PDA

- 눈이 잘 안보이는 어른들의 PDA

http://images.google.co.kr/imgres?imgurl=http://www.readingeagle.com/editor/archives/mario.jpg&imgrefurl=http://www.readingeagle.com/editor/archives/2005/03/&h=180&w=180&sz=11&hl=ko&start=8&tbnid=6dwmXbw6icP5eM:&tbnh=96&tbnw=96&prev=/images%3Fq%3Dmario%2Bamerican%2Bidol%26svnum%3D10%26hl%3Dko%26lr%3D%26newwindow%3D1%26rls%3DGGLJ,GGLJ:2006-10,GGLJ:en%26sa%3DN


Steps





Do & Don‟t





Techniques for Gathering Stories

1. 사용자 인터뷰

- 대화가 중요하다.

- 닫힌 질문을 하지마라 ( 예 / 아니오 식의 답변을 요구하는 )

2. 설문조사

- 가지고 있는 스토리에 대한 정보수집용으론 좋다

- 폭넓은 기존 사용자 층에 대한 조사

3. 관찰

- 실 사용자가 어떻게 SW를 사용하고 있는지 살펴본다.

4. 스토리 작성 워크숍

- 개발자 , 사용자 , 고객 그외 스토리 작성에 기여할 수 있는 사람들을 포함

- 질이 아니라 양에 기반한 가능한 많은 스토리를 만들어 낸다.

- 우선순위를 매기지 않는다.

- Template : “ As a <User Role> , I want <goal> so that <reason> “

“ 나는 <역할>로서 <비즈니스 가치> 를 위해 <기능>을 원한다.”


Steps





Do & Don‟t





Guidelines for Good Stories

1. 목적 스토리로 시작하라

2. 케이크 자르듯 나누어라

3. 닫힌 스토리를 작성하라

4. 제약사항 기록하기

5. 스토리의 크기는 시간축에 맞추어라

6. 되도록 사용자 인터페이스를 배제하라

7. 스토리에 사용자 역할을 포함하라

8. 한명의 사용자를 대상으로 작성하라

9. 능동태로 작성하라

10.고객이 작성하라

11.스토리카드에 번호를 부여하지 마라

12.목적을 잊지 말라

- 하나의 사용자 역할을 선택하여 시스템을 사용하는 주 목적을 식별

- 스토리를 나눌때 하나의 작업이 처음부터 끝까지 포함되도록 하라

- 기능별 분리의 폐해 ( 1.구직자는 입력양식에 값을 넣는다. 2.양식의 값이 DB 에 기록된다.)

- 의미 있는 목적을 달성하는 형태로 작성하여 사용자로 하여금 뭔가를 해냈다고 느끼게 하는것

- 예) 채용공고를 관리할수 있다 이력서를 삭제/검토 할수 있다. 마감일을 변경할수있다.

- 제약사항을 카드에 기록하여 벽에 붙여둠으로서 잊지 않도록 한다.

- 예) 시스템은 최대 50명까지 동시 사용자를 지원해야 한다. 모든 버전 윈도우를 지원해야한다.

- 바로 다음 이터레이션용 스토리는 작고 자세하게 , 훨씬 나중에 할것은

크게 작성한다. 다양한 수준으로 스토리를 작성하라

- 사용자 보다는 구직자 또는 마리오 라는 역할을 지정하라

- 이력서는 구직자에 의해 게시될 수 있다 구직자는 이력서를 게시할 수 있다.

- 차라리 짧은 제목을 붙이고 이를 대신하여 지칭하라

- 스토리는 대화를 재기하기 위해 기억하면 될 정도의 세부사항만을 기록

- 너무 많은 세부사항을 적으면 카드가 대화를 대신하게 된다.


Steps





Do & Don‟t





User Story Estimation

1. 스토리 점수 - 이상적 작업일 기준

2. 팀전체가 함께 추정 – Wideband Delphi (Boehm , 1981)

3. 삼각측량

4. 이터레이션당 스토리 점수의 활용 – 속도(Velocity)

5. 스토리가 크면 정확성이 떨어진다 – ½ ,1,2,3,5,8,13,20,40,80

6. 잊지 말아야 할 몇가지

A. 팀간의 스토리 점수는 다르다

B. 에픽을 스토리로 나눌경우 각 스토리점수의 합은 에픽의 합과 다를수 있다.

C. 정직하게 추정해야 한다. 일관되게 유지해야 한다.

Software Engineering Economics


Steps





Do & Don‟t





Release, Iteration, Velocity

- 릴리즈는 여러 개의 이터레이션으로 이루어진다.

- 각 이터레이션은 같은 크기의 상자와 같다.

- 스토리는 각각의 상자에 꽉찰때까지 채워진다.

- 상자의 크기는 각 이터레이션에 대한 속도이다.

Release

Iteration Iteration

1

5

4

3

1

2

2

6

34

1

12

1


Three Levels of ...

Planning Precision

Release Plan

Iteration Plan

Iteration Plan

Daily Plan Daily Plan Daily Plan

Daily Plan Daily Plan Daily Plan

사용자는 이력서를 작성..

관리자는 채용정보를..

3

2

기업은 채용정보를 게시..

사용자는 다수의 이력..

4

1

Ite

ratio

n

1

Ite

ratio

n

2

UI 작성

테스트 모듈 작성

8

3

Middle Tier 작성

공통 모듈 작성

4

1

어제 UI 작성 시작했다.오늘 집에가기 전에 끝내부러~

Tasks


Release Planning

1. 언제 릴리즈 할것인가 ? - 특정일자 / 몇번의 이터레이션 ..

2. 각 스토리의 우선순위는 어떻게 되는가 ?

A. DSDM – MoSCoW ( Must , Should , Could , Won‟t )

B. 고객 맘대로 / 위험도 순 ..

3. 이터레이션 길이 선택 - 대체로 1-4주가 적당

4. 스토리 점수로 예상 기간 산정 – 이전 속도/첫 이터레이션 속도..

5. 릴리즈 계획 생성 – 우선순위별 선택하여 이터레이션에 할당


Iteration Planning

1. 스토리에 대해 토의

A. 각 스토리를 완전히 이해할수 있게 고객과 대화

2. 스토리를 작업단위로 나눈다

A. 개발자들에게 알맞은 작업 단위로 분리 – 전문분야별 할당 등

3. 각 작업마다 개발자 한 명이 책임을 맡는다.

A. 해당 작업을 완료하는 책임. BUT “모두 함께 한다”는 마음가짐

4. 개발자가 자신이 맡은 작업량을 추정


Steps





Do & Don‟t





Why User Stories ?

1. 구두 의사소통

2. 이해하기 쉽다

3. 계획수립에 적합한 크기

4. 반복개발에 효과적

5. 세부사항 고려를 미룰수있다

6. 참여적 설계를 유도

7. 암묵적 지식을 구축

- 스토리가 많을때 스토리 사이의 관계를 이해하기 어렵다 사용자 역할을 사용 실 개발전에는 스토리를 적당한 수준이상으로 유지

- 요구사항 추적이 필요한경우 문서 추가 작성 부담 이터레이션별 스토리를 문서로 취합 테스트도 문서에 추가

- 큰 규모의 팀에서는 대화도 기록이 필요하다. 절충해서 적용


우리가 차용할수 있는 것 ?

1. 스토리 카드

2. 유저 역할 모델 & Persona

3. 이상적 작업일

4. 스토리 점수

5. 팀단위 Wideband Delphi 추정

6. 이터레이션과 속도

2010-01-26http://xguru.net

Questions ?Please contact 권정혁 , [email protected]

Twitter : @xguru


References

1. 사용자 스토리(User Stories Applied) – Mike Cohn

2. User Stories for Agile Requirements – Mike Cohn

- Software Development West 2006 Presentation

3. Agile Estimating And Planning – Mike Cohn

- Software Development West 2006 Presentation

4. Applied Software Project Management - Andrew Stellman

Technology

User Stories Applied