User Story

1. 고객 중심의 요구사항 기법
사용자 스토리
2015.04.
ITSM 팀
정희찬

2. References
마이크 콘 지음
한주영 외 옮김
인사이트
초판 3쇄 (2009년 9월 4일)
사용자 스토리 (User Stories Applied)

3. Steps
1. 사용자 스토리란 무엇인가?
2. 왜 사용자 스토리인가?
3. 스토리 작성 개요
4. 사용자 역할 모델링
5. 스토리 수집
6. 스토리 추정
7. 릴리즈 / 이터레이션 계획

4. 사용자 스토리 정의
사용자 스토리는 소프트웨어의 사용자나 구매자에게 가치를 줄 수 있는 기능을 서술한 것이다.
스토리는 서술 형태로 기술되며, 계획하거나 기억하기 위한 단서로 사용된다.
전통적으로 인덱스 카드에 작성되어서 카드라고 표현
문서화하기 위한 목적이 아닌 고객의 요구사항을 표현하기 위한 목적
스토리는 대화를 통해 세부사항을 구체화한다.
스토리는 테스트를 통해 세부사항을 문서화하고 전달하며, 스토리의 완료 여부를 판단한다.
Card
Conversation
Confirmation

5. 사용자 스토리 정의
사용자 스토리는 소프트웨어의 사용자나 구매자에게 가치를 줄 수 있는 기능을 서술한 것이다.
기업은 채용 정보를 게시할 수 있다.
사용자는 자신의 이력서를 열람할 사람을 제한할 수 있다.
프로그램은 커넥션풀을 통해 데이터베이스에 연결한다.
소프트웨어는 C++로 작성한다.
고객에게 가치를 평가 받을 수 있는 기능을 표현해야 함

6. Steps
1. 사용자 스토리란 무엇인가?
2. 왜 사용자 스토리인가?
3. 스토리 작성 개요
4. 사용자 역할 모델링
5. 스토리 수집
6. 스토리 추정
7. 릴리즈 / 이터레이션 계획

7.  일반적으로 사용자와 고객은 자신이 원하는 것을 정확히 알지 못한다.
 소프트웨어 개발자가 모든 요구사항을 파악했더라도, 그 소프트웨어를 개발하
기 위해 필요한 많은 세부사항은 시스템을 개발하면서 비로소 명확해진다.
 모든 세부사항을 미리 알 수 있다 해도 인간인 이상 그 모든 것을 이해하기는
힘들다.
 우리가 모든 것을 이해할 수 있더라도 제품이나 프로젝트에는 변경사항이 발
생하기 마련이다.
 사람을 실수를 한다.
1986 파나스, 클레멘츠

8. 구두 의사소통을 강조
이해가 쉬운 사용자 스토리
계획수립에 적합한 크기
반복적 개발에 효과적
세부사항을 나중에 고려
기회주의적 개발 지원
참여적 설계를 유도
암묵적 지식 축적
사용자 스토리의 장단점
대규모일 경우 스토리 구조화의
어려움으로 추가적인 문서 작업
이 필요
대규모일 경우 문서를 완전히 대
체 불가

9. Steps
1. 사용자 스토리란 무엇인가?
2. 왜 사용자 스토리인가?
3. 스토리 작성 개요
4. 사용자 역할 모델링
5. 스토리 수집
6. 스토리 추정
7. 릴리즈 / 이터레이션 계획

10. 좋은 사용자 스토리 원칙
독립적이다. (Independent)
협상 가능하다 (Negotiable)
사용자 및 고객에게 가치가 있다. (Valuable)
추정 가능하다 (Estimatable)
작다 (Small)
테스트 가능하다 (Testable)
INVEST
- 독립적이지 못한 스토리는 우선순위와 계획에 문제가 생김
- 통합 혹은 분류 방식 변환으로 해결
- 계약서나 요구사항 명세서가 아님
- 모든 세부사항을 처음부터 모두 포함하는 경우 대화에 오히려 방해.
(정확도와 정밀도의 차이)
- 개발자에게만 가치가 있는 스토리는 꼭 피하자.
- 도메인 지식 부족 -> 전반적인 이해는 필요
- 기술 부족 -> 스파이크 (스파이크는 다른 이터레이션)
- 너무 큰 스토리 -> 일정에 따라 분리
- 적정한 크기를 가지도록 기준 수립 필요 (1일 미만 ~ 일주일정도?)
- 인수기준이 표현되도록 작성 (‘절대~하지 않는다.’, ‘오래’, ‘쉽게’ 같은 단어 배제)
- 테스트 자동화

11. 스토리 기법 진행
사용자 역할 모델링
릴리즈, 이터레이션 계획
스토리 수집
스토리 추정

12. Steps
1. 사용자 스토리란 무엇인가?
2. 왜 사용자 스토리인가?
3. 스토리 작성 개요
4. 사용자 역할 모델링
5. 스토리 수집
6. 스토리 추정
7. 릴리즈 / 이터레이션 계획

