第1部分 起步
識(shí)別搪柑、編寫(xiě)薄腻、測(cè)試用戶故事
第1章 概覽
幫助開(kāi)發(fā)人員和客戶團(tuán)隊(duì)雙方協(xié)作，任何一方都不能占絕對(duì)主導(dǎo)地位棉姐，保證資源的合理分配。
不要妄想在項(xiàng)目一開(kāi)始就做出包羅萬(wàn)象的決策啦逆，注重反饋伞矩，將各個(gè)決策分散到項(xiàng)目過(guò)程中。
客戶團(tuán)隊(duì)活躍于軟件開(kāi)發(fā)的全過(guò)程夏志，編寫(xiě)用戶故事乃坤、確定優(yōu)先級(jí)，客戶團(tuán)隊(duì)包括確保軟件符合潛在用戶需求的人沟蔑，可以包括測(cè)試人員湿诊、產(chǎn)品經(jīng)理、實(shí)際用戶和交互設(shè)計(jì)師
用戶故事工作量大小瘦材，迭代長(zhǎng)度每個(gè)版本的計(jì)劃工作時(shí)間厅须，迭代速率~用戶故事/迭代長(zhǎng)度
一個(gè)發(fā)布由一個(gè)或多輪迭代組成，發(fā)布的要求是項(xiàng)目時(shí)間表和預(yù)期功能集合之間達(dá)到平衡
每個(gè)故事用故事點(diǎn)來(lái)估計(jì)食棕，故事點(diǎn)表明一個(gè)故事相對(duì)于其他故事的大小和復(fù)雜度
驗(yàn)收測(cè)試用來(lái)驗(yàn)證實(shí)現(xiàn)的用戶故事是否符合客戶團(tuán)隊(duì)的期望朗和，測(cè)試應(yīng)盡早在迭代中編寫(xiě)，將假設(shè)和預(yù)期更早的與開(kāi)發(fā)人員溝通
用戶故事強(qiáng)調(diào)對(duì)話交流而非書(shū)面溝通簿晓，代表用戶在單一環(huán)境中可能做的事情眶拉；用戶故事需要避免使用技術(shù)術(shù)語(yǔ)，保證客戶團(tuán)隊(duì)和開(kāi)發(fā)團(tuán)隊(duì)都能理解憔儿；用戶故事可以促進(jìn)考慮細(xì)節(jié)忆植，且能更新；客戶團(tuán)隊(duì)進(jìn)行故事的優(yōu)先級(jí)排列， 同時(shí)也要考慮開(kāi)發(fā)團(tuán)隊(duì)的意見(jiàn)和成本
第2章 編寫(xiě)故事
獨(dú)立的：故事之間相互依賴
將相互依賴的故事合并成一個(gè)大的朝刊、獨(dú)立的故事耀里；用一個(gè)不同的方式去分割故事
可討論的：關(guān)于細(xì)節(jié)的處理
故事卡包含一兩句短語(yǔ)，提醒開(kāi)發(fā)人員和客戶進(jìn)行對(duì)話坞古；故事卡包含一些注釋备韧，表明在對(duì)話中亟待解決的問(wèn)題；將細(xì)節(jié)變成測(cè)試
對(duì)purchasers或users有價(jià)值的：避免過(guò)度關(guān)注技術(shù)和實(shí)現(xiàn)細(xì)節(jié)
讓客戶編寫(xiě)用戶故事
可估計(jì)的：估算工作量
開(kāi)發(fā)人員缺少領(lǐng)域知識(shí)痪枫；開(kāi)發(fā)人員缺少技術(shù)知識(shí)织堂；故事太大
小的：有助于制定計(jì)劃
合適的故事大小取決于團(tuán)隊(duì)、容量以及使用的技術(shù)
按照創(chuàng)建奶陈、編輯易阳、刪除這些動(dòng)作來(lái)分解故事，或者根據(jù)數(shù)據(jù)邊界來(lái)分解故事
可測(cè)試的：量化的測(cè)試效果
第3章 用戶角色建模
用戶角色user role：一組屬性的集合吃粒，刻畫(huà)了一群人的特征以及這群人與系統(tǒng)可能的交互
角色建模的步驟：頭腦風(fēng)暴潦俺，列出能想到的用戶角色——整理用戶集合——整合角色——提煉角色
兩個(gè)額外的技術(shù)：虛擬人物（假想的用戶角色代表，用戶強(qiáng)化用戶角色在團(tuán)隊(duì)成員心中的印象）+極端人物（幫助考慮原本遺漏的故事徐勃，也可能產(chǎn)生新的用戶故事）
第4章 搜集故事
拖網(wǎng) trawling 將收集需求比作捕魚(yú)
用戶訪談：通過(guò)提出開(kāi)放式的/與背景無(wú)關(guān)的問(wèn)題獲取用戶的本質(zhì)需求
問(wèn)卷調(diào)查：可以用于確定故事優(yōu)先級(jí)事示，但不適合捕獲新的用戶故事
觀察：明確需求
故事編寫(xiě)工作坊：編寫(xiě)大量用戶故事，確定工作流
第5章 與用戶代理合作
用戶代理user proxy僻肖，在項(xiàng)目中代表用戶
誰(shuí)適合做用戶代理肖爵？
用戶經(jīng)理：并非軟件使用者，盡可能接觸終端用戶臀脏，不能得罪
開(kāi)發(fā)經(jīng)理：避免讓開(kāi)發(fā)經(jīng)理?yè)?dān)任用戶代理
銷售人員：通過(guò)銷售人員認(rèn)識(shí)客戶
領(lǐng)域?qū)＜遥核捷^高劝堪，圍繞他們開(kāi)發(fā)出來(lái)的產(chǎn)品可能對(duì)其他人不友好
市場(chǎng)營(yíng)銷團(tuán)隊(duì)：更關(guān)注產(chǎn)品特性的數(shù)量而非質(zhì)量
以前的客戶：考慮其動(dòng)機(jī)和目標(biāo)是否與實(shí)際用戶一致
客戶purchaser：考慮用戶與客戶在需求上的差異
培訓(xùn)師和技術(shù)支持：與實(shí)際用戶的差異
業(yè)務(wù)分析師或系統(tǒng)分析師：適合作為用戶代理，既懂技術(shù)揉稚，又熟悉軟件相關(guān)的領(lǐng)域知識(shí)
與用戶代理合作時(shí)秒啦，做些什么？
能接觸到用戶但訪問(wèn)受限時(shí)搀玖，啟動(dòng)用戶顧問(wèn)團(tuán)隊(duì)user task force提出意見(jiàn)和建議余境，用戶代理做決策
實(shí)在不能接觸到用戶時(shí)，可以使用多個(gè)用戶代理模擬用戶巷怜，避免開(kāi)發(fā)出的系統(tǒng)僅僅滿足一個(gè)人的需求葛超，并且確保多個(gè)代理來(lái)自不同的類型
設(shè)立客戶團(tuán)隊(duì)的步驟：邀請(qǐng)真實(shí)用戶加入——確定項(xiàng)目負(fù)責(zé)人——確定項(xiàng)目成功必須的關(guān)鍵因素
第6章 用戶故事驗(yàn)收測(cè)試
記錄客戶和開(kāi)發(fā)團(tuán)隊(duì)所討論過(guò)的細(xì)節(jié)，在寫(xiě)代碼之前寫(xiě)測(cè)試可以為開(kāi)發(fā)人員提供有價(jià)值的信息延塑，測(cè)試應(yīng)當(dāng)是軟件開(kāi)發(fā)過(guò)程中的一部分
集成驗(yàn)收測(cè)試工具FIT：每次迭代都會(huì)破壞一些已完成驗(yàn)收測(cè)試的代碼绣张，所以迭代后的測(cè)試應(yīng)包含以往所有的測(cè)試，F(xiàn)IT通過(guò)明確輸入輸出关带，驗(yàn)證程序得到輸入后是否能正確輸出
測(cè)試類型：功能測(cè)試/用戶交互測(cè)試/可用性測(cè)試/性能測(cè)試/壓力測(cè)試侥涵，測(cè)試的是缺陷沼撕，而非覆蓋率
第7章 優(yōu)秀用戶故事準(zhǔn)則
考慮從每個(gè)用戶角色使用目的
每個(gè)故事提供一個(gè)完整的端到端end to end的功能（每個(gè)功能有輸入有輸出）
權(quán)衡相互沖突的需求，編寫(xiě)封閉故事
基于大故事實(shí)現(xiàn)的時(shí)間跨度芜飘，編寫(xiě)小故事
在故事中包括用戶角色
故事的可讀性在只為一個(gè)用戶編寫(xiě)時(shí)务豺，是最強(qiáng)的
以主動(dòng)語(yǔ)態(tài)編寫(xiě)
由客戶編寫(xiě)
不要過(guò)早涉及用戶頁(yè)面
第2部分 估算和計(jì)劃
項(xiàng)目計(jì)劃，為最高優(yōu)先級(jí)的故事創(chuàng)建高層次的發(fā)布計(jì)劃
第8章 估算用戶故事
故事點(diǎn)：一個(gè)故事點(diǎn)的工作量可以看作一個(gè)理想日的工作
以團(tuán)隊(duì)估算：估算故事由整個(gè)團(tuán)隊(duì)進(jìn)行
估算：將客戶和開(kāi)發(fā)團(tuán)隊(duì)集合嗦明；第一輪各寫(xiě)各的笼沥，而后表達(dá)觀點(diǎn)；第二輪根據(jù)觀點(diǎn)重新估算娶牌；隨著輪數(shù)的增加奔浅，估算值會(huì)越來(lái)越統(tǒng)一
三角測(cè)量：幫助團(tuán)隊(duì)驗(yàn)證他們是否認(rèn)同各個(gè)故事的工作量
使用故事點(diǎn)：每輪迭代能夠完成的故事點(diǎn)數(shù)要考慮 1、這輪迭代中是否有異常時(shí)間诗良，2汹桦、估算方法保持不變，3鉴裹、第一輪迭代的故事必須獨(dú)立
如果用結(jié)對(duì)編程呢舞骆？：工作量相同，速率值不一樣
開(kāi)發(fā)人員給出工作量估算径荔，客戶負(fù)責(zé)回答問(wèn)題并澄清故事細(xì)節(jié)
第9章 發(fā)布計(jì)劃
已知每輪迭代的工作量估算督禽，合理預(yù)測(cè)完成符合用戶期望的發(fā)布需要多少輪迭代
開(kāi)發(fā)人員和客戶商定一個(gè)日期范圍，而非具體日期
決定在發(fā)布中包含哪些功能：DSDM優(yōu)先級(jí)排列方法（must have,should have,could have,won't have this time）
排列故事優(yōu)先級(jí)：考慮風(fēng)險(xiǎn)和相互影響总处；客戶和用戶也有自己的考慮赂蠢，當(dāng)客戶與開(kāi)發(fā)相左時(shí)，交由客戶決定辨泳；估算故事點(diǎn)，成本也會(huì)影響客戶的優(yōu)先級(jí)排序
混合優(yōu)先級(jí)：客戶在確定優(yōu)先級(jí)時(shí)玖院，可能會(huì)分割故事
高風(fēng)險(xiǎn)故事：以價(jià)值優(yōu)先為導(dǎo)向菠红，開(kāi)發(fā)人員會(huì)傾向于先做風(fēng)險(xiǎn)最高的故事，但最終必須由客戶決定
選擇迭代長(zhǎng)度：開(kāi)發(fā)人員和客戶共同選擇难菌，長(zhǎng)度越短進(jìn)度越透明
初始速率：參考?xì)v史值/執(zhí)行一輪初始迭代獲取速率/猜測(cè)
創(chuàng)建發(fā)布計(jì)劃：設(shè)立初始期望试溯，不斷調(diào)整期望和監(jiān)控每輪迭代大的速率
開(kāi)發(fā)人員提供信息輔助客戶準(zhǔn)確排列優(yōu)先級(jí)
第10章 迭代計(jì)劃
討論故事：調(diào)整故事優(yōu)先級(jí)
分解任務(wù)：分割出某個(gè)特別困難的任務(wù)/展示給客戶幫助客戶了解的部分任務(wù)/分割能提高效率的任務(wù)
承擔(dān)職責(zé)：任務(wù)關(guān)聯(lián)團(tuán)隊(duì)成員
估算并確認(rèn)：評(píng)估是否承擔(dān)過(guò)度的職責(zé)
開(kāi)發(fā)人員認(rèn)領(lǐng)任務(wù)，客戶優(yōu)化故事優(yōu)先級(jí)順序
第11章 測(cè)量并監(jiān)控速率
測(cè)量速率：兩三次迭代后才能獲得一個(gè)長(zhǎng)期的郊酒、穩(wěn)定的速率遇绞，只考慮通過(guò)驗(yàn)收測(cè)試的故事，不能將部分完成的故事計(jì)算在速率內(nèi)
計(jì)劃速率和實(shí)際速率：故事點(diǎn)圖和累計(jì)故事點(diǎn)圖
迭代燃盡圖（剩余故事點(diǎn)-迭代次數(shù)）：以故事點(diǎn)表示的在每輪迭代末剩余的工作量燎窘，雖然不能表示團(tuán)隊(duì)的開(kāi)發(fā)速度摹闽，但能更好的展示項(xiàng)目的整體進(jìn)展
每日燃盡圖（剩余小時(shí)數(shù)-天）：展示團(tuán)隊(duì)在某輪迭代中的進(jìn)展
公開(kāi)剩余工作量信息
第3部分 經(jīng)常討論的話題
用戶故事與其他需求方法的區(qū)別
第12章 故事不是什么
常見(jiàn)的需求方法：1.用例use case 2.軟件需求指南software requirements specifications IEEE830 3.場(chǎng)景interaction design scenario
故事小于用例
IEEE 830關(guān)注解決方案的特征，用戶故事關(guān)心用戶目標(biāo)
場(chǎng)景大于故事褐健，場(chǎng)景較為具體
預(yù)想再全面付鹿，也無(wú)法得到一個(gè)完整的系統(tǒng)，原因是忽略的反饋系統(tǒng)
第13章 用戶故事的優(yōu)勢(shì)
突出交流，保證溝通順暢
提供迅速的反饋周期舵匾，促成對(duì)需求的充分理解
便于迭代開(kāi)發(fā)和制定計(jì)劃
鼓勵(lì)細(xì)節(jié)俊抵、隨機(jī)應(yīng)變式開(kāi)發(fā)、參與性涉及
缺點(diǎn)：不太適用大型項(xiàng)目（故事多坐梯、文檔的可回溯性）
第14章 用戶故事不良征兆一覽
故事太小
故事相互依賴
鍍金（開(kāi)發(fā)人員實(shí)現(xiàn)了不需要的功能）
細(xì)節(jié)太多
過(guò)度考慮用戶界面細(xì)節(jié)
想得太遠(yuǎn)
故事劃分太過(guò)頻繁
客戶難以為故事安排優(yōu)先級(jí)
客戶不愿意寫(xiě)用戶故事徽诲，不愿意排列優(yōu)先級(jí)
了解不良征兆，找出解決方案
第15章 scrum與用戶故事
scrum：一種迭代遞增的軟件過(guò)程（遞增過(guò)程：團(tuán)隊(duì)按功能點(diǎn)開(kāi)發(fā)和發(fā)布軟件吵血，每個(gè)迭代的工作往往不需要返工谎替；迭代過(guò)程：通過(guò)持續(xù)改進(jìn)來(lái)取得進(jìn)展）
scrum基礎(chǔ)：30天1周期的print；4~7人的自組織開(kāi)發(fā)團(tuán)隊(duì)践瓷；待開(kāi)發(fā)產(chǎn)品功能的backlog列表院喜；計(jì)劃會(huì)議；評(píng)審會(huì)議晕翠；每日簡(jiǎn)會(huì)
在sprint中使用用戶故事
第16章 其他話題
非功能性需求（性能喷舀、準(zhǔn)確性、可維護(hù)性等）可以通過(guò)創(chuàng)建約束的方式來(lái)處理
紙質(zhì)還是軟件淋肾？適合項(xiàng)目團(tuán)隊(duì)就好
迭代過(guò)程中盡量避免用戶界面的反復(fù)變化
故事完成后硫麻，保留故事卡card
記錄缺陷報(bào)告形成封面故事卡
第4部分 一個(gè)完整的實(shí)例
編寫(xiě)用戶故事-估算故事-做發(fā)布計(jì)劃-為故事編寫(xiě)驗(yàn)收測(cè)試
第17章 用戶角色
項(xiàng)目：了解項(xiàng)目詳情
定義客戶：幫助編寫(xiě)用戶故事
定義一些角色雛形
整合與提煉
角色建模（使用頻率/用戶專業(yè)程度/用戶對(duì)電腦的數(shù)量程度/用戶對(duì)團(tuán)隊(duì)正在開(kāi)發(fā)的軟件的熟練程度/目的/用戶體驗(yàn)）
添加虛擬人物
了解項(xiàng)目背景以及目標(biāo)用戶，確定用戶畫(huà)像
第18章 一些用戶故事
不按照角色或者虛擬人物的順序?qū)懗龉适?br>
先從一個(gè)特定的用戶角色或者虛擬人物開(kāi)始寫(xiě)出團(tuán)隊(duì)能夠想到的所有故事樊卓，然后考慮下一個(gè)角色或虛擬人物
第19章 估算故事
用故事點(diǎn)代表理想日拿愧、復(fù)雜度或?qū)F(tuán)隊(duì)有意義的其他一些度量值
客戶與開(kāi)發(fā)團(tuán)隊(duì)通過(guò)多次討論，最終確定每個(gè)故事的故事點(diǎn)
第20章 發(fā)布計(jì)劃
確定迭代長(zhǎng)度（考慮交付時(shí)間）
估算速率
給故事安排優(yōu)先級(jí)
最終的發(fā)布計(jì)劃
第21章 驗(yàn)收測(cè)試
在用戶故事的基本上碌尔，充分考慮細(xì)節(jié)輸出盡可能詳細(xì)的測(cè)試內(nèi)容
