敏捷開發中如何寫好用戶故事？

什麼是用戶故事？
用戶故事（user story）是一個用來確認用戶和用戶需求的簡短描述，做爲何用戶，但願如何，這樣作的目的或者價值何在。用戶故事在軟件研發中又被描述爲需求。用戶故事一般的格式爲：做爲一個<角色>, 我想要<功能>, 以便於<商業價值>。

所以，一個好的用戶故事就包括了這三個要素：
1.角色：使用者。
2.功能：須要完成什麼樣的功能。
3.價值：爲何須要這個功能，這個功能帶來什麼樣的價值。

另外，用戶故事還須要遵循3C原則：卡片（Card）、會話（Conversation）和確認（Confirmation），用戶故事的3C原則由Ron Jeffries在2001年提出，直到今天仍被奉爲用戶故事的基本原則。

1.卡片：
用戶故事描述的傳統形式是手工書寫的用戶故事卡，卡片上應該只有幾句話來捕獲需求的精髓或目的。

後來產品經理們經過寫需求設計文檔或者規格說明書，經過一個很是完整的word文檔將某一個產品的需求定義出來。因爲產品需求文檔涉及到的內容從項目到實現效果，很是龐大，以致於後來的項目管理中出現了摒棄繁雜的需求文檔的作法，或將需求文檔僅做爲一個參考標準。如知名項目管理軟件 禪道提倡將需求文檔中的需求點摘出來，錄在禪道的【需求描述】裏面，做爲一個個獨立的功能點。
這其實跟卡片做用是一致的，用簡潔凝練的語言，完整呈現用戶故事的三要素。

2.會話：
會話指的是卡片上所記錄的用戶故事是能夠進行討論和細化的，它包括利益相關人（客戶/用戶）、產品負責人及開發團隊之間進行更細化地討論用戶故事的可行性。用戶故事通過會話確認後，才能正式進入開發階段（用戶故事實現）。敏捷開發的流程完總體現了用戶故事（需求）的流轉過程。

以敏捷開發中的Scrum爲例：

scrum的基本流程如上圖所示：
1.產品負責人負責整理user story，造成左側的product backlog。 ——用戶故事整理
2.發佈計劃會議：product owner負責講解user story，對其進行估算和排序，發佈計劃會議的產出就是制定出這一期迭代要完成的story列表，sprint backlog。 ——用戶故事確認
3.迭代計劃會議：項目團隊對每個story進行任務分解，分解的標準是完成該story的全部任務，終每一個任務都有明確的負責人，並完成工時的初估計。 ——用戶故事分解
4.每日例會：天天scrum master召集站立會議，團隊成員回答昨天作了什麼今天計劃作什麼，有什麼問題。 ——用戶故事實現
5.演示會議：迭代結束以後，召開演示會議，相關人員都受邀參加，團隊負責向你們展現本次迭代取得的成果。期間你們的反饋記錄下來，由po整理，造成新的story。 ——用戶故事的二次整理

敏捷開發中用戶故事的細化爲開發提供了可執行標準，敏捷開發的特色是快速迭代，一個用戶故事的大小和複雜度應該在一個迭代中開發完畢爲宜。若是用戶故事太大，可能會致使對它的開發橫跨幾個迭代。，此時就應該將這個用戶故事分解。每一個任務的時間最好不要超過8小時，就是要保證1個工做日內完成，若是作計劃時發現有些任務的時間超過了8小時，就說明任務的劃分有問題，須要進行子任務的分解。

3.確認：
用戶故事確承認以理解爲對用戶故事是否達到驗收標準的檢測。用戶故事須要一系列的驗收測試用以保證故事功能的完成及軟件按照咱們的預期運行。同時要保證這個用戶故事最後實現是能夠帶來商業價值的。

用戶故事的確認由測試人員完成。測試人員在測試版本所關聯的用例列表裏執行用例，完成測試，而後生成測試報告。測試報告是對用戶故事實現程度的最直接體現。

若是一個用例執行失敗，能夠直接由這個測試用例建立一個Bug，由開發人員進行二次開發和修復，直到測試經過。

寫好用戶故事除了要以3C原則爲基礎，同時須要考慮到用戶故事須要具有的六個特徵（也叫INVEST原則）：
Independent：獨立性
用戶故事之間應該具備獨立性，不該該依賴於其餘的用戶故事。通常能夠經過組合用戶故事或者分割用戶故事來減小用戶故事間的相互依賴性。
Negotiable：可協商
用戶故事是由客戶或者PO同開發小組的成員共同協商制定的，用戶故事表明了一個用戶羣體的需求，而這個需求是零散的，經過相關人員的溝通，協商常常能夠豐富用戶故事。
Valuable：有價值
用戶故事對於最終的用戶是有價值的，所以應該站在用戶的角度去編寫，描述的是一個一個的feature，而非一個一個的task。
Estimable：可評估
對於一個用戶故事的劃分須要足夠的領域知識，使得在劃分故事之時就能大體瞭解故事開發的週期，爲了減小估算的不肯定性，故事自己不能太大。
Small：短小
故事應該儘可能的短小，固然也不是說越小越好。短小的故事能夠減小分解過程當中估算的偏差，最好的故事是可以在一個迭代週期以內完成的。若是太大就應該考慮將其拆分爲多個粒度更小的用戶故事。
Testable：可測試
若是一個用戶故事沒法進行測試，那麼也就沒法判斷該故事是否真的完成。因此，用戶故事必須在定義了驗收測試經過的標準後才能認爲用戶故事開發完畢。