13. 사용자 모델링
어쩌면 우리는 무의식 중에 한 종류의 사용자만 있고 한 명의 사용자 관점에서 생각하고 다른 모든 사용자
가 같은 목적을 가지고 있다고 가정하는 것은 아닐까?
브레인 스토밍
• 고객과 개발자가 같은 물리적 공간에서 더 이상 나오지 않을 때까지 역할을 뽑아낸다.
• 브레인 스토밍이므로 평가는 하지 않는다.
조직화 및 역할 통합
• 비슷하거나 중첩되는 역할을 묶고 토론을 통해 역할을 합치거나 교체한다.
• 때에 따라 필요가 없는 역할을 제외한다.
역할 다듬기
• 정리된 역할에 대해 속성을 정리한다.
• 지식 수준, 사용빈도, 숙련도, 사용 목적 등 => 등장인물 만들기, 극단적 인물 만들기

14. Steps
1. 사용자 스토리란 무엇인가?
2. 왜 사용자 스토리인가?
3. 스토리 작성 개요
4. 사용자 역할 모델링
5. 스토리 수집
6. 스토리 추정
7. 릴리즈 / 이터레이션 계획

15. 스토리 수집 기법
1. 사용자 인터뷰
- 대화는 사용자 스토리 기법에서 가장 중요하게 생각하는 부분. 스토리 카드도 이 대화를 유도하
기 위한 장치임을 기억
- 질문은 단답식으로 답변을 유도하는 질문이 아닌 이야기를 풀어놓을 수 있는 질문을 유도
2. 설문 조사
- 현실적으로 인터뷰가 불가능한 폭넓은 사용자 층에 대한 조사에 유용
- 최초 스토리 작성보다는 어느 정도 작성된 스토리에 대한 추가 정보 수집에 유용
3. 관찰
- 실제 사용자가 SW를 사용하는 패턴을 직접 확인하고, 관련 업무에 대한 기존 프로세스를 관찰
4. 스토리 작성 워크숍
- 관련된 개발자, 사용자, 고객들을 모두 포함하여 가능한 많은 스토리를 뽑아내는 방법
- 우선순위를 매기지는 않고, “나는 <역할>로서 <비즈니스 가치>를 위해 <기능>을 원한다.” 와 같
은 형식으로 작성

16. Steps
1. 사용자 스토리란 무엇인가?
2. 왜 사용자 스토리인가?
3. 스토리 작성 개요
4. 사용자 역할 모델링
5. 스토리 수집
6. 스토리 추정
7. 릴리즈 / 이터레이션 계획

17. 추정 및 속도
스토리 점수
스토리 점수와 팀 속도
• 각 스토리 별 예상 작업 일을 기준으로 점수 부여
• 개발자가 직접 추정을 해야 하며 팀 전체가 함께 추정한다. (Wideband Delphi)
• 너무 큰 점수의 스토리의 경우, 작은 스토리로 분리한다.
• 스토리가 점수가 너무 크면 계획 추정에 적합하지 않고 정확성이 많이 부족함.
• 같은 스토리에 대해서도 팀 별로 점수는 다르다는 점을 유의
• 에픽(Epic)을 작은 스토리로 나눌 경우 합은 최초 에픽과 다른 점수이다.
• 자신의 팀에 맞게 정직하게, 일관되게 기준을 유지
• 처음에는 점수가 많이 불확실해도 진행됨에 따라 정확도가 나아짐.
• 이렇게 정리된 점수에 따라 하나의 이터레이션, 릴리즈에 처리할 수 있는 팀의 속도 (처리 가능한 스
토리점수)가 예상 가능

18. Steps
1. 사용자 스토리란 무엇인가?
2. 왜 사용자 스토리인가?
3. 스토리 작성 개요
4. 사용자 역할 모델링
5. 스토리 수집
6. 스토리 추정
7. 릴리즈 / 이터레이션 계획

19. Release, Iteration, Velocity
User Story 의 묶음 => Iteration
 Iteration은 모두 크기가 같음.
 즉, 1~4주와 같이 팀과 프로젝트의 상황에 맞게 정해진 기간
 스토리에 대한 충분한 토의를 기반으로 함
 점수를 기반으로 하지만 일정을 개별로 가야 하지 않을까?
Iteration 의 묶음 => Release
 Release는 배포, 시연 등의 Milestone과 연계될 수 있을 듯.
 Iteration, Release의 순서는 우선순위에 기반
Release Iteration Story Task
1
A
사용자는…
UI작성
테이블 설계
승인자는… …
B 담당자는… …
일정 수립

20. Remember?

21. Really possible?
 팀의 미션, 비전, 핵심 가치
 스토리 카드
 유저 역할 모델
 스토리 점수
 팀 속도
 이터레이션, 릴리즈
 함께 앉기 (Sit Together) ●
 전체 팀 (Whole Team) ○ - Role 정의
 정보를 제공하는 작업 공간 (Informative Workspace) ○ - 방법 고민
 활기찬 작업 (Energized Work) ○ - 근무시간 준수
 짝 프로그래밍 (Pair Programming)
 스토리 (Story)
 여유 (Slack) ○ - 우선순위 선별
 일주일별 주기 (Weekly Cycle) ○ - 주간회의
 분기별 주기 (Quarterly Cycle) ○ - 분기별 목표 수립
 10분 빌드 (Ten-minute Build) ○ - 자동화
 지속적 통합 (Continuous Integration) ○ - 자동화
 테스트 우선 프로그래밍 (Test Driven Development) ○ - 가장 중요
 점진적 설계 (Incremental Design) ○ - 가장 중요