SlideShare a Scribd company logo
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)한다.


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


                                     User Stories for Agile Requirements
                                                                           3
Resource allocation

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


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




                                 User Stories for Agile Requirements
                                                                       4
Responsibility for resource allocation
1. 개발자에게 짐을 씌운다면...
  A. 추가기능구현을 위해 품질은 뒤로 미룰지도 모른다.

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

  C. 고객과 사용자들이 참여해서 결정해야할 사항을 독단적으로 처리하는
     경우가 발생할지도 모른다.
2. 고객과 사용자에게 자원 할당 문제의 짐이 맡겨진다면…
  A. 프로젝트의 초기에 지루한 논의만 계속하다가 기능들을 점차 제거하
     게 될것이다.

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



                                   User Stories for Agile Requirements
                                                                         5
Imperfect Schedules
1. 소프트웨어 스케쥴을 완벽하게 예측하는 것은 불가능하다.
  A. 사용자들은 소프트웨어 초기버전을 보고 새로운 아이디어를 말한다.

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

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


2. 스케줄을 정확하게 예측할수 없다면,
 정확히 어떤 제품이 완성(Deliver)될지도 말할수 없다.




                                 User Stories for Agile Requirements
                                                                       6
So what do we do ?


 당장 손에 잡히는 정보를                      ..그리고 자주 그렇게
가지고 결정을 내려야 한다.                         해야한다.




프로젝트 착수시점에 모든
                                   …프로젝트 전 기간에 걸쳐
것을 포괄하는 결정을 하기
                                    의사를 결정해야 한다.
      보다


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


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

                                         User Stories for Agile Requirements
                                                                               7
Steps

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



                          User Stories for Agile Requirements
                                                                8
Ron Jeffries‟ Three Cs

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

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

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




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




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




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

                                            User Stories for Agile Requirements
                                                                                  9
Sample User Stories : BigMoneyJobs


사용자는 자신의 이력서를 웹 사이
                           기업은 채용 정보를 게시할수 있다.
트에 게시할수 있다


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




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




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




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



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


      EPIC

사용자는 자신의 이력서를 웹 사이        사용자는 검색 조건과 일치하는 채용 정보를 볼 수
트에 게시할수 있다                있다.




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



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

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




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


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




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




                                                  User Stories for Agile Requirements
                                                                                        12
Steps

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



                          User Stories for Agile Requirements
                                                                13
What makes a good story?


Independent

Negotiable

Valuable

Estimatable

Small

Testable

                                  User Stories for Agile Requirements
                                                                        14
What makes a good story?
                   가능하면 스토리 간에 의존성을 배제해야 한다.
                          의존성은 추정을 어렵게 한다.
Independent
                기업은 채용공고를 게시할때 비자카
Negotiable      드로 결제할수 있다.

                 기업은 채용공고를 게시할때 마스터                  첫 카드는 3일
                 카드로 결제할수 있다.                        다른카드는 1일
Valuable           기업은 채용공고를 게시할때 아메리
                   칸익스프레스카드로 결제할수 있다.

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

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

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

                                              User Stories for Agile Requirements
                                                                                    15
What makes a good story?
              협상가능 : 스토리는 계약서/SRS처럼 꼭 구현해야 한다는 기록이 아니다.

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




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

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




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

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

Estimatable
                     호를 저장해 두어야 한다. 카드의 유효기간 연/월을 수집한다.




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

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



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

                                                       User Stories for Agile Requirements
                                                                                             16
What makes a good story?
                      사용자와 고객 혹은 구매자에게 가치가 있어야 한다.

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




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



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




Estimatable
               모든 데이터베이스 연결은 커넥션 풀을 통해 이     사용자 라이센스 5개로 50명까지 데이터베이

Small          루어 져야 한다.                     스에 연결하여 사용할수 있어야 한다.




Testable       모든 에러 처리 및 로그 생성은 공통 클래스들
               을 통해 이루어 져야 한다.
                                             모든 에러는 사용자에게 보여야 하며, 일관된
                                             형태의 로그로 기록되어야 한다.




                                                  User Stories for Agile Requirements
                                                                                        17
What makes a good story?
               각 스토리의 크기 혹은 작업 소요 시간을 추정(추측)할수 있어야 한다.

Independent
                  해당분야의 지식
                (Domain Knowledge)
Negotiable
                                        작성한 고객과 직접 의논
                     이 부족



Valuable
                                        스파이크(Spike)를 수행
                기술적인 지식이 부족
Estimatable                           스파이크와 실제구현의 두개 스토리로
                                      분리 (서로 다른 이터레이션에 배치)



Small
                                       좀더 작은 단위로 나누거나
                 스토리가 너무 크다
Testable                             큰 추정치를 부여하고 일단 마감




                                            User Stories for Agile Requirements
                                                                                  18
What makes a good story?
                          너무 크거나 너무 작으면 사용하기 어렵다

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

Negotiable     사용자는 자신의 이력서를
                                   사용자는 이력서를 활성화/비활성화 할수 있다.
               게시할수 있다.
                                   사용자는 이력서를 여러 개 만들수 있다.

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




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


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

                                    ( 개발자 한두명이 최대허용시간을 정하고 연구/조사 해본다 )
               기업은 채용 공고를 게시할 때


Testable
               신용카드로 결제할 수 있다.


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



                                                      User Stories for Agile Requirements
                                                                                            19
What makes a good story?
                         스토리는 테스트 가능하도록 작성해야 한다.

Independent
                테스트는 스토리가 고객의 요구를 만족시키게 개발되었다는것을 확인할수 있게 한다.
                테스트는 자동화가 가능하도록 작성해야 한다.




Negotiable
                사용자가 소프트웨어를 쉽               신규 사용자가 별도의 교육없이 작
Valuable        게 사용할 수 있어야 한다.              업을 완료할 수 있어야 한다.



Estimatable
                어떤 화면도 사용자를 오               새 화면은 95%의 경우에 2초안에
Small           래 기다리게 해선 안된다.                   나타나야 한다.



Testable

                                                User Stories for Agile Requirements
                                                                                      20
Steps

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



                          User Stories for Agile Requirements
                                                                21
The User


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


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


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


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




                               User Stories for Agile Requirements
                                                                     22
BigMoneyJobs – Who‟s the User ?

 Mario                       Allan                                  Scott
이제 막 졸업하고                  마우이에서 윈드서핑                         현재 일자리가 싫지는
직장을 구하는 중                  만 즐길수 있다면 어떤                       않지만 이직할때가 되
                           일자리라도 상관없음                         었다고 생각중


              Carrie                        Kindra
             현재 직장이 있지만                    6개월전 해고당하
             항상 더 나은 일자리                   고 일자리가 없어
             를 염두에 두고 있음                   이젠 어떤곳이라도
                                           취직하고 싶음

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

                                 매달 한번정도 접속하여 자신이 선택할수 있는 일자리들을 검색
 Chris
인사팀 담당자로                          하루에 4시간 이상 필요인력 충원을 위해 사이트 이용
구인 공고를 게시
하려고 함
                                  역   할                  사     용 자
                  Peter           구직자                    Scott
                XX사 인사팀           최초 구직자                 Mario
                이력서 검토 담당자        해고 피해자                 Kindra
                                  지역 선호자                 Allan

Richard                           관찰자                    Carrie
                                  채용 공고 게시자              Chris , Richard
일자리와 인력을 모                        이력서 조회자                Peter , Richard
두 찾는 헤드헌터
                                  * 또는 상근 , 비상근 , 게약직 , 인턴 등등으로도 구분
                                                       User Stories for Agile Requirements
                                                                                             23
User Role Modeling Steps
1. 브레인 스토밍     1.   고객과 한께 가능한 많은 개발자가 한방에 모두 모여 회
                    의를 시작한다.

               2. 각자 카드를 한 묶음 가지고 간다.
2. 목록 초안 조직화   3. 각자 생각나는 사용자 역할을 적어 테이블/칠판에 놓는
                  다.

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

4. 역할 다듬기
                     역   할         사 용      자

                     구직자           Scott
                     최초 구직자        Mario
                     해고 피해자        Kindra
                     지역 선호자        Allan
                     관찰자           Carrie
                     채용 공고 게시자     Chris , Richard
                     이력서 조회자       Peter , Richard


                                            User Stories for Agile Requirements
                                                                                  24
