\"《敏捷軟件開發：用戶故事實戰》的特色如下： 專注於“用戶故事”這一靈活、敏捷和實用的需求方法 強調如何用*短的時間開發*符合用戶需求的軟件應用 揭示如何在不能直接與用戶交流的情況下搜集用戶故事 精闢闡述如何圍繞著用戶故事進行全面的規劃、進度、估算和測試 詮釋用戶故事的優勢，用戶故事與用例、使用場景和傳統需求方法的不同 極限編程（Extreme Programming）、Scrum或其他任何敏捷方法的理想搭檔 《敏捷軟件開發：用戶故事實戰》的精彩內容： 用戶角色建模：理解不同用戶角色之間的共性與差異 搜集故事：用戶訪談、問卷調查、觀察和工作坊 與管理者、培訓師、銷售人員和其他代理人合作 為驗收測試寫用戶故事 運用故事來排優先級、設進度和估算發布成本 各章末尾包含思考練習題 \"

\"作為敏捷社區的經典名作，《敏捷軟件開發：用戶故事實戰》不負眾望，為軟件行業提供了一種高效的需求過程，通過用戶故事來節省時間、消除重復工作和開發更優秀的軟件。要想構建可以滿足用戶需求的軟件，最好的方法是從“用戶故事”開始，用簡明扼要的語言清楚明確地描述對實際用戶有價值的功能。在本書中，敏捷實干家提供了一個詳盡的藍圖來指導讀者如何編寫用戶故事，如何在軟件開發生命周期中實際運用用戶故事。 《敏捷軟件開發：用戶故事實戰》共5部分21章，介紹了如何寫出理想的用戶故事，造成用戶故事不理想的因素有哪些，如何在無法直接接觸到用戶的情況下有效搜集用戶故事，如何對寫好的用戶故事進行整理、排優先級並在此基礎上進行計劃、管理和測試。 《敏捷軟件開發：用戶故事實戰》適合采用XP、Scrum甚至其他自主敏捷方法的所有開發、測試、分析師和項目負責人閱讀和參考，可以幫助他們以更少的人手在更短的時間內開發出更符合用戶需求的產品或服務。 \"

\"作者簡介 邁克？科恩（Mike Cohn） 敏捷聯盟聯合創始人&Scrum聯盟聯合創始人及理事會主席，CST（Scrum認證講師），Mountain Goat Software創始人兼總裁。邁克從1984年開始編程，1988年開始管理軟件項目，1995年開始做自己的第一個Scrum項目，從此一發不可收，成為Scrum的忠實擁躉和積極的倡導者。他熟悉很多硬件和軟件環境，尤其擅長於指導組織采用和改進敏捷過程和技術的應用，幫助他們打造高績效的軟件開發企業。他服務過很多公司，從新創公司到財富40強都有，比如加拿大遊戲制作公司Bioware、第一資本Capital One、藝電Electronic Arts、谷歌，高月工作室High Moon Studios、財捷Intuit、JDA軟件，律商聯訊Lexis Nexis、航空航天公司洛克希德馬丁Lockheed Martin、微軟、尼爾森媒體調研、培生教育、飛利浦電器、旅遊公司Sabre、西門子、升陽微繫統、德州儀器、特納廣播公司TBS、人力資源軟件開發商Ultimate Software和雅虎。 譯者簡介 王凌宇 精益敏捷踐行者，PMI-ACP，PMP。歷任高級項目經理、研發經理、項目群經理、產品經理、敏捷教練等職位，現任上市公司PMO敏捷教練和研發管理專家。 教練指導過多個產品團隊實現敏捷轉型，成效顯著。對於精益敏捷方法的推廣應用，項目管理以及PMO的建設運營具有豐富的實踐經驗。參與譯著有《SAFe 4.0精粹：運用規模化敏捷框架實現精益軟件與繫統工程》。 \"

