用戶故事
用戶故事卡片的三個(gè)步驟：
1.Card，把客戶描述的需求記錄在卡片上（可能并不是最終需求）
2.Conversation，在對(duì)話中細(xì)化卡片內(nèi)容和需求細(xì)節(jié)
3.Confirmation，確認(rèn)最終的卡片內(nèi)容
當(dāng)故事的細(xì)節(jié)過多時(shí)，可以用另外的故事來描述，多個(gè)小故事遠(yuǎn)遠(yuǎn)勝于一個(gè)龐大的故事。
故事卡片的背面可以寫上AC（acceptance criteria）
客戶團(tuán)隊(duì)（軟件客戶和最終用戶）需要（被期望）積極地參與到編寫用戶故事的環(huán)節(jié)中。因?yàn)樗麄兛梢詫?duì)故事的優(yōu)先級(jí)進(jìn)行排列，并且他們作為產(chǎn)品的主要構(gòu)想者，很適合描述產(chǎn)品的行為。甚至可以參與定義測(cè)試場(chǎng)景。
發(fā)布和迭代
客戶團(tuán)隊(duì)和開發(fā)人員一起選擇迭代長(zhǎng)度，可能是1-4周時(shí)間。在每個(gè)迭代結(jié)束時(shí)，需要能夠發(fā)布完全可用的軟件子集（即某一部分功能模塊）。
一旦確定迭代長(zhǎng)度之后，開發(fā)就可以開始估計(jì)開發(fā)速度（即velocity速率，每個(gè)迭代周期可以做的事情的量）。第一次的速率估計(jì)也許是錯(cuò)誤的，但是可以在一個(gè)迭代完成之后進(jìn)行修正。每個(gè)迭代周期的任務(wù)量不應(yīng)該超過估計(jì)的速率。
任務(wù)量通過故事點(diǎn)（story point）來衡量。
進(jìn)行發(fā)布規(guī)劃時(shí)需要考慮故事優(yōu)先級(jí)，客戶團(tuán)隊(duì)在排列優(yōu)先級(jí)時(shí)需要考慮如下因素：
1. 大部分用戶和客戶對(duì)特定特性的渴望程度
2. 小部分重要用戶和客戶對(duì)特定特性的渴望程度
3. 故事之間的關(guān)系，比如互補(bǔ)關(guān)系的故事（例如“放大”和“縮小”）
驗(yàn)收測(cè)試
驗(yàn)收測(cè)試用來驗(yàn)證實(shí)現(xiàn)的用戶故事是否符合客戶團(tuán)隊(duì)的期望。
測(cè)試應(yīng)該盡早開始編寫，以便客戶團(tuán)隊(duì)與開發(fā)人員溝通假設(shè)和預(yù)期，驗(yàn)證理解的準(zhǔn)確性，也便于開發(fā)人員自測(cè)。
驗(yàn)收測(cè)試樣例：
用Visa信用卡、MasterCard卡測(cè)試支付功能
用銀聯(lián)卡測(cè)試支付功能
用過期卡測(cè)試支付功能
用不同金額測(cè)試支付功能（包括超出信用卡額度的金額）
...
為什么要用用戶故事而不是需求文檔？
用戶故事情調(diào)對(duì)話交流而不是書面溝通
用戶故事可以同時(shí)被業(yè)務(wù)人員和開發(fā)人員所理解
用戶故事的大小適合于做計(jì)劃
用戶故事適用于迭代開發(fā)
用戶故事鼓勵(lì)推遲細(xì)節(jié)設(shè)計(jì)，直到在不斷的交流中讓需求細(xì)節(jié)更加清晰
用戶故事可以迭代，比如在最開始寫下了一個(gè)巨大的低優(yōu)先級(jí)的史詩故事（epic），當(dāng)開發(fā)進(jìn)行到一定程度，需要準(zhǔn)備把這個(gè)故事加入系統(tǒng)之后，再來提煉它，用一系列更小更具體的用戶故事來代替這個(gè)史詩故事。