User Role Modeling Steps
1. 브레인 스토밍     비슷하거나 중첩되는 역할끼리 모아 놓는다.
               * 중복되면 겹쳐 놓는다. 완전히 같다면 카드를 포개 놓는다.




2. 목록 초안 조직화
               대학 졸업자               채용공고 게시자                 이력서 조회자
               최초 구직자
                                           채용 담당자
3. 역할 통합하기      해고 피해자

                 지역 선호자

                  구직자

4. 역할 다듬기                 관찰자                          관리자




                                           User Stories for Agile Requirements
                                                                                 25
User Role Modeling Steps
1. 브레인 스토밍     - 각 역할이 의미하는 바를 토론한다.
               - 역할을 합치거나 좀더 Generic 한 카드로 교체한다.
               - 프로젝트의 성공에 상관없다고 생각하는 카드는 버린다.


2. 목록 초안 조직화
               구직자          채용 담당자                    관리자


3. 역할 통합하기
                 해고 피해자       내부 채용 담당자




4. 역할 다듬기        지역 선호자       외부 채용 담당자



                 최초 구직자




                                     User Stories for Agile Requirements
                                                                           26
User Role Modeling Steps
1. 브레인 스토밍      - 역할 속성들을 정의한다.
                     -   소프트웨어를 사용하는 빈도
                     -   해당 분야에 관한 전문 지식 수준
                     -   컴퓨터 및 소프트웨어에 대한 일반적인 숙련도
                     -   개발 대상 소프트웨어에 대한 숙련도
2. 목록 초안 조직화         -   소프트웨어에 대한 일반적인 사용 목적
                         (어떤 사용자들은 편리함, 어떤사용자들은 다양한 기능선호)

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

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



4. 역할 다듬기      도움 1) 등장인물(Persona) 만들기           도움 2) 극단적 인물 만들기

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

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



                          User Stories for Agile Requirements
                                                                28
Techniques for Gathering Stories
1. 사용자 인터뷰
  - 대화가 중요하다.

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

2. 설문조사
  - 가지고 있는 스토리에 대한 정보수집용으론 좋다

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

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

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

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

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

  - Template : “ As a <User Role> , I want <goal> so that <reason> “
              “ 나는 <역할>로서 <비즈니스 가치> 를 위해 <기능>을 원한다.”
                                                               User Stories for Agile Requirements
                                                                                                     29
Steps

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



                          User Stories for Agile Requirements
                                                                30
Guidelines for Good Stories
1. 목적 스토리로 시작하라   - 하나의 사용자 역할을 선택하여 시스템을 사용하는 주 목적을 식별



2. 케이크 자르듯 나누어라   - 스토리를 나눌때 하나의 작업이 처음부터 끝까지 포함되도록 하라
                  - 기능별 분리의 폐해 ( 1.구직자는 입력양식에 값을 넣는다. 2.양식의 값이 DB 에 기록된다.)

3. 닫힌 스토리를 작성하라   - 의미 있는 목적을 달성하는 형태로 작성하여 사용자로 하여금 뭔가를 해냈다고 느끼게 하는것
                  - 예) 채용공고를 관리할수 있다  이력서를 삭제/검토 할수 있다. 마감일을 변경할수있다.

4. 제약사항 기록하기      - 제약사항을 카드에 기록하여 벽에 붙여둠으로서 잊지 않도록 한다.
                  - 예) 시스템은 최대 50명까지 동시 사용자를 지원해야 한다. 모든 버전 윈도우를 지원해야한다.

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

6. 되도록 사용자 인터페이스를 배제하라
7. 스토리에 사용자 역할을 포함하라            - 사용자 보다는 구직자 또는 마리오 라는 역할을 지정하라



8. 한명의 사용자를 대상으로 작성하라
9. 능동태로 작성하라      - 이력서는 구직자에 의해 게시될 수 있다  구직자는 이력서를 게시할 수 있다.



10. 고객이 작성하라
11. 스토리카드에 번호를 부여하지 마라         - 차라리 짧은 제목을 붙이고 이를 대신하여 지칭하라



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



                                                    User Stories for Agile Requirements
                                                                                          31
Steps

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



                          User Stories for Agile Requirements
                                                                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. 정직하게 추정해야 한다. 일관되게 유지해야 한다.




                                                User Stories for Agile Requirements
                                                                                      33
Steps

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



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

               Iteration                     Iteration




               2           1             1               1
                                                 2
                                         1
           2
                   3                                     3
                                             4
           1               5

               4                                 6



                               Release
                                                         User Stories for Agile Requirements
                                                                                               35
Three Levels of ...
               Planning                                                Precision

Release Plan                                                                                      Tasks




                                            Iteration
                                                        사용자는 이력서를 작성..   3
                                                                                              UI 작성                8
 Iteration Plan
                                                                                        테스트 모듈 작성                  3
                                                        관리자는 채용정보를..     2
                                             1
                                                                                       Middle Tier 작성              4

                                                                                          공통 모듈 작성                 1




                                            Iteration
Daily Plan        Daily Plan   Daily Plan               기업은 채용정보를 게시..   4


                                                        사용자는 다수의 이력..    1
                                             2



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

Daily Plan        Daily Plan   Daily Plan




                                                                             User Stories for Agile Requirements
                                                                                                                   36
Release Planning
1. 언제 릴리즈 할것인가 ?          - 특정일자 / 몇번의 이터레이션 ..


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


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


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



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


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



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



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



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

                                    User Stories for Agile Requirements
                                                                          38
Steps

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



                          User Stories for Agile Requirements
                                                                39
Why User Stories ?
1. 구두 의사소통
2. 이해하기 쉽다
3. 계획수립에 적합한 크기
4. 반복개발에 효과적
5. 세부사항 고려를 미룰수있다
6. 참여적 설계를 유도     - 스토리가 많을때 스토리 사이의 관계를 이해하기 어렵다
                    사용자 역할을 사용
7. 암묵적 지식을 구축       실 개발전에는 스토리를 적당한 수준이상으로 유지

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

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

                                     User Stories for Agile Requirements
                                                                           40
우리가 차용할수 있는 것 ?

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




                              User Stories for Agile Requirements
                                                                    41
Questions ?
Please contact 권정혁 , 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




                                                     User Stories for Agile Requirements
                                                                                           43

More Related Content

What's hot

스토리포인트가이드
스토리포인트가이드스토리포인트가이드
스토리포인트가이드
YoungKi Hong
 
0. review. 린과 애자일 개발
0. review. 린과 애자일 개발0. review. 린과 애자일 개발
0. review. 린과 애자일 개발
Unyong (Sheldon) Choi
 
애자일을 실천하는 사람들이 겪는 어려움
애자일을 실천하는 사람들이 겪는 어려움애자일을 실천하는 사람들이 겪는 어려움
애자일을 실천하는 사람들이 겪는 어려움
Bonna Choi
 
애자일 게임 프레임워크
애자일 게임 프레임워크애자일 게임 프레임워크
애자일 게임 프레임워크
agilekorea
 
애자일에대한오해와진실
애자일에대한오해와진실애자일에대한오해와진실
애자일에대한오해와진실
Sangcheol Hwang
 
애자일의 모든것
애자일의 모든것애자일의 모든것
애자일의 모든것
KH Park (박경훈)
 
잘하면고효율, 못하면가문의원수가되는 짝프로그래밍 (Effective Pair Programming with Lessons Learned)
잘하면고효율, 못하면가문의원수가되는 짝프로그래밍 (Effective Pair Programming with Lessons Learned)잘하면고효율, 못하면가문의원수가되는 짝프로그래밍 (Effective Pair Programming with Lessons Learned)
잘하면고효율, 못하면가문의원수가되는 짝프로그래밍 (Effective Pair Programming with Lessons Learned)
Suwon Chae
 
실전 애자일 게임 개발 (Agile Game Agile Game Development From The Trenches)
실전 애자일 게임 개발 (Agile Game Agile Game Development From The Trenches)실전 애자일 게임 개발 (Agile Game Agile Game Development From The Trenches)
실전 애자일 게임 개발 (Agile Game Agile Game Development From The Trenches)
Kay Kim
 
