［小編］上週六瞭解了使用者故事地圖後，小編又查閱了一些資料，找到了以下這篇關於如何組織使用者故事地圖規劃的文章，分享給大家。也希望大家如果有好的實踐，也可以留言一起交流。
原文地址：http://winnipegagilist.blogspot.jp/2012/03/how-to-create-user-story-map.html
感謝Jeff Patton和其他人的大力推廣，使用者故事地圖已經成為敏捷需求規劃中的一個流行方法。使用者故事地圖可以將你的backlog變成一張二維地圖，而不是傳統的簡單列表。使用者故事地圖可以解決以下問題：
– 讓你更容易看清backlog的全貌
– 為新功能篩選（grooming）和劃定優先順序提供了更好的工具，幫助你做出決策
– 便於使用靜默頭腦風暴模式和其他協作方式來產生使用者故事
– 幫助你更好的進行迭代增量式開發，同時確保早期的釋出可以驗證整體架構和解決方案
– 為傳統的專案計劃提供了一個更好的替代工具
– 有助於激發討論和管理專案範圍
– 允許你從多個維度進行專案規劃，並確保不同的想法都可以得到採納
建立使用者故事地圖的8個步驟
- 召集到3-5名對產品非常熟悉的人員參與。3-5人聽上去像是個魔法數字，實際上是的。因為更少的人意味著你無法獲得足夠的建議，而更多人則會因為討論和協調降低會議效率。
- 使用靜默頭腦風暴模式，讓每個人在便籤紙上寫下自己認為重要的“所要做的事情”也就是 使用者任務（user task）。每個人都用同樣顏色的便籤來書寫自己的使用者任務描述，這個階段不要互相討論。一旦大家都基本完成了準備，讓每個人輪流大聲讀出自己的內容，並把便籤紙全部放置在桌面上，這時如果出現重複的內容就可以省略掉：
- 根據你的產品規模，這個過程可能需要3-10分鐘的時間；你可以觀察大家的行為來判斷是否需要停止。
- 基本上每張便籤都會以一個動詞開頭，如：傳送郵件，建立聯絡人，新增使用者等。
- 這些便籤組成了一級使用者故事，Jeff Patton稱為使用者任務（user tasks），它們組成了使用者故事地圖上的 “行走的骨骼” （the walking skeleton）部分。
- 這時可以提示參與者：我們只用了很少的時間就完成了需求的收集過程，而且有些內容你可能沒有想到，而其他人幫你想到了。
- 然後，讓大家將桌面上所有的便籤進行分組，將類似的任務分為一組，其他的的類似
- 這個過程最好也讓大家採用靜默模式進行，因為這樣做會更快。如果發現重複的內容，就略過
- 基本上分組會很容易完成
- 這時同樣觀察每個人的行為，判斷大家是否已經做完，基本上這個過程需要2-5分鐘
- 選擇另外一個顏色的便籤，對每個組進行命名，並貼在每組便籤的上部
- 對這些分好組的便籤進行排序，一般按照使用者完成操作的順序，從左到右擺放
- 如果大家無法決定順序，那麼順序可能沒有那麼重要（明顯）。
- 這一組便籤，Jeff Patton稱為 使用者活動 （User Activities）
- 這時你的地圖應該類似於
- 現在，按照 “行走的骨骼” 使用者行為 這行開始講述使用者故事，確保你沒有遺漏任何使用者行為和使用者任務。這時一般由組織者進行講述，其他人提出意見，甚至可以讓終端使用者來參與討論。
- 這時，我們已經完成了使用者故事地圖的基本框架；可以在每個使用者任務下面新增更加細節的 使用者故事（User Stories）了。這時仍然建議使用靜默頭腦風暴的模式來進行第一輪使用者故事的產生，同時藉助如Persona和Scenario等方式協助完成這個過程。一旦你完成了使用者故事的建立，就可以開始劃定你的 釋出計劃（Releases）了
- 一般我習慣在第一個釋出中只選擇每個使用者任務的2-3個使用者故事。這對於幫助大家排定優先順序和範圍將很有幫助。
- 基本上我們不必使用使用者故事的標準句法（As a …）來書寫這些故事，因為每張便籤都處於我們的地圖的特定位置，大家很容易識別其所處的場景和角色。
- 最後，針對第一個釋出的所有使用者故事進行分解，確保我們的第一個釋出越小越好，基本上你需要保證在1-2個迭代後就可以釋出你產品的第一個版本。
使用者故事地圖樣例
這裡是一個電子郵件系統的使用者故事地圖
– 第二行所包含的內容就是“大家在電子郵件系統所要做的事情”，包括類似：書寫郵件，傳送郵件，建立約會等等。
– 第一行對這些事情進行了分組
– 黃色的便籤的第一行包含了最小化的使用者故事，如：寫郵件只包括髮件人，收件人，標題，內容和傳送取消按鈕。其他如支援RTF，HTML格式，新增附件，從通訊部獲取聯絡人郵件地址等，都不在此行，放入更靠下的便籤中。
– 黃色便籤上的更小的藍色和橘黃色便籤表示了不同的狀態，比如：藍色代表完成，橘黃色代表進行中（wip），這樣你就可以看到專案的進展
現在如果我們專注於從左到右完成第一行的黃色便籤，我們就可以確保很快釋出一款包含了最最基本功能的郵件系統。這樣我們就可以驗證我們的郵件系統整體架構（傳送郵件同時確保其可以被閱讀）可行。同時也可以幫助我們對系統的功能進行端到端的測試，確保我們可以從使用者處獲取到反饋，知道我們是否解決了它們的問題（提供了商業價值）。注意我們在第一行沒有包含“刪除郵件”這一功能，因為並不一定要完成所有使用者任務的開發。
使用者故事地圖規範
– 第2個步驟中的便籤表示 使用者任務（user tasks），藍色便籤
– 第3-4個步驟中的便籤表示 使用者行為（user activies），橘色便籤。Jeff 稱這兩行的內容為 “行走的骨骼”（walking skeleton）和 “主幹”（backbone）
– 使用者故事（user stories），黃色便籤在每個使用者任務下自上而下排列，便於我們確定優先順序
– 一般來說使用者會按照從左到右的順序來使用你的系統（使用者故事地圖）
請關注微信公眾號 devopshub，獲取更多關於DevOps研發運維一體化的資訊
