第1部分 起步
識別、編寫、測試用戶故事
第1章 概覽
幫助開發人員和客戶團隊雙方協作，任何一方都不能占絕對主導地位，保證資源的合理分配。
不要妄想在項目一開始就做出包羅萬象的決策，注重反饋，將各個決策分散到項目過程中。
客戶團隊活躍于軟件開發的全過程，編寫用戶故事、確定優先級，客戶團隊包括確保軟件符合潛在用戶需求的人，可以包括測試人員、產品經理、實際用戶和交互設計師
用戶故事工作量大小，迭代長度每個版本的計劃工作時間，迭代速率~用戶故事/迭代長度
一個發布由一個或多輪迭代組成，發布的要求是項目時間表和預期功能集合之間達到平衡
每個故事用故事點來估計，故事點表明一個故事相對于其他故事的大小和復雜度
驗收測試用來驗證實現的用戶故事是否符合客戶團隊的期望，測試應盡早在迭代中編寫，將假設和預期更早的與開發人員溝通
用戶故事強調對話交流而非書面溝通，代表用戶在單一環境中可能做的事情；用戶故事需要避免使用技術術語，保證客戶團隊和開發團隊都能理解；用戶故事可以促進考慮細節，且能更新；客戶團隊進行故事的優先級排列， 同時也要考慮開發團隊的意見和成本
第2章 編寫故事
獨立的：故事之間相互依賴
將相互依賴的故事合并成一個大的、獨立的故事；用一個不同的方式去分割故事
可討論的：關于細節的處理
故事卡包含一兩句短語，提醒開發人員和客戶進行對話；故事卡包含一些注釋，表明在對話中亟待解決的問題；將細節變成測試
對purchasers或users有價值的：避免過度關注技術和實現細節
讓客戶編寫用戶故事
可估計的：估算工作量
開發人員缺少領域知識；開發人員缺少技術知識；故事太大
小的：有助于制定計劃
合適的故事大小取決于團隊、容量以及使用的技術
按照創建、編輯、刪除這些動作來分解故事，或者根據數據邊界來分解故事
可測試的：量化的測試效果
第3章 用戶角色建模
用戶角色user role：一組屬性的集合，刻畫了一群人的特征以及這群人與系統可能的交互
角色建模的步驟：頭腦風暴，列出能想到的用戶角色——整理用戶集合——整合角色——提煉角色
兩個額外的技術：虛擬人物（假想的用戶角色代表，用戶強化用戶角色在團隊成員心中的印象）+極端人物（幫助考慮原本遺漏的故事，也可能產生新的用戶故事）
第4章 搜集故事
拖網 trawling 將收集需求比作捕魚
用戶訪談：通過提出開放式的/與背景無關的問題獲取用戶的本質需求
問卷調查：可以用于確定故事優先級，但不適合捕獲新的用戶故事
觀察：明確需求
故事編寫工作坊：編寫大量用戶故事，確定工作流
第5章 與用戶代理合作
用戶代理user proxy，在項目中代表用戶
誰適合做用戶代理？
用戶經理：并非軟件使用者，盡可能接觸終端用戶，不能得罪
開發經理：避免讓開發經理擔任用戶代理
銷售人員：通過銷售人員認識客戶
領域專家：水平較高，圍繞他們開發出來的產品可能對其他人不友好
市場營銷團隊：更關注產品特性的數量而非質量
以前的客戶：考慮其動機和目標是否與實際用戶一致
客戶purchaser：考慮用戶與客戶在需求上的差異
培訓師和技術支持：與實際用戶的差異
業務分析師或系統分析師：適合作為用戶代理，既懂技術，又熟悉軟件相關的領域知識
與用戶代理合作時，做些什么？
能接觸到用戶但訪問受限時，啟動用戶顧問團隊user task force提出意見和建議，用戶代理做決策
實在不能接觸到用戶時，可以使用多個用戶代理模擬用戶，避免開發出的系統僅僅滿足一個人的需求，并且確保多個代理來自不同的類型
設立客戶團隊的步驟：邀請真實用戶加入——確定項目負責人——確定項目成功必須的關鍵因素
第6章 用戶故事驗收測試
記錄客戶和開發團隊所討論過的細節，在寫代碼之前寫測試可以為開發人員提供有價值的信息，測試應當是軟件開發過程中的一部分
集成驗收測試工具FIT：每次迭代都會破壞一些已完成驗收測試的代碼，所以迭代后的測試應包含以往所有的測試，FIT通過明確輸入輸出，驗證程序得到輸入后是否能正確輸出
測試類型：功能測試/用戶交互測試/可用性測試/性能測試/壓力測試，測試的是缺陷，而非覆蓋率
第7章 優秀用戶故事準則
考慮從每個用戶角色使用目的
每個故事提供一個完整的端到端end to end的功能（每個功能有輸入有輸出）
權衡相互沖突的需求，編寫封閉故事
基于大故事實現的時間跨度，編寫小故事
在故事中包括用戶角色
故事的可讀性在只為一個用戶編寫時，是最強的
以主動語態編寫
由客戶編寫
不要過早涉及用戶頁面
第2部分 估算和計劃
項目計劃，為最高優先級的故事創建高層次的發布計劃
第8章 估算用戶故事
故事點：一個故事點的工作量可以看作一個理想日的工作
以團隊估算：估算故事由整個團隊進行
估算：將客戶和開發團隊集合；第一輪各寫各的，而后表達觀點；第二輪根據觀點重新估算；隨著輪數的增加，估算值會越來越統一
三角測量：幫助團隊驗證他們是否認同各個故事的工作量
使用故事點：每輪迭代能夠完成的故事點數要考慮 1、這輪迭代中是否有異常時間，2、估算方法保持不變，3、第一輪迭代的故事必須獨立
如果用結對編程呢？：工作量相同，速率值不一樣
開發人員給出工作量估算，客戶負責回答問題并澄清故事細節
第9章 發布計劃
已知每輪迭代的工作量估算，合理預測完成符合用戶期望的發布需要多少輪迭代
開發人員和客戶商定一個日期范圍，而非具體日期
決定在發布中包含哪些功能：DSDM優先級排列方法（must have,should have,could have,won't have this time）
排列故事優先級：考慮風險和相互影響；客戶和用戶也有自己的考慮，當客戶與開發相左時，交由客戶決定；估算故事點，成本也會影響客戶的優先級排序
混合優先級：客戶在確定優先級時，可能會分割故事
高風險故事：以價值優先為導向，開發人員會傾向于先做風險最高的故事，但最終必須由客戶決定
選擇迭代長度：開發人員和客戶共同選擇，長度越短進度越透明
初始速率：參考歷史值/執行一輪初始迭代獲取速率/猜測
創建發布計劃：設立初始期望，不斷調整期望和監控每輪迭代大的速率
開發人員提供信息輔助客戶準確排列優先級
第10章 迭代計劃
討論故事：調整故事優先級
分解任務：分割出某個特別困難的任務/展示給客戶幫助客戶了解的部分任務/分割能提高效率的任務
承擔職責：任務關聯團隊成員
估算并確認：評估是否承擔過度的職責
開發人員認領任務，客戶優化故事優先級順序
第11章 測量并監控速率
測量速率：兩三次迭代后才能獲得一個長期的、穩定的速率，只考慮通過驗收測試的故事，不能將部分完成的故事計算在速率內
計劃速率和實際速率：故事點圖和累計故事點圖
迭代燃盡圖（剩余故事點-迭代次數）：以故事點表示的在每輪迭代末剩余的工作量，雖然不能表示團隊的開發速度，但能更好的展示項目的整體進展
每日燃盡圖（剩余小時數-天）：展示團隊在某輪迭代中的進展
公開剩余工作量信息
第3部分 經常討論的話題
用戶故事與其他需求方法的區別
第12章 故事不是什么
常見的需求方法：1.用例use case 2.軟件需求指南software requirements specifications IEEE830 3.場景interaction design scenario
故事小于用例
IEEE 830關注解決方案的特征，用戶故事關心用戶目標
場景大于故事，場景較為具體
預想再全面，也無法得到一個完整的系統，原因是忽略的反饋系統
第13章 用戶故事的優勢
突出交流，保證溝通順暢
提供迅速的反饋周期，促成對需求的充分理解
便于迭代開發和制定計劃
鼓勵細節、隨機應變式開發、參與性涉及
缺點：不太適用大型項目（故事多、文檔的可回溯性）
第14章 用戶故事不良征兆一覽
故事太小
故事相互依賴
鍍金（開發人員實現了不需要的功能）
細節太多
過度考慮用戶界面細節
想得太遠
故事劃分太過頻繁
客戶難以為故事安排優先級
客戶不愿意寫用戶故事，不愿意排列優先級
了解不良征兆，找出解決方案
第15章 scrum與用戶故事
scrum：一種迭代遞增的軟件過程（遞增過程：團隊按功能點開發和發布軟件，每個迭代的工作往往不需要返工；迭代過程：通過持續改進來取得進展）
scrum基礎：30天1周期的print；4~7人的自組織開發團隊；待開發產品功能的backlog列表；計劃會議；評審會議；每日簡會
在sprint中使用用戶故事
第16章 其他話題
非功能性需求（性能、準確性、可維護性等）可以通過創建約束的方式來處理
紙質還是軟件？適合項目團隊就好
迭代過程中盡量避免用戶界面的反復變化
故事完成后，保留故事卡card
記錄缺陷報告形成封面故事卡
第4部分 一個完整的實例
編寫用戶故事-估算故事-做發布計劃-為故事編寫驗收測試
第17章 用戶角色
項目：了解項目詳情
定義客戶：幫助編寫用戶故事
定義一些角色雛形
整合與提煉
角色建模（使用頻率/用戶專業程度/用戶對電腦的數量程度/用戶對團隊正在開發的軟件的熟練程度/目的/用戶體驗）
添加虛擬人物
了解項目背景以及目標用戶，確定用戶畫像
第18章 一些用戶故事
不按照角色或者虛擬人物的順序寫出故事
先從一個特定的用戶角色或者虛擬人物開始寫出團隊能夠想到的所有故事，然后考慮下一個角色或虛擬人物
第19章 估算故事
用故事點代表理想日、復雜度或對團隊有意義的其他一些度量值
客戶與開發團隊通過多次討論，最終確定每個故事的故事點
第20章 發布計劃
確定迭代長度（考慮交付時間）
估算速率
給故事安排優先級
最終的發布計劃
第21章 驗收測試
在用戶故事的基本上，充分考慮細節輸出盡可能詳細的測試內容