모바일 앱 개발을 위한 Agile 적용
모바일 앱 개발을 위한 Agile 적용모바일 앱 개발을 위한 Agile 적용
모바일 앱 개발을 위한 Agile 적용
Kevin Kim
 
실패한 프로젝트들의 개발문화_개발방법론
실패한 프로젝트들의 개발문화_개발방법론실패한 프로젝트들의 개발문화_개발방법론
실패한 프로젝트들의 개발문화_개발방법론
Suwon Chae
 
개발 생산성과 품질 향상을 위한 글로벌기업의 애자일 도입 및 적용사례
개발 생산성과 품질 향상을 위한 글로벌기업의 애자일 도입 및 적용사례개발 생산성과 품질 향상을 위한 글로벌기업의 애자일 도입 및 적용사례
개발 생산성과 품질 향상을 위한 글로벌기업의 애자일 도입 및 적용사례
Woogon Shim
 
더 나은 S/W를 만드는 것에 관하여 (OKKY 세미나)
더 나은 S/W를 만드는 것에 관하여 (OKKY 세미나)더 나은 S/W를 만드는 것에 관하여 (OKKY 세미나)
더 나은 S/W를 만드는 것에 관하여 (OKKY 세미나)
Jeongho Shin
 
Undocumented agile.dist
Undocumented agile.distUndocumented agile.dist
Undocumented agile.dist
Jongin Oh
 
Sk planet 이야기
Sk planet 이야기Sk planet 이야기
Sk planet 이야기
종범 고
 
협업도구 및 주요 Agile practices 적용사례 v1.0
협업도구 및 주요 Agile practices 적용사례 v1.0협업도구 및 주요 Agile practices 적용사례 v1.0
협업도구 및 주요 Agile practices 적용사례 v1.0
Sangcheol Hwang
 
스크럼을 이용한 게임 개발
스크럼을 이용한 게임 개발스크럼을 이용한 게임 개발
스크럼을 이용한 게임 개발
Insub Lee
 
Agile 방법론
Agile 방법론Agile 방법론
Agile 방법론
Astin Choi
 
[Springcamp 2017] Build the RIGHT thing - 린 & 애자일 이야기 @ Pivotal Labs SF
[Springcamp 2017] Build the RIGHT thing - 린 & 애자일 이야기 @ Pivotal Labs SF[Springcamp 2017] Build the RIGHT thing - 린 & 애자일 이야기 @ Pivotal Labs SF
[Springcamp 2017] Build the RIGHT thing - 린 & 애자일 이야기 @ Pivotal Labs SF
Insuk (Chris) Cho
 

What's hot (19)

스토리포인트가이드
스토리포인트가이드스토리포인트가이드
스토리포인트가이드
 
0. review. 린과 애자일 개발
0. review. 린과 애자일 개발0. review. 린과 애자일 개발
0. review. 린과 애자일 개발
 
애자일을 실천하는 사람들이 겪는 어려움
애자일을 실천하는 사람들이 겪는 어려움애자일을 실천하는 사람들이 겪는 어려움
애자일을 실천하는 사람들이 겪는 어려움
 
애자일 게임 프레임워크
애자일 게임 프레임워크애자일 게임 프레임워크
애자일 게임 프레임워크
 
애자일에대한오해와진실
애자일에대한오해와진실애자일에대한오해와진실
애자일에대한오해와진실
 
애자일의 모든것
애자일의 모든것애자일의 모든것
애자일의 모든것
 
스크럼과 Xp
스크럼과 Xp스크럼과 Xp
스크럼과 Xp
 
잘하면고효율, 못하면가문의원수가되는 짝프로그래밍 (Effective Pair Programming with Lessons Learned)
잘하면고효율, 못하면가문의원수가되는 짝프로그래밍 (Effective Pair Programming with Lessons Learned)잘하면고효율, 못하면가문의원수가되는 짝프로그래밍 (Effective Pair Programming with Lessons Learned)
잘하면고효율, 못하면가문의원수가되는 짝프로그래밍 (Effective Pair Programming with Lessons Learned)
 
실전 애자일 게임 개발 (Agile Game Agile Game Development From The Trenches)
실전 애자일 게임 개발 (Agile Game Agile Game Development From The Trenches)실전 애자일 게임 개발 (Agile Game Agile Game Development From The Trenches)
실전 애자일 게임 개발 (Agile Game Agile Game Development From The Trenches)
 
모바일 앱 개발을 위한 Agile 적용
모바일 앱 개발을 위한 Agile 적용모바일 앱 개발을 위한 Agile 적용
모바일 앱 개발을 위한 Agile 적용
 
실패한 프로젝트들의 개발문화_개발방법론
실패한 프로젝트들의 개발문화_개발방법론실패한 프로젝트들의 개발문화_개발방법론
실패한 프로젝트들의 개발문화_개발방법론
 
개발 생산성과 품질 향상을 위한 글로벌기업의 애자일 도입 및 적용사례
개발 생산성과 품질 향상을 위한 글로벌기업의 애자일 도입 및 적용사례개발 생산성과 품질 향상을 위한 글로벌기업의 애자일 도입 및 적용사례
개발 생산성과 품질 향상을 위한 글로벌기업의 애자일 도입 및 적용사례
 
더 나은 S/W를 만드는 것에 관하여 (OKKY 세미나)
더 나은 S/W를 만드는 것에 관하여 (OKKY 세미나)더 나은 S/W를 만드는 것에 관하여 (OKKY 세미나)
더 나은 S/W를 만드는 것에 관하여 (OKKY 세미나)
 
Undocumented agile.dist
Undocumented agile.distUndocumented agile.dist
Undocumented agile.dist
 
Sk planet 이야기
Sk planet 이야기Sk planet 이야기
Sk planet 이야기
 
협업도구 및 주요 Agile practices 적용사례 v1.0
협업도구 및 주요 Agile practices 적용사례 v1.0협업도구 및 주요 Agile practices 적용사례 v1.0
협업도구 및 주요 Agile practices 적용사례 v1.0
 
스크럼을 이용한 게임 개발
스크럼을 이용한 게임 개발스크럼을 이용한 게임 개발
스크럼을 이용한 게임 개발
 
Agile 방법론
Agile 방법론Agile 방법론
Agile 방법론
 
[Springcamp 2017] Build the RIGHT thing - 린 & 애자일 이야기 @ Pivotal Labs SF
[Springcamp 2017] Build the RIGHT thing - 린 & 애자일 이야기 @ Pivotal Labs SF[Springcamp 2017] Build the RIGHT thing - 린 & 애자일 이야기 @ Pivotal Labs SF
[Springcamp 2017] Build the RIGHT thing - 린 & 애자일 이야기 @ Pivotal Labs SF
 

Viewers also liked

Agile - SCRUM을 통한 개발관리
Agile - SCRUM을 통한 개발관리Agile - SCRUM을 통한 개발관리
Agile - SCRUM을 통한 개발관리
SangJin Kang
 
애자일은 반드시 없어져야 한다
애자일은 반드시 없어져야 한다애자일은 반드시 없어져야 한다
애자일은 반드시 없어져야 한다
종범 고
 
애자일 게임 개발(Agile Game Development) - GDC2007
애자일 게임 개발(Agile Game Development) - GDC2007애자일 게임 개발(Agile Game Development) - GDC2007
애자일 게임 개발(Agile Game Development) - GDC2007
Kay Kim
 
Scrum - Agile Development Process
Scrum - Agile Development ProcessScrum - Agile Development Process
Scrum - Agile Development Process
Kook Maeng
 
Agile korea 2013 유석문
Agile korea 2013 유석문Agile korea 2013 유석문
Agile korea 2013 유석문
Sangcheol Hwang
 
Tester vs Developer
Tester vs DeveloperTester vs Developer
Tester vs Developer
Tricon Infotech
 
Agile SW 개발
Agile SW 개발Agile SW 개발
Agile SW 개발
혁 권
 
애자일 코치
애자일 코치애자일 코치
애자일 코치
영기 김
 
