第一部分 起步
第一章 概覽
什么是用戶故事
用戶故事描述了對用戶、系統(tǒng)或軟件購買者有價值的功能。
- 一份書面的故事描述，用來做計劃和作為提示。（Card）
- 有關(guān)故事的對話，用于具體化故事細節(jié)。（Conversation）
- 測試，用戶表達和編檔故事細節(jié)且可用于確定故事何時完成。（Confirmation）
用戶故事代表對用戶有價值的功能。
例如，一個用戶故事雛形是“寫在卡片上的用戶故事雛形”，那么對應(yīng)的示例故事可能包括如下幾個：
- 用戶可以搜索職業(yè)。
- 用戶可以發(fā)布新職位。
- 用戶可以限制瀏覽其簡歷的人。
- 這個軟件將用C++語言來編寫。
- 程序?qū)⑼ㄟ^連接池連接到數(shù)據(jù)庫。
故事1、2、3就是比較理想的用戶故事，因為他們對用戶是有價值的。
而故事4、5就不是理想的用戶故事，因為用戶不關(guān)心系統(tǒng)是用什么語言編寫的，也不關(guān)心應(yīng)用程序如何連接數(shù)據(jù)庫之類的技術(shù)細節(jié)。這2個故事都是開發(fā)人員才需要關(guān)心的技術(shù)問題。
客戶為什么要編寫故事？
1、首先，每個故事必須用商業(yè)語言來寫，不是用技術(shù)術(shù)語，這樣一來，客戶團隊可以排列故事的優(yōu)先級，放入迭代和發(fā)布。
2、其次，作為主要的產(chǎn)品構(gòu)想者，客戶端團隊所處的位置最適合描述產(chǎn)品行為。
規(guī)劃發(fā)布和迭代
發(fā)布規(guī)劃指的是確定項目時間表和預(yù)期功能集合之間達到平衡。
假設(shè)開發(fā)團隊每輪迭代的速率是13個故事點：
| 故事 | 故事點數(shù) |
|---|---|
| 故事A | 3 |
| 故事B | 5 |
| 故事C | 5 |
| 故事D | 3 |
| 故事E | 1 |
| 故事F | 8 |
| 故事G | 5 |
| 故事H | 5 |
| 故事I | 5 |
| 故事J | 2 |
用戶故事的發(fā)布計劃：
| 迭代 | 故事 | 故事點數(shù) |
|---|---|---|
| 迭代 | A、B、C | 13 |
| 迭代 | D、E、F | 12 |
| 迭代 | G、H、J | 12 |
| 迭代 | I | 5 |
分割故事，做更好的發(fā)布計劃：把故事I分成故事Y（3個點）和故事Z（2個點）
| 迭代 | 故事 | 故事點數(shù) |
|---|---|---|
| 迭代 | A、B、C | 13 |
| 迭代 | D、E、F | 12 |
| 迭代 | G、H、Y | 13 |
| 迭代 | J、Z | 4 |
什么是驗收測試？
驗收測試用來驗證實現(xiàn)的用戶故事是否符合客戶團隊的期望。
測試應(yīng)該盡早的在迭代中編寫，早期編寫測試是非常有用的，因為這樣一來，客戶團隊的假設(shè)和預(yù)期會更早與開發(fā)人員溝通。
假設(shè)寫下故事“用戶可以用信用卡為購物車中的物品付款”。然后再故事卡背面寫下測試描述：
- 用Visa信用卡、萬事達信用卡測試（通過）。
- 用大來卡測試（失敗）
- 用Visa借記卡測試（通過）
- 用有效、無效和反面丟失卡ID號的信用卡測試
- 用過期卡測試。
- 用不同購買金額測試（包括超出信用卡額度）
這些測試捕獲了這樣的預(yù)期：系統(tǒng)將可以處理Visa卡、萬事達卡和美國運輸卡，不允許用其他卡購買。盡早把這些測試交給開發(fā)人員，客戶團隊不僅澄清了他們的預(yù)期，他們可能也同時提醒了程序員可能會忘記的情形。
為什么要變？
- 用戶故事強調(diào)對話交流而不是書面溝通。
- 用戶故事可以同時被你和開發(fā)人員理解。
- 用戶故事的大小適合于做計劃。
- 用戶故事適用于迭代開發(fā)。
- 用戶故事鼓勵推遲考慮細節(jié)，直到你非常清楚地了解自己的真正需求。
每個用戶故事代表一個獨立的功能，即用戶在一個單一環(huán)境中可能做的事情。
迭代過程是一個逐步求精的過程。
推遲細節(jié)很重要，因為這樣一來，我們在不確定是否真正需要某個新特性時，可以不花過多時間來考慮它。使用故事，我們不必假裝可以事先知道并寫下所有東西。以客戶團隊和開發(fā)人員的討論為基礎(chǔ)，不斷地精煉我們的需求。
小結(jié)
- 故事卡包含對用戶或者客戶有價值的功能的簡短描述。
- 故事卡是故事的可見部分，但客戶團隊和開發(fā)人員關(guān)于故事的對話更重要。
- 客戶團隊包括那些確保軟件符合潛在用戶需求的人，可以包括測試人員、產(chǎn)品經(jīng)理、實際用戶和交互設(shè)計師。
- 故事卡由客戶團隊編寫，因為他們最了解如何表達需要實現(xiàn)的需求，也因為他們會在后期于開發(fā)人員共同確定故事細節(jié)并安排故事的優(yōu)先級。
- 按照故事對客戶的價值來安排故事的優(yōu)先級。
- 將各個故事放入迭代，進行發(fā)布與迭代規(guī)劃。
- 速率是開發(fā)人員可以在一輪迭代中完成的工作量。
- 放入一輪迭代的故事估計總和不能超過事先開發(fā)人員預(yù)計的速率。
- 如果故事太大以至于無法在一輪迭代中完成，可以考慮把它分成兩個或更多的小故事。
- 驗收測試用于驗證實現(xiàn)的故事是否開發(fā)成符合客戶團隊的設(shè)想。
- 用戶故事是很有意義的，因為它們強調(diào)口頭交流，你和開發(fā)人員都可以理解，可以用于進行迭代計劃，在迭代開發(fā)中能很好地工作，而且因為它們鼓勵推遲細節(jié)。
