解累積流圖的真正含義

 原文連結：https://blog.csdn.net/renxiaop/article/details/81013625

原始連線:http://baijiahao.baidu.com/s?id=1594434241891156737&wfr=spider&for=pc

轉載自科技夜譚

累積流圖（CFD: Cumulative Flow Diagram)是看板方法裡的核心度量，可以很好地反映工作項在每個流程環節的流動問題。但遺憾的是，由於這個度量圖表比較抽象，導致很多團隊想用又不會用。筆者今天做個雷鋒。

原理

想知道怎麼用，首先要理解怎麼畫出來的：

團隊在每天站會的時候，記錄看板系統的各個流程階段在製品數量，每個流程階段用不同顏色繪製，每天連續記錄，就繪出了小河彎彎的累積流圖。

舉例，某團隊今天站會上的看板如下：

首先繪製橫軸和縱軸：

橫軸：時間

縱軸：工作項數量

然後數看板上的工作項數量即可：

今天在“完成”列上有2個工作項，因此在橫軸為今天、縱軸為2的位置打個綠色的點，表示累計共完成了2個工作項。為簡單起見，綠線我們稱為“完成線”；

測試列有2個工作項，完成列與測試列共計4個工作項。於是，在橫軸為今天、縱軸為4的位置打個藍色的點，表示累計共進入測試環節4個工作項，包括正在測試和測試完成的所有工作項。藍線我們稱為“進入測試線”；

開發列（包括開發進行中和開發完成列）共3個在製品，開發列、測試列與完成列合計共7個工作項。於是，在橫軸為今天、縱軸為7的位置打個紅色的點，表示累計共進入開發環節7個工作項，包括正在開發、開發完成、測試中、 測試完成的所有工作項。紅線我們稱為“進入開發線”；

Backlog列有7個在製品，Backlog列、開發列、測試列與完成列合計共14個工作項。於是，在橫軸為今天、縱軸為14的位置打個橙黃色的點，表示累計共進入Backlog列14個工作項，包括當前在Backlog中、正在開發、開發完成、測試中、 測試完成的所有工作項。橙黃色線我們稱為“進入Backlog線”。

每天持續打點，就形成如下圖一樣的累積流圖：

如何分析

知道了怎麼畫，你就知道了含義。兩條線之間的垂直高度代表該流程階段有多少在製品。比如：“進入開發線”與“進入測試線”之間的高度是3，代表開發環節當前有3個在製品。

累積流圖還能分析到什麼呢？

分析在製品（Work In Progress，以下簡稱WIP）

看縱軸：從“進入開發線”到“完成線”之間的高度，代表了整個看板的在製品數量，因此，這個高度的變化，反映了看板上在製品變化。

如果某個流程階段的垂直高度較高，可能暗示了研發流程在該處有瓶頸或超負載工作等問題，需注意分析解決。

2. 平均週期時間（Lead Time）

看橫軸：從“進入開發線”到“完成線”之間的長度，代表了從開發啟動到完成的週期時間。這個長度的變化，反映了團隊交付能力的變化。

如果某個流程階段的水平長度較長，說明該流程環節的週期時間長，而往往是由於該環節的在製品堆積造成。

3. 吞吐率(Throughput)

按照排隊理論（Little’s Law）：

Throughput（吞吐率） = WIP（在製品） / Average Lead Time（平均週期時間）

在累積圖中，“完成”線的斜率就是吞吐率。通過觀察“完成”線的斜率變化，就可以直觀地看出團隊的交付效率的變化。

4. 需求範圍的變化

“進入Backlog線”的高度反應了所有Backlog的工作項的數量。這條線變高說明有新的需求進入了Backlog；平的時候表示這段時間Backlog裡沒有進新需求；這條線變低，說明需求從Backlog裡刪除。

5. 預測交付日期

將“完成線”按照當前的斜率畫出其延長線，與“進入Backlog”線的交點，就是按照當前的吞吐率交付現有Backlog範圍的預計日期。這個預測隨著Backlog範圍的變化、以及吞吐率的變化而變化。

美麗的，向小溪流動一樣的累積流圖是罕見的。真實世界裡的累積流圖都是醜陋的。這就是人生。

下面舉幾個案例

案例1：在製品持續堆積

解析：