스크럼, 이걸 왜 하나요
스크럼, 이걸 왜 하나요스크럼, 이걸 왜 하나요
스크럼, 이걸 왜 하나요
Insub Lee
 

Viewers also liked (9)

Agile - SCRUM을 통한 개발관리
Agile - SCRUM을 통한 개발관리Agile - SCRUM을 통한 개발관리
Agile - SCRUM을 통한 개발관리
 
애자일은 반드시 없어져야 한다
애자일은 반드시 없어져야 한다애자일은 반드시 없어져야 한다
애자일은 반드시 없어져야 한다
 
애자일 게임 개발(Agile Game Development) - GDC2007
애자일 게임 개발(Agile Game Development) - GDC2007애자일 게임 개발(Agile Game Development) - GDC2007
애자일 게임 개발(Agile Game Development) - GDC2007
 
Scrum - Agile Development Process
Scrum - Agile Development ProcessScrum - Agile Development Process
Scrum - Agile Development Process
 
Agile korea 2013 유석문
Agile korea 2013 유석문Agile korea 2013 유석문
Agile korea 2013 유석문
 
Tester vs Developer
Tester vs DeveloperTester vs Developer
Tester vs Developer
 
Agile SW 개발
Agile SW 개발Agile SW 개발
Agile SW 개발
 
애자일 코치
애자일 코치애자일 코치
애자일 코치
 
스크럼, 이걸 왜 하나요
스크럼, 이걸 왜 하나요스크럼, 이걸 왜 하나요
스크럼, 이걸 왜 하나요
 

Similar to User Stories Applied

User stories
User storiesUser stories
User stories
정혁 권
 
사용자 스토리 기반의 스크럼(Scrum)
사용자 스토리 기반의 스크럼(Scrum)사용자 스토리 기반의 스크럼(Scrum)
사용자 스토리 기반의 스크럼(Scrum)
재능마켓 크몽
 
[교육리뷰] 스토리텔링을 통한 모바일 서비스 시나리오 작성 110321
[교육리뷰] 스토리텔링을 통한 모바일 서비스 시나리오 작성 110321[교육리뷰] 스토리텔링을 통한 모바일 서비스 시나리오 작성 110321
[교육리뷰] 스토리텔링을 통한 모바일 서비스 시나리오 작성 110321
Kyungeun Kim
 
Hupod 사업 소개서
Hupod 사업 소개서Hupod 사업 소개서
Hupod 사업 소개서
Jiho Kang
 
[한국IBM] AI활용을 위한 머신러닝 모델 구현 및 운영 세션
[한국IBM] AI활용을 위한 머신러닝 모델 구현 및 운영 세션[한국IBM] AI활용을 위한 머신러닝 모델 구현 및 운영 세션
[한국IBM] AI활용을 위한 머신러닝 모델 구현 및 운영 세션
Sejeong Kim 김세정
 
어플리케이션 기획 및 마케팅 전략_코드캠프_4_1(110611)
어플리케이션 기획 및 마케팅 전략_코드캠프_4_1(110611)어플리케이션 기획 및 마케팅 전략_코드캠프_4_1(110611)
어플리케이션 기획 및 마케팅 전략_코드캠프_4_1(110611)
ideaguide
 
AI시대, 개발자로서 살아가는 법 - AI를 이용해서 더 좋은 개발자로 성장하기
AI시대, 개발자로서 살아가는 법 - AI를 이용해서 더 좋은 개발자로 성장하기AI시대, 개발자로서 살아가는 법 - AI를 이용해서 더 좋은 개발자로 성장하기
AI시대, 개발자로서 살아가는 법 - AI를 이용해서 더 좋은 개발자로 성장하기
YoungJae Kwon
 
그로스 해킹 & 데이터 프로덕트 (Growth Hacking & Data Product) - 고넥터 고영혁 (Gonnector Dylan Ko)
그로스 해킹 & 데이터 프로덕트 (Growth Hacking & Data Product) - 고넥터 고영혁 (Gonnector Dylan Ko)그로스 해킹 & 데이터 프로덕트 (Growth Hacking & Data Product) - 고넥터 고영혁 (Gonnector Dylan Ko)
그로스 해킹 & 데이터 프로덕트 (Growth Hacking & Data Product) - 고넥터 고영혁 (Gonnector Dylan Ko)
Dylan Ko
 
큐레이션의 비즈니스 기회와 전망
큐레이션의 비즈니스 기회와 전망큐레이션의 비즈니스 기회와 전망
큐레이션의 비즈니스 기회와 전망
SungJin Lim
 
대학생 It전공자를 위한 소프트웨어특강
대학생 It전공자를 위한 소프트웨어특강 대학생 It전공자를 위한 소프트웨어특강
대학생 It전공자를 위한 소프트웨어특강
병석 양
 
사물인터넷(IoT)/웨어러블 UX 디자인툴킷_UX-trigger for Iot/Wearable_v1
사물인터넷(IoT)/웨어러블 UX 디자인툴킷_UX-trigger for Iot/Wearable_v1사물인터넷(IoT)/웨어러블 UX 디자인툴킷_UX-trigger for Iot/Wearable_v1
사물인터넷(IoT)/웨어러블 UX 디자인툴킷_UX-trigger for Iot/Wearable_v1
Limepaper, Inc.
 
Kakao agile 2nd story
Kakao agile 2nd storyKakao agile 2nd story
Kakao agile 2nd story
호정 이
 
퍼소나로 완성하는 인터랙션 디자인
퍼소나로 완성하는 인터랙션 디자인퍼소나로 완성하는 인터랙션 디자인
퍼소나로 완성하는 인터랙션 디자인
정인 주
 
How to implement your dream 20150427
How to implement your dream 20150427How to implement your dream 20150427
How to implement your dream 20150427
Will Kim
 
Bm report bmc_lc_bmg_130305
Bm report bmc_lc_bmg_130305Bm report bmc_lc_bmg_130305
Bm report bmc_lc_bmg_130305
ROA Invention LAB Inc. CEO
 
2012 UX 트렌드
2012 UX 트렌드2012 UX 트렌드
2012 UX 트렌드
Billy Choi
 
UX 디자인 7가지 비밀: 비밀 4
UX 디자인 7가지 비밀: 비밀 4UX 디자인 7가지 비밀: 비밀 4
UX 디자인 7가지 비밀: 비밀 4
Nammin Lee
 
2013년이 요구하는 UX/UI
2013년이 요구하는 UX/UI 2013년이 요구하는 UX/UI
2013년이 요구하는 UX/UI
Billy Choi
 
Oracle Digital Assistant 소개
Oracle Digital Assistant 소개Oracle Digital Assistant 소개
Oracle Digital Assistant 소개
Mee Nam Lee
 
INNOIZ_UX_YuriLee
INNOIZ_UX_YuriLeeINNOIZ_UX_YuriLee
INNOIZ_UX_YuriLee
Yu-Ri Lee
 

Similar to User Stories Applied (20)

User stories
User storiesUser stories
User stories
 
사용자 스토리 기반의 스크럼(Scrum)
사용자 스토리 기반의 스크럼(Scrum)사용자 스토리 기반의 스크럼(Scrum)
사용자 스토리 기반의 스크럼(Scrum)
 
[교육리뷰] 스토리텔링을 통한 모바일 서비스 시나리오 작성 110321
[교육리뷰] 스토리텔링을 통한 모바일 서비스 시나리오 작성 110321[교육리뷰] 스토리텔링을 통한 모바일 서비스 시나리오 작성 110321
[교육리뷰] 스토리텔링을 통한 모바일 서비스 시나리오 작성 110321
 
Hupod 사업 소개서
Hupod 사업 소개서Hupod 사업 소개서
Hupod 사업 소개서
 
[한국IBM] AI활용을 위한 머신러닝 모델 구현 및 운영 세션
[한국IBM] AI활용을 위한 머신러닝 모델 구현 및 운영 세션[한국IBM] AI활용을 위한 머신러닝 모델 구현 및 운영 세션
[한국IBM] AI활용을 위한 머신러닝 모델 구현 및 운영 세션
 
