User stories

User Stories Applied
for agile software development
Book by Mike Cohn
Presentation by 권정혁
Twitter @xguru
Based on Mike‟s SDWest 2006 Conference Presentation

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

What problem do stories address ?
- 소프트웨어 요구사항은 의사소통(communication)의 문제다.
- 소프트웨어를 사용하거나 팔기를 원하는 사람은 그것을 만드는 사
람들과 의사소통을 해야 한다.

User Stories for Agile Requirements

2

Balance is Critical !
어느 한쪽이 의사소통에서 우위를 차지 한다면(dominates),
프로젝트는 실패(business loses)한다.
비즈니스쪽 사람들이 우위를 차지한다면…
그들은 기능과 마감시한을 동시에 요구할것이다. 개발자들이 요구사
항을 이해했는지, 이 두가지 목표를 달성할수 있는지는 고려하지 않
은채로..
개발자들이 우위를 차지한다면…
비즈니스 언어대신 기술적인 용어들이 난무하게 될것이고, 개발자들
은 정작 필요한것이 무엇인지 알수 없게 될것이다.(고객으로 부터
들을 기회를 잃어 버린다.)


3

Resource allocation
-

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

-

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


4

Responsibility for resource allocation
1. 개발자에게 짐을 씌운다면...
A. 추가기능구현을 위해 품질은 뒤로 미룰지도 모른다.
B. 기능을 일부만 구현할수도 있다.
C. 고객과 사용자들이 참여해서 결정해야할 사항을 독단적으로 처리하는
경우가 발생할지도 모른다.

2. 고객과 사용자에게 자원 할당 문제의 짐이 맡겨진다면…
A. 프로젝트의 초기에 지루한 논의만 계속하다가 기능들을 점차 제거하
게 될것이다.
B. 결국 완성된 소프트웨어에는 이렇게 줄어든 기능목록 보다도 훨씬 적
은 기능만 구현되어 있을것이다.


5

Imperfect Schedules
1. 소프트웨어 스케쥴을 완벽하게 예측하는 것은 불가능하다.
A. 사용자들은 소프트웨어 초기버전을 보고 새로운 아이디어를 말한다.
B. 계속 생각(요구사항)이 변한다.
C. SW의 무형성 때문에 프로젝트가 얼마나 걸릴지 추정하기가 어렵다.

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

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


6

So what do we do ?

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

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

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

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

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

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

7

Steps
 스토리란 무엇인가 ?
 스토리 작성하기

 사용자 역할 모델링
 스토리 수집하기
 Do & Don‟t
 사용자 스토리 추정
 릴리즈 / 이터레이션 계획
 왜 사용자 스토리인가 ?


8

Ron Jeffries‟ Three Cs
- 스토리는 전통적으로 인덱스카드에 작성 된다.
Card

- 고객(제품 소유자)에 의해 작성된다.
- 카드에는 추정치 또는 메모 같은것도 첨부될수 있다.

Conversation

Confirmation

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

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

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

9

Sample User Stories : BigMoneyJobs

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

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

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

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

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

소프트웨어는 C++ 로 작성한다.

프로그램은 커넥션풀을 통해 데이터
베이스에 연결한다.


10

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

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

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

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

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

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

11

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

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

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

 채용 정보를 입력하지 않고 시도해 본다.
 채용 정보를 아주 길게 넣어 본다.
 급여 정보가 빠진 경우를 확인해 본다.

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


12

Steps

 Do & Don‟t


13

What makes a good story?
Independent
Negotiable

Valuable
Estimatable
Small
Testable

14

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

Independent
Negotiable

Valuable

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

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

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

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

Estimatable
Small

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

스토리들을 다른방식으로 분리한다.

Testable

 고객은 한종류의 신용카드로 결제할수 있다.
 고객이 결제할 수 있는 신용카드는 두 종류가 더 있다.

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

15

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

Independent
Negotiable

Valuable
Estimatable
Small
Testable

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

기업은 채용공고를 게시할때 신용카드로 결제할수 있다.
주) 비자,마스터,아멕스카드를 지원한다. 디스커버는 검토

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

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

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

16

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

Independent

사용자

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

Negotiable

구매자

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

Valuable

관리자

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

Estimatable
Small
Testable

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

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

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

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


17

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

Independent
Negotiable

해당분야의 지식
(Domain Knowledge)
이 부족

작성한 고객과 직접 의논

Valuable
스파이크(Spike)를 수행

Estimatable

기술적인 지식이 부족

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

Small
Testable

스토리가 너무 크다

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


18

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

Independent
Negotiable