圖中“進入開發線”與“進入測試線”之間的高度，以及“進入測試線”和“完成線”之間的高度都在持續增長，說明開發環節、和測試環節的在製品在持續堆積。為什麼出現這樣的現象呢？需要結合看團隊的看板，並且與團隊一起分析才能知道原因。但是肯定一點：團隊沒有設定在製品限制，任由在製品持續堆積。

案例2：批次性交付

解析：

圖中，“完成線”呈階梯式上升，像爬樓梯一樣。可以判斷出這個團隊採取了固定的釋出節奏，每到釋出的時候，累積流圖就上了一層樓梯，釋出之前，“完成線”是平的。

然後，觀察“進入Backlog線”，也是呈現臺階狀，而且與“完成線”上臺階的節奏一致。可見該團隊的Backlog填充節奏與交付節奏保持高度一致。

再次，觀察“進入測試線”與“完成線”之間的高度越來越高，但是我們無法判斷出是由於“測試進行”列的在製品堆積，還是由於測試完成後釋出工作碰到了問題，導致測試完了不能釋出所造成。因此，需要在看板上將測試環節、釋出環節細化，才能判斷出問題所在。

案例3：集體停滯

解析：

上圖中，在很長一段時間內，“進入開發線”、“進入測試線”、和“完成線”都是平的，可見這段時間內沒有任何工作項流入開發，也沒有任何工作項完成。怎麼會這樣呢？

常見的原因有以下幾種可能性：

1. 這段時間是法定假日

2. 團隊整體調走去其他專案

3. 運維有故障，團隊所有人去幫助運維解決故障

到底什麼原因，需要引導團隊分析。

案例5：某個環節無法啟動

解析：

圖中“完成線”與“進入測試線”在一段時間內是平的，由於“進入測試線”比“進入完成”線先平了一段時間，所以貌似是由於測試無法開始，導致無法完成。可以判斷出，測試環節遇到了阻礙導致測試工作無法開始。

同時，“進入開發線”持續攀升。由此可以判斷出，開發人員在測試環節遇到阻礙的時候，沒有去幫助解除阻礙，反而繼續拉動工作項開發，導致開發環節的在製品持續堆積。

案例6：吞吐率不穩定

解析：

上圖中，“進入開發線”的斜率穩定，而“完成線”與“進入測試”線的斜率陡然上升。可見，開發和測試的吞吐率突然大幅度提升。要記住：團隊的效率不會忽然上升，一定發生了重大變化。

常見的可能性是：

1. 團隊忘記了更新看板。某一天，忽然想起來了，於是大量卡片完成。

2. 團隊剛接受了需求拆分的培訓，開始嘗試將大需求拆小，導致交付的數量上升。

3. 團隊迫於管理層的進度壓力，拼命趕工，一段時間內集中完成大量需求。這樣做一定是有副作用的，過一段時間，團隊的吞吐率不僅會下降，反而會花更多的時間修改前段時間趕工埋下的雷。

案例7：Scrumban團隊

解析：

圖中，從原點到結束，所有線”彙集到一點，這說明：在最後一天，團隊的看板上是空的。此外，“進入Backlog”線是平的，即：在這段時間內，沒有新需求進入到Backlog裡。這是典型的Scrum團隊的特徵。

此外，仔細觀察可以發現，在前半段時間，開發環節的在製品持續堆積，而測試環節的在製品較少；而後，測試環節的在製品開始多起來，而開發環節的在製品開始減少。可見這個Scrum 團隊需要改進Sprint週期的工作流，避免小批量開發，讓工作平衡流動。

案例8：中途拋棄需求

解析：

正常的情況下，所有的線都是向上走的。如果有線向下走，一定是有工作項拋棄的情況。圖中，除了“進入完成線”，每條線都向下走，而向下的高度相同，可見是測試列拋棄了工作項，從而“進入開發線”和“進入完成線”都同時向下走。

這種情況團隊要回顧：為什麼工作項在啟動研發後拋棄？這種浪費如何避免？

最後

團隊的累積流圖千差萬別，上面介紹了幾個典型例子，並不能涵蓋所有場景。總之記下兩個操作要點：

累積流圖是團隊交付過程的回放，抓住累積流圖的幾個點，引導團隊回顧發生了什麼，從而改進價值的流動過程。

累積流圖在站會結束後更新，在交付評審（回顧）會議上分析。累積流圖的分析週期不能短於1周，應該與交付節奏保持一致，否則對一個交付週期的過程看不完整。

 

原始連線:http://baijiahao.baidu.com/s?id=1594434241891156737&wfr=spider&for=pc