SlideShare a Scribd company logo
사용자 스토리 기반의
스크럼
2013.07.24
Aaron
@kmong.com
socurites@gmail.com
사용자 스토리와 애자일
조직의 생산성을 향상시키기 위해서는 개인의 실력을 향상시켜야 한다.
하지만 개개인 사이의 협력하는 방법을 바꿈으로써 조직을 발전시킬 수도 있다.
사용자 스토리는 아래와 같이 작성한다.
사용자 스토리와 애자일
사용자 스토리에는 2가지 정보를 작성한다.
1. 사용자가 시스템을 통해 이루고자 하는 목적
2. 사용자 스토리를 만들기 위한 비용
사용자 스토리는 단순해야 한다.
세세한 구현 내용은 실제로 구현하기 전까지 미룬다.
필요한 마지막 순간까지 기능의 세부사항을 작성하는 일을 미루게 됨으로써,
가장 중요한 기능을 가장 먼저 사용자에게 전달할 수 있는 기회를 얻게 된다.
사용자 스토리는 구현에 대한 약속이라기보다는
구현하기 전에 사용자/개발팀간의 대화를 이끌어내는 도구다.
사용자 스토리란
사용자 스토리란 서비스 고객에게 가치를 줄 수 있는 기능을 서술한 것이다.
따라서 사용자 스토리는 고객이 가치를 평가할 수 있도록 작성해야 한다.
스토리는 한두명의 개발자가 반나절에 ~ 2주일안에 구현하고 테스트할 수 있는
정도의 크기를 가져야 한다.
스토리에 모든 세부사항을 작성하는 대신,
개발팀과 고객이 세부사항에 대해 논의하는 편이 낫다.
각 스토리는 기술적 전문 용어가 아닌 비즈니스 언어로 작성해야 한다.
사용자 스토리란
스토리 카드의 뒷면에는 카드를 어떻게 테스트할 것인가에 대한 기록을 남긴다.
사용자 스토리 프로세스
사용자 스토리 프로세스
용어 정리
스프린트(이터레이션) : 1주 단위
릴리즈 : 1개 이상의 스프린트
제품 백로그 : 사용자 스토리 집합
스프린트 리뷰 미팅 : 매주 금요일, 이번 스프린트에 대한 리뷰 실시
스프린트 계획 미팅 : 매주 금요일, 다음 스프린트에 대한 계획 실시
데일리 스크럼 : 매일 9시 30분, 어제 한일/오늘 할일/어려움에 다한 공유 미팅 실
시
스프린트 계획 미팅 : 사용자 스토리 우선순위 정하기
다음 스프린트에서 만들 사용자 스토리의 우선순위를 정할 때
아래의 질문에 답해야 한다.
1. 다수의 사용자가 원하는 기능인가?
2. 다수는 아니더라도, 중요한 사용자가 바라는 기능인가?
3. 다른 중요한 기능과 연관된 기능인가?
우선순위를 매길 때는, 사용자뿐만 아니라
우리에게 최대의 가치를 가져오록 신경써야 한다.
좋은 사용자 스토리란?
INVEST
Independent : 독립적이다.
Negotiable : 조절 가능해야 한다.
Valuable : 사용자에게 가치를 제공해야 한다.
Estimatable : 측정 가능해야 한다.
Small : 작야아 한다.
Testable : 테스트 가능해야 한다.
개발자 중심의 사용자 스토리는 피해야 한다.
기술에 대한 가정도 포함해서는 안된다.
* 버그나 UI 변경과 같은 작은 스토리는 하나로 합쳐서, 하나의 스토리로 만든다.
누가 사용자인가?
사용자 스토리를 쉽게 도출하기 위해서는, 사용자 역할 및 페르소나(Persona)를
만들면 도움이 된다.
페르소나를 만들 때, 일반적인 인적정보 뿐만 아니라 컴퓨터와 인터넷에 대한 숙
련도를
함께 기입하면 도움이 된다.
컴퓨터/인터넷에 숙련된 사용자와 익숙하지 않은 사용자는 서로 다른 요구를 가
지기 마련이다.
절대로 개발자가 사용자를 대신해서는 안된다.
스토리 수집하기
다음 릴리즈를 시작하기 전에, 스토리 작성 워크숍을 실시한다.
브레인 스토밍 형태로 진행하며, 절대로 다른 사람의 아이디어를 평가하지 않는
다.
스토리 작성 워크숍은 스토리의 질보다는 양을 우선해야 한다.
스토리 작성 워크숍에서 문제를 제기할 수 있지만, 절대로 해결책을 찾으려 해서
는 안된다
스토리 도출하기 : 사용자 되기 게임
기존의 제품과 경쟁하는 상황이라면,
경쟁사 서비스를 벤치마킹하고
연구하는 방식으로도
사용자 스토리를 도출할 수 있다.
1. 팀원은 페르소나를 선택한다.
2. 페르소나의 입장에서
선호사이트/경쟁사이트를 사용한
다
3. 장점, 단점, 경험, 느낌, 성공요인
을
찾는다.
4. 각 팀원은 내용을 공유한다.
5. 공유한 내용을 바탕으로
사용자 스토리를 도출한다.
인수 테스트
고객이 기대하거나 가정하는 내용을 테스트 항목으로 도출하여 스토리 뒷면에
작성한다.
테스트의 종류
기능 테스트
프로그램의 기능이 게대한 대로 구현되었는지 확인
사용자 인터페이스 테스트
사용자 인터페이스 구성 요소가 예상한대로 동작하는지 확인
사용성 테스트
프로그램이 쉽게 사용가능한지 확인
성능 테스트
작업에 부하가 걸린 상황에서 어느정도의 성능을 보이는지 확인
스트레스 테스트
사용자 초과, 과다 트랜잭션 상황에서 프로그램이 어떻게 반응하는지 확인
좋은 사용자 스토리란
사용자가 시스템을 사용하는 주 목적을 중심으로 작성하라
사용자가 기능을 사용하여 목적을 완료할 수 있는 단위로 작성하라.
스토리가 반드시 지켜야하는 비기능(제약사항)인 경우, 제약사항 스토리로 만든
다.
능동태로 작성하라
스토리 카드에 번호를 부여하지 말라
가까운 시기에 구현할 기능은 작은 스토리로,
훨씬 나중에 구현할 기능에 대해서는 큰 스토리로 작성하라
추정하기 : 스토리 포인트
스토리를 완료하는 데 필요한 스토리 포인트를 추정할 때, "완료"라는 단어에는
코드를 만들고, 테스트하며, 릴리즈하기까지 전 과정에 필요한 작업들이 포함된
다.
스토리의 포인트와, 해당 스토리를 만들기 위해 필요한 각 태스크들의 포인트 합
이
같을 필요는 없다.
릴리즈 계획
릴리즈 계획에서는 아래의 2가지 질문에 대답해야 한다.
1. 언제 릴리즈할 것인가?
2. 각 스토리의 우선순위는 어떻게 되는가?
스토리 우선순위 정하기
MosCoW 규칙
필수(Must-have)
시스템에 반드시 필요하다.
희망(Should-have)
중요하지만, 단기적으로는 차선택이 있다.
선택(Could-have)
시간이 부족하다면, 다음 릴리즈로 넘겨도 크게 문제가 없다.
보류(Won't-have)
좋기는 하지만 미뤄도 전혀 문제가 없다.
이터레이션 계획하기
릴리즈 계획이 끝나고, 다음 릴리즈에서 전달할 사용자 스토리가 선택되었다면,
이제 각 이터레이션을 반복하면서 점진적으로 제품을 사용자에게 전달할 수 있
다.
이터레이션, 또는 스프린트 계획 미팅은 아래의 순서로 진행한다.
1. 스토리에 대해 토의한다.
2. 스토리별로 태스트를 도출한다.
3. 각 스토리별로 책임자를 할당한다.
4. 책임자가 할당된 스토리는 이제 제품 백로그에서 스프린트 백로그로 옮긴다.
이때 선택된 전체 스토리의 포인트 합이, 개발팀의 개발 속도보다 많아서는 안된
다.
스프린트를 완료할 책임은 개인이 아닌 팀 전체에 있다. 따라서 아래와 같은 얘
기가 나와서는 안된다.
"내가 맡은 일은 다 끝냈어. 근데 애런은 아직도 태스크가 많이 남았군"
만약 팀원 중 누군가가 태스크를 모두 완료하지 못했다면, 다른 팀원은 동료의
태스크를
팀의 속도 측정하기 및 이터레이션 차트
스프린트가 완료되면, 완료된 스토리 포인트의 합으로 팀의 속도를 측정한다.
이때 부분적으로 완료한 스토리는 속도 계산에 포함하지 않는다.
다시 말해 미완성인 채의 여러 스토리보다는, 완성된 한개의 스토리가 낫다.
이터레이션 차트
예상(계획했던) 스토리 포인트와 실제 완료한 스토리 포인트를 비교하여 팀의 속
도 측정
스토리
포인트
이터레이션
사용자 스토리와 스크럼
스크럼 팀
팀에는 다양한 전문 분야를 가진 사람들로 구성된다.
하지만 자신의 전문분야를 고수하기보다는 "함께 한다"는 자세로 임해야 한다.
팀원이 무엇을 할지를 누군가 정해주는 수동적인 방식이 아닌,
스스로 무엇을 할지를 능동적으로 결정한다.
스크럼 마스터는 스크럼 팀이 올바르게 움직이도롭 돕는 조력자다.
제품 책임자는 제품 백로그에 있는 사용자 스토리의 우선순위를 결정하는 책임
을 가진다.
스프린트 계획 미팅(Spring Planning Meeting)은 매주 금요일 하루 종일 진행된
다.
매 스프린트 시작전에, 스프린트의 목적 또는 테마를 정의해야 한다.
매 스프린트 종료전에, 스프린트 리뷰 미팅을 가진다.
스프린트 종료시, 제품을 반드시 시연해야 한다.
스프린트가 시작되면, 개발팀만이 제품 백로그에 스토리/작업을 추가할 수 있다.
데일리 스크럼 미팅(Daily Scrum Meeting)
일일 스크럼은 간단한 체크인으로 시작한다.
"저는 어제 친구들과 맥주를 마셔서인지, 오늘 상태가 메롱입니다."
데일리 스크럼에서 각 팀원은 아래의 내용을 공유한다.
1. 어제 무엇을 했는가?
2. 오늘 무엇을 할 것인가?
3. 문제점/이슈는 무엇인가? (어제 작업에서 무슨 문제점이 있었나?)
데일리 스크럼에서는 자연스레 이슈가 드러나기 마련이다.
하지만 행여 데일리 스크럼에서 이슈를 해결하려고 해서는 안된다.
문제에 대한 해결책을 찾는 미팅을 별도로 진행해라.
참고자료
사용자 스토리
- 고객 중심의 요구사항 기법-
마이크 콘 지음
한주영, 심우곤, 송인철 옮김
인사이트 출판사

More Related Content

What's hot

그럴듯한 랜덤 생성 컨텐츠 만들기
그럴듯한 랜덤 생성 컨텐츠 만들기그럴듯한 랜덤 생성 컨텐츠 만들기
그럴듯한 랜덤 생성 컨텐츠 만들기
Yongha Kim
 
유니티3D에서 2D 이미지 다루기
유니티3D에서 2D 이미지 다루기유니티3D에서 2D 이미지 다루기
유니티3D에서 2D 이미지 다루기
Jungsoo Park
 
[NDC 2009] 행동 트리로 구현하는 인공지능
[NDC 2009] 행동 트리로 구현하는 인공지능[NDC 2009] 행동 트리로 구현하는 인공지능
[NDC 2009] 행동 트리로 구현하는 인공지능
Yongha Kim
 
[NDC14] 모바일 게임의 다음 혁신 - 야생의 땅 듀랑고의 계산 프로세스 중심 게임 디자인
[NDC14] 모바일 게임의 다음 혁신 - 야생의 땅 듀랑고의 계산 프로세스 중심 게임 디자인[NDC14] 모바일 게임의 다음 혁신 - 야생의 땅 듀랑고의 계산 프로세스 중심 게임 디자인
[NDC14] 모바일 게임의 다음 혁신 - 야생의 땅 듀랑고의 계산 프로세스 중심 게임 디자인
승명 양
 
김동건, 갈망의 아궁이
김동건, 갈망의 아궁이김동건, 갈망의 아궁이
김동건, 갈망의 아궁이
devCAT Studio, NEXON
 
오승준, 사회적 기술이 프로그래머 인생을 바꿔주는 이유, NDC2011
오승준, 사회적 기술이 프로그래머 인생을 바꿔주는 이유, NDC2011오승준, 사회적 기술이 프로그래머 인생을 바꿔주는 이유, NDC2011
오승준, 사회적 기술이 프로그래머 인생을 바꿔주는 이유, NDC2011devCAT Studio, NEXON
 
NDC2013 - 인디게임 프로젝트 중도에 포기하지 않는 방법
NDC2013 - 인디게임 프로젝트 중도에 포기하지 않는 방법NDC2013 - 인디게임 프로젝트 중도에 포기하지 않는 방법
NDC2013 - 인디게임 프로젝트 중도에 포기하지 않는 방법ChangHyun Won
 
1인개발자가되기전알아야할것들
1인개발자가되기전알아야할것들1인개발자가되기전알아야할것들
1인개발자가되기전알아야할것들
Jinsub Jung
 
[IGC 2017] 블루홀 최준혁 - '플레이어언노운스 배틀그라운드' DEV 스토리
[IGC 2017] 블루홀 최준혁 - '플레이어언노운스 배틀그라운드' DEV 스토리[IGC 2017] 블루홀 최준혁 - '플레이어언노운스 배틀그라운드' DEV 스토리
[IGC 2017] 블루홀 최준혁 - '플레이어언노운스 배틀그라운드' DEV 스토리
강 민우
 
게임서버프로그래밍 #4 - 멀티스레드 프로그래밍
게임서버프로그래밍 #4 - 멀티스레드 프로그래밍게임서버프로그래밍 #4 - 멀티스레드 프로그래밍
게임서버프로그래밍 #4 - 멀티스레드 프로그래밍
Seungmo Koo
 
스타트업처럼 토이프로젝트하기
스타트업처럼 토이프로젝트하기스타트업처럼 토이프로젝트하기
스타트업처럼 토이프로젝트하기
Sunyoung Shin
 
어서와 게임기획은 처음이지?
어서와 게임기획은 처음이지?어서와 게임기획은 처음이지?
어서와 게임기획은 처음이지?
Lee Sangkyoon (Kay)
 
프로그래머가 되고 싶으세요
프로그래머가 되고 싶으세요프로그래머가 되고 싶으세요
프로그래머가 되고 싶으세요Chris Ohk
 
애자일 게임 개발이란?
애자일 게임 개발이란?애자일 게임 개발이란?
애자일 게임 개발이란?
Kay Kim
 
게임에서 흔히 쓰이는 최적화 전략 by 엄윤섭 @ 지스타 컨퍼런스 2013
게임에서 흔히 쓰이는 최적화 전략 by 엄윤섭 @ 지스타 컨퍼런스 2013게임에서 흔히 쓰이는 최적화 전략 by 엄윤섭 @ 지스타 컨퍼런스 2013
게임에서 흔히 쓰이는 최적화 전략 by 엄윤섭 @ 지스타 컨퍼런스 2013영욱 오
 
NDC2019 - 게임플레이 프로그래머의 역할
NDC2019 - 게임플레이 프로그래머의 역할NDC2019 - 게임플레이 프로그래머의 역할
NDC2019 - 게임플레이 프로그래머의 역할
Hoyoung Choi
 
스크럼을 이용한 게임 개발
스크럼을 이용한 게임 개발스크럼을 이용한 게임 개발
스크럼을 이용한 게임 개발
Insub Lee
 
정종필 팀장이됐어요(더저용량)
정종필 팀장이됐어요(더저용량)정종필 팀장이됐어요(더저용량)
정종필 팀장이됐어요(더저용량)JP Jung
 
게임 개발자가 되고 싶어요
게임 개발자가 되고 싶어요게임 개발자가 되고 싶어요
게임 개발자가 되고 싶어요
Lee Sangkyoon (Kay)
 
[IGC 2017] 아마존 구승모 - 게임 엔진으로 서버 제작 및 운영까지
[IGC 2017] 아마존 구승모 - 게임 엔진으로 서버 제작 및 운영까지[IGC 2017] 아마존 구승모 - 게임 엔진으로 서버 제작 및 운영까지
[IGC 2017] 아마존 구승모 - 게임 엔진으로 서버 제작 및 운영까지
강 민우
 

What's hot (20)

그럴듯한 랜덤 생성 컨텐츠 만들기
그럴듯한 랜덤 생성 컨텐츠 만들기그럴듯한 랜덤 생성 컨텐츠 만들기
그럴듯한 랜덤 생성 컨텐츠 만들기
 
유니티3D에서 2D 이미지 다루기
유니티3D에서 2D 이미지 다루기유니티3D에서 2D 이미지 다루기
유니티3D에서 2D 이미지 다루기
 
[NDC 2009] 행동 트리로 구현하는 인공지능
[NDC 2009] 행동 트리로 구현하는 인공지능[NDC 2009] 행동 트리로 구현하는 인공지능
[NDC 2009] 행동 트리로 구현하는 인공지능
 
[NDC14] 모바일 게임의 다음 혁신 - 야생의 땅 듀랑고의 계산 프로세스 중심 게임 디자인
[NDC14] 모바일 게임의 다음 혁신 - 야생의 땅 듀랑고의 계산 프로세스 중심 게임 디자인[NDC14] 모바일 게임의 다음 혁신 - 야생의 땅 듀랑고의 계산 프로세스 중심 게임 디자인
[NDC14] 모바일 게임의 다음 혁신 - 야생의 땅 듀랑고의 계산 프로세스 중심 게임 디자인
 
김동건, 갈망의 아궁이
김동건, 갈망의 아궁이김동건, 갈망의 아궁이
김동건, 갈망의 아궁이
 
오승준, 사회적 기술이 프로그래머 인생을 바꿔주는 이유, NDC2011
오승준, 사회적 기술이 프로그래머 인생을 바꿔주는 이유, NDC2011오승준, 사회적 기술이 프로그래머 인생을 바꿔주는 이유, NDC2011
오승준, 사회적 기술이 프로그래머 인생을 바꿔주는 이유, NDC2011
 
NDC2013 - 인디게임 프로젝트 중도에 포기하지 않는 방법
NDC2013 - 인디게임 프로젝트 중도에 포기하지 않는 방법NDC2013 - 인디게임 프로젝트 중도에 포기하지 않는 방법
NDC2013 - 인디게임 프로젝트 중도에 포기하지 않는 방법
 
1인개발자가되기전알아야할것들
1인개발자가되기전알아야할것들1인개발자가되기전알아야할것들
1인개발자가되기전알아야할것들
 
[IGC 2017] 블루홀 최준혁 - '플레이어언노운스 배틀그라운드' DEV 스토리
[IGC 2017] 블루홀 최준혁 - '플레이어언노운스 배틀그라운드' DEV 스토리[IGC 2017] 블루홀 최준혁 - '플레이어언노운스 배틀그라운드' DEV 스토리
[IGC 2017] 블루홀 최준혁 - '플레이어언노운스 배틀그라운드' DEV 스토리
 
게임서버프로그래밍 #4 - 멀티스레드 프로그래밍
게임서버프로그래밍 #4 - 멀티스레드 프로그래밍게임서버프로그래밍 #4 - 멀티스레드 프로그래밍
게임서버프로그래밍 #4 - 멀티스레드 프로그래밍
 
스타트업처럼 토이프로젝트하기
스타트업처럼 토이프로젝트하기스타트업처럼 토이프로젝트하기
스타트업처럼 토이프로젝트하기
 
어서와 게임기획은 처음이지?
어서와 게임기획은 처음이지?어서와 게임기획은 처음이지?
어서와 게임기획은 처음이지?
 
프로그래머가 되고 싶으세요
프로그래머가 되고 싶으세요프로그래머가 되고 싶으세요
프로그래머가 되고 싶으세요
 
애자일 게임 개발이란?
애자일 게임 개발이란?애자일 게임 개발이란?
애자일 게임 개발이란?
 
게임에서 흔히 쓰이는 최적화 전략 by 엄윤섭 @ 지스타 컨퍼런스 2013
게임에서 흔히 쓰이는 최적화 전략 by 엄윤섭 @ 지스타 컨퍼런스 2013게임에서 흔히 쓰이는 최적화 전략 by 엄윤섭 @ 지스타 컨퍼런스 2013
게임에서 흔히 쓰이는 최적화 전략 by 엄윤섭 @ 지스타 컨퍼런스 2013
 
NDC2019 - 게임플레이 프로그래머의 역할
NDC2019 - 게임플레이 프로그래머의 역할NDC2019 - 게임플레이 프로그래머의 역할
NDC2019 - 게임플레이 프로그래머의 역할
 
스크럼을 이용한 게임 개발
스크럼을 이용한 게임 개발스크럼을 이용한 게임 개발
스크럼을 이용한 게임 개발
 
정종필 팀장이됐어요(더저용량)
정종필 팀장이됐어요(더저용량)정종필 팀장이됐어요(더저용량)
정종필 팀장이됐어요(더저용량)
 
게임 개발자가 되고 싶어요
게임 개발자가 되고 싶어요게임 개발자가 되고 싶어요
게임 개발자가 되고 싶어요
 
[IGC 2017] 아마존 구승모 - 게임 엔진으로 서버 제작 및 운영까지
[IGC 2017] 아마존 구승모 - 게임 엔진으로 서버 제작 및 운영까지[IGC 2017] 아마존 구승모 - 게임 엔진으로 서버 제작 및 운영까지
[IGC 2017] 아마존 구승모 - 게임 엔진으로 서버 제작 및 운영까지
 

Similar to 사용자 스토리 기반의 스크럼

Itsm팀 내부세미나 사용자스토리_정희찬
Itsm팀 내부세미나 사용자스토리_정희찬Itsm팀 내부세미나 사용자스토리_정희찬
Itsm팀 내부세미나 사용자스토리_정희찬
정 희찬
 
User stories
User storiesUser stories
User stories
정혁 권
 
중간관리자를 위한 모바일 어플리케이션 _ WETEAM
중간관리자를 위한 모바일 어플리케이션 _ WETEAM중간관리자를 위한 모바일 어플리케이션 _ WETEAM
중간관리자를 위한 모바일 어플리케이션 _ WETEAM
Chaemin Lim
 
프로덕트 매니지먼트하기
프로덕트 매니지먼트하기프로덕트 매니지먼트하기
프로덕트 매니지먼트하기
YOO SE KYUN
 
Uxtrigger template v5.compressed_2019
Uxtrigger template v5.compressed_2019Uxtrigger template v5.compressed_2019
Uxtrigger template v5.compressed_2019
Potentialeyes, Inc.
 
User Stories Applied
User Stories AppliedUser Stories Applied
User Stories Applied
JungHyuk Kwon
 
프로덕트 매니저 8년의 경험
프로덕트 매니저 8년의 경험프로덕트 매니저 8년의 경험
프로덕트 매니저 8년의 경험
Jihye OK
 
Pivotal Labs 고객사례 - Coinone
Pivotal Labs 고객사례 - CoinonePivotal Labs 고객사례 - Coinone
Pivotal Labs 고객사례 - Coinone
VMware Tanzu Korea
 
애자일의 모든것
애자일의 모든것애자일의 모든것
애자일의 모든것
KH Park (박경훈)
 
사용자경험유지하기(@UX Storming/2012)
사용자경험유지하기(@UX Storming/2012)사용자경험유지하기(@UX Storming/2012)
사용자경험유지하기(@UX Storming/2012)
keesung kim
 
220806 UX/UI 해외 인기 아티클 6기 : 3주차 발표
220806 UX/UI 해외 인기 아티클 6기 : 3주차 발표220806 UX/UI 해외 인기 아티클 6기 : 3주차 발표
220806 UX/UI 해외 인기 아티클 6기 : 3주차 발표
Minho Lee
 
Part2.Design_이준경
Part2.Design_이준경Part2.Design_이준경
Part2.Design_이준경
Junkyeong Lee
 
더 나은 사용자 경험과 비즈니스를 만들기 위한 프로덕트 매니저로 일하기
더 나은 사용자 경험과 비즈니스를 만들기 위한 프로덕트 매니저로 일하기더 나은 사용자 경험과 비즈니스를 만들기 위한 프로덕트 매니저로 일하기
더 나은 사용자 경험과 비즈니스를 만들기 위한 프로덕트 매니저로 일하기
Hyunjung Kim
 
학교에서는 배울 수 없는 스타트업 엔지니어링 (연세대 특강)
학교에서는 배울 수 없는 스타트업 엔지니어링 (연세대 특강)학교에서는 배울 수 없는 스타트업 엔지니어링 (연세대 특강)
학교에서는 배울 수 없는 스타트업 엔지니어링 (연세대 특강)
Lab80
 
UX 디자인 7가지 비밀: 비밀 4
UX 디자인 7가지 비밀: 비밀 4UX 디자인 7가지 비밀: 비밀 4
UX 디자인 7가지 비밀: 비밀 4
Nammin Lee
 
여기컨_스타트업 기획자의 월화수목금_이수지
여기컨_스타트업 기획자의 월화수목금_이수지여기컨_스타트업 기획자의 월화수목금_이수지
여기컨_스타트업 기획자의 월화수목금_이수지
TechFeministgroup
 
AKC2020 인썸니아 이성훈
AKC2020 인썸니아 이성훈AKC2020 인썸니아 이성훈
AKC2020 인썸니아 이성훈
AgileKoreaConference Alliance
 
D2 캠퍼스 세미나 - 학생 개발자에서 신입 개발자로 한단계 업그레이드 하기
D2 캠퍼스 세미나 - 학생 개발자에서 신입 개발자로 한단계 업그레이드 하기D2 캠퍼스 세미나 - 학생 개발자에서 신입 개발자로 한단계 업그레이드 하기
D2 캠퍼스 세미나 - 학생 개발자에서 신입 개발자로 한단계 업그레이드 하기
Soojin Ro
 
2015 hi first 스터디 최종보고서
2015 hi first 스터디 최종보고서2015 hi first 스터디 최종보고서
2015 hi first 스터디 최종보고서
Seongho Park
 
Agile sw development 101
Agile sw development 101Agile sw development 101
Agile sw development 101
Kiwon Kyung
 

Similar to 사용자 스토리 기반의 스크럼 (20)

Itsm팀 내부세미나 사용자스토리_정희찬
Itsm팀 내부세미나 사용자스토리_정희찬Itsm팀 내부세미나 사용자스토리_정희찬
Itsm팀 내부세미나 사용자스토리_정희찬
 
User stories
User storiesUser stories
User stories
 
중간관리자를 위한 모바일 어플리케이션 _ WETEAM
중간관리자를 위한 모바일 어플리케이션 _ WETEAM중간관리자를 위한 모바일 어플리케이션 _ WETEAM
중간관리자를 위한 모바일 어플리케이션 _ WETEAM
 
프로덕트 매니지먼트하기
프로덕트 매니지먼트하기프로덕트 매니지먼트하기
프로덕트 매니지먼트하기
 
Uxtrigger template v5.compressed_2019
Uxtrigger template v5.compressed_2019Uxtrigger template v5.compressed_2019
Uxtrigger template v5.compressed_2019
 
User Stories Applied
User Stories AppliedUser Stories Applied
User Stories Applied
 
프로덕트 매니저 8년의 경험
프로덕트 매니저 8년의 경험프로덕트 매니저 8년의 경험
프로덕트 매니저 8년의 경험
 
Pivotal Labs 고객사례 - Coinone
Pivotal Labs 고객사례 - CoinonePivotal Labs 고객사례 - Coinone
Pivotal Labs 고객사례 - Coinone
 
애자일의 모든것
애자일의 모든것애자일의 모든것
애자일의 모든것
 
사용자경험유지하기(@UX Storming/2012)
사용자경험유지하기(@UX Storming/2012)사용자경험유지하기(@UX Storming/2012)
사용자경험유지하기(@UX Storming/2012)
 
220806 UX/UI 해외 인기 아티클 6기 : 3주차 발표
220806 UX/UI 해외 인기 아티클 6기 : 3주차 발표220806 UX/UI 해외 인기 아티클 6기 : 3주차 발표
220806 UX/UI 해외 인기 아티클 6기 : 3주차 발표
 
Part2.Design_이준경
Part2.Design_이준경Part2.Design_이준경
Part2.Design_이준경
 
더 나은 사용자 경험과 비즈니스를 만들기 위한 프로덕트 매니저로 일하기
더 나은 사용자 경험과 비즈니스를 만들기 위한 프로덕트 매니저로 일하기더 나은 사용자 경험과 비즈니스를 만들기 위한 프로덕트 매니저로 일하기
더 나은 사용자 경험과 비즈니스를 만들기 위한 프로덕트 매니저로 일하기
 
학교에서는 배울 수 없는 스타트업 엔지니어링 (연세대 특강)
학교에서는 배울 수 없는 스타트업 엔지니어링 (연세대 특강)학교에서는 배울 수 없는 스타트업 엔지니어링 (연세대 특강)
학교에서는 배울 수 없는 스타트업 엔지니어링 (연세대 특강)
 
UX 디자인 7가지 비밀: 비밀 4
UX 디자인 7가지 비밀: 비밀 4UX 디자인 7가지 비밀: 비밀 4
UX 디자인 7가지 비밀: 비밀 4
 
여기컨_스타트업 기획자의 월화수목금_이수지
여기컨_스타트업 기획자의 월화수목금_이수지여기컨_스타트업 기획자의 월화수목금_이수지
여기컨_스타트업 기획자의 월화수목금_이수지
 
AKC2020 인썸니아 이성훈
AKC2020 인썸니아 이성훈AKC2020 인썸니아 이성훈
AKC2020 인썸니아 이성훈
 
D2 캠퍼스 세미나 - 학생 개발자에서 신입 개발자로 한단계 업그레이드 하기
D2 캠퍼스 세미나 - 학생 개발자에서 신입 개발자로 한단계 업그레이드 하기D2 캠퍼스 세미나 - 학생 개발자에서 신입 개발자로 한단계 업그레이드 하기
D2 캠퍼스 세미나 - 학생 개발자에서 신입 개발자로 한단계 업그레이드 하기
 
2015 hi first 스터디 최종보고서
2015 hi first 스터디 최종보고서2015 hi first 스터디 최종보고서
2015 hi first 스터디 최종보고서
 
Agile sw development 101
Agile sw development 101Agile sw development 101
Agile sw development 101
 

More from Junyi Song

201804 neo4 j_cypher_guide
201804 neo4 j_cypher_guide201804 neo4 j_cypher_guide
201804 neo4 j_cypher_guide
Junyi Song
 
딥러닝프레임워크비교
딥러닝프레임워크비교딥러닝프레임워크비교
딥러닝프레임워크비교
Junyi Song
 
딥러닝(Deep Learing) using DeepDetect
딥러닝(Deep Learing) using DeepDetect딥러닝(Deep Learing) using DeepDetect
딥러닝(Deep Learing) using DeepDetect
Junyi Song
 
20151022 elasticsearch 적용및활용_송준이_sds발표용
20151022 elasticsearch 적용및활용_송준이_sds발표용20151022 elasticsearch 적용및활용_송준이_sds발표용
20151022 elasticsearch 적용및활용_송준이_sds발표용
Junyi Song
 
elasticsearch_적용 및 활용_정리
elasticsearch_적용 및 활용_정리elasticsearch_적용 및 활용_정리
elasticsearch_적용 및 활용_정리
Junyi Song
 
20140512 node.js를 활용한 실시간 웹채팅
20140512 node.js를 활용한 실시간 웹채팅20140512 node.js를 활용한 실시간 웹채팅
20140512 node.js를 활용한 실시간 웹채팅Junyi Song
 

More from Junyi Song (6)

201804 neo4 j_cypher_guide
201804 neo4 j_cypher_guide201804 neo4 j_cypher_guide
201804 neo4 j_cypher_guide
 
딥러닝프레임워크비교
딥러닝프레임워크비교딥러닝프레임워크비교
딥러닝프레임워크비교
 
딥러닝(Deep Learing) using DeepDetect
딥러닝(Deep Learing) using DeepDetect딥러닝(Deep Learing) using DeepDetect
딥러닝(Deep Learing) using DeepDetect
 
20151022 elasticsearch 적용및활용_송준이_sds발표용
20151022 elasticsearch 적용및활용_송준이_sds발표용20151022 elasticsearch 적용및활용_송준이_sds발표용
20151022 elasticsearch 적용및활용_송준이_sds발표용
 
elasticsearch_적용 및 활용_정리
elasticsearch_적용 및 활용_정리elasticsearch_적용 및 활용_정리
elasticsearch_적용 및 활용_정리
 
20140512 node.js를 활용한 실시간 웹채팅
20140512 node.js를 활용한 실시간 웹채팅20140512 node.js를 활용한 실시간 웹채팅
20140512 node.js를 활용한 실시간 웹채팅
 

사용자 스토리 기반의 스크럼

  • 2. 사용자 스토리와 애자일 조직의 생산성을 향상시키기 위해서는 개인의 실력을 향상시켜야 한다. 하지만 개개인 사이의 협력하는 방법을 바꿈으로써 조직을 발전시킬 수도 있다. 사용자 스토리는 아래와 같이 작성한다.
  • 3. 사용자 스토리와 애자일 사용자 스토리에는 2가지 정보를 작성한다. 1. 사용자가 시스템을 통해 이루고자 하는 목적 2. 사용자 스토리를 만들기 위한 비용 사용자 스토리는 단순해야 한다. 세세한 구현 내용은 실제로 구현하기 전까지 미룬다. 필요한 마지막 순간까지 기능의 세부사항을 작성하는 일을 미루게 됨으로써, 가장 중요한 기능을 가장 먼저 사용자에게 전달할 수 있는 기회를 얻게 된다. 사용자 스토리는 구현에 대한 약속이라기보다는 구현하기 전에 사용자/개발팀간의 대화를 이끌어내는 도구다.
  • 4. 사용자 스토리란 사용자 스토리란 서비스 고객에게 가치를 줄 수 있는 기능을 서술한 것이다. 따라서 사용자 스토리는 고객이 가치를 평가할 수 있도록 작성해야 한다. 스토리는 한두명의 개발자가 반나절에 ~ 2주일안에 구현하고 테스트할 수 있는 정도의 크기를 가져야 한다. 스토리에 모든 세부사항을 작성하는 대신, 개발팀과 고객이 세부사항에 대해 논의하는 편이 낫다. 각 스토리는 기술적 전문 용어가 아닌 비즈니스 언어로 작성해야 한다.
  • 5. 사용자 스토리란 스토리 카드의 뒷면에는 카드를 어떻게 테스트할 것인가에 대한 기록을 남긴다.
  • 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. 팀의 속도 측정하기 및 이터레이션 차트 스프린트가 완료되면, 완료된 스토리 포인트의 합으로 팀의 속도를 측정한다. 이때 부분적으로 완료한 스토리는 속도 계산에 포함하지 않는다. 다시 말해 미완성인 채의 여러 스토리보다는, 완성된 한개의 스토리가 낫다. 이터레이션 차트 예상(계획했던) 스토리 포인트와 실제 완료한 스토리 포인트를 비교하여 팀의 속 도 측정 스토리 포인트 이터레이션
  • 21. 스크럼 팀 팀에는 다양한 전문 분야를 가진 사람들로 구성된다. 하지만 자신의 전문분야를 고수하기보다는 "함께 한다"는 자세로 임해야 한다. 팀원이 무엇을 할지를 누군가 정해주는 수동적인 방식이 아닌, 스스로 무엇을 할지를 능동적으로 결정한다. 스크럼 마스터는 스크럼 팀이 올바르게 움직이도롭 돕는 조력자다. 제품 책임자는 제품 백로그에 있는 사용자 스토리의 우선순위를 결정하는 책임 을 가진다. 스프린트 계획 미팅(Spring Planning Meeting)은 매주 금요일 하루 종일 진행된 다. 매 스프린트 시작전에, 스프린트의 목적 또는 테마를 정의해야 한다. 매 스프린트 종료전에, 스프린트 리뷰 미팅을 가진다. 스프린트 종료시, 제품을 반드시 시연해야 한다. 스프린트가 시작되면, 개발팀만이 제품 백로그에 스토리/작업을 추가할 수 있다.
  • 22. 데일리 스크럼 미팅(Daily Scrum Meeting) 일일 스크럼은 간단한 체크인으로 시작한다. "저는 어제 친구들과 맥주를 마셔서인지, 오늘 상태가 메롱입니다." 데일리 스크럼에서 각 팀원은 아래의 내용을 공유한다. 1. 어제 무엇을 했는가? 2. 오늘 무엇을 할 것인가? 3. 문제점/이슈는 무엇인가? (어제 작업에서 무슨 문제점이 있었나?) 데일리 스크럼에서는 자연스레 이슈가 드러나기 마련이다. 하지만 행여 데일리 스크럼에서 이슈를 해결하려고 해서는 안된다. 문제에 대한 해결책을 찾는 미팅을 별도로 진행해라.
  • 23. 참고자료 사용자 스토리 - 고객 중심의 요구사항 기법- 마이크 콘 지음 한주영, 심우곤, 송인철 옮김 인사이트 출판사