Compound Story - 복합적인 스토리
사용자는 학력/업무경력/희망급여/단체활동/향후 목표를 포함하는
이력서를 만들수 있다.
사용자는 이력서를 활성화/비활성화 할수 있다.

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

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

Valuable
Estimatable

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

Complex Story - 복잡한 스토리
 문제 조사 스토리와 기능개발 스토리로 분리

Small

웹에서 신용카드를 처리하는 방법을 조사한다. (Spike)
( 개발자 한두명이 최대허용시간을 정하고 연구/조사 해본다 )

Testable

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

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


19

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

Independent

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

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

Negotiable

Valuable

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

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

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

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

Estimatable
Small
Testable

20

Steps

 Do & Don‟t


21

The User
-

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

-

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

-

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

-

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


22

BigMoneyJobs – Who‟s the User ?
Mario

Allan

Scott

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

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

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

Carrie

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

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

마우이에 있는 일자리가 게시되면 자동으로 통보해주기 바람
매달 한번정도 접속하여 자신이 선택할수 있는 일자리들을 검색

Chris

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

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

Peter

역

할

사

용 자

구직자

Scott

최초 구직자

Mario

해고 피해자

Kindra

지역 선호자

Allan

Richard

관찰자

Carrie

채용 공고 게시자

Chris , Richard

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

이력서 조회자

Peter , Richard

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

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

23

User Role Modeling Steps
1. 브레인 스토밍

1.

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

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

2. 목록 초안 조직화
3. 역할 통합하기

3. 각자 생각나는 사용자 역할을 적어 테이블/칠판에 놓는
다.
- 평가는 하지 않는다.
- 적고 내려놓으면서 단지 역할의 이름만을 말한다.
- 새로 적을수 없을때까지 계속한다. ( 보통 약 15분이
면 충분하다 )

4. 역할 다듬기
역

할

사

용 자

구직자

Scott

최초 구직자

Mario

해고 피해자

Kindra

지역 선호자

Allan

관찰자

Carrie

채용 공고 게시자

Chris , Richard

이력서 조회자

Peter , Richard


24


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

대학 졸업자

채용공고 게시자

최초 구직자


이력서 조회자

채용 담당자

해고 피해자
지역 선호자

4. 역할 다듬기

구직자
관찰자

관리자


25


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

구직자

채용 담당자

관리자

해고 피해자

4. 역할 다듬기

내부 채용 담당자

지역 선호자

외부 채용 담당자

최초 구직자


26


- 역할 속성들을 정의한다.
-

소프트웨어를 사용하는 빈도
해당 분야에 관한 전문 지식 수준
컴퓨터 및 소프트웨어에 대한 일반적인 숙련도
개발 대상 소프트웨어에 대한 숙련도
소프트웨어에 대한 일반적인 사용 목적
(어떤 사용자들은 편리함, 어떤사용자들은 다양한 기능선호)

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


4. 역할 다듬기

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

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

도움 2) 극단적 인물 만들기
- 양다리를 걸치는 아가씨의 PDA
- 눈이 잘 안보이는 어른들의 PDA


27

Steps

 Do & Don‟t


28

Techniques for Gathering Stories
1. 사용자 인터뷰
- 대화가 중요하다.
- 닫힌 질문을 하지마라 ( 예 / 아니오 식의 답변을 요구하는 )

2. 설문조사
- 가지고 있는 스토리에 대한 정보수집용으론 좋다
- 폭넓은 기존 사용자 층에 대한 조사

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

4. 스토리 작성 워크숍
- 개발자 , 사용자 , 고객 그외 스토리 작성에 기여할 수 있는 사람들을 포함
- 질이 아니라 양에 기반한 가능한 많은 스토리를 만들어 낸다.

- 우선순위를 매기지 않는다.
- Template : “ As a <User Role> , I want <goal> so that <reason> “
“ 나는 <역할>로서 <비즈니스 가치> 를 위해 <기능>을 원한다.”

29

Steps

 Do & Don‟t


30

Guidelines for Good Stories
1. 목적 스토리로 시작하라

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

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

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

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

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

4. 제약사항 기록하기

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

- 기능별 분리의 폐해 ( 1.구직자는 입력양식에 값을 넣는다. 2.양식의 값이 DB 에 기록된다.)
- 예) 채용공고를 관리할수 있다  이력서를 삭제/검토 할수 있다. 마감일을 변경할수있다.
- 예) 시스템은 최대 50명까지 동시 사용자를 지원해야 한다. 모든 버전 윈도우를 지원해야한다.

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

- 바로 다음 이터레이션용 스토리는 작고 자세하게 , 훨씬 나중에 할것은
크게 작성한다. 다양한 수준으로 스토리를 작성하라