어플리케이션 기획 및 마케팅 전략_코드캠프_4_1(110611)
어플리케이션 기획 및 마케팅 전략_코드캠프_4_1(110611)어플리케이션 기획 및 마케팅 전략_코드캠프_4_1(110611)
어플리케이션 기획 및 마케팅 전략_코드캠프_4_1(110611)
 
AI시대, 개발자로서 살아가는 법 - AI를 이용해서 더 좋은 개발자로 성장하기
AI시대, 개발자로서 살아가는 법 - AI를 이용해서 더 좋은 개발자로 성장하기AI시대, 개발자로서 살아가는 법 - AI를 이용해서 더 좋은 개발자로 성장하기
AI시대, 개발자로서 살아가는 법 - AI를 이용해서 더 좋은 개발자로 성장하기
 
그로스 해킹 & 데이터 프로덕트 (Growth Hacking & Data Product) - 고넥터 고영혁 (Gonnector Dylan Ko)
그로스 해킹 & 데이터 프로덕트 (Growth Hacking & Data Product) - 고넥터 고영혁 (Gonnector Dylan Ko)그로스 해킹 & 데이터 프로덕트 (Growth Hacking & Data Product) - 고넥터 고영혁 (Gonnector Dylan Ko)
그로스 해킹 & 데이터 프로덕트 (Growth Hacking & Data Product) - 고넥터 고영혁 (Gonnector Dylan Ko)
 
큐레이션의 비즈니스 기회와 전망
큐레이션의 비즈니스 기회와 전망큐레이션의 비즈니스 기회와 전망
큐레이션의 비즈니스 기회와 전망
 
대학생 It전공자를 위한 소프트웨어특강
대학생 It전공자를 위한 소프트웨어특강 대학생 It전공자를 위한 소프트웨어특강
대학생 It전공자를 위한 소프트웨어특강
 
사물인터넷(IoT)/웨어러블 UX 디자인툴킷_UX-trigger for Iot/Wearable_v1
사물인터넷(IoT)/웨어러블 UX 디자인툴킷_UX-trigger for Iot/Wearable_v1사물인터넷(IoT)/웨어러블 UX 디자인툴킷_UX-trigger for Iot/Wearable_v1
사물인터넷(IoT)/웨어러블 UX 디자인툴킷_UX-trigger for Iot/Wearable_v1
 
Kakao agile 2nd story
Kakao agile 2nd storyKakao agile 2nd story
Kakao agile 2nd story
 
퍼소나로 완성하는 인터랙션 디자인
퍼소나로 완성하는 인터랙션 디자인퍼소나로 완성하는 인터랙션 디자인
퍼소나로 완성하는 인터랙션 디자인
 
How to implement your dream 20150427
How to implement your dream 20150427How to implement your dream 20150427
How to implement your dream 20150427
 
Bm report bmc_lc_bmg_130305
Bm report bmc_lc_bmg_130305Bm report bmc_lc_bmg_130305
Bm report bmc_lc_bmg_130305
 
2012 UX 트렌드
2012 UX 트렌드2012 UX 트렌드
2012 UX 트렌드
 
UX 디자인 7가지 비밀: 비밀 4
UX 디자인 7가지 비밀: 비밀 4UX 디자인 7가지 비밀: 비밀 4
UX 디자인 7가지 비밀: 비밀 4
 
2013년이 요구하는 UX/UI
2013년이 요구하는 UX/UI 2013년이 요구하는 UX/UI
2013년이 요구하는 UX/UI
 
Oracle Digital Assistant 소개
Oracle Digital Assistant 소개Oracle Digital Assistant 소개
Oracle Digital Assistant 소개
 
INNOIZ_UX_YuriLee
INNOIZ_UX_YuriLeeINNOIZ_UX_YuriLee
INNOIZ_UX_YuriLee
 

More from JungHyuk Kwon

웹을 지탱하는 기술
웹을 지탱하는 기술웹을 지탱하는 기술
웹을 지탱하는 기술
JungHyuk Kwon
 
Mobile 시대의 SEO ( Search Engine Optimization )
Mobile 시대의 SEO ( Search Engine Optimization )Mobile 시대의 SEO ( Search Engine Optimization )
Mobile 시대의 SEO ( Search Engine Optimization )
JungHyuk Kwon
 
2011 Mobile & Web technologies
2011 Mobile & Web technologies 2011 Mobile & Web technologies
2011 Mobile & Web technologies
JungHyuk Kwon
 
2011 The Year of Web apps
2011 The Year of Web apps2011 The Year of Web apps
2011 The Year of Web apps
JungHyuk Kwon
 
HTML5 on mobile
HTML5 on mobileHTML5 on mobile
HTML5 on mobile
JungHyuk Kwon
 
HTML5 로 iPhone App 만들기
HTML5 로 iPhone App 만들기HTML5 로 iPhone App 만들기
HTML5 로 iPhone App 만들기
JungHyuk Kwon
 
Twitter Api Mashup
Twitter Api MashupTwitter Api Mashup
Twitter Api Mashup
JungHyuk Kwon
 
Crawling The Web
Crawling The WebCrawling The Web
Crawling The Web
JungHyuk Kwon
 

More from JungHyuk Kwon (8)

웹을 지탱하는 기술
웹을 지탱하는 기술웹을 지탱하는 기술
웹을 지탱하는 기술
 
Mobile 시대의 SEO ( Search Engine Optimization )
Mobile 시대의 SEO ( Search Engine Optimization )Mobile 시대의 SEO ( Search Engine Optimization )
Mobile 시대의 SEO ( Search Engine Optimization )
 
2011 Mobile & Web technologies
2011 Mobile & Web technologies 2011 Mobile & Web technologies
2011 Mobile & Web technologies
 
2011 The Year of Web apps
2011 The Year of Web apps2011 The Year of Web apps
2011 The Year of Web apps
 
HTML5 on mobile
HTML5 on mobileHTML5 on mobile
HTML5 on mobile
 
HTML5 로 iPhone App 만들기
HTML5 로 iPhone App 만들기HTML5 로 iPhone App 만들기
HTML5 로 iPhone App 만들기
 
Twitter Api Mashup
Twitter Api MashupTwitter Api Mashup
Twitter Api Mashup
 
Crawling The Web
Crawling The WebCrawling The Web
Crawling The Web
 

