本書概覽
主要帶著每章的問題，看書找答案
第Ⅰ部分：起步
第一章 概覽
問題
1.1 用戶故事描述了對(duì)用戶、系統(tǒng)或軟件購買者有價(jià)值的功能，由以下三部分組成：
一份書面的故事描述，用來做計(jì)劃和作為提示；
有關(guān)故事的對(duì)話，用于具體化故事細(xì)節(jié)；
測(cè)試，用于表達(dá)和編檔故事細(xì)節(jié)且可用于確定故事何時(shí)完成
1.2 客戶團(tuán)隊(duì)包括確保軟件滿足用戶需求的所有人，可以包括測(cè)試人員、產(chǎn)品經(jīng)理、實(shí)際用戶、交互設(shè)計(jì)師
1.4 面向瀑布的模型過程中，客戶和用戶只在開始的適合參與進(jìn)來寫需求，在結(jié)束的適合驗(yàn)收軟件，不參與中間環(huán)節(jié)，故事驅(qū)動(dòng)的項(xiàng)目，客戶和用戶在項(xiàng)目整個(gè)過程中全程參與
用戶故事優(yōu)勢(shì)：
強(qiáng)調(diào)對(duì)話交流而不是書面溝通、可同時(shí)被你和開發(fā)人員理解、大小適合于做計(jì)劃、適用于迭代開發(fā)、鼓勵(lì)推遲考慮細(xì)節(jié)，知道非常清楚的倆姐自己的真正需求
1.5 測(cè)試應(yīng)該盡早的在迭代中編寫，客戶團(tuán)隊(duì)的假設(shè)和預(yù)期會(huì)更早與開發(fā)人員溝通。
小結(jié)
答案
第二章 編寫故事
問題
小結(jié)
史詩故事分兩種：復(fù)合和復(fù)雜
架構(gòu)刺探(Architectural Spike) -源于極限編程模式中的技術(shù)探險(xiǎn)，寫足夠的代碼來探知某個(gè)新興技術(shù)（或不熟悉的技術(shù)）的使用所可能帶來的技術(shù)風(fēng)險(xiǎn)， 對(duì)于復(fù)雜的調(diào)研任務(wù)，架構(gòu)Owner可能需要部分團(tuán)隊(duì)成員的配合，在Sprint中安排Spike類型的任務(wù)。
探針(Spike) - Spike是一種技術(shù)嘗試，用于通過快速失敗來降低風(fēng)險(xiǎn)。
答案
第三章 用戶角色建模
問題
小結(jié)
答案
第四章 搜集故事
問題
小結(jié)
不過在過程中評(píng)價(jià)故事的好壞，參與者覺得大家只是積累而不是評(píng)價(jià)故事，會(huì)更樂意參與
答案
第五章 與用戶代理合作
問題
小結(jié)
開發(fā)人員：負(fù)責(zé)幫助組織機(jī)構(gòu)為項(xiàng)目物色合適的客戶，了解不同類型的用戶代理怎么考慮你們正在開發(fā)的系統(tǒng)，他們的背景如何影響交互
客戶團(tuán)隊(duì)：如果你不是軟件的用戶，則要負(fù)責(zé)了解自己屬于哪類用戶代理；理解自己會(huì)將哪些偏見帶入項(xiàng)目中，如何克服這個(gè)問題，無論是依靠別人還是其他方法
答案
第六章 用戶故事驗(yàn)收測(cè)試
問題
小結(jié)
測(cè)試是一個(gè)兩步流程：第一，將測(cè)試要點(diǎn)記錄在故事卡的背面，任何適合發(fā)現(xiàn)新的測(cè)試，都可以記錄到故事卡的背面；第二，將測(cè)試要點(diǎn)變成全面的測(cè)試，這些測(cè)試可以用來演示故事已爭(zhēng)取、完整的實(shí)現(xiàn)。
一般在下面這些時(shí)候?qū)憸y(cè)試：開發(fā)人員和客戶討論故事且需要記錄明確的細(xì)節(jié)時(shí)；在迭代開始時(shí)，在寫代碼前作為一項(xiàng)專門的任務(wù)；在開發(fā)中或之后的任何時(shí)候發(fā)現(xiàn)新的測(cè)試時(shí)
考慮每個(gè)故事，然后問類似問題：關(guān)于這個(gè)故事，程序員還需要知道什么？對(duì)怎么實(shí)現(xiàn)這個(gè)故事，我的想法是什么？有沒有一些特殊情況會(huì)使這個(gè)故事有不一樣的行為？這個(gè)故事在什么情況會(huì)出錯(cuò)？
測(cè)試類型：用戶交互測(cè)試，確保所有用戶交互組建如期工作；可用性測(cè)試，確保程序好用；性能測(cè)試，測(cè)量應(yīng)用程序在各種符合下的工作情況；壓力測(cè)試，使應(yīng)用程序在用戶和事務(wù)的極限值情況或其他任何讓應(yīng)用程序處于壓力下的情況運(yùn)行
測(cè)試和開發(fā)活動(dòng)是合作負(fù)責(zé)不應(yīng)相對(duì)抗，測(cè)試的是缺陷，而不是覆蓋率，不必追求100%的代碼覆蓋率，隨著時(shí)間的推移，通過溝通和觀察哪些類型的測(cè)試經(jīng)常出現(xiàn)問題，項(xiàng)目中所有人都可以知道測(cè)試重點(diǎn)在哪些地方
答案
第七章 優(yōu)秀用戶故事準(zhǔn)則
問題
小結(jié)
封閉故事：一個(gè)封閉的故事是指那種隨著一個(gè)有意義的目標(biāo)的實(shí)現(xiàn)而結(jié)束的故事，能讓用戶使用后覺得她完成了某個(gè)任務(wù)。
如：招聘者可以審核針對(duì)他發(fā)布的招聘廣告發(fā)的簡(jiǎn)歷；招聘者可以更改招聘廣告的過期日期；招聘者可以刪除不合適的申請(qǐng)；
編寫封閉故事其實(shí)實(shí)在相互沖突得各種需求之間權(quán)衡的結(jié)果，故事要小到能做評(píng)估，小到方便的安排到一輪迭代中，也要足夠大（粗顆粒度、高層次的、抽象的），從而避免過早捕獲當(dāng)下還不需要的細(xì)節(jié)。
需求和解決方案不要混在一起
有些需求并不是故事，用戶故事不是“萬靈藥”
答案
第Ⅱ部分 估算和計(jì)劃
第八章 估算用戶故事
問題
小結(jié)
故事點(diǎn)（story point）估算，特性是團(tuán)隊(duì)可以定義自己認(rèn)為合適的故事點(diǎn)。團(tuán)隊(duì)可能決定定義一個(gè)故事點(diǎn)為一個(gè)理想日的工作，也可以定義為一個(gè)理想周的工作，還可以把故事點(diǎn)作為故事復(fù)雜度的測(cè)量。故事點(diǎn)有很多意義，是代表時(shí)間的模糊單位，或叫做NUT（Nebulous Units of Time）。建議用一個(gè)故事點(diǎn)工作量看到一個(gè)理想日。
三角測(cè)量，估算一個(gè)故事時(shí)，根據(jù)這個(gè)故事與其他一個(gè)或多個(gè)故事的關(guān)系來估算，不用太精確，三角測(cè)量是幫助團(tuán)隊(duì)驗(yàn)證他們沒有逐漸改變一個(gè)故事點(diǎn)含義的有效方法。
速率（velocity）代表一個(gè)團(tuán)隊(duì)再一輪迭代中完成（或期望完成）的故事點(diǎn)數(shù)?？捎靡惠喌乃俾蕘眍A(yù)測(cè)未來迭代的速率。
如使用結(jié)對(duì)編程，團(tuán)隊(duì)可選擇以理想結(jié)對(duì)日或理想個(gè)人來估算故事點(diǎn)，區(qū)別會(huì)表現(xiàn)再速率值上。
開發(fā)人員職責(zé)：負(fù)責(zé)用一個(gè)方式定義故事點(diǎn)，并且對(duì)團(tuán)隊(duì)可用和相關(guān)的，努力保證整個(gè)定義的一致性；負(fù)責(zé)給出誠實(shí)的估算，不屈服于誘惑或壓力而給出低的估算；負(fù)責(zé)以團(tuán)隊(duì)估算；負(fù)責(zé)估算與其他估算一致，即所有2點(diǎn)的故事都應(yīng)差不多
客戶職責(zé)：負(fù)責(zé)參加估算會(huì)議，但是你的任務(wù)是回答問題并澄清故事細(xì)節(jié)，不必參與故事估算
答案
第九章 發(fā)布計(jì)劃
問題
小結(jié)
DSDM包括一個(gè)排列優(yōu)先級(jí)的方法，稱為MoSCoW規(guī)則
必須有（must have）
應(yīng)該有（Should have）
可以有（Could have）
這次不會(huì)有（Won't have this time）
必須有指系統(tǒng)的基本功能，應(yīng)該有指的重要但短期有替代解決方法的功能，如果項(xiàng)目沒有時(shí)間約束，通常應(yīng)該有的功能是強(qiáng)制性的。
可以有的指如果沒時(shí)間可以再發(fā)布中不予考慮的功能
不會(huì)有的功能，是客戶期望擁有但同時(shí)承認(rèn)需要再后續(xù)發(fā)布中實(shí)現(xiàn)的功能
多維度排列故事優(yōu)先級(jí)
故事不能如期完成的風(fēng)險(xiǎn)
推遲實(shí)現(xiàn)一個(gè)故事時(shí)對(duì)其他故事的影響
故事對(duì)于廣泛用戶或客戶的重要性
故事與其他故事的內(nèi)聚性（如Zoom out 縮寫功能本書可能低優(yōu)先級(jí)，但Zoom In放大高優(yōu)先級(jí)）
混合優(yōu)先級(jí)
如有優(yōu)先級(jí)有異議，可分割整個(gè)故事，對(duì)獨(dú)立的故事排列出不同的優(yōu)先級(jí)
成本可改變優(yōu)先級(jí)、高風(fēng)險(xiǎn)故事、根據(jù)架構(gòu)需求按排優(yōu)先級(jí)
選擇迭代長度
迭代長度通常為1至4周，短迭代允許項(xiàng)目更加頻繁的做出調(diào)整，項(xiàng)目進(jìn)度也會(huì)更加透明，但每輪迭代會(huì)有少許額外開銷，假如不確定迭代長度，請(qǐng)選擇短迭代而不是長迭代，長迭代更容易犯錯(cuò)。
項(xiàng)目開發(fā)期間，盡量堅(jiān)持固定的迭代長度，保持固定的節(jié)奏，利于團(tuán)隊(duì)的開發(fā)速度。視需要可以調(diào)整迭代長度，但不要隨意修改。
初始速率
三種方法獲得初始速率：使用歷史值、執(zhí)行一輪初始迭代，使用那輪迭代的速率；猜測(cè)
答案
第十章 迭代計(jì)劃
問題
小結(jié)
迭代計(jì)劃，把粗顆粒度的故事分配到發(fā)布中的多輪迭代。
迭代計(jì)劃會(huì)議一般內(nèi)容：討論故事、從故事中分解任務(wù)、開發(fā)人員承擔(dān)每個(gè)任務(wù)的職責(zé)、討論過所有故事，并接受所有任務(wù)后，開發(fā)人員單獨(dú)估計(jì)他們承擔(dān)的任務(wù)，以確保他們不會(huì)做出過于樂觀的承諾。
故事的任務(wù)分解時(shí)即時(shí)設(shè)計(jì)（just in time design）中的一次短脈沖，這些脈沖的集合取代了瀑布過程中的前期設(shè)計(jì)階段。
準(zhǔn)則:因?yàn)楣适乱呀?jīng)很小了，沒必要圍繞任務(wù)的期望大小設(shè)定非常精確的準(zhǔn)則，從故事分解任務(wù)時(shí)可使用一下準(zhǔn)則。
- 如果故事的某個(gè)任務(wù)特別難于估算，就把那個(gè)任務(wù)從故事的其余任務(wù)中分離出來
- 倘若有些任務(wù)可以很容易安排個(gè)多名開發(fā)人員共同完成，就分割他們
- 若有必要讓客戶了解故事某一部分的完成情況，可以把那部分拿出來作為一個(gè)任務(wù)
開發(fā)人員職責(zé)
負(fù)責(zé)參加迭代計(jì)劃會(huì)議
負(fù)責(zé)把所有故事分為任務(wù)，而不只是自己想做的故事
負(fù)責(zé)為認(rèn)領(lǐng)的任務(wù)承擔(dān)責(zé)任
負(fù)責(zé)確保承擔(dān)適當(dāng)工作量的工作
在整輪迭代中，負(fù)責(zé)監(jiān)控自己剩余的工作，同時(shí)也要監(jiān)控隊(duì)友剩余的工作，如果很快就能完成自己的工作，就有責(zé)任幫助隊(duì)友承擔(dān)部分工作
客戶職責(zé)
負(fù)責(zé)對(duì)迭代中包含的故事排列優(yōu)先級(jí)
負(fù)責(zé)指導(dǎo)開發(fā)人員交付他們能提供的最大商業(yè)價(jià)值，從發(fā)布計(jì)劃設(shè)定后，若有更高價(jià)值的故事，要負(fù)責(zé)調(diào)整優(yōu)先級(jí)以交付最大的商業(yè)價(jià)值
負(fù)責(zé)參加迭代計(jì)劃會(huì)議
答案
第十一章 測(cè)量并監(jiān)控速率
小結(jié)
開發(fā)人員職責(zé)
盡量在完成一個(gè)故事后再去做下一個(gè)故事，我們更希望看到少量已完成的故事，而不是較多未完成的故事
清楚所作的任何決定對(duì)項(xiàng)目速率的影響
理解本章所講的所有圖
經(jīng)理或者極限編程項(xiàng)目中的追蹤者，應(yīng)知道怎樣以及再什么時(shí)候畫本章中的這些圖
客戶職責(zé)
理解本章所講的所有圖
知道團(tuán)隊(duì)的速率
知道實(shí)際速率和機(jī)會(huì)速率的差別和是否需要調(diào)整計(jì)劃
為發(fā)布添加或刪除故事，以確保團(tuán)隊(duì)再種種限制團(tuán)結(jié)下盡量多實(shí)現(xiàn)項(xiàng)目目標(biāo)
答案
第Ⅲ部分 經(jīng)常討論的話題
第十二章 故事不是什么
不是IEEE 830?
IEEE標(biāo)準(zhǔn)文檔的建議覆蓋了諸如如何整理需求規(guī)則文檔、角色原型和良好需求特性等主題。
使用項(xiàng)目需求規(guī)格書的問題，規(guī)格文檔再開發(fā)小組和其他小組（如市場(chǎng)、產(chǎn)品管理）會(huì)來回打乒乓，不可能吧需求描述到想要的精度。
用戶故事不是用例
用例（use case）是對(duì)系統(tǒng)質(zhì)檢以及一個(gè)或多個(gè)用戶質(zhì)檢交互的一般性描述。用例可以編寫為非結(jié)構(gòu)化的文本，或者符合結(jié)構(gòu)化的模板。
用例和故事的目的不同，用例編寫成客戶還開發(fā)人員都可以接受的格式，目的是記錄客戶和開發(fā)團(tuán)隊(duì)之間的協(xié)議，而編寫故事是為了更方便發(fā)布計(jì)劃和迭代計(jì)劃，并且它充當(dāng)這用戶具體需求對(duì)話的占位符。
用戶故事不是場(chǎng)景
場(chǎng)景是用戶與計(jì)算機(jī)交互的詳細(xì)描述，交互涉及場(chǎng)景通常比用例更大或更全面。
用戶故事和場(chǎng)景的主要區(qū)別是范圍和細(xì)節(jié)，場(chǎng)景包含更多細(xì)節(jié)，范圍通常涵蓋多個(gè)故事。
問題
第十三章 用戶故事的優(yōu)勢(shì)
用戶故事的好處
強(qiáng)調(diào)口頭溝通
人人都可以理解用戶故事
大小適合做計(jì)劃
適合于迭代開發(fā)
鼓勵(lì)延遲細(xì)節(jié)
支持隨機(jī)應(yīng)變的開發(fā)
鼓勵(lì)參與性設(shè)計(jì)
傳播隱形知識(shí)
用戶故事的不足
在擁有大了用戶故事的大型項(xiàng)目中，故事之間的關(guān)系可能是錯(cuò)綜復(fù)雜，難以捕捉。可以使用角色來淡化此問題，進(jìn)來保證用戶故事不要過于細(xì)節(jié)化，直到團(tuán)隊(duì)開發(fā)這些故事時(shí)才開始細(xì)化。面對(duì)大量的需求時(shí)，用例的固有層級(jí)性會(huì)使需求收集比較方便。
如果開發(fā)過程規(guī)定需要有需求的可追溯性，比如離不開額外的文檔?？梢酝ㄟ^輕量的方式解決，在每一輪迭代時(shí)，生成一份文檔，列出改迭代中計(jì)劃開發(fā)的每一個(gè)故事。隨著測(cè)試的不斷出現(xiàn)，我們把測(cè)試的名詞添加到文檔中，在迭代進(jìn)行期間，挪入或挪出故事時(shí)我們保持文檔的更新。
我們要在兩種情況取得平衡：很多人都知道一點(diǎn)點(diǎn)信息（通過低帶寬的書面文檔）或者一小群人知道非常多信息（通過搞貸款的面對(duì)面交流）
小結(jié)
開發(fā)人員職責(zé)
理解選擇任何方法的原因，如果團(tuán)隊(duì)決定使用用戶故事，需要明白為什么
了解其他需求方法的優(yōu)先以及知道什么情況下適合使用
客戶職責(zé)
用戶故事與其他需求管理方式相對(duì)的一大有點(diǎn)事鼓勵(lì)參與性設(shè)計(jì)，應(yīng)該積極參與軟件的設(shè)計(jì)。
問題
第十四章 用戶故事不良征兆一覽
問題
第十五章 Scrum與用戶故事
問題
第十六章 其他話題
問題
第Ⅳ部分 一個(gè)完整實(shí)例
