需求變化太過頻繁?

解決需求變化太過頻繁的最好方法，就是提升需求的品質。

提升需求的品質的良方 — 使用者故事地圖。

.

User Story Mapping  使用者故事地圖 / 使用者故事對照

Jeff Patton

.

化繁為簡，看見全貌

使用故事地圖的二個最大功能，第一、是化繁為簡；把一堆使用者故事用階層的方式加以排列出來之後，便可以讓需求的主從關係透過誰包含誰的方式逐漸的清晰化。讓你宛如在瀏覽書籍一般，那些個章、節、細節以至於小節及附錄都變得層次分明，確確實實的可以看得見需求的整體、看得見專案的Roadmap了。尤其可以讓你從龐大的需求中找出開發的起始點來，看到哪裡才是這次開發上的主要章節。

.

第二、是看見全貌 The Whole Picture。

我們往往要擁有足夠的抽象化才看的見全貌。例如:在畫廊裡欣賞畫作，想要細細品味時我們會站得近一些，想看見全貌時我們會往後退一些。尤其當有人請我們批評一下這幅畫作時，勢必要向後退個兩步，設法來看見全貌免得偏頗的妄下定論，避開以偏蓋全的小家視野。在英文著作裡常常可以看到作家寫道「從三萬英尺的高空看地面」正是這個意思。

常常有人批評我老是把「抽象」掛在嘴上，一副很容易的樣子，但對別人而言其實是很難的。我要辯駁一下，其實覺得空泛只是缺少練習罷了。請多練習讓自己退一步! 退一步有多難嗎? 就是不要看得太仔細了而已，先把細節拋在腦後，不要太快看到細節，因為這樣你反而不容易看見全貌了，是細節的內容先佔據了你的主觀。隨後要在逐步弄清全貌就要反反覆覆花上許多工夫了，這是需求必須反覆變動的一大因素 — 沒能夠在一開始，先看到全貌(這便是我們經常要求工程師不要太快將使用者故事 breakdown 成 Task 的主要原因)。

.

哈哈! 我知道你要埋怨我講得太容易，不急，我們不要空談，我們用工具來解決這個問題。

.

工具能夠能夠讓你事半功倍，尤其是 User Story Mapping

.

介紹二個我最喜歡的工具: Featuremap & StoriesOnBoard.

這二個工具都讓我學到一些運用使用者故事地圖的技巧，都很棒! 不論你用或不用他們，請一定要看完它們的廣告簡介，設計的真好，能一眼就教會你它是怎麼設計、怎麼來詮釋使用者故事地圖的。唯一不好的是，它們都要花錢去買，而且是按月計費的不是很便宜，這一點便很難讓人輕易的下決心將整個需求的大業就這樣子的交給他，但老實說，他們是絕對值得的。

.

我在太多地方推行過使用者故事地圖了，但客戶用得很成功的例子卻少之又少，原因是它們缺少好的工具(這一點微軟的 VSTS 或 Atlassian 的 JIRA都太讓人失望了)，這些挫折事後給我的教訓便是上完課後盡快推薦上面二個工具給他們，藉由好的工具來協助它們能夠化繁為簡，確實地掌握需求的全貌。

 

FeatureMap

這是一家法國公司Salience 的佳作，他採用的是平鋪直敘式的陳列使用者故事，我已經使用好幾年了，因為他針對個別的使用者帳號可以免費製作二個地圖。這一點確實很方便，我的"精實開發與看板方法"一書裡附錄的地圖就是用他編輯的。用起來像在編課表很簡單又好用，還可以列印出來分享。

.

實施"看板方法"的使用者故事地圖

.

 

 StoriesOnBoard

是匈牙利一家叫做 DevMads 的公司的傑作。他最精彩的地方是擁有二個操作模式，一個是創意模式，可以大量的放入使用者故事。 另一個是規劃模式，PO可以依據已有的使用者故事，開始區分相對功能的重要性及何時作甚麼版本的Release。他可以讓擁有構想的人們的抽象視野變得清晰可見(這是我最喜歡他的地方)。

