使用者故事 

使用者故事描述了對使用者、系統或軟體購買者有價值的功能。

使用者故事應該具備以下特點：

1) 獨立的：應該避免故事間的專案依賴。在對故事排列優先順序時，或者做計劃時，故事間的相互依賴會導致問題。

2) 可討論的：故事不是簽署好的合同，故事是功能的階段描述，它提供了適量的資訊給開發人員和客戶團隊，提醒他們在以後進行關於需求的對話。它並不是需求本身，因而不需要包含所有細節。

3) 對使用者或客戶有價值的：每個故事必須對使用者有價值，因此應該避免那些只對開發人員有價值的故事，例如技術和實現細節，使用者介面等。保證每個故事對客戶又加重的最好方法是讓客戶來便攜故事。

4) 可估計的：對於開發人員來時，應該能夠估算故事的大小。如果故事太大而無法進行估算，則需要分解成更小的故事。但有時也需要史詩故事作為佔位符或提示。

5) 小的：故事的大小很關鍵，故事太大或太小，都無助於制定計劃。史詩故事在執行前，需要分成更小的故事。合適的故事大小取決於團隊，它的容量及所使用的技術。

6) 可測試的：故事必須是可測試的，成功通過測試可以證明開發人員正確地實現了故事。如果故事不能被測試，開發人員將無法知道什麼時候才算完成了程式碼。

使用者故事的優點有：

1）強調對話交流而不是書面溝通：

使用使用者故事的目的並不是讓我們事無鉅細的記錄下想要的特徵，而是提醒開發人員在將來需要與客戶進行溝通與交談。相較於追求完美的需求文件，更有價值的是運用頻繁的溝通來加強恰當的故事。

2）容易被使用者和開發人員理解：

使用者故事中通常沒有太多的技術術語或領域術語，使用者和開發人員都可以理解。另外，使用者故事通常實在使用者故事會中討論出來的，參與者能夠從使用者故事清楚的回憶起討論清楚的情節。

3）大小適合於做計劃：

與用例和場景不同，使用者故事的大小可以掌控，可以很方便的用於釋出規劃以及進行程式設計和測試。

4）適用於迭代開發：

使用者故事與迭代開發相輔相成，我們並不需要在開始編碼之前寫出所有使用者故事。 我們可以寫出一部分故事，就進行編碼和測試，然後按照需要的節奏重複這一過程。寫故事時，我們可以按照我們認為合適的粒度去寫。正式由於我們很容易對故事本身也進行迭代，因此使用者故事很適合迭代開發。

5）鼓勵推至考慮細節

團隊可以費城迅速的寫出數十個使用者故事，讓大家對系統有一個整體概念，然後就討論前幾個故事的細節並開始編碼，而其他故事在後來對於開發程序變得重要時，才補充更多細節來代替簡單的描述。這遠比被迫先完成一份完美的軟體需求文件進展快許多。

6）鼓勵參與性設計

把交談的中點從系統特性轉移到使用者使用該系統目標的故事，會使討論變得有趣，激發使用者的積極性，成為軟體設計的參與者。

使用者故事不良徵兆

1 故事太小，導致經常需要調整估算；

2 故事之間相互依賴，導致很難做迭代計劃；

3 鍍金，開發人員在迭代中實現計劃外的功能；

4 細節太多，導致前期花太多的攻速整理故事細節，或者寫故事而不是討論故事；

5 過早考慮使用者介面細節；

6 想得太遠，追求在前期花很多功夫捕捉故事相關的所有細節；

7 故事劃分變化頻繁；

8 客戶難以為故事安排優先順序，這可能是由於故事太大或包含了體現不出商業價值的使用者故事； 

9 客戶不願意寫使用者故事，也不願意為故事安排優先順序；