創建用戶故事地圖(User Story Mapping)的8個步驟

［小編］上周六了解了用戶故事地圖后，小編又查閱了一些資料，找到了以下這篇關於如何組織用戶故事地圖規划的文章，分享給大家。也希望大家如果有好的實踐，也可以留言一起交流。

原文地址：http://winnipegagilist.blogspot.jp/2012/03/how-to-create-user-story-map.html

 

---

 感謝Jeff Patton和其他人的大力推廣，用戶故事地圖已經成為敏捷需求規划中的一個流行方法。用戶故事地圖可以將你的backlog變成一張二維地圖，而不是傳統的簡單列表。用戶故事地圖可以解決以下問題：

– 讓你更容易看清backlog的全貌
– 為新功能篩選（grooming）和划定優先級提供了更好的工具，幫助你做出決策
– 便於使用靜默頭腦風暴模式和其他協作方式來產生用戶故事
– 幫助你更好的進行迭代增量式開發，同時確保早期的發布可以驗證整體架構和解決方案
– 為傳統的項目計划提供了一個更好的替代工具
– 有助於激發討論和管理項目范圍
– 允許你從多個維度進行項目規划，並確保不同的想法都可以得到采納

 

創建用戶故事地圖的8個步驟

1. 召集到3-5名對產品非常熟悉的人員參與。3-5人聽上去像是個魔法數字，實際上是的。因為更少的人意味着你無法獲得足夠的建議，而更多人則會因為討論和協調降低會議效率。
2. 使用靜默頭腦風暴模式，讓每個人在便簽紙上寫下自己認為重要的“所要做的事情”也就是 用戶任務（user task）。每個人都用同樣顏色的便簽來書寫自己的用戶任務描述，這個階段不要互相討論。一旦大家都基本完成了准備，讓每個人輪流大聲讀出自己的內容，並把便簽紙全部放置在桌面上，這時如果出現重復的內容就可以省略掉：
   1.  根據你的產品規模，這個過程可能需要3-10分鍾的時間；你可以觀察大家的行為來判斷是否需要停止。
   2. 基本上每張便簽都會以一個動詞開頭，如：發送郵件，創建聯系人，添加用戶等。
   3. 這些便簽組成了一級用戶故事，Jeff Patton稱為用戶任務（user tasks），它們組成了用戶故事地圖上的 “行走的骨骼” （the walking skeleton）部分。
   4. 這時可以提示參與者：我們只用了很少的時間就完成了需求的收集過程，而且有些內容你可能沒有想到，而其他人幫你想到了。
3. 然后，讓大家將桌面上所有的便簽進行分組，將類似的任務分為一組，其他的的類似
   1. 這個過程最好也讓大家采用靜默模式進行，因為這樣做會更快。如果發現重復的內容，就略過
   2. 基本上分組會很容易完成
   3. 這時同樣觀察每個人的行為，判斷大家是否已經做完，基本上這個過程需要2-5分鍾
4. 選擇另外一個顏色的便簽，對每個組進行命名，並貼在每組便簽的上部
5. 對這些分好組的便簽進行排序，一般按照用戶完成操作的順序，從左到右擺放
   1. 如果大家無法決定順序，那么順序可能沒有那么重要（明顯）。
   2. 這一組便簽，Jeff Patton稱為 用戶活動 （User Activities）
   3. 這時你的地圖應該類似於
      
6. 現在，按照 “行走的骨骼” 用戶行為 這行開始講述用戶故事，確保你沒有遺漏任何用戶行為和用戶任務。這時一般由組織者進行講述，其他人提出意見，甚至可以讓最終用戶來參與討論。
7. 這時，我們已經完成了用戶故事地圖的基本框架；可以在每個用戶任務下面添加更加細節的 用戶故事（User Stories）了。這時仍然建議使用靜默頭腦風暴的模式來進行第一輪用戶故事的產生，同時借助如Persona和Scenario等方式協助完成這個過程。一旦你完成了用戶故事的創建，就可以開始划定你的 發布計划（Releases）了
   1. 一般我習慣在第一個發布中只選擇每個用戶任務的2-3個用戶故事。這對於幫助大家排定優先級和范圍將很有幫助。
   2. 基本上我們不必使用用戶故事的標准句法（As a …）來書寫這些故事，因為每張便簽都處於我們的地圖的特定位置，大家很容易識別其所處的場景和角色。
8. 最后，針對第一個發布的所有用戶故事進行分解，確保我們的第一個發布越小越好，基本上你需要保證在1-2個迭代后就可以發布你產品的第一個版本。

 

用戶故事地圖樣例

這里是一個電子郵件系統的用戶故事地圖

– 第二行所包含的內容就是“大家在電子郵件系統所要做的事情”，包括類似：書寫郵件，發送郵件，創建約會等等。
– 第一行對這些事情進行了分組
– 黃色的便簽的第一行包含了最小化的用戶故事，如：寫郵件只包括發件人，收件人，標題，內容和發送取消按鈕。其他如支持RTF，HTML格式，添加附件，從通訊部獲取聯系人郵件地址等，都不在此行，放入更靠下的便簽中。
– 黃色便簽上的更小的藍色和橘黃色便簽表示了不同的狀態，比如：藍色代表完成，橘黃色代表進行中（wip），這樣你就可以看到項目的進展

現在如果我們專注於從左到右完成第一行的黃色便簽，我們就可以確保很快發布一款包含了最最基本功能的郵件系統。這樣我們就可以驗證我們的郵件系統整體架構（發送郵件同時確保其可以被閱讀）可行。同時也可以幫助我們對系統的功能進行端到端的測試，確保我們可以從用戶處獲取到反饋，知道我們是否解決了它們的問題（提供了商業價值）。注意我們在第一行沒有包含“刪除郵件”這一功能，因為並不一定要完成所有用戶任務的開發。

 

用戶故事地圖規范

 

– 第2個步驟中的便簽表示 用戶任務（user tasks），藍色便簽
– 第3-4個步驟中的便簽表示 用戶行為（user activies），橘色便簽。Jeff 稱這兩行的內容為 “行走的骨骼”（walking skeleton）和 “主干”（backbone）
– 用戶故事（user stories），黃色便簽在每個用戶任務下自上而下排列，便於我們確定優先級
– 一般來說用戶會按照從左到右的順序來使用你的系統（用戶故事地圖）

 

---

請關注微信公眾號 devopshub，獲取更多關於DevOps研發運維一體化的信息