.

這一 張圖的左右二邊，說明了二階段的運作。

.

不能再寫下去，再寫下去就有幫廠商廣告的意思了。純粹是把好東西介紹給大家，不過如果你已經試過採用 Excel 或 Powerpoint 來製作使用者故事地圖，而始終覺得少了些什麼的話，請試試上面的工具吧!

.

是的，敏捷宣言是這麼說的；「人與互動 更勝於 流程與工具」，但當你需要化繁為簡的時候，還是運用工具吧!這不就是我們身為軟體人所努力的方向嗎?

 

參考自:  Top Tools for User Story Mapping: From Post-Its to the Best Digital Apps

.

請用影響地圖講故事

有了架構良好的使用者故事地圖之後，該是PO把願景透過使用者故事逐步傳遞給團隊的時候了 — 講故事。這段前置作業的時間十分重要，雖然因為運用了抽象化的使用者故事來描述需求，讓我們擁有了避開傳統 waterfall 的計畫枷鎖，但過度的注重故事的細節將會導致團隊的開發時間的受到壓縮，會導致團隊因此而沒有了足夠的開發時間，這是一種浪費。但什麼時候才可以開始說故事呢? 正式的回答是在需求達到 Definition Of Ready 的時候，這是一個較大的議題，我們先不談他，跳過這個問題，我們來談談如何講故事?

.

使用者故事地圖不是一個講故事的好工具。因為好的故事總是從主角開始，然後描述了他的生長環境及背景，接著帶引大家一窺在各種遭遇之下他的種種反應成就了現在的他 – 這正是影響路徑。哈哈! 故事就是要這麼開始才有吸引力。所以我介紹大家要運用影響地圖 Impact Mapping 來說故事。因為他可以輕易的把你辛辛苦苦所寫出來的功能對應到他所要實現的業務目標上(我們稱他為影響路徑)。這裡不在贅述，請大家參考Gojko Adzic 的 Impact Mapping《影響地圖》這本只有73頁的小冊子。(我的說明在這裡)

.

使用者故事地圖可以讓你看見全貌、化繁為簡，

但影響地圖卻足以讓你開始講故事。

.

適合講故事用的《影響地圖》

強調一下，不是所有故事都該做 Impact Mapping 的(這麼做就太浪費時間了)，但他實在比使用者故事地圖要適合用來講故事用了。我通常會慎選在主要的網頁上那個主要的元件來做說明(一般就是這一個網頁的特色所在)，因為他值得我們多花一些時間來弄清楚，寫了這麼多的程式到底是為了甚麼。而相對的，目的通常是拿來評論(讓大家都看見)這麼做是值得的嗎?

.

 

 

 

User Story Mapping 使用者故事對照

 《 對付需求模糊的好幫手 – User Story Mapping》

.

（想寫一系列的User Story Mapping的實際應用，打算從 breakdown 自己上的《Scrum課程》開始: 簡報資料在這裡。我採用電子化的App來做這件事，它是純HTML的版本，可以隨時隨地更新故事，下面那張圖正是運用它EXPORT的功能所產生出來的。對時時需要做規劃的人而言；省時、省力，真是棒極了! ）

.

User Story Mapping 它能夠結構化使用者故事，好處多多，還能告訴我們:

• 專案該從哪裡開始做起(What to build first).
• 增強學習，鼓勵迭代開發(Encourage iterative development)
• 界定專案範圍(Scoping the project)
• 易於規劃專案(Planning the project)
• Backlog疏理及優先順序考量(Prioritizing and grooming the backlog)
• 專案進展的可視化(Visualize project progress)