目 錄
第I部分 開 始
第1章 概述 3
什麼是用戶故事？ 4
細節在哪裡？ 5
“需要在多長時間內完成？” 7
客戶團隊 7
使用故事的過程是什麼樣的？ 8
計劃發布和迭代 9
什麼是驗收測試？ 11
為什麼要改變？ 12
小結 13
思考練習題 13
第2章 編寫故事 15
獨立的 15
可協商的 16
對用戶或客戶有價值的 18
可估算的 19
小的 20
拆分故事 20
合並故事 22
可測試的 23
小結 24
開發人員的責任 24
客戶的責任 24
思考練習題 24
第3章 用戶角色建模 27
用戶角色 27
角色建模步驟 29
通過頭腦風暴，創建初始的用戶角色集合 29
整理初始的角色集合 30
聚合角色 31
細化角色 32
兩個額外的技術 33
用戶畫像 33
**人物 34
如果有現場用戶呢？ 34
小結 35
開發人員的責任 35
客戶的責任 35
思考練習題 36
第4章 收集故事 37
引出和捕捉需求是不適用的 37
一點兒就夠用了，不是嗎？ 38
方法 39
用戶訪談 39
問卷調查 41
觀察 41
故事編寫工作坊 42
小結 44
開發人員的責任 45
客戶的責任 45
思考練習題 45
第5章 與用戶代理合作 47
用戶的經理 47
開發經理 48
銷售人員 49
領域專家 50
營銷團隊 50
前用戶 50
客戶 51
培訓師和技術支持 52
業務分析師或繫統分析師 52
如何與用戶代理合作？ 52
當用戶存在但訪問受限時 52
當真的找不到用戶時 53
你能自己做嗎？ 54
建立客戶團隊 54
小結 54
開發人員的責任 55
客戶的責任 55
思考練習題 55
第6章 用戶故事驗收測試 57
在編碼之前編寫測試 58
客戶定義測試 59
測試是過程的一部分 59
多少測試纔算多？ 59
集成測試框架 60
測試的類型 61
小結 62
開發人員的責任 62
客戶的責任 62
思考練習題 62
第7章 好故事編寫指南 63
從目標故事開始 63
縱切蛋糕 64
編寫封閉的故事 64
約束卡片 65
根據實現時間來確定故事規模 66
不要過早涉及用戶界面 66
需求不止故事 67
故事中包括用戶角色 67
為一個用戶編寫故事 68
用主動語態 68
客戶編寫 68
不要給故事卡編號 68
不要忘記目的 69
小結 69
思考練習題 69
第II部分 估算和計劃
第8章 估算用戶故事 73
故事點 73
團隊估算 74
估算 74
三角測量 76
使用故事點 77
如果用結對編程呢？ 78
“敲黑板” 79
小結 79
開發人員的責任 79
客戶的責任 79
思考練習題 80
第9章 發布計劃 81
我們希望什麼時候發布？ 82
希望在發布中包含哪些特性？ 82
故事優先級排序 83
混合優先級排序 84
風險故事 84
優先考慮基礎設施需求 85
選擇迭代長度 86
從故事點到預期工期 86
初始速率 86
猜測速率 87
創建發布計劃 87
小結 88
開發人員的責任 88
客戶的責任 89
思考練習題 89
**0章 迭代計劃 91
迭代計劃概述 91
討論故事 92
分解任務 92
認領責任 94
估算及確認 94
小結 95
開發人員的責任 96
客戶的責任 96
思考練習題 96
**1章 度量和監測速率 97
度量速率 97
計劃速率和實際速率 99
發布燃盡圖 100
迭代燃盡圖 102
小結 104
開發人員的責任 104
客戶的責任 105
思考練習題 105
第III部分 經常討論的話題
**2章 用戶故事不是什麼 109
用戶故事不是IEEE 830 109
用戶故事不是用例 112
用戶故事不是場景 115
小結 117
思考練習題 117
**3章 用戶故事的優點 119
口頭溝通 119
用戶故事容易理解 121
用戶故事的大小適合於計劃 122
用戶故事適合迭代開發 123
故事鼓勵推遲細節 124
故事支持隨機應變的開發 124
用戶故事鼓勵參與式設計 125
故事增強隱性知識 125
用戶故事的不足 126
小結 126
開發人員的責任 127
客戶的責任 127
思考練習題 127
**4章 用戶故事的不良“氣味” 129
故事太小 129
故事相互依賴 130
鍍金 130
細節過多 131
過早包含用戶界面細節 131
想得太遠 132
故事拆分太頻繁 132
客戶很難對故事排列優先級 132
客戶不願意寫故事並對故事進行優先級排序 133
小結 134
開發人員的責任 134
客戶的責任 134
思考練習題 134
**5章 在Scrum項目中使用用戶故事 135
Scrum是迭代式和增量式的 135
Scrum基礎 136
Scrum團隊 137
產品待辦列表 137
Sprint計劃會議 138
Sprint評審會議 140
每日Scrum站會 140
在Scrum項目中加入用戶故事 142
用戶故事和產品待辦列表 142
Sprint計劃會議中使用用戶故事 142
Sprint評審會議中使用用戶故事 143
用戶故事和每日Scrum站會 143
案例學習 143
小結 144
思考練習題 145
**6章 其他主題 147
處理非功能性需求 147
紙質還是軟件？ 148
用戶故事和用戶界面 150
保留故事 152
用戶故事描述bug 153
小結 154
開發人員的責任 154
客戶的責任 154
思考練習題 155
第IV部分 一個完整的項目案例
**7章 用戶角色 159
項目 159
識別客戶 159
識別一些初始角色 160
聚類與細化 161
角色建模 163
增加用戶畫像 164
**8章 故事 165
Teresa的故事 165
Ron船長的故事 168
初級海員的故事 168
非海員禮品購買者的故事 169
報表查看者的故事 169
一些管理員的故事 170
結束 171
**9章 估算故事 173
**個故事 174
**搜索 176
評分和評價 177
賬號 177
完成估算 178
所有的估算 179
第20章 計劃發布 181
估算速率 181
對故事進行優先級排序 182
完成的發布計劃 183
第21章 驗收測試 185
搜索的測試 185
購物車的測試 186
購買書籍 187
用戶賬號 188
管理 188
測試約束 189
*後一個故事 190
第V部分 附 錄
附錄A 極限編程概述 193
附錄B 各章思考練習題參考答案 203
參考文獻 217

