在 Scrum 與 SAFe 情境下應用 Cumulative Flow 的實踐

在本文中，我打算講述我們在自己的實踐中，如何在 SAFe 框架下工作的過程中，於 Scrum 裡應用 Cumulative Flow Chart。 SAFe

我想先從連結到 這篇文章 開始——我認為這裡很好地描述了它在標準形式下的用途，建議在閱讀我的文章之前先研究一下。下面我將描述我們如何為 Scrum 流程對其進行調整（它最初用於 Kanban），以及它在按衝刺工作時幫助我們解決哪些問題。

此前，在 關於 Burn Down Charts 的文章 中，我已經談到，在那裡我們看到新工作的出現和舊工作的燃盡。Burn Down Chart 的問題在於，與 Cumulative Flow Chart 不同，在它上面我們看不到使用者故事在各狀態之間的移動。而當我們開始在 Cumulative Flow Chart 中觀察各狀態之間的移動時，我們開始看到每日的變化（Burn Down Chart 可能好幾天都不變化，在某些情境下這可能完全正常），並且能夠注意到更細微的問題。

這就是它在動態中的樣子（圖中是用真實資料繪製的圖表）。

在這個例子中，我們看到以下情況

• 衝刺的前 7 天，測試中的工作量非常少，而且沒有變化
• 從 DOR（這裡是草稿）進入工作的使用者故事相當均勻——這很好。
• 與 Burn Down 一樣，我們看到根據趨勢，使用者故事不會在衝刺結束前完成

這 3 個觀察合在一起得出以下結論。這裡顯然在早期階段（大約在衝刺的第二到第三天），Scrum Master 就應該注意「測試」這一層，它太小且長時間沒有變化（查明原因）。可以假設，準備好測試的工作量因某些情況而無法測試，但那樣就意味著測試人員閒置，因此至少應該在最近的站立會議上更仔細地聽他們說。

說到應用實踐，例如，我每天在站立會議前在團隊聊天中發布所有指標，並提及整個團隊。

總的來說，不要忘記指標仍然需要正確解讀。要能夠看到真正的系統性問題（如果存在），並且不要把在您的情境中甚至可能是正面跡象的事情當作問題