Ruddy Lee 分享空間

Emergent Design 演化設計

需求變化太過頻繁?

leave a comment »

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

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

.

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

000 Jeff-Patton-Headshot-200x200.jpg

Jeff Patton

.

化繁為簡,看見全貌

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

.

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

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

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

.

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

.

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

.

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

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

.

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

 

FeatureMap

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

.

0 看板方法 map

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

.

 

 StoriesOnBoard

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

.

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

000 StoriesOnBoard

.

不能再寫下去,再寫下去就有幫廠商廣告的意思了。純粹是把好東西介紹給大家,不過如果你已經試過採用 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 的(這麼做就太浪費時間了),但他實在比使用者故事地圖要適合用來講故事用了。我通常會慎選在主要的網頁上那個主要的元件來做說明(一般就是這一個網頁的特色所在),因為他值得我們多花一些時間來弄清楚,寫了這麼多的程式到底是為了甚麼。而相對的,目的通常是拿來評論(讓大家都看見)這麼做是值得的嗎?

.

 

 

 

Written by ruddyllee

2016 年 07 月 16 日 於 10:47:29

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 變更 )

Twitter picture

You are commenting using your Twitter account. Log Out / 變更 )

Facebook照片

You are commenting using your Facebook account. Log Out / 變更 )

Google+ photo

You are commenting using your Google+ account. Log Out / 變更 )

連結到 %s

%d 位部落客按了讚: