北京這幾日的天兒真是好的出奇，白天風和日麗，晚上繁星漫天；在這樣一個週六的下午，小編參加了一次北京敏捷社群（微訊號：Agile1001）組織的活動：《使用者故事地圖User Story Mapping 實戰工坊》，雖然對使用者故事地圖是第一次接觸，但也有一些小小的體會，回到家中是在按捺不住想寫下來分享給大家。
今天的活動由《百度方法+》發起人，軟體工程團隊負責人李濤引領大家進行實戰體驗，他也是《使用者故事地圖》這本書中文版的譯者。
《使用者故事地圖》這本書的原作者 Jeff Patton 是一位獨立顧問，講師和敏捷教練；他所提出的使用者故事地圖的方法主要用於解決敏捷需求分析過程中的問題：
– 只見樹木不見林，重要的待辦項容易淹沒在各種細節中看不到全貌，因而難以排列優先順序
– 不能明顯地聚焦於使用者需求
– 很難了解不同粒度故事(史詩故事、主題故事以及故事)之間的關係
– 不能方便地瞭解系統提供的功能的完整性
– 不能方便地瞭解系統提供的工作流以及價值流
– 不能方便地利用遞增和迭代的方式去確定釋出計劃以及釋出目標
小編之前使用敏捷方法帶過幾個專案，對這些問題深有體會。當我們開始進行一個產品或者專案規劃的時候，首先需要梳理出一個backlog，在其中按照優先順序列出所要實現的場景和具體功能。這時我們首先遇到的一個問題就是如何確保我們的backlog覆蓋了最重要的使用者體驗路徑，是否我們當前所規劃的場景確實可以為使用者提供價值？這點對於敏捷開發非常重要。對精益有一定了解的朋友一定知道MVP（Most Variable Product 最小化可用產品）的概念，MVP的目的是以最小的投入釋出對使用者有價值的產品，幫助我們快速試錯，並通過不停的迭代最終找到產品的正確方向。這個思路很好，但如何確認我們的backlog中的內容是那個“最小的”而且“可用”的產品卻是件很困難的事情。我在和團隊一起討論初始產品需求的時候常常會因為大家的理解不同而花費大量的時間進行梳理，但卻發現每次即便我們將結果用文件記錄下來，大家仍然缺乏對產品的總體認識，這就是所說得“只見樹木不見林”的狀態 … … 因為，缺乏一種將使用者故事視覺化的方法。
使用者故事視覺化 – 起床故事
今天的實戰工坊中最精彩的部分就是團隊演練，李老師首先對使用者故事地圖的結構進行了簡單介紹，然後要求我們分組討論一個最簡單的場景：早上起床出門。以下就是我和小夥伴們整理的第一個使用者故事地圖：
每個人都非常熟悉這個場景，但是當我們開始討論的時候，2個問題開始浮現
– 每個人習慣不同，如何統一我們的故事？
– 從起床到出門要經歷幾個不同的階段，到底應該如何確定階段？
第一個問題其實是“使用者故事”要解決的首要問題，這個場景的角色（Persona）是誰？第二個問題其實就是確認需求的粒度過程。
在敏捷需求分析過程中，對Persona的確認非常關鍵，如何統一大家的思路並讓大家可以在討論某個場景的時候可以聚焦到特定的Persona上是我之前經常遇到的問題。討論中經常會跑偏，本來談這個Persona，結果跑到另外一個Persona上去了。今天討論中，我們首先將Persona的定義通過卡片貼在了時間線的左側，這個很小的動作，卻讓團隊的成員可以非常專注於當前Persona的場景討論，效率很高。
再說說粒度，以前經常有人問我backog item的粒度如何確定，而我的回答經常是從實現的角度來考慮，比如：控制在2-3天的工作量上。其實這是個非常不靠譜的建議，因為在討論需求的過程中還無法確認是否要做，更談不上評估工作量。
這裡暴露了Scrum的一個最主要的問題，backlog解決的是在story確認以後如何進行開發過程規劃的問題，而對story該如何產生，如何設計的問題並沒有給出很好的解決辦法。我們往往把story當成需求來看，而實際上敏捷使用story來描述需求的目的是為了協助團隊進行討論，以便最終確認需求（也就是specification）。使用者故事地圖的作用就是將user story的簡單描述：
As a …. I want to … so that …
用視覺化的方式展現在團隊面前，讓團隊可以仔細梳理，討論，確認這個story包含的內容，最終產出specification進行開發。
使用者故事地圖的結構
– 每個使用者故事地圖代表一個完整的使用者故事
– 地圖的核心是一條從左到右的時間線
– 時間線的上部放置最大粒度的內容（可以理解為Epic）
– 時間線的下部的第一行放置二級粒度內容（可以理解為backlog item），並在每個一級粒度下按照從左到右的優先順序進行放置
– 每個二級粒度內容的下面，自上而下放置三級粒度內容（可以理解為task）
最終我們繪製出來一個完整的端到端的使用者故事。今天的“起床故事”體驗中感受最強烈的是：大家專注，目標明確，討論完成的故事非常完整。
使用者故事地圖如何銜接開發計劃
因為有時間線和卡片放置方式的約束，可以很容易的劃分出每個Release所需要完成的需求，如下圖：
自上而下，我們可以劃分出不同的Release；同時因為每個Release都是和時間線平行的，確保了在放入Release的過程中必須考慮故事的完整性。
小結
今天下午短短的4個小時，對使用者故事地圖只能說有了一個非常膚淺的瞭解；個人覺得這是一個非常簡單易行的方法，確實能夠解決敏捷需求分析/設計階段的問題。而這，恰恰是Scrum中所缺失的部分。
小編也很喜歡實戰工坊的組織形式，很感謝北京敏捷社群的組織者們，這才是用敏捷的方式學習敏捷！
這裡也附上北京敏捷社群2016年活動預告，感興趣的同學自己掃碼關注吧。
附上幾張照片，讓大家也體會一下現場的火爆：
小編在現場也忍不住體驗了一把產品經理， 一個字：爽！
推薦這本書大家，封面上這行字道出了使用者故事地圖的真諦 “洞察真需求，研磨好產品”。不過，此書還未正式出版（應該很快了），大家先不要急著去搜，今天小編在現場也是第一次見到“毛（坯）書”，只可惜沒有搶到。索性定了英文原著，待我仔細研讀後再和大家分享。
請關注微信公眾號 devopshub，獲取更多關於DevOps研發運維一體化的資訊
