.
「使用者故事地圖」是用來組織和對需求排列優先順序的最佳工具。
User Story Mapping is an an approach to Organizing and Prioritizing user stories
寫書的道理
書；因為要闡述一堆道理，因此需要由淺入深、按部就班地讓讀者吸收到裡面的資訊，因此排列的井然有序是必要的，為了吸引讀者，它竭盡所能的運用各種圖像、色彩來加深讀者的吸收能力。這跟專案開始之初，PO 運用卡片來撰寫使用者故事作需求的描述，希望工程師能夠讀懂它，然後拿來開發製作軟體，幾乎是同一個道理。
我喜歡拿規劃出書來比喻排列組織「使用者故事地圖」的過程。在看書時，我們總是由前言開始 — 目的是，知道他想表達些甚麼。然後翻到目錄 –希望能一眼望穿有多少東西在裡面。翻到有興趣的章節，接著便是用眼睛來聆聽作者所想講的故事。使用者故事地圖也是這麼回事。尤其是它能讓我們看到專案開始之初的全貌 (Big Picture)。
.
The big picture 指的是一件事的全貌, 或是長期的願景, 真正的目標。
.
敏捷開發的浮現式開發方式 — 容易遺漏全貌
由於敏捷開發採用使用者故事來描述需求，因此專案在開始之初便是大量的產出需求，也就是透過大量的使用者故事來描述需求，然後開發團隊再針對這些故事進行討論，透過會議、討論、溝通，嘗試讓團隊對需求有進一步相同的認知與了解以便進行開發作業，接著便是期待著每一個Sprint 的開發過程，都能夠產出一個大家預期的功能，用這種漸增的方式讓產品越來越完整，這便是敏捷開發。但這種運用一個一個故事來描述需求的方式很容易讓我們過度專注於故事所描述的細節而反而忽略了專案的全貌。
.
專案開始之初，最重要的一件事便是看見全貌，劃出邊界。
.
使用者故事的缺點 — 見樹不見林
基本上，使用者故事並不容易得到，因為使用者並不知道所有的需求，所以不能單靠使用者給我們解釋需求。當需要大量產出使用者故事時；有一種常用的克服方式，便是找一些專家(SME，Subject Matter Expert)進行一場頭腦風暴，然後很快地便能找到許多使用者故事了，接著再來進行需求梳理的動作。但這種作法有一個明顯的缺點，便是要花上許多時間來對使用者故事進行一一的梳理動作，這樣的動作非常容易讓我們落入所謂的見樹不見林的迷惑中。尤其是針對一群專業的工程師們，因為專業性的作祟，一看見需求，便很容易迅速地就落入解題的思維，於是很快地開始畫架構圖、選擇適用的設計模式等等，而忽略了應該先審視一下專案的全貌，先確定工作的範圍才是專案開始時最最重要的一件事。
另外；便是受使用者故事粒度太細所牽引的關係，越細的故事越容易讓人立即落入估算、解題的思維，所以在面對一堆較細粒度的故事時，就很容易落入見樹不見林的情境。
解決的方法: 採用使用者故事地圖user story mapping來看見全貌。
(我喜歡Jeff Patton在他的名著:使用者故事地圖一書裡的第一章第一節所用的抬頭 The “A” Word，拿這個字來描述專案的全貌，讓人感覺既抽象又很容易記住。)
The “A” Word – The Big Picture
讓使用者故事地圖 User Story Mapping 協助你看見全貌(The Big Picture)。怎麼做呢? 我們用寫一本書的步驟來比喻如何建立使用者故事地圖。
》首先；列出章、節。
「章」便是使用者的活動User Activities。一般就是按照使用者完成操作的顺序，從左到右依序擺放。重要的放在前面。
「節」便是使用者的任務User Tasks。就是撰寫一級(較大)的使用者故事(Epic)，一般會用動詞開頭的描述來說明較完整的任務(例如: 建立郵件、發送郵件、等功能 )。
這樣便完成Jeff 所謂的“行走的骨骼”walking skeleton，還有他的書裡頭那張有一點嚇人的圖片。
Walking skeleton
他是拿來講故事用的。我們可以按照 “行走的骨骼”來描述使用者的行為，從這一行開始講述故事，確保你沒有遺漏任何使用者必要的行為(user activities)和使用者任務(user tasks)。明顯得很“行走的骨骼”是用來隱喻，需求尚缺少大部分的物件(沒有肉體)，但實質上已經具有一個外型及架構了。
》接著，加一點東西
此時；我的習慣是立刻加入下一層的「小節」段，而且通常只加入一二個項目，不會加多或企圖加的完整，目的只是讓思緒再深入一點點而已，它是一個標誌點(tag)。我覺得這樣可以讓我在下一次新增項目時有一個參考點可以很快地繼續想下去。下圖是我的書”精實開發與看板方法”的目錄，寫作時就是先用user story mapping 來做構思的。
作者之所以想出書，通常都是有一大堆東西想跟讀者分享，所以才會動起寫書的念頭，但千頭萬緒該從哪裡開始呢?! 使用者故事地圖正是此時拿來做為解題用的佳作，它尤其適合在太多觀念想說的時候(也就是使用者故事太多，造成需求模糊的時候)。我想；不管你想不想出書，試試看，把一堆觀念作成階層式的排列，井然有序的外觀，對思緒的淨化是有相當的幫助的。
書的行走的骨骼 walking skeleton
使用者故事本身是文字化的描述，我們很難依據字面上的描述來看出它的大小階層，然後進行排序，但一旦採用上圖的階層式的排列之後。大的章節便清晰可見，上圖中的第二層，也就是 User Tasks層正是書的骨架，也就是整個產品的骨幹。( jeff Patton 把第一層稱之為使用者的活動User Activities，第二層為使用者任務層 user tasks。這二層構成了他所謂的行走的骨骼 walking skeleton)。
最後；依據功能多寡，推定迭代的範圍及預訂的產出功能。
完成後書使用者地圖的全貌:
對照使用者故事地圖轉換成product backlog，並依照需求重要性排列優先順序的圖示如下。便可以看見概略的估算在哪一個迭代的Sprint開發之後，將會產出哪一些功能(如右側圖示的Sprint 週期)。
結論
使用者故事地圖可以讓我們更容易看清需求的全貌。它能協助你進行決策，篩選功能（grooming）和制定需求的優先順序，尤其是讓我們很容易看見使用者故事描述到的功能有重疊的現象，便於我們進行篩選、定位。當然它尤其對架構的設計有相當的幫助，讓開發作業較為井然有序，甚至讓我們據以預測未來(錯! 實際上是規劃未來)。
乍看起來真是好棒的功能，我們可以從中間獲得(確定)好多利益，但是老實說，在專案開始之初由於不確定的因素或是資訊佔大多數，所以使用者故事地圖最大的目的應該是放在協助我們抽象的看見全貌，然後依據它來思考專案的起始點，拿來規劃每個迭代循環的階段性目標(產出物)，也就是規劃要產出的潛在可交付的產品為何，而不是進行完整的規劃工作。在本質上；因為專案的全貌是會變動的，這一點與使用者故事十分相同。人們在剛開始接觸到使用者故事時，往往用靜態的觀念來思考它，但其實它是一直在蛻變的(請參考Gojko Adzic的實例化需求)，也就是說全貌是會隨著開發過程而演進的。使用者地圖會隨著需求功能的新增或刪除而改變，因此我們的規劃也必須隨著它的變化進行調整，而這才是敏捷開發的本質。
下圖是採用FeatureMap 所製作的使用者故事地圖，需要的人email給我，歡迎分享。(https://www.featuremap.co/maps/ruddytest22/使用者故事地圖)
Jeff Patton 所著的"用戶故事地圖" 的用戶故事地圖。
參考: http://winnipegagilist.blogspot.jp/2012/03/how-to-create-user-story-map.html
Ruddy Lee 分享空間 