今天談談用戶故事地圖，不是用戶故事
摘要：用戶故事地圖其實並非是將描述好的用戶故事匯總在地圖上。而是通過分析、梳理，將用戶故事展現出來，進而匯成了一副用戶故事地圖。
本文分享自華為雲社區《淺談用戶故事地圖》，作者： 敏捷的小智。
用戶故事地圖是梳理用戶故事的方法
說到用戶故事地圖（User Story Mapping），大家都會聯想到用戶故事（User Story）。沒錯，可以認為用戶故事地圖就是把許多個用戶故事羅列在一張地圖上的事物。但是，這只是用戶故事地圖與用戶故事的表層關係。當我們在做發布規劃、梳理需求的時候，我們往往很難將用戶故事直接描述出來。這個時候，我們需要通過用戶故事地圖展現出清晰的故事脈絡，來幫助我們梳理出用戶故事。也就是說，用戶故事地圖其實並非是將描述好的用戶故事匯總在地圖上。而是通過分析、梳理，將用戶故事展現出來，進而匯成了一副用戶故事地圖。
用戶故事地圖的誕生
用戶故事地圖是由一位叫傑夫（Jeff）的敏捷教練首先使用並總結的。傑夫最初使用這個方法的時候非常偶然。當時他的一位好朋友正在創業，準備做一個連接歌手與粉絲的音樂發行平台Mad Mini，因為遲遲不能發布產品，錢也燒得差不多了，於是找傑夫幫忙，希望通過敏捷實現快速交付。
傑夫那天去朋友的辦公室時，公司正在搬家，要搬到一個便宜的民居去，屋裡便空了。傑夫拉著他的朋友，坐在地板上，讓他描述用戶使用Mad Mini 的場景和需要做的特定動作。傑夫一邊聽，一邊寫用戶故事，並按照時間順序，排在地板上，不時地問些細節問題，寫些細化的故事。兩個小時，他們在地板上擺了一地的卡片，這就是世界上的第一幅用戶故事地圖。隨後，傑夫又幫他的朋友在地圖上直接做了一次發布規劃， 劃分出若干個交付版本。最後，傑夫帶著那個團隊按照敏捷的方式開發快速交付、快速探索用戶需求。
後來，傑夫就開始把這種整理需求的方式，記錄下來，並在部落格上分享，很快得到了很多人的認同。為此，他專門寫了《用戶故事地圖》這本書。
此部分內容節選自《敏捷無敵之DevOps時代》作者：王立傑、許舟平、姚冬（清華大學出版社）
如何製作用戶故事地圖
那麼，我們來看看用戶故事地圖應該怎麼製作呢？通過何種分析才能將用戶故事梳理出來呢？
• 地圖的核心是一條從左到右的時間線。
• 時間線的上部放置最大粒度的內容（可以理解為Epic）。
• 時間線的下部的第一行放置二級粒度內容（可以理解為Backlog Item），並在每個一級粒度下按照從左到右的優先順序進行放置。
• 每個二級粒度內容的下面，自上而下放置三級粒度內容（可以理解為Task）。
• 最終繪製出來一個完整的端到端的用戶故事。
我們先來看一個「早上起床出門」的用戶故事地圖：
我們首先划出一條時間線。在線的上部，是我們做的幾個主要事務，相當於Epic。接下來就是對主要事務的拆分了。比如「起床」這個Epic下，涉及「離床」、「疊被子」這樣的Backlog Item（Feature/Story）。而「疊被子」肯定是要在「離床」之後再做，所以按照時間線的順序，把「疊被子」放在「離床」的右側。再對Backlog Item進行細化，「離床」下面細化出了「睜眼」、「停鬧鐘」這樣的粒度更細的事項，相當於Task。
按照這樣的結構，我們就製作成了一幅用戶故事地圖。
這樣的用戶故事地圖構建體驗中，很強烈感受的是：大家專註、目標明確，討論完成的故事非常完整。
而且，筆者認為，用戶故事地圖最終展現出的成果並不是最重要的。我們最應當關注的是在製作用戶故事地圖的過程中，我們對於整個結構、流程的梳理。通過這樣的討論，讓每一個團隊成員都了解用戶故事地圖的脈絡，讓大家明白需求從何而來、為何而做，才是用戶故事地圖的意義。
