內容簡介
作為敏捷社區的經典名作，《敏捷軟件開發：用戶故事實戰》不負眾望，為軟件行業提供了一種高效的需求過程，通過用戶故事來節省時間、消除重復工作和開發更優秀的軟件。要想構建可以滿足用戶需求的軟件，最好的方法是從“用戶故事”開始，用簡明扼要的語言清楚明確地描述對實際用戶有價值的功能。在本書中，敏捷實干家提供了一個詳盡的藍圖來指導讀者如何編寫用戶故事，如何在軟件開發生命周期中實際運用用戶故事。
《敏捷軟件開發：用戶故事實戰》共5部分21章，介紹了如何寫出理想的用戶故事，造成用戶故事不理想的因素有哪些，如何在無法直接接觸到用戶的情況下有效搜集用戶故事，如何對寫好的用戶故事進行整理、排優先級并在此基礎上進行計劃、管理和測試。
《敏捷軟件開發：用戶故事實戰》適合采用XP、Scrum甚至其他自主敏捷方法的所有開發、測試、分析師和項目負責人閱讀和參考，可以幫助他們以更少的人手在更短的時間內開發出更符合用戶需求的產品或服務。
前 言
在20世紀90年代中期的大部分時間里，我都感到愧疚。我當時正在為一家公司工作，這家公司每年都會收購一家新公司。每次收購一家新公司，我都會被分派去負責打理他們的軟件開發團隊。收購的每個開發團隊都帶來了輝煌、美觀、冗長的需求文檔。我不可避免地感到愧疚，因為我自己的團隊從來沒有寫出過如此優美的需求規格說明。但是，我的團隊在生產軟件方面一直比我們收購的團隊成功得多。
我清楚我們成功的方法。然而，我總有一種難以名狀的感覺，如果我們能寫出大而冗長的需求文檔，我們可能會更加成功。畢竟，那正是我當時正在閱讀的書籍和文章中所描述的做法。如果成功的軟件開發團隊都在編寫華麗的需求文檔，那么看起來我們也應該這樣做。但是，我們從來沒有時間做。我們的項目總是太重要，需要我們盡快啟動，以至于我們從一開始就沒有時間來寫文檔。
因為我們從來沒有時間寫美觀而冗長的需求文檔，所以我們決定采用一種工作方式來與用戶溝通。我們不是把需求寫下來，讓它們來回傳遞，并在時間不夠用的時候還在談判，而是和客戶交談。我們會在紙上繪制界面樣例，有時候會創建原型，通常我們會寫一些代碼，然后向預期用戶展示我們編寫的內容。至少每月一次，我們會邀請一組具有代表性的用戶，并向他們演示我們開發的功能。通過貼近用戶并向他們演示小的增量進展，我們找到了一種方法來幫助我們在沒有美觀需求文檔的情況下取得成功。
盡管如此，肯特•貝克（Kent Beck）仍然感到愧疚，認為我們沒有按照我們應該的方式去做事。
1999年，肯特•貝克的革命性小冊子《解析極限編程》出版發行。一夜之間，我所有的愧疚蕩然無存。終于有人提出了開發人員和客戶之間用討論取代“寫文檔-商談-再寫文檔”的模式。肯特闡明了很多事情，并帶給我很多新的工作方法。但是，最重要的是，他證明了我從自己的實踐中領悟到的是正確的。
大量的前期需求收集和文檔可能在多方面導致項目失敗。最常見的一種情況是需求文檔本身成為軟件開發的目標。需求文檔只有在能夠幫助實現交付某些軟件的真正目標時才應該編寫。
大量的前期需求收集和文檔可能在多方面導致項目失敗的第二種情況是書面語言的不準確性。我記得很多年前聽到過一個小孩洗澡的故事。小孩的父親已經在浴缸中放滿了水，正準備幫助他的小孩進入水中。這個小孩大概兩三歲，先把腳趾頭伸入水中蘸了一下，然后迅速將腳趾移開，并告訴她的父親“讓它暖和一些”（make it warmer.）。父親把手伸入水中，驚訝地發現水不是太冷，已經比他女兒習慣的溫度更熱了。
父親思索了一下孩子的請求，意識到他們的溝通出現了問題，用相同的詞語來表示不同的意思。孩子“讓它暖和一些”的請求被任何成年人都解釋為“調高水溫”（increase the temperature）。然而，對于孩子來說，“讓它變暖”意味著“讓它接近我認為暖和的程度”。
文字，尤其是白紙黑字那樣的，通過它來表達軟件這樣復雜東西的需求，是比較簡單有限的載體。由于它們可能被誤解，所以我們需要用開發人員、客戶和用戶之間頻繁的對話來取代書面文字。用戶故事為我們提供了這種方法，讓我們寫下來足夠多我們不會遺忘的內容，并且我們可以估算和計劃，同時還鼓勵及時溝通。
讀完本書的第I部分時，你將準備開始改變總是嚴格寫下每一個需求最后細節的工作方式。讀完本書的時候，你會知道在具體環境中實施故事驅動過程所有的必要信息。本書分為四個部分和兩個附錄。
第I部分“開始”，描述開始編寫故事需要了解的一切。用戶故事的目標之一是讓人們說話而不是寫作。第I部分的目標是盡快讓你交談。第1章概述了什么是用戶故事以及如何使用故事。接下來的章節提供了編寫用戶故事，通過用戶角色建模收集故事，在無法訪問實際最終用戶時編寫故事以及測試用戶故事的更多細節。第I部分的結尾部分提供了一些指導方針，可以用來改進用戶故事。
第II部分“估算和計劃”，有了一系列用戶故事后，我們經常需要回答的第一件事是“需要花費多長時間來開發？”。第II部分介紹了如何使用故事點來估算故事，如何在3~6個月的時間范圍內計劃發布，如何更詳細地計劃隨后的迭代，最后如何度量進度并評估項目是否按照既定的意愿進行。
第III部分“經常討論的話題”，首先描述故事與用例，軟件需求說明和交互設計場景等需求方案的不同之處。隨后探討用戶故事的獨特優點，如何判斷出現問題的時間，如何調整敏捷過程Scrum以使用故事。最后一章著眼于各種小問題，例如是否在紙質卡片或者軟件系統中編寫故事以及如何處理非功能性需求。
第IV部分“一個完整的項目案例”，一個擴展的例子，旨在幫助歸納用戶故事的所有內容。如果說開發人員可以通過故事更好地理解用戶的需求，那么本部分的完整示例是非常重要的，這個示例將展示用戶故事的各個方面及其結合方式。
第V部分“附錄”，用戶故事源于極限編程。閱讀本書之前不需要熟悉極限編程。附錄A提供了極限編程的簡要介紹。附錄B包含對各章結尾思考練習題的解答。
目 錄
第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第10章 迭代計劃 91迭代計劃概述 91討論故事 92分解任務 92認領責任 94估算及確認 94小結 95開發人員的責任 96客戶的責任 96思考練習題 96第11章 度量和監測速率 97度量速率 97計劃速率和實際速率 99發布燃盡圖 100迭代燃盡圖 102小結 104開發人員的責任 104客戶的責任 105思考練習題 105第III部分 經常討論的話題第12章 用戶故事不是什么 109用戶故事不是IEEE 830 109用戶故事不是用例 112用戶故事不是場景 115小結 117思考練習題 117第13章 用戶故事的優點 119口頭溝通 119用戶故事容易理解 121用戶故事的大小適合于計劃 122用戶故事適合迭代開發 123故事鼓勵推遲細節 124故事支持隨機應變的開發 124用戶故事鼓勵參與式設計 125故事增強隱性知識 125用戶故事的不足 126小結 126開發人員的責任 127客戶的責任 127思考練習題 127第14章 用戶故事的不良“氣味” 129故事太小 129故事相互依賴 130鍍金 130細節過多 131過早包含用戶界面細節 131想得太遠 132故事拆分太頻繁 132客戶很難對故事排列優先級 132客戶不愿意寫故事并對故事進行優先級排序 133小結 134開發人員的責任 134客戶的責任 134思考練習題 134第15章 在Scrum項目中使用用戶故事 135Scrum是迭代式和增量式的 135Scrum基礎 136Scrum團隊 137產品待辦列表 137Sprint計劃會議 138Sprint評審會議 140每日Scrum站會 140在Scrum項目中加入用戶故事 142用戶故事和產品待辦列表 142Sprint計劃會議中使用用戶故事 142Sprint評審會議中使用用戶故事 143用戶故事和每日Scrum站會 143案例學習 143小結 144思考練習題 145第16章 其他主題 147處理非功能性需求 147紙質還是軟件？ 148用戶故事和用戶界面 150保留故事 152用戶故事描述bug 153小結 154開發人員的責任 154客戶的責任 154思考練習題 155第IV部分 一個完整的項目案例第17章 用戶角色 159項目 159識別客戶 159識別一些初始角色 160聚類與細化 161角色建模 163增加用戶畫像 164第18章 故事 165Teresa的故事 165Ron船長的故事 168初級海員的故事 168非海員禮品購買者的故事 169報表查看者的故事 169一些管理員的故事 170結束 171第19章 估算故事 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
