사용자 스토리(인사이트 출판사)을 읽고 도움이 될만한 내용과 제 생각들을 정리해보았습니다.

1. 사용자 스토리 기반의
스크럼
2013.07.24
Aaron
@kmong.com
socurites@gmail.com

2. 사용자 스토리와 애자일
조직의 생산성을 향상시키기 위해서는 개인의 실력을 향상시켜야 한다.
하지만 개개인 사이의 협력하는 방법을 바꿈으로써 조직을 발전시킬 수도 있다.
사용자 스토리는 아래와 같이 작성한다.

3. 사용자 스토리와 애자일
사용자 스토리에는 2가지 정보를 작성한다.
1. 사용자가 시스템을 통해 이루고자 하는 목적
2. 사용자 스토리를 만들기 위한 비용
사용자 스토리는 단순해야 한다.
세세한 구현 내용은 실제로 구현하기 전까지 미룬다.
필요한 마지막 순간까지 기능의 세부사항을 작성하는 일을 미루게 됨으로써,
가장 중요한 기능을 가장 먼저 사용자에게 전달할 수 있는 기회를 얻게 된다.
사용자 스토리는 구현에 대한 약속이라기보다는
구현하기 전에 사용자/개발팀간의 대화를 이끌어내는 도구다.

4. 사용자 스토리란
사용자 스토리란 서비스 고객에게 가치를 줄 수 있는 기능을 서술한 것이다.
따라서 사용자 스토리는 고객이 가치를 평가할 수 있도록 작성해야 한다.
스토리는 한두명의 개발자가 반나절에 ~ 2주일안에 구현하고 테스트할 수 있는
정도의 크기를 가져야 한다.
스토리에 모든 세부사항을 작성하는 대신,
개발팀과 고객이 세부사항에 대해 논의하는 편이 낫다.
각 스토리는 기술적 전문 용어가 아닌 비즈니스 언어로 작성해야 한다.

5. 사용자 스토리란
스토리 카드의 뒷면에는 카드를 어떻게 테스트할 것인가에 대한 기록을 남긴다.

6. 사용자 스토리 프로세스

7. 사용자 스토리 프로세스
용어 정리
스프린트(이터레이션) : 1주 단위
릴리즈 : 1개 이상의 스프린트
제품 백로그 : 사용자 스토리 집합
스프린트 리뷰 미팅 : 매주 금요일, 이번 스프린트에 대한 리뷰 실시
스프린트 계획 미팅 : 매주 금요일, 다음 스프린트에 대한 계획 실시
데일리 스크럼 : 매일 9시 30분, 어제 한일/오늘 할일/어려움에 다한 공유 미팅 실
시

8. 스프린트 계획 미팅 : 사용자 스토리 우선순위 정하기
다음 스프린트에서 만들 사용자 스토리의 우선순위를 정할 때
아래의 질문에 답해야 한다.
1. 다수의 사용자가 원하는 기능인가?
2. 다수는 아니더라도, 중요한 사용자가 바라는 기능인가?
3. 다른 중요한 기능과 연관된 기능인가?
우선순위를 매길 때는, 사용자뿐만 아니라
우리에게 최대의 가치를 가져오록 신경써야 한다.

9. 좋은 사용자 스토리란?
INVEST
Independent : 독립적이다.
Negotiable : 조절 가능해야 한다.
Valuable : 사용자에게 가치를 제공해야 한다.
Estimatable : 측정 가능해야 한다.
Small : 작야아 한다.
Testable : 테스트 가능해야 한다.
개발자 중심의 사용자 스토리는 피해야 한다.
기술에 대한 가정도 포함해서는 안된다.
* 버그나 UI 변경과 같은 작은 스토리는 하나로 합쳐서, 하나의 스토리로 만든다.

10. 누가 사용자인가?
사용자 스토리를 쉽게 도출하기 위해서는, 사용자 역할 및 페르소나(Persona)를
만들면 도움이 된다.
페르소나를 만들 때, 일반적인 인적정보 뿐만 아니라 컴퓨터와 인터넷에 대한 숙
련도를
함께 기입하면 도움이 된다.
컴퓨터/인터넷에 숙련된 사용자와 익숙하지 않은 사용자는 서로 다른 요구를 가
지기 마련이다.
절대로 개발자가 사용자를 대신해서는 안된다.

11. 스토리 수집하기
다음 릴리즈를 시작하기 전에, 스토리 작성 워크숍을 실시한다.
브레인 스토밍 형태로 진행하며, 절대로 다른 사람의 아이디어를 평가하지 않는
다.
스토리 작성 워크숍은 스토리의 질보다는 양을 우선해야 한다.
스토리 작성 워크숍에서 문제를 제기할 수 있지만, 절대로 해결책을 찾으려 해서
는 안된다

12. 스토리 도출하기 : 사용자 되기 게임
기존의 제품과 경쟁하는 상황이라면,
경쟁사 서비스를 벤치마킹하고
연구하는 방식으로도
사용자 스토리를 도출할 수 있다.
1. 팀원은 페르소나를 선택한다.
2. 페르소나의 입장에서
선호사이트/경쟁사이트를 사용한
다
3. 장점, 단점, 경험, 느낌, 성공요인
을
찾는다.
4. 각 팀원은 내용을 공유한다.
5. 공유한 내용을 바탕으로
사용자 스토리를 도출한다.