第2章 編寫故事 在這一章裡，我們將介紹如何編寫故事。為了創建好的故事，我們需要關注六個特征。一個好的故事應該具備以下特征（INVEST）： 獨立的（Independent） 可協商的（Negotiable） 對用戶或客戶有價值的（Valuable to users or customers） 可估算的（Estimatable） 小的（Small） 可測試的（Testable） 《極限編程》（Extreme Programming Explored）和《重構實踐手冊》（Refactoring Workbook）的作者比爾？威克（Bill Wake）建議用單詞首寫字母縮寫INVEST指代這六個特征（Wake 2003a）。
獨立的 我們應該盡量避免故事之間相互依賴。故事間的相互依賴會導致優先級排序和計劃出現問題。例如，假設客戶選定了一個高優先級的故事，而這個故事卻依賴於一個低優先級的故事，這樣就會產生問題。
故事間的相互依賴也會使估算變得*加困難。例如，假設我們在BigMoneyJobs網站上工作，需要編寫故事：公司如何為在網站上發布職位進行付費。我們可以寫出如下這些： 1.公司可以用Visa信用卡對發布職位進行付費。
2.公司可以用萬事達信用卡對發布職位進行付費。
3.公司可以用美國運通卡對發布職位進行付費。
假設開發人員估算需要3天的時間來支持**種信用卡（不管它是哪種），然後給第二種和第三種各分別需要1天。對於像這些有相互高依賴關繫的故事，你不知道如何對每個故事進行估算—哪個故事應該給3天的估算？ 當故事間出現這種依賴時，有兩種應對方法可以避免。
將相互依賴的故事合並成一個*大但獨立的故事。
尋找一種不同的方式來拆分故事。
將不同種類的信用卡合並成一個獨立的大故事（“公司可以使用信用卡對發布職位進行付費”）是不錯的，因為合並後的故事隻需要5天時間。如果合並後的故事花費的時間要比這長得多，通常一個*好的方法是找一個不同的維度來拆分故事。如果對這些拆分後故事的估算時間*長，那麼另一種拆分方法如下： 1.客戶可以用一種信用卡支付。
2.客戶可以用另外兩種信用卡支付。
如果你不想將這些故事合並在一起，並且無法找到一個很好的方法來拆分它們，那麼你還可以采用簡單的方法，即在故事卡上放兩個估算值：較高的估算值給二者之間必須在前面完成的故事，較低的估算值給後面接著要完成的故事。
可協商的 故事是可協商的，它們不是簽署好的書面合同或者是軟件必須實現的需求。故事卡是對功能的簡短描述，其細節是在客戶和開發團隊之間的對話中協商產生的。因為故事卡本身並不是詳細的需求，而是用來提示客戶和開發團隊進行對話的，所以它們不需要包括所有相關的細節。然而，在編寫故事的時候，如果一些重要的細節是已知的，那麼就應該把它們包括在故事卡的注釋中，如故事卡2.1所示。挑戰在於如何掌握包含“足夠”的細節。
公司可以用信用卡支付發布職位的費用。
注釋：接受Visa信用卡、萬事達信用卡和美國運通卡。考慮美國發現卡。
故事卡2.1 一個注釋了額外細節的故事卡 故事卡 2.1是一個不錯的故事卡，因為它提供了適量的信息供開發人員和客戶討論。當一個開發人員開始編碼實現這個故事時，故事卡會提示她必須支持三種主卡（Visa信用卡、萬事達信用卡和美國運通卡），同時她也可以詢問客戶是否已經決定接受美國發現卡。卡片上的注釋可以幫助開發人員和客戶恢復之前中斷的對話。理想的情況下，不管是原來對話的開發人員和客戶，還是其他的開發人員和客戶，對話都應該能夠恢復。把細節加入故事時，應該以此為指導原則。
另一方面，讓我們思考一個帶有太多注釋的故事，如故事卡2.2所示。這個故事有太多的細節（“收集卡片的過期月份和日期”），還結合了一個單獨的故事（“繫統可以存儲一個卡號供將來備用”）。
公司可以用信用卡支付發布職位的費用。
注釋：接受Visa信用卡、萬事達信用卡和美國運通卡。考慮美國發現卡。當支付金額超過100美元時，需要提供卡背面的ID號。繫統可以根據卡號的前兩位數字識別客戶使用的是何種類型的信用卡。繫統可以存儲卡號以備將來使用。收集信用卡的過期月份和日期。
故事卡2.2 細節過多的故事卡 處理故事卡2.2這樣的故事是**困難的。大多數讀者在閱讀這種故事時，會錯誤地關注本不應該關注的細節。然而，在許多情況下，過早指定細節隻會產生*多的工作。例如，如果兩個開發人員討論和估算一個簡單的故事“公司可以用信用卡支付發布職位的費用”，開發人員知道他們的討論有點抽像，他們不會誤以為他們的討論是明確的，或者他們的估算是準確的，因為缺少太多的細節。然而，如果向故事卡中添加*多類似故事卡2.2中的細節，關於這個故事的討論就有可能變得*加具體和真實。但這可能會導致錯誤的判斷：故事卡反映了所有的細節，沒有必要再與客戶進一步討論這個故事了。
如果我們把故事卡看作是開發人員和客戶進行對話的一種提示，那麼故事卡中包含如下信息就是很有價值的。
用來提示保持開發人員和客戶對話的一兩句話。
在整個對話期間待解決問題的注釋。
已經通過對話確定的細節將變成測試。如果使用紙質故事卡，我們可以在故事卡背面注明測試內容，如果使用電子繫統，可以標注在合適的地方。故事卡2.3和故事卡2.4展示了故事卡2.2中的過多細節如何變成測試，用於提示對話的注釋可以留存在故事卡正面。這樣，故事卡的正面包含故事本身和關於相關問題的注釋，而卡片的背面則包含用於驗證故事是否像預期的那樣，以測試形式體現的故事細節。
公司可以用信用卡支付發布職位的費用。
注釋：我們需要接受美國發現卡嗎？ UI注釋：不需要專門的字段來輸入信用卡類型（可以從信用卡號的前兩位來獲得該信息） 故事卡2.3 修正後的故事卡正面（隻有故事和需要討論的問題）