6. 되도록 사용자 인터페이스를 배제하라
7. 스토리에 사용자 역할을 포함하라

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

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

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

10. 고객이 작성하라

11. 스토리카드에 번호를 부여하지 마라
12. 목적을 잊지 말라

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

- 스토리는 대화를 재기하기 위해 기억하면 될 정도의 세부사항만을 기록
- 너무 많은 세부사항을 적으면 카드가 대화를 대신하게 된다.


31

Steps

 Do & Don‟t


32

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

2. 팀전체가 함께 추정 –

Wideband Delphi (Boehm , 1981)
Software Engineering Economics

3. 삼각측량
4. 이터레이션당 스토리 점수의 활용 –

속도(Velocity)

5. 스토리가 크면 정확성이 떨어진다 –

½ ,1,2,3,5,8,13,20,40,80

6. 잊지 말아야 할 몇가지
A. 팀간의 스토리 점수는 다르다
B. 에픽을 스토리로 나눌경우 각 스토리점수의 합은 에픽의 합과 다를수 있다.
C. 정직하게 추정해야 한다. 일관되게 유지해야 한다.


33

Steps

 Do & Don‟t


34

Release, Iteration, Velocity
- 릴리즈는 여러 개의 이터레이션으로 이루어진다.
- 각 이터레이션은 같은 크기의 상자와 같다.
- 스토리는 각각의 상자에 꽉찰때까지 채워진다.
- 상자의 크기는 각 이터레이션에 대한 속도이다.
Iteration

2

Iteration

1

1

2

1

2

3

1

3

4

5
4

1

6

Release

35

Three Levels of ...
Planning
Iteration

Release Plan

Precision

Iteration Plan

1
Daily Plan

Daily Plan

Iteration

Daily Plan

2

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

3

관리자는 채용정보를..

2

4

사용자는 다수의 이력..

8

테스트 모듈 작성

3

Middle Tier 작성
기업은 채용정보를 게시..

UI 작성

4

공통 모듈 작성

1

1

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

Daily Plan

Daily Plan


36

Release Planning
1. 언제 릴리즈 할것인가 ?

- 특정일자 / 몇번의 이터레이션 ..

2. 각 스토리의 우선순위는 어떻게 되는가 ?
A. DSDM – MoSCoW ( Must , Should , Could , Won‟t )
B. 고객 맘대로 / 위험도 순 ..

3. 이터레이션 길이 선택

- 대체로 1-4주가 적당

4. 스토리 점수로 예상 기간 산정

5. 릴리즈 계획 생성

– 이전 속도/첫 이터레이션 속도..

– 우선순위별 선택하여 이터레이션에 할당


37

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

2. 스토리를 작업단위로 나눈다
A. 개발자들에게 알맞은 작업 단위로 분리 – 전문분야별 할당 등

3. 각 작업마다 개발자 한 명이 책임을 맡는다.
A. 해당 작업을 완료하는 책임. BUT “모두 함께 한다”는 마음가짐

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

38

Steps

 Do & Don‟t


39

Why User Stories ?
1. 구두 의사소통

2. 이해하기 쉽다
3. 계획수립에 적합한 크기
4. 반복개발에 효과적
5. 세부사항 고려를 미룰수있다
6. 참여적 설계를 유도

7. 암묵적 지식을 구축

- 스토리가 많을때 스토리 사이의 관계를 이해하기 어렵다
 사용자 역할을 사용
 실 개발전에는 스토리를 적당한 수준이상으로 유지
- 요구사항 추적이 필요한경우 문서 추가 작성 부담
 이터레이션별 스토리를 문서로 취합
 테스트도 문서에 추가

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

40

Why User Stories ?
1. 구두 의사소통

2. 이해하기 쉽다
3. 계획수립에 적합한 크기
4. 반복개발에 효과적
5. 세부사항 고려를 미룰수있다
6. 참여적 설계를 유도

7. 암묵적 지식을 구축

- 스토리가 많을때 스토리 사이의 관계를 이해하기 어렵다
 사용자 역할을 사용
 실 개발전에는 스토리를 적당한 수준이상으로 유지
- 요구사항 추적이 필요한경우 문서 추가 작성 부담
 이터레이션별 스토리를 문서로 취합
 테스트도 문서에 추가

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

41

우리가 차용할수 있는 것 ?
1. 스토리 카드

2. 유저 역할 모델 & Persona
3. 이상적 작업일
4. 스토리 점수
5. 팀단위 Wideband Delphi 추정
6. 이터레이션과 속도


42

Questions ?
권정혁 , guru@xguru.net
Twitter @xguru

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

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


44

User stories

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à User stories

Similaire à User stories (20)

User stories