什麼是使用者故事
使用者故事（User Story）是用來對軟體或使用者有價值功能的簡短描述，是對需求的一種描述。它清晰簡潔的傳達了使用者想要的功能。
它從使用者角度出發，用來描述使用者的需求，用來表達使用者需求的方式之一。
它從使用者角度出發，解釋了使用者所期望得到的結果。使用者故事清楚的解釋了新功能給使用者提供的價值，而不僅僅專注於功能。
它也是程式開發人員、產品經理、利益相關者關於需求交流的一種媒介。
使用者故事三要素
使用者故事是用來描述使用者需求的一種方式，一份使用者故事的組成要素有哪些？
它一般由 3 個要素組成：
- 角色（who）：誰使用。
- 活動（what）：要完成什麼活動。系統提供了什麼功能？
- 價值（value）：為什麼這麼做？提供了什麼價值。給使用者帶來什麼價值？產生什麼商業價值？實現什麼業務目標？
作為一個<角色>，我想要<完成活動>，以便<達到目的/實現價值>
使用者故事包含哪些內容
上面是對使用者故事包含要素的簡短概述。在《敏捷軟體開發：使用者故事實戰》一書中描述了一份使用者故事需要包含 3 方面內容：
- 一份故事的書面描述。
- 有關故事的交談，用於充實故事的細節。為了獲取使用者故事的細節，需要與相關人員溝通交談來獲取故事詳細細節。
- 記錄故事細節的測試，用來驗證故事是否完成。
用卡片描述使用者故事內容
用什麼工具能快速、便捷，準確的描述和記錄使用者故事呢？答：卡片記錄。
對於使用者故事的描述，另外一個人榮恩 (Ron Jeffries) 用 3 個單詞簡明概括了上節裡使用者故事 3 方面內容，3 個英文單詞如下：
- 卡片(Card)
- 交談(Conversation)
- 確認(Confirmation)
卡片（Card）包含了使用者故事的文字概括說明，需求的詳細細節需要在交談（Conversation）中獲得，在確認（Confirmation）環節記錄並加以驗證。
卡片 Card
在卡片上寫著使用者故事的簡短描述、規則和完成驗收標準。
- 卡片正面寫使用者故事三要素描述，格式為：
作為一個<角色>，我想要<完成活動>，以便於<實現價值>。
例子：
作為操作後臺的銷售人員，我希望合併來自不同來源的銷售資料，以便我可以方便的地分析銷售資料並建立銷售報告。
- 卡片下寫使用者故事的規則和完成驗收標準，格式為：
Given…When…Then，給使用者一個 xxx 功能，在 xxx 時候的 xxx 情況下使用，然後 xxx（成功/失敗/錯誤）
舉一個簡單例子：
場景：使用者憑手機號和驗證碼登入軟體系統。
- Given：使用者用手機號登入系統。
- When：當我在介面上輸入手機號，然後點選獲取驗證碼，輸入驗證碼登入系統。
- Then：輸入了正確的驗證碼，成功登入進系統。
（故事卡片）
故事卡片寫著使用者故事的簡短描述、一些規則和完成驗收標準。使用者故事的詳情、一些細節還需要與相關人員交談獲得。
用物理卡片展示，而不是假設的想法，有助於團隊成員共同討論需求。
交談 Conversation
使用者故事的細節來源是與使用者/客戶、產品利益相關者的溝通交流，與所有利益相關者對話交談，並在對話基礎上的理解，整理出需求。然後需要確保各方對使用者故事的理解相一致。
這其實是怎麼挖掘使用者需求詳情和細節的方法，與使用者/客戶交流對談就是其中一種。
使用者故事的第二個階段，如何實現卡片上的要求以及瞭解需求的細節，需要與使用者/客戶、產品相關人員討論、提問來獲得。
確認 Confirmation
透過驗收測試，來確認每個使用者故事被正確的完成了。
驗收測試格式舉例：
一般是對操作業務規則的驗證。比如驗證使用者登入系統功能：
1、在輸入錯誤手機號的條件下，會出現 xxx 錯誤提示，結果登入失敗。
2、在驗證碼輸入超時情況下，會出現 xxx 提示，結果登入失敗。
3、測試輸入過期手機號碼，會出現 xxx 提示，結果登入失敗。
一些測試的方法：1、功能測試（單元測試）2、互動測試（整合測試）3、自動化測試（持續交付測試）4、效能測試（壓力測試）
好故事的六個特徵 INVEST
好故事的六個特徵 INVEST，它由六個英文首字母組成：
-
獨立的（Independent）：每個使用者故事之間應該相互獨立，儘量避免故事之間相互依賴。故事之間相互依賴會導致優先順序排序和計劃出現問題，也會使估算變得困難。
-
可協商的（Negotiable）：故事是可協商的，它不是軟體必須實現的需求，只是對需求的簡短描述，故事細節（需求細節）是在交談溝通階段產出的。
-
對使用者或客戶有價值的（Valuable to users or customers）：確保故事對使用者或客戶是有價值的，必須站在使用者或客戶角度來編寫故事。這通常不容易做到但儘量去做到。
-
可估算的（Estimatable）：對於需要進行開發的 User Story（使用者故事）大小進行估算，或將一個使用者故事給到開發人員，使用者故事的程式碼實現需要的工作量，多長時間開發完成進行評估。
-
小的（Small）：一個好的使用者故事不能太大也不能太小。太大的故事叫史詩（Epic），史詩應該拆分為較小的故事。那怎麼判斷好故事大小呢？一個標準就是至少在一個迭代或 Sprint 中能夠完成。故事太大，在工作量估算方面存在很大風險。
-
可測試的（Testable）：使用者故事是小的具體的，且可以測試。故事太模糊的話，無法進行測試，那怎麼驗證？
怎麼編寫使用者故事
怎麼編寫有效的使用者故事，從哪裡開始？
目標使用者
為了編寫有效使用者故事，需要識別和定義產品的目標使用者？誰會使用軟體產品，他們怎麼與軟體進行互動？
明確使用者需求
確定了使用產品的使用者後，就要挖掘使用者使用產品想要達成的目標。
也就是說使用者使用產品想要得到什麼、對產品的期望是什麼，使用者想要什麼？
這一步是要挖掘使用者的真正需求。
產品功能
明確了使用者需求，就要思考產品可以提供什麼樣的功能？能滿足使用者需求。
這一步還有一個重要的步驟，競品分析。
或者思考一個重要的問題：使用者為什麼選擇我們，而不是競爭對手？
驗收標準
團隊開發完成交付產品，需要驗收使用者故事是否正在完成、適合標準。
每個使用者故事可以列出幾個驗證標準。
參考
- 《使用者故事與敏捷方法》https://book.douban.com/subject/4743056/ 作者: Mike Cohn