13. 인수 테스트
고객이 기대하거나 가정하는 내용을 테스트 항목으로 도출하여 스토리 뒷면에
작성한다.
테스트의 종류
기능 테스트
프로그램의 기능이 게대한 대로 구현되었는지 확인
사용자 인터페이스 테스트
사용자 인터페이스 구성 요소가 예상한대로 동작하는지 확인
사용성 테스트
프로그램이 쉽게 사용가능한지 확인
성능 테스트
작업에 부하가 걸린 상황에서 어느정도의 성능을 보이는지 확인
스트레스 테스트
사용자 초과, 과다 트랜잭션 상황에서 프로그램이 어떻게 반응하는지 확인

14. 좋은 사용자 스토리란
사용자가 시스템을 사용하는 주 목적을 중심으로 작성하라
사용자가 기능을 사용하여 목적을 완료할 수 있는 단위로 작성하라.
스토리가 반드시 지켜야하는 비기능(제약사항)인 경우, 제약사항 스토리로 만든
다.
능동태로 작성하라
스토리 카드에 번호를 부여하지 말라
가까운 시기에 구현할 기능은 작은 스토리로,
훨씬 나중에 구현할 기능에 대해서는 큰 스토리로 작성하라

15. 추정하기 : 스토리 포인트
스토리를 완료하는 데 필요한 스토리 포인트를 추정할 때, "완료"라는 단어에는
코드를 만들고, 테스트하며, 릴리즈하기까지 전 과정에 필요한 작업들이 포함된
다.
스토리의 포인트와, 해당 스토리를 만들기 위해 필요한 각 태스크들의 포인트 합
이
같을 필요는 없다.

16. 릴리즈 계획
릴리즈 계획에서는 아래의 2가지 질문에 대답해야 한다.
1. 언제 릴리즈할 것인가?
2. 각 스토리의 우선순위는 어떻게 되는가?

17. 스토리 우선순위 정하기
MosCoW 규칙
필수(Must-have)
시스템에 반드시 필요하다.
희망(Should-have)
중요하지만, 단기적으로는 차선택이 있다.
선택(Could-have)
시간이 부족하다면, 다음 릴리즈로 넘겨도 크게 문제가 없다.
보류(Won't-have)
좋기는 하지만 미뤄도 전혀 문제가 없다.

18. 이터레이션 계획하기
릴리즈 계획이 끝나고, 다음 릴리즈에서 전달할 사용자 스토리가 선택되었다면,
이제 각 이터레이션을 반복하면서 점진적으로 제품을 사용자에게 전달할 수 있
다.
이터레이션, 또는 스프린트 계획 미팅은 아래의 순서로 진행한다.
1. 스토리에 대해 토의한다.
2. 스토리별로 태스트를 도출한다.
3. 각 스토리별로 책임자를 할당한다.
4. 책임자가 할당된 스토리는 이제 제품 백로그에서 스프린트 백로그로 옮긴다.
이때 선택된 전체 스토리의 포인트 합이, 개발팀의 개발 속도보다 많아서는 안된
다.
스프린트를 완료할 책임은 개인이 아닌 팀 전체에 있다. 따라서 아래와 같은 얘
기가 나와서는 안된다.
"내가 맡은 일은 다 끝냈어. 근데 애런은 아직도 태스크가 많이 남았군"
만약 팀원 중 누군가가 태스크를 모두 완료하지 못했다면, 다른 팀원은 동료의
태스크를

19. 팀의 속도 측정하기 및 이터레이션 차트
스프린트가 완료되면, 완료된 스토리 포인트의 합으로 팀의 속도를 측정한다.
이때 부분적으로 완료한 스토리는 속도 계산에 포함하지 않는다.
다시 말해 미완성인 채의 여러 스토리보다는, 완성된 한개의 스토리가 낫다.
이터레이션 차트
예상(계획했던) 스토리 포인트와 실제 완료한 스토리 포인트를 비교하여 팀의 속
도 측정
스토리
포인트
이터레이션

20. 사용자 스토리와 스크럼

21. 스크럼 팀
팀에는 다양한 전문 분야를 가진 사람들로 구성된다.
하지만 자신의 전문분야를 고수하기보다는 "함께 한다"는 자세로 임해야 한다.
팀원이 무엇을 할지를 누군가 정해주는 수동적인 방식이 아닌,
스스로 무엇을 할지를 능동적으로 결정한다.
스크럼 마스터는 스크럼 팀이 올바르게 움직이도롭 돕는 조력자다.
제품 책임자는 제품 백로그에 있는 사용자 스토리의 우선순위를 결정하는 책임
을 가진다.
스프린트 계획 미팅(Spring Planning Meeting)은 매주 금요일 하루 종일 진행된
다.
매 스프린트 시작전에, 스프린트의 목적 또는 테마를 정의해야 한다.
매 스프린트 종료전에, 스프린트 리뷰 미팅을 가진다.
스프린트 종료시, 제품을 반드시 시연해야 한다.
스프린트가 시작되면, 개발팀만이 제품 백로그에 스토리/작업을 추가할 수 있다.

22. 데일리 스크럼 미팅(Daily Scrum Meeting)
일일 스크럼은 간단한 체크인으로 시작한다.
"저는 어제 친구들과 맥주를 마셔서인지, 오늘 상태가 메롱입니다."
데일리 스크럼에서 각 팀원은 아래의 내용을 공유한다.
1. 어제 무엇을 했는가?
2. 오늘 무엇을 할 것인가?
3. 문제점/이슈는 무엇인가? (어제 작업에서 무슨 문제점이 있었나?)
데일리 스크럼에서는 자연스레 이슈가 드러나기 마련이다.
하지만 행여 데일리 스크럼에서 이슈를 해결하려고 해서는 안된다.
문제에 대한 해결책을 찾는 미팅을 별도로 진행해라.

23. 참고자료
사용자 스토리
- 고객 중심의 요구사항 기법-
마이크 콘 지음
한주영, 심우곤, 송인철 옮김
인사이트 출판사