(尤其能處理模糊的需求，它採用的是功能強大的 Hierarchical Planning 技巧，"階層“在這裡再次的展現了它的魔力)

.

※ 迅速展開的階層模式，能解決模糊的需求

其實我最喜歡它的是階層式(Hierarchical)的規劃模式，這是早該出現的使用者故事規劃方式了。大家還記得IBM早期作業系統的規劃文件嗎? 一種叫做 HIPO(Hierarchical Input Process Output)的文件製作模式，它被運用在描述OS/360、S/34/36/38 …等作業系統上。是1970年的古董了。凡是我經手的委外開發案，我一向採用HIPO來做交接文件(簡單、好用又不出狀況)。User Story Mapping (使用者故事對照)與HIPO 確實具有異曲同工之妙。

 

用它來做需求規畫可以讓原本顆粒較大、比較難以下手的需求，迅速的明確起來(試了幾回，效果好極了)。尤其是配合使用者故事的標準描述Template.

As a <role> , I want <goal/desire> so that <benefit>

完全相同，都是"以使用者為出發“，真是再適合不過了。描述: 第一層、針對該使用者(角色)，第二層、是他的目標(主題)，再依該目標所需要的第三層、活動及完成該活動所需要的第四層、任務來層層相扣，形成大故事包含小故事的情境。

下圖就是大故事包含小故事的情境，而我們現在所做的描述動作正是在作反過來用對照的訊息來說故事，這是它的另一個好處(参考資料)。我試著把上課的內容依聽課的學員種類，規劃如下:

Scrum 課程的Story Mapping

上圖是將Scrum課程的內容依照:

第一層是使用者: 區分成共通的部分、主管級、資深工程師、工程師。

第二、三層是主要題目及細項: 包括

1) 敏捷觀念；極致編成、SCRUM及看板方法。

2) Scrum原汁原味，採用2012 的Scrum Papers.

3) 需求分析；BrownCow理論說明: 採用 Robertson夫婦所撰寫的Mastering the Requirements Process: Getting Requirements.

4) 召開Scrum四種會議的練習:      Planning meeting/ Standup meeting/ Review meeting/ retrospective meeting.

5) 繪製 Scrum 流程練習: 請學員分別以目標、開發作業、特殊目的做主題繪製Scrum Process圖。

6) 使用者故事練習: 產品負責人做需求描述、Scrum Master及團隊成員做需求描述。

7)  讀書計畫練習: (分別參考以下書籍)

• 敏捷武士：看敏捷高手交付卓越软件
• 硝烟中的Scrum和XP
• Scrum 精髓
• 使用者故事與敏捷開發
• 敏捷教練
• Scrum 捷徑
• 30天軟體發展：告別瀑布擁抱敏捷
• Succeeding with Agile：Software Development Using Scrum

8) 針對主管的敏捷項目說明:

• 複雜專案的定義 Stacey Matrix
• 敏捷式的專案估算
• 敏捷合約
• 敏捷文件
• 制定簡單的團隊規範
• 敏捷風險管理

9) 針對資深工程師:

• 敏捷式的估算
• 結對編程   Pair Prohgramming
• 專案測試 – 測試案例 Testcase

10) 針對工程師:

• 工作項目的估算
• 使用者故事的拆解練習
• 單元測試 Unit Test

第四層是參考資料:

1) 針對主管: 說明”從Reifer的十個知識點”及Just Enough Software Architecture.

2) 針對資深工程師:” Scrum+Kanban敏捷專案管理培訓” 加上“Fit for Developing Software Framework for Integrated Tests”.

3) 針對工程師: 番茄工作法 The Pomodoro Technique"，"Code Simplicity“,"C#測試驅動開發“,"修改代码的艺术"

.

» 使用者故事對照的一個特色就是在你對照完成之後，可以反過來；按著表格把一塊一塊的故事說一遍，採用這種方式跟客戶進行確認故事的描述是否正確（這ㄧ點很像過去做系統訪談時，最後總要把內容疏理ㄧ遍，讓客戶確認）。例如：上圖中所分類的三種使用者，在第四層、参考資料的地方，1) 針對主管：我們取用Reifer的十個知識點作参考。目的是為了說明透過過去的統計資料，採用Scrum這種開發架構，在那些範圍適用，而那些地方較不適用。

.

故事先說到這裡，下一篇我會把剛剛完成的看板方法的書本章節，也來用 User Story Mapping 對照一下，經過對照之後，整個課程看得讓人神清氣爽，相信我你也會喜歡它的。