什麼是使用者故事？

        使用者故事是從使用者的角度來描述使用者渴望得到的功能。一個好的使用者故事包括三個要素：

1. 角色：誰要使用這個功能。

2. 活動：需要完成什麼樣的功能。

3. 商業價值：為什麼需要這個功能，這個功能帶來什麼樣的價值。

使用者故事通常按照如下的格式來表達：

作為一個<角色>, 我想要<活動>, 以便於<商業價值>

舉例：

作為一個“網站管理員”，我想要“統計每天有多少人訪問了我的網站”，以便於“我的贊助商瞭解我的網站會給他們帶來什麼收益。”

需要注意的是使用者故事不能夠使用技術語言來描述，要使用使用者可以理解的業務語言來描述。

關於使用者故事，用3個C來描述它：

1.卡片（Card） – 使用者故事一般寫在小的記事卡片上。卡片上可能會寫上故事的簡短描述，工作量估算等。

2.交談（Conversation）- 使用者故事背後的細節來源於和客戶或者產品負責人的交流溝通。

3.確認（Confirmation）- 通過驗收測試確認使用者故事被正確完成。

使用者故事的六個特性- INVEST

INVEST = Independent, Negotiable, Valuable, Estimable, Small, Testable

一個好的使用者故事應該遵循INVEST原則。

1.獨立性（Independent）— 要儘可能的讓一個使用者故事獨立於其他的使用者故事。使用者故事之間的依賴使得制定計劃，確定優先順序，工作量估算都變得很困難。通常我們可以通過組合使用者故事和分解使用者故事來減少依賴性。

2.可協商性（Negotiable）— 一個使用者故事的內容要是可以協商的，使用者故事不是合同。一個使用者故事卡片上只是對使用者故事的一個簡短的描述，不包括太多的細節。具體的細節在溝通階段產出。一個使用者故事卡帶有了太多的細節，實際上限制了和使用者的溝通。

3.有價值（Valuable）— 每個故事必須對客戶具有價值（無論是使用者還是購買方）。一個讓使用者故事有價值的好方法是讓客戶來寫下它們。一旦一個客戶意識到這是一個使用者故事並不是一個契約而且可以進行協商的時候，他們將非常樂意寫下故事。

4.可以估算性（Estimable）—開發團隊需要去估計一個使用者故事以便確定優先順序，工作量，安排計劃。但是讓開發者難以估計故事的問題來自：對於領域知識的缺乏（這種情況下需要更多的溝通），或者故事太大了（這時需要把故事切分成小些的）。

5.短小（Small）— 一個好的故事在工作量上要儘量短小，最好不要超過10個理想人/天的工作量,至少要確保的是在一個迭代或Sprint中能夠完成。使用者故事越大，在安排計劃，工作量估算等方面的風險就會越大。

6.可測試性（Testable）—一個使用者故事要是可以測試的，以便於確認它是可以完成的。如果一個使用者故事不能夠測試，那麼你就無法知道它什麼時候可以完成。一個不可測試的使用者故事例子：軟體應該是易於使用的。