敏捷需求的分析工具

.

敏捷探討需求的分析工具

圖示.png

敏捷說明敏捷探討需求的分析工具說明

.

專案負責人Product Owner的利器

  1. 產品心經: 產品經理應該知道的60件事
  2. 超越需求: 敏捷思維模式下的分析 (Beyond Requirements: Analysis with an Agile Mindset)
  3. 用戶至上 (Understanding your users: a practical guide to user research methods) 用户至上(用户研究方法与实践原书第2版)
  4. 如何衡量萬事萬物:大數據時代,做好量化決策、分析的有效方法 (How to Measure Anything: Finding the Value of“intangibles” in business
  5. Essential Kanban Condensed  by David J Anderson and Andy Carmichael
  6. 使用者故事對照 (User Story Mapping: Discover the Whole Story, Build the Right Product)
  7. Google 創投認證!SPRINT 衝刺計畫:Google 最實用工作法,5天5步驟迅速解決難題、測試新點子、完成更多工作!(Sprint: How to Solve Big Problems and Test New Ideas in Just 5 Days)
廣告

需求變化太過頻繁?

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

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

.

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

.

 

 

 

看見的力量 – (III)使用者故事地圖

.

使用者故事地圖」是用來組織和對需求排列優先順序的最佳工具。

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,還有他的書裡頭那張有一點嚇人的圖片。

00 walking skeleton

Walking skeleton

他是拿來講故事用的。我們可以按照 “行走的骨骼”來描述使用者的行為,從這一行開始講述故事,確保你沒有遺漏任何使用者必要的行為(user activities)和使用者任務(user tasks)。明顯得很“行走的骨骼”是用來隱喻,需求尚缺少大部分的物件(沒有肉體),但實質上已經具有一個外型及架構了。

 

》接著,加一點東西

此時;我的習慣是立刻加入下一層的「小節」段,而且通常只加入一二個項目,不會加多或企圖加的完整,目的只是讓思緒再深入一點點而已,它是一個標誌點(tag)。我覺得這樣可以讓我在下一次新增項目時有一個參考點可以很快地繼續想下去。下圖是我的書”精實開發與看板方法”的目錄,寫作時就是先用user story mapping 來做構思的。

0 chapter

作者之所以想出書,通常都是有一大堆東西想跟讀者分享,所以才會動起寫書的念頭,但千頭萬緒該從哪裡開始呢?! 使用者故事地圖正是此時拿來做為解題用的佳作,它尤其適合在太多觀念想說的時候(也就是使用者故事太多,造成需求模糊的時候)。我想;不管你想不想出書,試試看,把一堆觀念作成階層式的排列,井然有序的外觀,對思緒的淨化是有相當的幫助的。

 

0 看板方法 map

書的行走的骨骼 walking skeleton

使用者故事本身是文字化的描述,我們很難依據字面上的描述來看出它的大小階層,然後進行排序,但一旦採用上圖的階層式的排列之後。大的章節便清晰可見,上圖中的第二層,也就是 User Tasks層正是書的骨架,也就是整個產品的骨幹。( jeff Patton 把第一層稱之為使用者的活動User Activities第二層為使用者任務層 user tasks。這二層構成了他所謂的行走的骨骼 walking skeleton)。

 

最後;依據功能多寡,推定迭代的範圍及預訂的產出功能。

完成後書使用者地圖的全貌:

書的結構

 

對照使用者故事地圖轉換成product backlog,並依照需求重要性排列優先順序的圖示如下。便可以看見概略的估算在哪一個迭代的Sprint開發之後,將會產出哪一些功能(如右側圖示的Sprint 週期)。

 

00 需求排序

結論

使用者故事地圖可以讓我們更容易看清需求的全貌。它能協助你進行決策,篩選功能(grooming)和制定需求的優先順序,尤其是讓我們很容易看見使用者故事描述到的功能有重疊的現象,便於我們進行篩選、定位。當然它尤其對架構的設計有相當的幫助,讓開發作業較為井然有序,甚至讓我們據以預測未來(錯! 實際上是規劃未來)。

乍看起來真是好棒的功能,我們可以從中間獲得(確定)好多利益,但是老實說,在專案開始之初由於不確定的因素或是資訊佔大多數,所以使用者故事地圖最大的目的應該是放在協助我們抽象的看見全貌,然後依據它來思考專案的起始點,拿來規劃每個迭代循環的階段性目標(產出物),也就是規劃要產出的潛在可交付的產品為何,而不是進行完整的規劃工作。在本質上;因為專案的全貌是會變動的,這一點與使用者故事十分相同。人們在剛開始接觸到使用者故事時,往往用靜態的觀念來思考它,但其實它是一直在蛻變的(請參考Gojko Adzic的實例化需求),也就是說全貌是會隨著開發過程而演進的。使用者地圖會隨著需求功能的新增或刪除而改變,因此我們的規劃也必須隨著它的變化進行調整,而這才是敏捷開發的本質。

下圖是採用FeatureMap 所製作的使用者故事地圖,需要的人email給我,歡迎分享。(https://www.featuremap.co/maps/ruddytest22/使用者故事地圖)

 user story mappingJeff Patton 所著的"用戶故事地圖" 的用戶故事地圖。

參考:  http://winnipegagilist.blogspot.jp/2012/03/how-to-create-user-story-map.html