什么是用戶故事？

傳統(tǒng)瀑布模式下，往往先等產品經理完成了產品PRD文檔，然后技術團隊再根據這份PRD文檔實施開發(fā)。
在千變萬化的市場下，基于完整PRD的才進行開發(fā)的模式遇到了挑戰(zhàn)，研發(fā)團隊越重視小步快跑，快速迭代，靈活滿足不斷變化的環(huán)境。比如出現(xiàn)一下狀況：

拆字理解，用戶故事=用戶+故事=人+故+事，通俗解釋，就是什么人因什么原因做某事。提煉出來就是三個要素，who、why、what。用這3個要素組成最簡單一句話的需求描述。

用戶故事由三部分組成，簡稱3C原則：

卡片也稱為用戶故事卡，相信大家對于這個卡片很熟悉了，雖然大家未必按照這個格式寫用戶故事。但有些人心中把用戶故事等同于用戶故事卡 ，如果這樣理解，就會理解片面了，卡片只是用戶故事最明顯的表現(xiàn)方式，它并不是最重要的。加上后面的溝通和確認才是完整的用戶故事。

用戶故事代表的是客戶最原始的需求，它并不是記錄大而全需求的地方?？ㄆ休d的是用戶需求故事，而需求細節(jié)則通過對話完成。
故事之所以是故事，它是用來講的，不是用來寫的。
比如一個卡片上代表一個用戶故事，它不是需求的全部，而組織相關干系人進行細節(jié)討論，探討價值和場景，才是最重要的。
而對話往往不是一次性的，用戶故事是一個需求源頭，剛開始定義的時候可以對話，設計評審、技術評審，測試驗收等環(huán)節(jié)都可以進行對話。也就要求我們，對用戶故事進行維護更新和持續(xù)迭代。
雖然我們常說的對話以口頭交流為主，但可以借助其它工具，比如業(yè)務流程圖、UI高保真圖等等，溝通的目的是我們對需求達成一致的理解和認知。

3.Confirmation (確認)
用戶故事還包含“確認”部分，也就是我們所說的“DoD”，“完成的定義”。這個DoD是大家共同討論出來的，是大家都愿意遵守的原則。
如果紙質版的卡片，確認部分就可以寫在故事的背面，即滿足了什么條件之下，這個用戶故事才算被滿足。

有了確認條件，技術團隊則更明確要測試什么，產品團隊則可以確認用戶故事是否達到預期和驗收標準。
注意，這里的DoD不僅僅是功能性的，也包括非功能性，這往往我們容易被忽略，比如易用性、性能等方面的要求。
當然確認條件不是不變的，如果要調整驗收條件，也勢必影響我們的范圍和工期，可能也要調整我們的迭代計劃。

一個好的故事要滿足INVEST原則：

顧名思義，從字面上大家應該都理解是什么意思了，這6個特性就不一一細講，用簡單的一句話講下這6個特性的好處。

講了這么多用戶故事的好處？那么它有不足嗎？
如果你分解了很多用戶故事，可能會發(fā)現(xiàn)它們是零散的，只見樹葉不見森林，這個時候就要用戶故事地圖來把故事串聯(lián)起來。
其次如果是大項目，則難以組織成千上萬的故事，此時就需要結合額外的文檔實現(xiàn)可追溯性。

本次分享到這里，有興趣的讀者可以閱讀原書，附上電子書鏈接 《用戶故事與敏捷方法》