Ruddy Lee 分享空間

Emergent Design 演化設計

如何知道團隊的開發速率 – 累積流程圖

leave a comment »

身為團隊的一員或許你是主管、PO或是Scrum Master,你需要知道團隊的開發速率,你需要依據這個簡單的輸出入模型(註1)。用來做為團隊是否能夠繼續接受新需求的依據。

.

(一些我曾經帶過的敏捷團隊,它們從頭到尾都沒有使用任何一種專案開發的工具,真是可惜! 也就是說,他們從來沒有機會看到工具為專案開發所統計出來的各種資訊。這篇文章是獻給你們的,祝一切順利! 即使不順利,我相信你們一定很快就能克服的)

.

000 死亡行軍

.

上圖,由上往下看: 橘色線是需求、紅色線是開發作業、藍色線是測試、綠色線是完成。從二個軸的交點,也就是由原點往右上方看去,所有的線條都漸行漸遠,沒有交集(如果是直線完全沒有波折那該有多好,那就是Waterfalls 認為的開發過程了)。線條沒有交集到,就表示沒有進度,顯示出一種永無止境的專案開發情境,真是可怕的情境,也就是從開發到完成越行越遠,也就是說產品交付日遙遙無期。除此之外,需求仍在增長。(這正是鳳凰項目小說裡的鳳凰計畫Phoenix project 的寫照,此書若有再版的話,我會建議它採用此圖來做說明的, 哈哈 XD)

.

 

盲目接收需求的後果死亡行軍

累積流程圖Cumulative Flow Diagram: CFD 水平軸的單位是時間,垂直軸線則是工作量。它記錄著這整個專案的開發歷程,從一個product backlog被拿出來(上圖,橘色的線條)開始分析一直到完成為止(綠色線條)的所有過程及時間。它是一種以面積做表示的區域性圖示(這些數據過於繁瑣,千萬不要用人工去收集)。若你有採用專案控管的數位工具,則一般而言你已經擁有了顯示累積流程圖的能力了,只是大家經常忽略了它的重要性。就好像許多IT部門的主管,極少數會去衡量開發或維運團隊是否已經觸及他們的工作極限了,應該設法平衡工作量大小的時候了。而不是等到有人員提出辭呈時才開始思考這個問題。其實答案一直在那裏,只要你翻開累積流程圖就能看到現在在開發上的真正問題,請從累積流程圖來查看你的專案狀態。

 

上面這張圖就是典型的開發團隊,不知節制,猛接需求的後果,結果就是產生著名的「死亡行軍」或是 DevOps小說「鳳凰項目」中的布倫特先生事件。說白一點,就是需求不斷的增加但產能卻越來越下降(開發團隊持續加班但就是不見好轉),交付日期只能不斷的延期,而產品品質卻一直下降。為什麼呢?! (這是鳳凰項目這本小說的第一部分所描述的主要問題,癥結就發生在布倫特先生身上,如果你還沒看過此書,它是DevOps 之下的一本成名小說,由一位CTO 及二位資深IT人共同撰寫的科技小說,全名是: The Phoenix Project: A novel about IT, DevOps, and Helping Your Business Win)

如果我們不知道開發(維運)團隊的能力所在,為他們設下限制的話。又繼續盲目的接受使用者提出的需求,結果可能就是上面這一張累積流程圖所顯示的狀態,所謂的「死亡行軍

 

.

解題方法

想辦法讓累積流程圖變成下面這個樣子。讓WIP半成品數越行越近,讓開發的Lead time 減少(努力設法讓每一個步驟花更少的時間來完成),造成下圖中的虛線部分能夠越快接觸到需求的頂端越好。正確作法: 就是立刻暫停需求。這是「鳳凰項目」小說裡的解題方法,也正是著名的啤酒效應(Beer effect,註2),也稱啤酒游戲(Beer Game / Beer Distribution Game)的正確解答,它一直是生產與供需平衡的一個著名故事。

.

 

000 cfd-03

修正死亡行軍的圖示

.

用暫停生產來換取庫存半成品數量的迅速下降

