累積流程圖 Cumulative Flow Diagram 解密

.

累積流程圖是用來描述工作是如何在系統中移動的圖示。

.

累積流程圖

一個真實世界的累積流程圖(PP: prepare production)

上圖顯示了隨著開發時間的推移,團隊在每個階段所進行的任務及消耗的時間。水平軸的單位是時間(Sprint日期),垂直軸線則是工作量(一般為故事點)。在Kanban Tool 網站上有一張手繪的累積流程圖,但一般建議不要用手來繪製,應該交由電子看板作自動呈現。下面這張圖看起來很專業但完全不推薦這麼做。

.

手繪累積流程圖.png

Kanban Tool 網站上有一張手繪的累積流程圖

.

他是一張極簡單的工作軌跡圖示,但卻能讓我們看見團隊在專案開發過程中的使用者故事完成的狀態,是一張流量圖,線與線之間的垂直距離,就是故事在欄位裡停留的期間,在這段時間裡它就是半成品(WIP)。

半成品的定義

Work In Progress,縮寫為WIP,又可寫為goods in process,in-process inventory,又稱為在製品,是尚未完成製造過程的商品,或是停留在庫存倉庫或是生產線上,等待著進一步處理的商品。這個術語常使用在供應鏈管理上。在軟體開發上,只要開始工作的任務,在尚未通過QA認可移入完成欄位的開發工作就還是「半成品」。它代表著一種浪費的指標,越大越浪費,也就是生產的效能越差。(WIP的值越大,就表示開發的 Lead time 越長)

.

信息輻射.png

這是我在GOPS 大會上的演講資料(原作是Pawel Brodzinski)

.

信息輻射: 所指的是輻射信息,也就是這張圖給你的第一印象,你在看的時它自然釋放出來的是什麼樣的訊息。

.

累積流程圖解讀

上圖中有10個現象,畫成這個樣子好像誇張了一點,但相信我只要你繼續待在這個圈子裡,早晚會遇到的。請問;閱讀累積流程圖應該從哪裡看起呢? 這一點和我們看看板是一樣的,要先從它所表現出來的輻射信息開始。上圖中很明顯的「瓶頸」應該是我想刻意表達的(但在演講廳裡,第一個回答的人沒挑那個很明顯的黑圓圈!)

當累積流程圖上面的各個線條都能夠保持常態的間距,就表示開發工作都能在看板上順暢的流動。若是有糾結(kink)的線條則表示出開發作業出現瓶頸了,我們可以透過持續觀察線條的呈現狀態,來追蹤開發作業是遇到瓶頸卡住了呢,還是工程師遇到連續假期讓進度變慢了,便可以思考如何運用調整WIP的數目限制來改善作業狀態。

.

累積流程圖_stat.png

A: 線條有放大的現象,B: 線條有趨近的現象。

.

 調整方式:

》當有二條線有放大的現象時,表示WIP值要變大了,也就是應該要投入較多資源來協助開發。反之;

當有二條線條有趨近的現象時,表示WIP值要減少了,也就是應該要調降投入的資源.

.

累積流程圖_0

上圖中,BC線段顯示出當前每個步驟裡正在處理的工作數目。而水平線條AB則是它們共花費了多少時間。當垂直線條的間距變大了,表示需要花去更多的時間(lead time 變大),也就是當前的開發速度變慢了,若其中有線條靠得很近時,則表示上面的作業追上下面的作業了(若是出現的是開發追上測試的欄位,則表示測試即將變成瓶頸。若是出現的是測試追上完成的欄位,則表示作了一堆小功能,沒太多可測的工作)

.

lead timeLead time 的趨勢圖

.

由lead time (也就是由需求故事被放入待辦事項欄位開始,一直到它被開發完成為止總共花費的時間稱之),上圖中;我們取每三個點的平均值來連接起來,就能看到Lead time 的趨勢線,便能夠預測接下來的開發工作有可能花費的時間了。當WIP值變大時,Lead time 就變長了,因此我們應該追求最小的半成品WIP的極小化。

 .

看板是一個持續改善的依據

由於看板能夠忠實記錄開發的過程,所以我們能夠透過持續觀察累績流程圖上線條的走向(趨勢),然後依靠它來決定如何進行調整的動作。舉例來說:當我們觀察到測試與完成二條線之間的間距有漸行加大的現象時,這表示: 測試作業的時間加長了,有可能會成為發布作業的瓶頸,這時候應該將WIP值加大,也就是投入更多的測試資源,解決之道可能是請測試人員將工作明確的切分出來,然後可能就是請團隊中的開發人員協助投入測試工作,來加速測試作業。

.

結論

實踐看板的三大步驟: 視覺化流程、WIP控管、流程管理。一般的使用者都停在第二步;也就是WIP的控管上。原因很簡單,因為WIP很難設定。設值很容易,但卻始終無法體驗到設定了的WIP值到底有什麼影響? 也就是一直試不出來WIP的影響。怎麼辦呢? 解決方法是去看累積流程圖,從記錄的曲線去看趨勢的走向,想知道調整WIP就能神奇的轉變流量嗎? 答案是;除非你看到了WIP的邊界值,否則你會始終感受不到設定的意義的,也就是調來調去都沒有特別的感覺。一種好的做法是: 配合WIP的趨勢去調整人力資源,而不是只有調整WIP值,去等待變化。這才是務實的做法。試試看吧! 很快你就能看到效果了。 範例:

.

累積流程圖_ab

由累積流程圖看開發流程的趨勢

.

設定WIP來改變趨勢走向

