Ruddy Lee 分享空間

Emergent Design 演化設計

需求分布圖

leave a comment »

.

為什麼要看需求的分布呢?

因為要了解專案開發的人力、時間都用到那裡去了,是否把開發的主力都放對地方了呢?若要加快專案開發的速度,那些地方(需求)是最可以取捨的、影響又較少的地方。不只開發人員想知道,使用者更應該知道。

.

由需求的數量、開發時間及它在示意圖上的服務節點,可以看出專案開發的負荷及重點所在,以及它完成後將對使用者的影響。

.

1.jpg.

示意圖提供了使用者的種種行為場景,接著在針對示意圖,把各個需求放在它所服務的節點上,這樣就可以看出相對於使用者行為上開發團隊將要付出的努力所在了。當然也能拿來看出此次專案的開發重點(通常就是需求最多,最花時間的地方)。下面們就用範例來做說明,讓大家比較容易了解。

.

用一場演講來作範例

首先講師把演講的過程畫成示意圖,下面的範例是我在參加Agile Tour 2017所演講的題目: 讓英雄先救貓咪。 演講過程的示意圖如下,左邊是「涉及人」也就是來聽演講的學員,最右邊是「標的物」也就是做完演講之後,所產出的圖像紀錄。

.

2.jpg

讓英雄先救貓咪的演講場景圖示

.

這裡我們把演講的Slides當成需求,演講的過程當成描述使用者行為的場景,圖上打勾的符號表示會講到的 Slide, 打叉的是不會講到的 Slide(這是自己講課時的一種習慣,通常我們會先針對演講主題準備演講資料,最後才是針對演講的時間長短進行刪刪減減,也就是那一堆打叉的slide囉,我的習慣是把它留給學員自己參考用而不做刪除,目的是針對演講主題的完整性而不是演講時間的限制)

花較多時間講的正是講師所想闡述的重點 

我們把slide數當成需求,由需求在示意圖上各個節點的分布數量,便可以一眼望穿每個節點個別需要多少使用者故事才足以完成這項服務(功能)。也能藉著視覺化看出專案服務客戶在進行各種操作行為上的負荷(完成此項需求,工程師所需要投入的開發時間),我們也可以依據它來進行價值判斷,考慮是不是值得做這麼大或是應該再加重投資開發某項功能的比例。因此,需求分布圖足以讓我們看見專案在開發上各個需求所占的比重大小。

.

3.jpg看見專案負荷的比重

.

專案開始之初  — 看見全貌

專案開始之初首要在先看見全貌,而「需求分布圖」則是可以在需求示意圖完成後用來分析專案開發的重點所在。我們可以拿來作為投資報酬率的評估用,依據開發功能、數量在某一個服務節點上是否做了過度的投資的統計依據。它可以讓我們再一次客觀的審視各個使用者故事在某一個情境上的負荷及相對的價值。

.

結語

需求分布圖的依據是使用者的場景示意圖,一切以使用者為主軸。它的效用就好必影響地圖一般,可以看見工程師開發某一個功能相對於它對使用者的影響路徑所在,可以用來分析用。而需求分布圖看的則是全貌,展示專案開發在需求負荷下的分布狀態,我們可以拿來評估專案的目標跟預期的計畫重點是否一致,有沒有做錯重點、把時間及開發功能投資錯了地方。

它也是我上課時的依據,我會把課程先做成情境的描述示意圖(它就是整個演講的過程),然後把如何協助講課的 Slide當成需求(凡需求就要區分重要性,也就是Must have/ Should have/ Could have/ Won’t have的區分),它是我拿來對演講時間有限的清況下,這時候;我只要斟酌這張投影片的重要性,再決定要不要放棄不講(也就是在右上角標示 W: won’t have 符號)。

 

參考: 「讓英雄先救貓咪」的演講投影片

https://1drv.ms/f/s!AtlpfGB0RrJoh7sK0CvFHArPKK95qA

 

廣告

Written by ruddyllee

2017 年 03 月 24 日 於 11:46:42

發表迴響

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

WordPress.com Logo

您的留言將使用 WordPress.com 帳號。 登出 / 變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 / 變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 / 變更 )

Google+ photo

您的留言將使用 Google+ 帳號。 登出 / 變更 )

連結到 %s

%d 位部落客按了讚: