如果你負責向你的客戶交付結果，並且你還沒有使用過累積流圖（cumulative flow diagram - CFD）管理項目或者服務的開發，那么請你仔細看看這個 工具。你很快就會每天都希望看到它。
一項工作何時才算完成？只有被交付到客戶手中，才算完成，因為只有這時我們才能從中收取費用。
正因如此，敏捷團隊用交付給客戶的功能/用戶故事的數量來度量項目進度。最初，Scrum開始使用燃盡圖來展現完成剩余待辦工作所需的小時數（或故事點數）。之后燃燒圖也開始被使用。這些圖將團隊每天完成的功能數量繪制了出來。
這些信息連同速率數據可用於展現某個Sprint/迭代的完成度。
然而，僅考慮到已經完成的工作還不夠。
里特定律（ Little’s law ）告訴我們交付時間（Delivery time）依賴於在制品數量（Work In Progress, WIP）。WIP是指所有已經初始但還未完成的工作，例如：所有在分析（Analysis）與完成（Done）之間的工作。
因此，必須要首先留意的就是WIP。
如果WIP增加了，你的交付日期就會有風險。
因此，用更短的Sprint待辦列表/迭代范圍（批量）尺寸比長待辦列表好。此外，保持更少的WIP數量可以降低由任務切換帶來的花銷。
縮小批量尺寸提高交付速度。
作為一個好的經理，不僅要知道什么是正在被開發的工作，你還需要了解這些工作的狀態，哪些工作項正處於困難之中，哪些有缺陷，以及哪些阻礙了其他工作的進行。你的工作室確保清除障礙並使工作流程持續順暢。
根據約束理論（ Theory of Constraints, ToC），每個系統有且只有1個約束（瓶頸）。所以你必須：
- 識別約束
- 決定如何消除約束
- 使所有其他的過程遵從於第2步的決定的開展
- 如果在第2、3步之后，需要更多產能提升，要放寬約束
- 回到第1步
如何才能識別出工作流程中的瓶頸？
根據瓶頸法則（Law of the bottleneck），你會在吞吐量最低的位置找到瓶頸。通常，在這個位置之前會有一個隊列，並且在那個環節之后環節的效率並不高。例如：一個在高速路上的限高梁、高峰時段的立交橋或者機場的安檢點。
回到我們軟件開發的流程上，我們可以將其中每個不同環節（分析、實現、測試、部署、完成）的工作項數量用不同顏色的帶狀區域可視化出來。
現在觀察一下，是否有一個區域在變窄，同時在流程中相對於這個環節之前的環節正在變寬（說明隊列正在增長）。
如果你看到了這種情況，就可以用上面提到步驟來解決瓶頸。
要留意的是，當我們看到了一個瓶頸，我們會本能的認為，我們需要更多資源。但是，這通常是代價最大的方法，並且通常不是最好的解決方法。關於如何消除瓶頸的詳細內容請見David Anderson的《看板方法》一書的第17章 瓶頸與持續可用。也許你還會很喜歡《Esteban, the Bottleneck》的故事。
在《Cumulative Flow Diagram》中，Pawel Brodzinski 展示了許多其他的當你使用CFD的時候可能會發現的情況。
接下來，
累積流圖是一個實踐工具，可以幫助我們看到WIP的狀態、項目的步調、並且快速識別出交付時間存在的風險以及瓶頸。
手工繪制一幅CFD需要專注和良好的數字表現技能。盡管如此，大多數看板方法工具都會自動繪制CFD，你還可以選擇需要跟蹤哪些環節。
對於使用傳統管理方式的組織：
如果你正在嘗試按照計划來跟蹤進度並基於項目的關鍵路徑（里程碑）來估算最終時間，使用CFD依舊對你有用 ：
- 在得到下次項目狀態匯報之前識別延期風險
- 找到工作流程中的障礙並在它們影響到項目計划完成之前進行消除
- 完整的看到當前工作的狀態以及項目的步調
此外，繪制CFD所需的數據也很簡單，只有工作項（任務、需求、故事、單據、事故）的狀態和已經處理的時間（前置時間，lead time）。團隊協同工具通常都會保留這些數據。當然，保證數據的正確不被作假是至關重要的。
原文地址：http://berriprocess.com/en/todas-las-categorias/item/63-diagrama-flujo-acumulado