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