立刻暫停需求是可以馬上減少WIP半成品數的最好方法,對生產線而言再正確不過了,在沒東西生產的情形下,只要有出貨多少量,庫房裡的半成品數自然就減多少了,這是在簡單不過的算術問題。但理想就是理想,小說終歸小說,你我都知道在真實的世界裡很難有那麼誇張的決策(正確講法是很少有人敢於負起這個責任),那該怎麼辦呢?

.

讓需求分級,讓處理人員分工

在真實世界裡,為了讓主要的維護人員挪出時間進行開發工作,一種權宜的作法(階層化):將需求依困難程度分類,只有最緊急的事件才由主要的人員來處理,其他業務就交給其他人員來處理,便可以逐漸的減少主要人員的負荷(讓團隊能夠平攤負荷)。嘗試看看,然後讓這個歷程所記錄下來的累積流程圖的結果來告訴你,接著該怎麼做(瓶頸理論Bottleneck principle是這麼說的,任何系統都至少會有一個瓶頸存在,解決完一個之後再去尋找下一個,瓶頸會一直存在的),所以這個行為必須是持續不斷的行為就好比累績流程圖的名稱一樣。

.

累積流程圖的效用

累積流程圖是開發歷程的全紀錄(請運用專案開發的工具來做紀錄),它有二部分,其一、基本功能部份,它提供我們一些明確的數據做參考,這部分不在此做說明,請參閱: 累積流程圖 Cumulative Flow Diagram。另一部分是它抽象化顯示的部分(例如上面那二張圖示,我刻意選擇了Pawel Brodzinski 的圖示,就是因為他用手繪的圖形,讓人有著足夠的抽象感,而抽象化的包容度能讓我們拿它來作為決策的依據時有著更大的容錯性),這正是累積流程圖最有威力的一部分,它能夠提供我們對未來做決策時的參考指標。

.

如何檢視累積流程圖

首先;讓他與看板相結合,下面圖示把工作看板畫在上面,而團隊開發歷程的紀錄則採用累積流程圖(cumulative flow diagram)畫在下面。圖上的顏色相互對照,你可以發現,看板上有幾個工作欄位,累積流程圖就會呈現出幾條線,他們是對稱的。很多人以為半成品 WIP是要設定才會產生的,這是一種錯誤的想法(沒設定是因為你有主動去規範它),其實半成品一直存在的,一旦我們將需求抽出來開始工作時(綠色的線)它就誕生了(如圖所示),要一直到它走進完成的區域(紅色的線),才會消失。換句話說,只要有開發流程就一定會有半成品。而我們該在意的是每個步驟之間在時間上的合理消長。也就是盡力去減少WIP的數值,相對的就是加快產能了。如圖上所示,設法讓綠色的線與紅色的線越密集,也就是開發速度越好。當然直接設法縮減每個開發步驟的時間也可以做到。

.

000 cfd

 

.

這部分說來話長,但 Pawel Brodzinski 寫得好極了(就是長了一點),請大家參考: Cumulative Flow Diagram

(我整理了一份中文化後的Ppt檔做為上課用,稍後再放到OneDrive上面。)

 .

 

小結

請善用專案管理工具的力量,尤其是開發歷程的所有統計資料所產出的圖示,例如: 累積流程圖 Cumulative Flow Diagram。當你需要分析細部資料時,請參考它完整的數據(注意,沒有二個開發專案會長得一模一樣的,因此越明確的數據就越是只能做為參考而已)。但當你需要進行預測或做風險決策時,請抽象化的參考它所表現出來的線條狀態就好,因為它在這部分更具威力的多了。

 

.

1. 輸出入模型

團隊的效能一般以他能接受多少工作量然後產出多少成果作為評量。也就是所謂的IPO 模型( Input – Process – Output, 投入- 開發歷程 – 產出)。

 

註2 啤酒效應

啤酒效應(Beer effect)指的並非僅是啤酒行業的現象,而是營銷流通領域一種具有普遍意義的現象。該效應指的是由於鏈中各節點企業之間資訊的不對稱以及為了追求自身利益的最大化,造成了需求資訊在內部的傳遞中失真。

.

參考:

  1. http://leanguru.pro/tag/cumulative-flow-diagram/
  2. http://brodzinski.com/2013/07/cumulative-flow-diagram.html

Written by ruddyllee

2016 年 08 月 02 日 於 18:37:06

張貼於未分類

Tagged with ,

發表迴響

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

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 位部落客按了讚: