前一篇我介紹了，什么是用戶故事，那這一片我們講，為什么我們要使用用戶故事來表達需求，用戶故事的應用都是基于敏捷開發的模式。

1. 敏捷開發的需求敏捷化的手段

就職在互聯網企業，在一個不大的項目組里，還是個要發揮產品經理主觀能動性的產品，你要去探索商業模式，做產品規劃，求生存。就先給你一只打火機讓你在黑暗中找金礦，你打著打火機只能照亮周圍1米，步子不能跨太大，不知道1米外是不是個坑，先跨一步看看，再能跨下一步。

更悲劇的是你的打火機不能一直按著，一直按著燙手啊，還要擔心燃氣夠不夠用。只能走走停停，摸摸索索，還要各方求資源補充燃氣。

這種環境下，整個團隊都在講小迭代，講敏捷，同樣你必須寫用戶故事啊。

用戶故事的出現使敏捷開發方法覆蓋了軟件研發中的“需求”環節，是敏捷開發模式中的需求敏捷化的重要手段。敏捷方法誕生十余年到現在我們知道，一個研發團隊要想實現完全的敏捷轉型光是實現迭代開發過程的敏捷化是不夠的，SCRUM和Kanban都無法解決產品需求敏捷化的問題。

而用戶故事的誕生，就是為了實現需求的敏捷化。雖然用戶故事實踐本身還存在一些不足，但是至少到現在我們知道，用戶故事是需求敏捷化的基石之一。

Ps：如果你說你們在敏捷開發，但是你從不寫用戶故事，那怕是你們對敏捷開發有誤解，你們做的應該就是單純的迭代開發，不是敏捷開發。敏捷中重要的一點就是團隊達成一致意見，成員都認同要做的事的價值，這是建立在對需求的3W（who、what、why）重復理解和討論的基礎上達成的。傳統的需求表述方式只體現了what，無法支撐這種理解和討論。

2. 貫穿整個產品實現過程

需求評審會之后，進入開發、測試環節，常常能聽到的聲音是“這個需求當初為什么要這么定？”“我也不知道，產品就這么定的?！?/p>

隨著時間的推移，可能產品經理自己也會忘記為什么要做這個需求，以及為什么要這么做。這就會造成團隊的后勁不足，無法明確自己正在做的事的價值。當一個人對于正在做的事，不知道有何意義時，是痛苦的。

而用戶故事能有效的將軟件研發過程中的需求環節、開發環節和測試環節有效的連接起來。通過經典的“三段論“描述和漸進的細節探索，用戶故事實現了需求描述的敏捷化；通過優先級排序和故事點的有效應用，用戶故事實現了需求到開發的連接；通過驗收標準的漸進明確，用戶故事實現了需求與測試的連接。

可以說，正是有了用戶故事這根線，才把軟件研發團隊的主要的工作環節：需求、開發、測試都有機的串聯起來。整個團隊成員都明確自己做的事能給團隊和客戶帶來什么價值，形成內驅動。

3. 提高溝通效果

舉個需求評審的場景：敏捷開發中，開發、設計、測試等在需求評審時，就會秉著敏捷參與的文化理念，來挑戰你的權威，一起懟產品啊，怎能錯過如此良機：這個需求誰提的，為什么這么做，做了有什么價值？

一頓舌戰群儒后，身心俱疲，開發還是用懷疑的眼光看著你說：“這都是你YY的吧？”

最后，不得已來一句，老板就讓這么做的，下周3上線。

但是，你用用戶故事的”三段論”作為一個<用戶角色>，我想要<完成活動>，以便于<實現價值>，在會前把故事發出去，注意力就是在故事的主人翁上，會中就是大家一起在探索用戶場景、路徑、給你提供思路，而不是在懟產品。

講故事不用太在意聽故事的人是誰？

