User stories

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

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 Valuable  의존성은 추정을 어렵게 한다. 기업은 채용공고를 게시할때 비자카 드로 결제할수 있다. 기업은 채용공고를 게시할때 마스터 카드로 결제할수 있다. 첫 카드는 3일 다른카드는 1일 기업은 채용공고를 게시할때 아메리 칸익스프레스카드로 결제할수 있다. Estimatable Small 의존성이 있는 스토리들을 합쳐 좀더 큰 하나의 독립적인 스토리로 만든다  기업은 채용공고를 게시할때 신용카드로 결제할수 있다(5일) 스토리들을 다른방식으로 분리한다. Testable  고객은 한종류의 신용카드로 결제할수 있다.  고객이 결제할 수 있는 신용카드는 두 종류가 더 있다. 각각의 스토리에 작업추정치를 두가지로 부여한다. User Stories for Agile Requirements 15

16. What makes a good story? 협상가능 : 스토리는 계약서/SRS처럼 꼭 구현해야 한다는 기록이 아니다. Independent Negotiable Valuable Estimatable Small Testable  대화를 이끌기 위한 단서지, 그 자체로 완성된 상세한 요구사항이 아니다. 너무 상세하게 적는다면 그것은 완성된것으로 추측하게되어 대화의 단절을 가져온다. 기업은 채용공고를 게시할때 신용카드로 결제할수 있다. 주) 비자,마스터,아멕스카드를 지원한다. 디스커버는 검토 기업은 채용공고를 게시할때 신용카드로 결제할수 있다. 주) 비자,마스터,아멕스카드를 지원한다. 디스커버는 검토 100달러 이상 구매시 카드 뒷면의 ID 번호를 확인한다. 시스템은 카드번호의 첫 두자리로 카드의 종류를 알수 있다. 시스템은 다음 사용에 대비하여 카드번 호를 저장해 두어야 한다. 카드의 유효기간 연/월을 수집한다. 기업은 채용공고를 게시할때 신용카드로 결제할수 있다. 주) 디스커버 카드도 지원해야 하나 ? 내 주) 카드 종류를 고르는 항목은 필요없다(카드 번호 첫2자리로 알수있음) 비자,마스타카드,아멕스 카드 테스트 (통과) 다이너스 클럽 테스트(실패) 정상/비정상 카드 ID 테스트, 분실카드 ID 테스트. 유효 기간 만료된 카드 테스트 100달러 이상/이하 테스트 User Stories for Agile Requirements 16

17. What makes a good story? 사용자와 고객 혹은 구매자에게 가치가 있어야 한다. Independent 사용자 직책과 연봉에 따라 채용정보를 검색할수 있다. Negotiable 구매자 ISO 9001 감사에 적합한 문서를 작성한다. CMM 레벨 3에 부합하게 소프트웨어를 개발한다. Valuable 관리자 프로그램 설정 정보를 중앙 저장위치에서 읽어와야 한다. Estimatable Small Testable 모든 데이터베이스 연결은 커넥션 풀을 통해 이 루어 져야 한다. 사용자 라이센스 5개로 50명까지 데이터베이 스에 연결하여 사용할수 있어야 한다. 모든 에러 처리 및 로그 생성은 공통 클래스들 을 통해 이루어 져야 한다. 모든 에러는 사용자에게 보여야 하며, 일관된 형태의 로그로 기록되어야 한다. User Stories for Agile Requirements 17

18. What makes a good story? 각 스토리의 크기 혹은 작업 소요 시간을 추정(추측)할수 있어야 한다. Independent Negotiable 해당분야의 지식 (Domain Knowledge) 이 부족 작성한 고객과 직접 의논 Valuable 스파이크(Spike)를 수행 Estimatable 기술적인 지식이 부족  스파이크와 실제구현의 두개 스토리로 분리 (서로 다른 이터레이션에 배치) Small Testable 스토리가 너무 크다 좀더 작은 단위로 나누거나 큰 추정치를 부여하고 일단 마감 User Stories for Agile Requirements 18

19. What makes a good story? 너무 크거나 너무 작으면 사용하기 어렵다 Independent Negotiable Compound Story - 복합적인 스토리 사용자는 학력/업무경력/희망급여/단체활동/향후 목표를 포함하는 이력서를 만들수 있다. 사용자는 이력서를 활성화/비활성화 할수 있다. 사용자는 자신의 이력서를 게시할수 있다. 사용자는 이력서를 여러 개 만들수 있다. Valuable Estimatable 사용자는 이력서를 수정/삭제할 수 있다. Complex Story - 복잡한 스토리  문제 조사 스토리와 기능개발 스토리로 분리 Small 웹에서 신용카드를 처리하는 방법을 조사한다. (Spike) ( 개발자 한두명이 최대허용시간을 정하고 연구/조사 해본다 ) Testable 기업은 채용 공고를 게시할 때 신용카드로 결제할 수 있다. 사용자는 신용카드로 결제 할수 있다. User Stories for Agile Requirements 19

