為什么要來討論用戶故事
在傳統研發模式下，特別是在一些小型的產品研發領域，產品經理往往會編寫一份產品需求文檔（PRD），然后技術團隊再依照于這個PRD文檔來做開發。
這種基于PRD的開發方式在當前市場變化越來越快，研發組織越來越追求小步快跑的產品發布節奏的環境下遇到了很多挑戰：
- 產品編寫一份PRD往往需要很長的時間（產品默認都會追求編寫一份完整的需求文檔，要考慮到方方面面），考慮到互聯網非常緊張的產品發布周期壓力，技術團隊會抱怨產品需求給得太晚，留給技術的開發時間太短。
- 整體的開發周期長，獲取用戶反饋也就晚。完整的產品需求也就可能導致只能完整的交付，當然，這個也和下面第三點有關。
- PRD內容的豐富同時造成了優先級不清晰。雖然PRD里也會標注有優先級，但是因為里面需求的數量龐大并且相互交織依賴，最后的結果就是高優先級的需求太多，優先級不能細化導致失去價值。
- 缺少對話。需求文檔不可能承載所有需求信息，而且由于描述的角度，容易造成誤解。所以需求不僅僅只是一份文檔，它更應該是一個溝通的工具，可以用來幫忙大家對特性的理解達成一致。
- 后期調整需求成本高，但不幸的是在隨著產品形態不斷的顯露出來的時候，需求的調整是不可避免的。而且過早的決策，需求調整的可能性只會更高。
為了解決這些問題，使用用戶故事的方法來表述需求逐漸流行起來。
本文試圖從非常基礎的角度解釋什么是用戶故事。
什么是用戶故事
用戶故事一共包含三個部分，簡稱3C模型：
- Card（卡片）
- Conversation（會話）
- Confirmation（確認）
1.Card
作為<用戶角色>，我想要<產品特性>，這樣可以<價值或收益>。
這個卡片形式已經是家喻戶曉的了（雖然大家不一定都能按這個來做），甚至當大家提到“用戶故事”的時候也就只記得這個卡片了，在很多人心中卡片和用戶故事是等同的。但顯然這樣是片面的，這樣的理解就只是得其形而失其神。
卡片僅僅是用戶故事最明顯的表現形式，但他不是最重要的。
2.Conversation
卡片代表客戶需求而不是記錄需求。
同樣一份文檔或卡片，閱讀的人不同，各自得到的信息也不一樣。
卡片包含故事的文字描述，然而需求細節要在對話中獲得。故事之所以叫故事，因為它是要講而不是要寫的。
說得通俗一點就是一張卡片只是代表了一個需求，但它遠遠不是需求的全部，相關干系人一起在對話中發現并探索需求的細節，這個才是更重要的。
對話肯定不是一次性的，而是持續的深度交談：寫故事的時候會有對話，宣講的時候又有一次，估算的時候再有一次，迭代計劃會議的時候還會有，迭代中在軟件設計，構建和測試的時候都會有。
盡管我們說對話主要是依靠口頭語言交流發生的，單我們仍然經常借助于文檔的方式做說明或記錄：比如一張PS的效果圖，一張畫在白板上的交互邏輯照片，引用某篇文檔中規范內容的鏈接，等等。
3.Confirmation
用戶故事還要包含確認信息，作為接收標準（或確認條件）。這和“完成的定義”（DoD）非常像，只不過DoD更偏向哪些general的和流程化的事項。
如果我們使用的物理化的卡片的話，正面寫的是story的描述，那么背面就很適合寫上確認條件。
有了確認條件，開發和測試團隊就能更好的理解要構建和測試的是什么，產品團隊可以確認用戶故事的實現是否和服預期。
“確認條件”最遲是需要在迭代planning meeting上確定的，很明顯，這個是story估算的重要依據之一。但是我們不保證確認條件不會發生變化，但前提是調整和變化不會影響本次迭代的交付，如果真的有大的影響，我們就要馬上調整我們的迭代計劃（re-planning）。
確認條件在某種程度上也能看成驗收條件，是story的測試要點，很自然的我們就想到了敏捷的另一種實踐：接收測試驅動開發（ATDD）。
關于“接收測試驅動開發”和“實例化需求”，我們以后再談。
好故事需要滿足的原則
一個好的故事需要滿足INVEST標準：
- 獨立的（Independent）
- 可協商的（Negotiable）
- 有價值的（Valuable）
- 可估算的（Estimatable）
- 小的（Small）
- 可測試的（Testable）
我不太想用長篇大論來一一介紹這六個好故事特征（不然篇幅太長），這里我只用最簡單的一句話來描述各個特征的好處：
- 不獨立的故事會對優先級的排列和測試帶來巨大的麻煩；
- 故事不是合同，故事只是占位符，它提醒我們需要更多的去對話和協商；
- 卡片的三段式寫法本身就是要強調價值的，這里要強調的是價值是對用戶和客戶來說的，我們要盡量避免做只是對開發團隊有價值的故事；
- 不能估算的故事要么是對業務還沒理解，要么是團隊缺少相應的技術實力，要么就是太大，總之這些都是要在開發之前解決的問題；
- 小是必須的，但是太小也不是不能合并一下，總之大小要合適；
- 如果不能測試，就不能證明它是完成的。
有興趣深入探討的話可以自己google或者參考Mike Cohn的《用戶故事與敏捷方法》。
非功能性需求
非功能性的需求往往包含安全性、可靠性、互操作性、健壯性、易使用性、可維護性、可移植性、可重用性、可擴充性、實驗性等，一般反應了系統的約束，而非系統特定行為的需求。
- 對于非功能性需求我們仍然希望能按照故事的結構來編寫它，這樣能幫助我們理清這些需求的價值，這往往是容易忽略的；
- 非功能性需求往往是跨所有功能性需求的，一旦你完成了一個非功能性需求，那么在以后的迭代中你要始終關注這個非功能性需求以防止它被影響而失效。那該怎么辦呢？
- 考慮把非功能性的要求放到每一個功能性需求DoD中去，在一開始就考慮到系統的各種限制
- 或者和PO約定，哪些迭代里需要對非系統性需求做驗證和維護
Story mapping
使用story的形式做需求管理最被人詬病的就是，相對于大而全的PRD，story是“只見樹木，不見森林”。用戶故事地圖（user story mapping）的是給這個問題一個解決辦法。
用戶故事地圖，就是在講大故事的同時進行拆分。
對于story mapping暫時就不在這篇文章中詳細描述了，后續會單獨開一片story mapping的小文。