用戶故事的一個核心在于對話（Conversation），客戶和開發人員可以就某個故事深入的交流，對每個重要的細節達成共識。這避免了通過文字記錄而可能導致的不精確性或語義多重性的問題。并且向用戶或客戶顯示價值，不涉及專業的技術術語，從而使得用戶和開發者理解起來都很容易。

4. 用戶故事適合于迭代開發

在開始編碼之前，我們并不需要寫出所有的用戶故事，我們可以寫出一部分故事，就開始編碼與測試，然后按需求的節奏重復這個過程。在寫故事時，也可以按照我們認為合適的粒度去寫，正是因為我們很容易對故事本身也進行迭代，所以用戶故事很適合迭代開發。

5. 用戶故事鼓勵延遲細節

我們可以先寫出一個起始的目標層面及占位意義的故事，在這個故事再后來對于開發進程變得重要時，才用更多對的細節來代替這個簡單的描述。

這很適用于有時間限制的項目。團隊可以非常迅速的寫出數十個用戶故事，讓大家對要開發的系統有一個整體的概念，然后先討論當前時間優先級較高的故事的細節并開始編碼，相對于事先完成系統的整體需求文檔，大大加快了研發進度。

6. 用戶故事傳播隱性知識

緣于對面對面溝通的重視，故事能夠促進團隊內隱性知識的積累。開發人員與客戶之間以及他們內部的溝通越密切，越多的隱性只是能得到傳播與加強。

補充：了解用戶故事的誕生

要了解為什么要用用戶故事，還有很重要的一點是，了解它的起源和發展。就像了解一個人，最好的方式就是了解他的成長環境，去他成長的地方，看看塑造他的環境是什么樣子的，以及他的經歷。

1998年，用戶故事首次提出。

用戶故事的起源是來自與XP極限編程的計劃游戲環節，據現在能夠追查的記錄，最早是在1998年這樣提到“用戶故事”的：客戶通過用戶故事（像用例）來定義項目范圍。 XP沒有把用戶故事作為一個單獨的實踐來說明，而是作為計劃游戲中的一個游戲環節。

在相同時期，另外一個與用戶故事對等的詞匯“故事卡片”（Story Card）同樣被XP提出，有人說其實那時故事卡片的使用頻率要高于用戶故事。

這是Ron Jeffries提供的1999年C3項目中的一個用戶故事實例照片。

• 2001年，用戶故事經典句型出世，As a role，I want to …, so that …
• 2001年，用戶故事3C要點由Ron Jeffries提出，Card，Conversation，Confirmation
• 2002年，計劃撲克發明，以故事點來估算故事的大小。
• 2003年，用戶故事INVEST檢查表提出，Independent ， Negotiable ，Valuable，Estimable，Small，Testable。
• 2003年，BDD由Dan North提出，它包括驗收測試和客戶測試驅動等的極限編程的實踐。
• 2004年，User Stories Applied 出版，作者Mike Cohn
• 2005年，Mike Cohn發表 “Agile Estimating and Planning”，planning poker開始流行。epic的使用，難以追查是哪年開始的，應當是在2003年以后。theme在用戶故事的使用，同樣難以追查何時開始，估計也是在2003年以后。
• 2006年，the Given-When-Then template 出現，適合ATDD和BDD
• 2014年，User Story Mapping 出版，作者 Jeff Patton

以Rally和Jira為代表的用戶故事管理工具在2005年以后得到了巨大發展。

從用戶故事的發展歷程可以看出，用戶故事的提出和應用，為后來發展的敏捷開發模式奠定了基礎，直到現在也是敏捷開發的中需求敏捷化的重要手段。

相關閱讀

系列文章目錄

用戶故事（一）：什么是用戶故事？

用戶故事（二）：為什么要使用用戶故事表達需求？

用戶故事（三）：用戶故事該怎么寫？

本文由 @chun 原創發布于人人都是產品經理，未經許可，禁止轉載。

題圖來自 Unsplash，基于CC0協議。