20. What makes a good story? 스토리는 테스트 가능하도록 작성해야 한다. Independent  테스트는 스토리가 고객의 요구를 만족시키게 개발되었다는것을 확인할수 있게 한다.  테스트는 자동화가 가능하도록 작성해야 한다. Negotiable Valuable 사용자가 소프트웨어를 쉽 게 사용할 수 있어야 한다. 신규 사용자가 별도의 교육없이 작 업을 완료할 수 있어야 한다. 어떤 화면도 사용자를 오 래 기다리게 해선 안된다. 새 화면은 95%의 경우에 2초안에 나타나야 한다. Estimatable Small Testable User Stories for Agile Requirements 20

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 최초 구직자 Mario 해고 피해자 Kindra 지역 선호자 Allan Richard 관찰자 Carrie 채용 공고 게시자 Chris , Richard 일자리와 인력을 모 두 찾는 헤드헌터 이력서 조회자 Peter , Richard XX사 인사팀 이력서 검토 담당자 * 또는 상근 , 비상근 , 게약직 , 인턴 등등으로도 구분 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) 만들기 마리오는 SpeedyNetwoks라는 하이엔드 네트워크 컴포넌트 제조 회사의 인사 부서에 6년째 근무하고 있는 채용 담당자다. 마리오는 자유 시간 근무제에 따라 금요일에는 재택근무를 한다. 마리오는 컴퓨터를 아주 잘 사용하며 자신이 사용 하는 프로그램에 대해서는 스스로 파워유저라고 생 각한다. 마리오의 부인, 킴(Kim)은 스탠포드 대학에 서 화학 분야 박사 과정을 곧 마칠 것이다. SpeedyNetworks가 지속적으로 성장하고 있기 때 문에 마리오는 언제나 좋은 기술자들을 찾고 있다. 도움 2) 극단적 인물 만들기 - 양다리를 걸치는 아가씨의 PDA - 눈이 잘 안보이는 어른들의 PDA User Stories for Agile Requirements 27

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

31. Guidelines for Good Stories 1. 목적 스토리로 시작하라 - 하나의 사용자 역할을 선택하여 시스템을 사용하는 주 목적을 식별 2. 케이크 자르듯 나누어라 - 스토리를 나눌때 하나의 작업이 처음부터 끝까지 포함되도록 하라 3. 닫힌 스토리를 작성하라 - 의미 있는 목적을 달성하는 형태로 작성하여 사용자로 하여금 뭔가를 해냈다고 느끼게 하는것 4. 제약사항 기록하기 - 제약사항을 카드에 기록하여 벽에 붙여둠으로서 잊지 않도록 한다. - 기능별 분리의 폐해 ( 1.구직자는 입력양식에 값을 넣는다. 2.양식의 값이 DB 에 기록된다.) - 예) 채용공고를 관리할수 있다  이력서를 삭제/검토 할수 있다. 마감일을 변경할수있다. - 예) 시스템은 최대 50명까지 동시 사용자를 지원해야 한다. 모든 버전 윈도우를 지원해야한다. 5. 스토리의 크기는 시간축에 맞추어라 - 바로 다음 이터레이션용 스토리는 작고 자세하게 , 훨씬 나중에 할것은 크게 작성한다. 다양한 수준으로 스토리를 작성하라 6. 되도록 사용자 인터페이스를 배제하라 7. 스토리에 사용자 역할을 포함하라 - 사용자 보다는 구직자 또는 마리오 라는 역할을 지정하라 8. 한명의 사용자를 대상으로 작성하라 9. 능동태로 작성하라 - 이력서는 구직자에 의해 게시될 수 있다  구직자는 이력서를 게시할 수 있다. 10. 고객이 작성하라 11. 스토리카드에 번호를 부여하지 마라 12. 목적을 잊지 말라 - 차라리 짧은 제목을 붙이고 이를 대신하여 지칭하라 - 스토리는 대화를 재기하기 위해 기억하면 될 정도의 세부사항만을 기록 - 너무 많은 세부사항을 적으면 카드가 대화를 대신하게 된다. User Stories for Agile Requirements 31

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

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

36. 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 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

40. Why User Stories ? 1. 구두 의사소통 2. 이해하기 쉽다 3. 계획수립에 적합한 크기 4. 반복개발에 효과적 5. 세부사항 고려를 미룰수있다 6. 참여적 설계를 유도 7. 암묵적 지식을 구축 - 스토리가 많을때 스토리 사이의 관계를 이해하기 어렵다  사용자 역할을 사용  실 개발전에는 스토리를 적당한 수준이상으로 유지 - 요구사항 추적이 필요한경우 문서 추가 작성 부담  이터레이션별 스토리를 문서로 취합  테스트도 문서에 추가 - 큰 규모의 팀에서는 대화도 기록이 필요하다.  절충해서 적용 User Stories for Agile Requirements 40

41. Why User Stories ? 1. 구두 의사소통 2. 이해하기 쉽다 3. 계획수립에 적합한 크기 4. 반복개발에 효과적 5. 세부사항 고려를 미룰수있다 6. 참여적 설계를 유도 7. 암묵적 지식을 구축 - 스토리가 많을때 스토리 사이의 관계를 이해하기 어렵다  사용자 역할을 사용  실 개발전에는 스토리를 적당한 수준이상으로 유지 - 요구사항 추적이 필요한경우 문서 추가 작성 부담  이터레이션별 스토리를 문서로 취합  테스트도 문서에 추가 - 큰 규모의 팀에서는 대화도 기록이 필요하다.  절충해서 적용 User Stories for Agile Requirements 41

42. 우리가 차용할수 있는 것 ? 1. 스토리 카드 2. 유저 역할 모델 & Persona 3. 이상적 작업일 4. 스토리 점수 5. 팀단위 Wideband Delphi 추정 6. 이터레이션과 속도 User Stories for Agile Requirements 42

43. Questions ? 권정혁 , guru@xguru.net Twitter @xguru 2010-01-26 http://xguru.net

44. 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 44

User stories

정혁 권

User stories