我們應該善用顯示在累積流程圖上頭的數據,不只因為數據可以讓我們看見過程,更可以看見趨勢,而WIP的調整正是用來調整流程的流動趨勢的。累積流程圖上線條的走向,劃一條垂直線就是開發作業在幾條交叉線之間所停留的工期,也就是 WIP值。由上圖中,4/12到4/13的開發過程,A點的數據Doing的WIP值由 8 提升到B點的 12,也就是 Lead time 變大了,原因可能是團隊正在開發一個較大的功能,所以開發時間就變長了。這段時間維持到 4/19 號,WIP值開始下降了,到 4/20 回復正常。所以測試欄位的 WIP值最小值是3,而Doing 的WIP值最大是E點的15。

反過來檢討;我們在遇到B點開發作業的WIP急遽增加時(8 增加到12時),可以發現是否遇到較大的開發功能了,該如何調整人力來縮短這段時間呢? 也就是要如何來縮短 4/12 到 4/20的開發負荷才能讓團隊維持在正常的產能。做法可能是找到合適的工程師來開發這項耗時的功能,或是把這項功能Breakdown 成更多細部的項目讓團隊發揮力量一起來運用分工的方式來克服它,這就需要視情況而定了。

.

.

註1. Kanbanize 的CFD 教學影片

註2. 上面圖示均採用 VSTS所產生的累積流程圖及 Lead time 圖示.

註3. 很多書上有另一種速率的度量方式: 也就是以開始點的WIP值為準,形成一種倒三角形的計算方式,立意是以開始時的半成品數為基準。我個人傾向以完成點的WIP值為準,也就是以完成時的半成品數為基準做計算。不論你選擇那一種方式,主重點是不要混用,只採用一種固定的計算方式,數值只是一個参考比較的指標,別忘了相對的意義重於精確的數據,重點是提供持續改善的指標。

another.png

.

 

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

身為團隊的一員或許你是主管、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

累積流程圖 Cumulative Flow Diagram

(因為很多敏捷團隊偏愛燃盡圖Burondown chart,而忽略了累積流程圖CFD,所以在此特別補充一下)

improve CFD

左圖是團隊工作一段時間之後的CFD圖經過統計分析後的結果,右圖則是希望經過改善後所能得到的結果。

.

《  改善: 就是設法讓曲線變得平滑 

.

累積流程圖 Cumulative Flow Diagram

敏捷開發團隊分析回饋的利器。它可以讓我們看到工作時間的燃燼結果一個循環週期所需要的時間正在製做中的半成品數目製作流程的瓶頸所在。更重要的是;它可以讓我們拿來做為工作流程持續改善的依據。

OTA DM CFD圖

這張圖取材自David J. Anderson 的看板方法: 科技企業漸進變革成功之道。我們拿它來做更詳盡的說明(OTA:Over-The-Air, DM: Device Management)。

累積流程圖是描述處於某個給特定狀態工作量的面積圖示(area graph)。上面的圖示說明了:

  • 庫存 (Inventory),是指待辦事項或queue中那些尚未開始的需求項目;
  •    第一條曲線面積,顯示的是專案範圍內的需求特性數量。
  • 已開始(Started),是指已經向開發人員解釋的需求
  •    第二條曲線面積,顯示的是已開始(Started)的特性數量。
  • 已設計(Designed),是特指那些 UML序列圖已經繪製好的需求項目
  •    第三條曲線面積,顯示的是已設計(Designed)的特性數量。
  • 編碼完成(Coded),是指那些已經實現了序列圖上的方法的需求項目;
  •    第四條曲線面積,顯示的是編碼完成(Coded)的 特性數量。
  • 完成(Complete),是指需求項的所有單元測試已經通過,程式碼也已經進行了同行評審(review),並且團隊主開發人員也已經認可編碼,並且確認已經可進入測試
  •    第五條曲線面積,顯示的則是已經編碼完成準備進行測試的特性數量。

.

(你可能會覺得上面的顏色真的有夠花了! 為何這麼做呢? 原因是我找了許多CFD圖的資料,但說明都令人不能很滿意,所以才決定自己寫一個的,顏色是花了,希望容易參考些!)

.

從CFD圖上,可以知道甚麼?

(用上圖來作說明)

1. 半成品的數量,即進行中的工作(work-in-progress):  先挑一個日期向上劃一條垂直線,在第二條曲線(開始)和第五條曲線(結束)之間的縱向高度就是半成品的數量

2. 平均前置時間: 第二條曲線和第五條曲線之間的橫向距離,顯示的則是一個特性從開始到結束的平均前置時間(average lead time)。

(需要特別說明,橫向距離為平均前置時間,並不是某個特定特性的具體前置時間。
累積流程圖並不會跟蹤特定的特性。) 

※ 半成品數量與前置時間直接相關
也就是說;當半成品數量減少時,平均前置時間也隨之減少。上圖在高峰期,平均前置時間為 12 天。 項目後期,隨著半成品數量越來越少,平均前置時間僅為 4 天。半成品數量和平均前置時間之間存在有相關性,而且是線性相關。在製造業中, 這種關係稱為利特爾定理Little’s Law)。

※  前置時間越長,質量越會顯著下降

前置時間和品質之間存在相關性,前置時間增加,則品質會下降。前置時間越長,品質越會顯著下降。事實上,平均前置時間增加約 6.5 倍,便會導致初始缺陷超過30倍的攀升(很可怕!)。半成品數量越多,平均前置時間越長。因此,提高品質的管理槓桿點(leverage point)是減少半成品數量

.

透過使用看板系統來限制半成品的數量便可提升品質、調整產能。

.