User Stories Applied

  • 1. 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
  • 2. What problem do stories address ? - 소프트웨어 요구사항은 의사소통(communication)의 문제다. - 소프트웨어를 사용하거나 팔기를 원하는 사람은 그것을 만드는 사 람들과 의사소통을 해야 한다. User Stories for Agile Requirements 2
  • 3. Balance is Critical ! 어느 한쪽이 의사소통에서 우위를 차지 한다면(dominates), 프로젝트는 실패(business loses)한다. 비즈니스쪽 사람들이 우위를 차지한다면… 그들은 기능과 마감시한을 동시에 요구할것이다. 개발자들이 요구사 항을 이해했는지, 이 두가지 목표를 달성할수 있는지는 고려하지 않 은채로.. 개발자들이 우위를 차지한다면… 비즈니스 언어대신 기술적인 용어들이 난무하게 될것이고, 개발자들 은 정작 필요한것이 무엇인지 알수 없게 될것이다.(고객으로 부터 들을 기회를 잃어 버린다.) User Stories for Agile Requirements 3
  • 4. Resource allocation - 우리에게 필요한것은 함께 일하는 방법이다. 이를 통해 감정 적으로 흐르거나 정치적일수 있는 자원할당의 문제를 공동 의 문제로 공유하는것이다. - 자원 할당 문제를 어느 한쪽에만 떠맡기는 프로젝트는 실패 한다. User Stories for Agile Requirements 4
  • 5. Responsibility for resource allocation 1. 개발자에게 짐을 씌운다면... A. 추가기능구현을 위해 품질은 뒤로 미룰지도 모른다. B. 기능을 일부만 구현할수도 있다. C. 고객과 사용자들이 참여해서 결정해야할 사항을 독단적으로 처리하는 경우가 발생할지도 모른다. 2. 고객과 사용자에게 자원 할당 문제의 짐이 맡겨진다면… A. 프로젝트의 초기에 지루한 논의만 계속하다가 기능들을 점차 제거하 게 될것이다. B. 결국 완성된 소프트웨어에는 이렇게 줄어든 기능목록 보다도 훨씬 적 은 기능만 구현되어 있을것이다. User Stories for Agile Requirements 5
  • 6. Imperfect Schedules 1. 소프트웨어 스케쥴을 완벽하게 예측하는 것은 불가능하다. A. 사용자들은 소프트웨어 초기버전을 보고 새로운 아이디어를 말한다. B. 계속 생각(요구사항)이 변한다. C. SW의 무형성 때문에 프로젝트가 얼마나 걸릴지 추정하기가 어렵다. 2. 스케줄을 정확하게 예측할수 없다면, 정확히 어떤 제품이 완성(Deliver)될지도 말할수 없다. User Stories for Agile Requirements 6
  • 7. So what do we do ? 당장 손에 잡히는 정보를 ..그리고 자주 그렇게 가지고 결정을 내려야 한다. 해야한다. 프로젝트 착수시점에 모든 …프로젝트 전 기간에 걸쳐 것을 포괄하는 결정을 하기 의사를 결정해야 한다. 보다 가능한 자주 , 신속하게 필요한 정보를 가져다 주는 프로세스가 필요 사용자 스토리는 이를 위한것이다. User Stories for Agile Requirements 7
  • 8. Steps  스토리란 무엇인가 ?  스토리 작성하기  사용자 역할 모델링  스토리 수집하기  Do & Don‟t  사용자 스토리 추정  릴리즈 / 이터레이션 계획  왜 사용자 스토리인가 ? User Stories for Agile Requirements 8
  • 9. Ron Jeffries‟ Three Cs - 스토리는 전통적으로 인덱스카드에 작성 된다. Card - 고객(제품 소유자)에 의해 작성된다. - 카드에는 추정치 또는 메모 같은것도 첨부될수 있다. - 스토리에 들어있는 세부사항은 사용자와의 대화를 Conversation 통해 도출된다. Confirmation - 테스트는 스토리가 정확히 개발(코딩)되었는지를 확인한다. „카드’ 는 스토리의 본문을 담고 있지만, 세부사항은 ‘대화’를 통해 결정되며 구현을 ‘확인’ 하기 위한 테스트를 포함한다. User Stories for Agile Requirements 9
  • 10. Sample User Stories : BigMoneyJobs 사용자는 자신의 이력서를 웹 사이 기업은 채용 정보를 게시할수 있다. 트에 게시할수 있다 사용자는 채용 정보를 검색할수 있 사용자는 자신의 이력서를 열람할 다. 사람을 제한할 수 있다. * 사용자 스토리는 사용자에게 가치를 평가받을수 있도록 기능을 표현 프로그램은 커넥션풀을 통해 데이터 소프트웨어는 C++ 로 작성한다. 베이스에 연결한다. User Stories for Agile Requirements 10
  • 11. Where are the Details ? 스토리는 한두 명의 개발자가 반나절~2주일 안에 구현하고 테스트 할수 있는 정도 크기가 적당 사용자는 위치,급여 수준,직업 명, 회사 명, 게시날 짜 등의 속성값으로 채용정보를 검색할수 있다. EPIC 사용자는 자신의 이력서를 웹 사이 사용자는 검색 조건과 일치하는 채용 정보를 볼 수 트에 게시할수 있다 있다. 사용자는 채용 정보를 게시한 기업에 대한 세부 정 보를 볼 수 있다. 스토리는 계약과 같은 구속 이 아니라, 대화하기 위한 수단이다 User Stories for Agile Requirements 11
  • 12. Details as conditions of satisfaction 좀더 자세한 충족 조건이 스토리에 추가될수 있다. ( 주석 / 테스트 ) 사용자는 검색 조건과 일치하는 채용 정보를 볼 수 있다. 주) 마르코는 설명,급여,위치 정보를 보여 주어야 한다고 함.  채용 정보를 입력하지 않고 시도해 본다.  채용 정보를 아주 길게 넣어 본다.  급여 정보가 빠진 경우를 확인해 본다.  여섯 자리 급여로 시도해 본다. User Stories for Agile Requirements 12
  • 13. Steps  스토리란 무엇인가 ?  스토리 작성하기  사용자 역할 모델링  스토리 수집하기  Do & Don‟t  사용자 스토리 추정  릴리즈 / 이터레이션 계획  왜 사용자 스토리인가 ? User Stories for Agile Requirements 13
  • 14. What makes a good story? Independent Negotiable Valuable Estimatable Small Testable User Stories for Agile Requirements 14
  • 15. What makes a good story? 가능하면 스토리 간에 의존성을 배제해야 한다.  의존성은 추정을 어렵게 한다. Independent 기업은 채용공고를 게시할때 비자카 Negotiable 드로 결제할수 있다. 기업은 채용공고를 게시할때 마스터 첫 카드는 3일 카드로 결제할수 있다. 다른카드는 1일 Valuable 기업은 채용공고를 게시할때 아메리 칸익스프레스카드로 결제할수 있다. Estimatable 의존성이 있는 스토리들을 합쳐 좀더 큰 하나의 독립적인 스토리로 만든다 Small  기업은 채용공고를 게시할때 신용카드로 결제할수 있다(5일) 스토리들을 다른방식으로 분리한다.  고객은 한종류의 신용카드로 결제할수 있다. Testable  고객이 결제할 수 있는 신용카드는 두 종류가 더 있다. 각각의 스토리에 작업추정치를 두가지로 부여한다. User Stories for Agile Requirements 15
  • 16. What makes a good story? 협상가능 : 스토리는 계약서/SRS처럼 꼭 구현해야 한다는 기록이 아니다. Independent  대화를 이끌기 위한 단서지, 그 자체로 완성된 상세한 요구사항이 아니다. 너무 상세하게 적는다면 그것은 완성된것으로 추측하게되어 대화의 단절을 가져온다. Negotiable 기업은 채용공고를 게시할때 신용카드로 결제할수 있다. 주) 비자,마스터,아멕스카드를 지원한다. 디스커버는 검토 Valuable 기업은 채용공고를 게시할때 신용카드로 결제할수 있다. 주) 비자,마스터,아멕스카드를 지원한다. 디스커버는 검토 100달러 이상 구매시 카드 뒷면의 ID 번호를 확인한다. 시스템은 카드번호의 첫 두자리로 카드의 종류를 알수 있다. 시스템은 다음 사용에 대비하여 카드번 Estimatable 호를 저장해 두어야 한다. 카드의 유효기간 연/월을 수집한다. 기업은 채용공고를 게시할때 신용카드로 결제할수 있다. Small 주) 디스커버 카드도 지원해야 하나 ? 내 주) 카드 종류를 고르는 항목은 필요없다(카드 번호 첫2자리로 알수있음) Testable 비자,마스타카드,아멕스 카드 테스트 (통과) 다이너스 클럽 테스트(실패) 정상/비정상 카드 ID 테스트, 분실카드 ID 테스트. 유효 기간 만료된 카드 테스트 100달러 이상/이하 테스트 User Stories for Agile Requirements 16
  • 17. What makes a good story? 사용자와 고객 혹은 구매자에게 가치가 있어야 한다. Independent 사용자 직책과 연봉에 따라 채용정보를 검색할수 있다. Negotiable 구매자 ISO 9001 감사에 적합한 문서를 작성한다. CMM 레벨 3에 부합하게 소프트웨어를 개발한다. Valuable 관리자 프로그램 설정 정보를 중앙 저장위치에서 읽어와야 한다. Estimatable 모든 데이터베이스 연결은 커넥션 풀을 통해 이 사용자 라이센스 5개로 50명까지 데이터베이 Small 루어 져야 한다. 스에 연결하여 사용할수 있어야 한다. Testable 모든 에러 처리 및 로그 생성은 공통 클래스들 을 통해 이루어 져야 한다. 모든 에러는 사용자에게 보여야 하며, 일관된 형태의 로그로 기록되어야 한다. User Stories for Agile Requirements 17
  • 18. What makes a good story? 각 스토리의 크기 혹은 작업 소요 시간을 추정(추측)할수 있어야 한다. Independent 해당분야의 지식 (Domain Knowledge) Negotiable 작성한 고객과 직접 의논 이 부족 Valuable 스파이크(Spike)를 수행 기술적인 지식이 부족 Estimatable  스파이크와 실제구현의 두개 스토리로 분리 (서로 다른 이터레이션에 배치) Small 좀더 작은 단위로 나누거나 스토리가 너무 크다 Testable 큰 추정치를 부여하고 일단 마감 User Stories for Agile Requirements 18
  • 19. What makes a good story? 너무 크거나 너무 작으면 사용하기 어렵다 Independent Compound Story - 복합적인 스토리 사용자는 학력/업무경력/희망급여/단체활동/향후 목표를 포함하는 이력서를 만들수 있다. Negotiable 사용자는 자신의 이력서를 사용자는 이력서를 활성화/비활성화 할수 있다. 게시할수 있다. 사용자는 이력서를 여러 개 만들수 있다. Valuable 사용자는 이력서를 수정/삭제할 수 있다. Estimatable Complex Story - 복잡한 스토리  문제 조사 스토리와 기능개발 스토리로 분리 Small 웹에서 신용카드를 처리하는 방법을 조사한다. (Spike) ( 개발자 한두명이 최대허용시간을 정하고 연구/조사 해본다 ) 기업은 채용 공고를 게시할 때 Testable 신용카드로 결제할 수 있다. 사용자는 신용카드로 결제 할수 있다. User Stories for Agile Requirements 19
  • 20. What makes a good story? 스토리는 테스트 가능하도록 작성해야 한다. Independent  테스트는 스토리가 고객의 요구를 만족시키게 개발되었다는것을 확인할수 있게 한다.  테스트는 자동화가 가능하도록 작성해야 한다. Negotiable 사용자가 소프트웨어를 쉽 신규 사용자가 별도의 교육없이 작 Valuable 게 사용할 수 있어야 한다. 업을 완료할 수 있어야 한다. Estimatable 어떤 화면도 사용자를 오 새 화면은 95%의 경우에 2초안에 Small 래 기다리게 해선 안된다. 나타나야 한다. Testable User Stories for Agile Requirements 20
  • 21. Steps  스토리란 무엇인가 ?  스토리 작성하기  사용자 역할 모델링  스토리 수집하기  Do & Don‟t  사용자 스토리 추정  릴리즈 / 이터레이션 계획  왜 사용자 스토리인가 ? User Stories for Agile Requirements 21
  • 22. The User - 많은 프로젝트들이 한종류의 사용자만 있다고 가정한다. - 모든 스토리들을 한명의 사용자 관점에서 작성한다. - 모든 사용자가 같은 목표(Goal)를 가지고 있다고 가정한다. - 이에 따라 스토리를 빼먹는 경우가 발생한다. User Stories for Agile Requirements 22
  • 23. BigMoneyJobs – Who‟s the User ? Mario Allan Scott 이제 막 졸업하고 마우이에서 윈드서핑 현재 일자리가 싫지는 직장을 구하는 중 만 즐길수 있다면 어떤 않지만 이직할때가 되 일자리라도 상관없음 었다고 생각중 Carrie Kindra 현재 직장이 있지만 6개월전 해고당하 항상 더 나은 일자리 고 일자리가 없어 를 염두에 두고 있음 이젠 어떤곳이라도 취직하고 싶음 마우이에 있는 일자리가 게시되면 자동으로 통보해주기 바람 매달 한번정도 접속하여 자신이 선택할수 있는 일자리들을 검색 Chris 인사팀 담당자로 하루에 4시간 이상 필요인력 충원을 위해 사이트 이용 구인 공고를 게시 하려고 함 역 할 사 용 자 Peter 구직자 Scott XX사 인사팀 최초 구직자 Mario 이력서 검토 담당자 해고 피해자 Kindra 지역 선호자 Allan Richard 관찰자 Carrie 채용 공고 게시자 Chris , Richard 일자리와 인력을 모 이력서 조회자 Peter , Richard 두 찾는 헤드헌터 * 또는 상근 , 비상근 , 게약직 , 인턴 등등으로도 구분 User Stories for Agile Requirements 23
  • 24. User Role Modeling Steps 1. 브레인 스토밍 1. 고객과 한께 가능한 많은 개발자가 한방에 모두 모여 회 의를 시작한다. 2. 각자 카드를 한 묶음 가지고 간다. 2. 목록 초안 조직화 3. 각자 생각나는 사용자 역할을 적어 테이블/칠판에 놓는 다. - 평가는 하지 않는다. 3. 역할 통합하기 - 적고 내려놓으면서 단지 역할의 이름만을 말한다. - 새로 적을수 없을때까지 계속한다. ( 보통 약 15분이 면 충분하다 ) 4. 역할 다듬기 역 할 사 용 자 구직자 Scott 최초 구직자 Mario 해고 피해자 Kindra 지역 선호자 Allan 관찰자 Carrie 채용 공고 게시자 Chris , Richard 이력서 조회자 Peter , Richard User Stories for Agile Requirements 24
  • 25. User Role Modeling Steps 1. 브레인 스토밍 비슷하거나 중첩되는 역할끼리 모아 놓는다. * 중복되면 겹쳐 놓는다. 완전히 같다면 카드를 포개 놓는다. 2. 목록 초안 조직화 대학 졸업자 채용공고 게시자 이력서 조회자 최초 구직자 채용 담당자 3. 역할 통합하기 해고 피해자 지역 선호자 구직자 4. 역할 다듬기 관찰자 관리자 User Stories for Agile Requirements 25
  • 26. User Role Modeling Steps 1. 브레인 스토밍 - 각 역할이 의미하는 바를 토론한다. - 역할을 합치거나 좀더 Generic 한 카드로 교체한다. - 프로젝트의 성공에 상관없다고 생각하는 카드는 버린다. 2. 목록 초안 조직화 구직자 채용 담당자 관리자 3. 역할 통합하기 해고 피해자 내부 채용 담당자 4. 역할 다듬기 지역 선호자 외부 채용 담당자 최초 구직자 User Stories for Agile Requirements 26
  • 27. User Role Modeling Steps 1. 브레인 스토밍 - 역할 속성들을 정의한다. - 소프트웨어를 사용하는 빈도 - 해당 분야에 관한 전문 지식 수준 - 컴퓨터 및 소프트웨어에 대한 일반적인 숙련도 - 개발 대상 소프트웨어에 대한 숙련도 2. 목록 초안 조직화 - 소프트웨어에 대한 일반적인 사용 목적 (어떤 사용자들은 편리함, 어떤사용자들은 다양한 기능선호) 사용자 역할 : 내부 채용 담당자 3. 역할 통합하기 특별히 컴퓨터를 잘 사용하지는 못하지만, 웹을 이용하는 데 꽤 능숙하다. 자주는 아니지만 시스템 의 세부 기능까지 모두 사용할 것이다. 채용공고를 작성하기 위해 다른 기업의 채용 공고를 참고할 것이다. 사용하기 쉬워야 한다. 하지만 더욱 중요한 것은 그가 익힌 내용을 몇 달 뒤에 다시 떠올 리기 쉬워야 한다는 것이다. 4. 역할 다듬기 도움 1) 등장인물(Persona) 만들기 도움 2) 극단적 인물 만들기 마리오는 SpeedyNetwoks라는 - 양다리를 걸치는 아가씨의 PDA 하이엔드 네트워크 컴포넌트 제조 회사의 인사 부서에 6년째 - 눈이 잘 안보이는 어른들의 PDA 근무하고 있는 채용 담당자다. 마리오는 자유 시간 근무제에 따라 금요일에는 재택근무를 한다. 마리오는 컴퓨터를 아주 잘 사용하며 자신이 사용 하는 프로그램에 대해서는 스스로 파워유저라고 생 각한다. 마리오의 부인, 킴(Kim)은 스탠포드 대학에 서 화학 분야 박사 과정을 곧 마칠 것이다. SpeedyNetworks가 지속적으로 성장하고 있기 때 문에 마리오는 언제나 좋은 기술자들을 찾고 있다. User Stories for Agile Requirements 27
  • 28. Steps  스토리란 무엇인가 ?  스토리 작성하기  사용자 역할 모델링  스토리 수집하기  Do & Don‟t  사용자 스토리 추정  릴리즈 / 이터레이션 계획  왜 사용자 스토리인가 ? User Stories for Agile Requirements 28
  • 29. Techniques for Gathering Stories 1. 사용자 인터뷰 - 대화가 중요하다. - 닫힌 질문을 하지마라 ( 예 / 아니오 식의 답변을 요구하는 ) 2. 설문조사 - 가지고 있는 스토리에 대한 정보수집용으론 좋다 - 폭넓은 기존 사용자 층에 대한 조사 3. 관찰 - 실 사용자가 어떻게 SW를 사용하고 있는지 살펴본다. 4. 스토리 작성 워크숍 - 개발자 , 사용자 , 고객 그외 스토리 작성에 기여할 수 있는 사람들을 포함 - 질이 아니라 양에 기반한 가능한 많은 스토리를 만들어 낸다. - 우선순위를 매기지 않는다. - Template : “ As a <User Role> , I want <goal> so that <reason> “ “ 나는 <역할>로서 <비즈니스 가치> 를 위해 <기능>을 원한다.” User Stories for Agile Requirements 29
  • 30. Steps  스토리란 무엇인가 ?  스토리 작성하기  사용자 역할 모델링  스토리 수집하기  Do & Don‟t  사용자 스토리 추정  릴리즈 / 이터레이션 계획  왜 사용자 스토리인가 ? User Stories for Agile Requirements 30
  • 31. Guidelines for Good Stories 1. 목적 스토리로 시작하라 - 하나의 사용자 역할을 선택하여 시스템을 사용하는 주 목적을 식별 2. 케이크 자르듯 나누어라 - 스토리를 나눌때 하나의 작업이 처음부터 끝까지 포함되도록 하라 - 기능별 분리의 폐해 ( 1.구직자는 입력양식에 값을 넣는다. 2.양식의 값이 DB 에 기록된다.) 3. 닫힌 스토리를 작성하라 - 의미 있는 목적을 달성하는 형태로 작성하여 사용자로 하여금 뭔가를 해냈다고 느끼게 하는것 - 예) 채용공고를 관리할수 있다  이력서를 삭제/검토 할수 있다. 마감일을 변경할수있다. 4. 제약사항 기록하기 - 제약사항을 카드에 기록하여 벽에 붙여둠으로서 잊지 않도록 한다. - 예) 시스템은 최대 50명까지 동시 사용자를 지원해야 한다. 모든 버전 윈도우를 지원해야한다. 5. 스토리의 크기는 시간축에 맞추어라 - 바로 다음 이터레이션용 스토리는 작고 자세하게 , 훨씬 나중에 할것은 크게 작성한다. 다양한 수준으로 스토리를 작성하라 6. 되도록 사용자 인터페이스를 배제하라 7. 스토리에 사용자 역할을 포함하라 - 사용자 보다는 구직자 또는 마리오 라는 역할을 지정하라 8. 한명의 사용자를 대상으로 작성하라 9. 능동태로 작성하라 - 이력서는 구직자에 의해 게시될 수 있다  구직자는 이력서를 게시할 수 있다. 10. 고객이 작성하라 11. 스토리카드에 번호를 부여하지 마라 - 차라리 짧은 제목을 붙이고 이를 대신하여 지칭하라 12. 목적을 잊지 말라 - 스토리는 대화를 재기하기 위해 기억하면 될 정도의 세부사항만을 기록 - 너무 많은 세부사항을 적으면 카드가 대화를 대신하게 된다. User Stories for Agile Requirements 31
  • 32. Steps  스토리란 무엇인가 ?  스토리 작성하기  사용자 역할 모델링  스토리 수집하기  Do & Don‟t  사용자 스토리 추정  릴리즈 / 이터레이션 계획  왜 사용자 스토리인가 ? User Stories for Agile Requirements 32
  • 33. 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. 정직하게 추정해야 한다. 일관되게 유지해야 한다. User Stories for Agile Requirements 33
  • 34. Steps  스토리란 무엇인가 ?  스토리 작성하기  사용자 역할 모델링  스토리 수집하기  Do & Don‟t  사용자 스토리 추정  릴리즈 / 이터레이션 계획  왜 사용자 스토리인가 ? User Stories for Agile Requirements 34
  • 35. Release, Iteration, Velocity - 릴리즈는 여러 개의 이터레이션으로 이루어진다. - 각 이터레이션은 같은 크기의 상자와 같다. - 스토리는 각각의 상자에 꽉찰때까지 채워진다. - 상자의 크기는 각 이터레이션에 대한 속도이다. Iteration Iteration 2 1 1 1 2 1 2 3 3 4 1 5 4 6 Release User Stories for Agile Requirements 35
  • 36. Three Levels of ... Planning Precision Release Plan Tasks Iteration 사용자는 이력서를 작성.. 3 UI 작성 8 Iteration Plan 테스트 모듈 작성 3 관리자는 채용정보를.. 2 1 Middle Tier 작성 4 공통 모듈 작성 1 Iteration Daily Plan Daily Plan Daily Plan 기업은 채용정보를 게시.. 4 사용자는 다수의 이력.. 1 2 Iteration Plan 어제 UI 작성 시작했다. 오늘 집에가기 전에 끝내부러~ Daily Plan Daily Plan Daily Plan User Stories for Agile Requirements 36
  • 37. Release Planning 1. 언제 릴리즈 할것인가 ? - 특정일자 / 몇번의 이터레이션 .. 2. 각 스토리의 우선순위는 어떻게 되는가 ? A. DSDM – MoSCoW ( Must , Should , Could , Won‟t ) B. 고객 맘대로 / 위험도 순 .. 3. 이터레이션 길이 선택 - 대체로 1-4주가 적당 4. 스토리 점수로 예상 기간 산정 – 이전 속도/첫 이터레이션 속도.. 5. 릴리즈 계획 생성 – 우선순위별 선택하여 이터레이션에 할당 User Stories for Agile Requirements 37
  • 38. Iteration Planning 1. 스토리에 대해 토의 A. 각 스토리를 완전히 이해할수 있게 고객과 대화 2. 스토리를 작업단위로 나눈다 A. 개발자들에게 알맞은 작업 단위로 분리 – 전문분야별 할당 등 3. 각 작업마다 개발자 한 명이 책임을 맡는다. A. 해당 작업을 완료하는 책임. BUT “모두 함께 한다”는 마음가짐 4. 개발자가 자신이 맡은 작업량을 추정 User Stories for Agile Requirements 38
  • 39. Steps  스토리란 무엇인가 ?  스토리 작성하기  사용자 역할 모델링  스토리 수집하기  Do & Don‟t  사용자 스토리 추정  릴리즈 / 이터레이션 계획  왜 사용자 스토리인가 ? User Stories for Agile Requirements 39
  • 40. Why User Stories ? 1. 구두 의사소통 2. 이해하기 쉽다 3. 계획수립에 적합한 크기 4. 반복개발에 효과적 5. 세부사항 고려를 미룰수있다 6. 참여적 설계를 유도 - 스토리가 많을때 스토리 사이의 관계를 이해하기 어렵다  사용자 역할을 사용 7. 암묵적 지식을 구축  실 개발전에는 스토리를 적당한 수준이상으로 유지 - 요구사항 추적이 필요한경우 문서 추가 작성 부담  이터레이션별 스토리를 문서로 취합  테스트도 문서에 추가 - 큰 규모의 팀에서는 대화도 기록이 필요하다.  절충해서 적용 User Stories for Agile Requirements 40
  • 41. 우리가 차용할수 있는 것 ? 1. 스토리 카드 2. 유저 역할 모델 & Persona 3. 이상적 작업일 4. 스토리 점수 5. 팀단위 Wideband Delphi 추정 6. 이터레이션과 속도 User Stories for Agile Requirements 41
  • 42. Questions ? Please contact 권정혁 , guru@xguru.net Twitter : @xguru 2010-01-26 http://xguru.net
  • 43. 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 User Stories for Agile Requirements 43