在 SAFe 與 Scrum 情境下運用燃盡圖的實務經驗

在本文中，我打算說明我們在實務上如何於 SAFe 方法論的工作流程中運用燃盡圖（Burn Down Chart）

我想就先從最有趣的部分開始吧。也就是說，在 SAFe 中使用這張圖表，不應該相對於在 SCRUM 中使用這張圖表有任何特殊性。還是說，應該要有？

我們的 SAFe 與 SCRUM 不同之處，在於有 RTE這個角色，而 SCRUM 中沒有。燃盡圖（Burn Down Chart）是追蹤短衝內工作量的工具，而且它首先應該是為 SCRUM 團隊所需，而不是為任何外部人員所需，不是嗎？

因此，儘管如此，我還是要回到我們如何使用燃盡圖（Burn Down Chart）這個話題，而且仍然是在 SAFe 框架之內。

我擔任 Scrum Master 的角色，並盡量每天向整個 Dev Team展示這張圖表。我使用的方式是團隊聊天室，透過「@」提及整個團隊，並附上圖表當前狀態的截圖。提及整個團隊是一個相當細膩的工具，重要的是要盡可能少用（畢竟，我們這些 Scrum Master 應該幫助團隊在舒適且盡可能減少分心的情況下工作，不是嗎？）

結果是團隊每天都能看到短衝的當前狀態，並能追蹤以下事件

• 出現未經規劃的工作
• 任務長時間停滯在未完成狀態
• 過度預留風險
• 了解工作是否以正確的節奏進行

接下來我將盡力闡述上述每一個事件，並舉出自己實務上的例子。

出現未經規劃的工作

從這張圖表可以很清楚地看到新工作是如何出現的（在為期兩週的短衝的第二個星期二）。

實務案例：「一位開發人員，作為認同敏捷原則的 scrum 團隊成員，與 Product 直接互動得很好。 Product 告訴他，這個東西得趕快做出來，你自己也明白，這裡很快而且風險極低。

這位開發人員很優秀，他了解所有關於敏捷的事，也了解交付商業價值的重要性，於是他去把 待辦清單中的一則故事丟到看板上，團隊對它的估算是 6 sp。

團隊其餘成員（除了開發人員和 Product 之外）在早晨的圖表更新時注意到了這件事。在站立會議上，團隊決定如何處理這種情況。最有可能的結果是，這則故事被踢出短衝，團隊讓 Product 和開發人員明白不能這樣做，Product 如有需要可以將這則故事放入下一個短衝。

當然，理想情況下團隊應該在站立會議上、即使沒有圖表也能注意到新工作的出現。但 圖表是一個很好的指標，能將沒注意到這種對整個團隊而言如此重要變化的風險降到最低。

這裡重要的是要理解，這個情境可能會因團隊水準不同而有不同的發展。在優秀的團隊中，產品負責人不太可能這樣做，而即使他這麼做了，也會以「我評估有 55% 的機率， 如果 現在做這個，可能使我們下個月的利潤增加 20%」之類的說法來論證，或 其他某種可衡量的指標。

任務長時間停滯在未完成狀態

在這裡我們看到，工作很長時間甚至連部分都未完成。這可能 預示著 各種問題，我來列舉其中一些

• 任務拆解不佳

  非常常見的是，新手團隊會說無法進行拆解。他們的一切 都在 最後一天燒毀，工作無法並行化等等。當然，Scrum Master 必須 處理這個問題 並向團隊解釋拆解的價值。

• DoD 表述不夠理想

  DoD（Definition of Done，完成的定義）—— 描述衝刺中 User Story 就緒標準的說明。 有時它們 根本不存在，或者描述得非常抽象。這完全可能是一個問題， 當然， Scrum Master 應該幫助解決

過度預留風險

在這種情況下，我們看到團隊過度預留了風險。

也許某個故事被 高估了。也許這是更系統性的問題，需要在 衝刺規劃時 增加工作量。 無論如何，這種情況都不正確。畢竟業務方規劃的是 衝刺的 任務會被完成，而且正是在衝刺結束時完成。取決於依賴關係是如何規劃的， 這裡很可能需要召開會議來調整期望。

在我的實務經驗中，這種情況發生在找到了比評估時所討論的 更快的解決方案時。 整個團隊討論了在衝刺結束前能關閉哪個故事，並在回顧會議上 約定，我們會盡量在梳理時查看程式碼。結果發現，其實只需要 看一下程式碼就能明白，解決方案要簡單得多。

理解 —— 工作是否以正確的節奏進行

在這裡我想提請注意圖形上不成功的 Burn Down Chart 呈現方式

圖片上半部分給出的是一個不算最成功的圖形實作範例，原因有兩個， 我將在下面說明。

• 新的 SP 進入衝刺不明顯

  在這裡，上方圖表中幾乎看不出新增了 未規劃的工作。下方圖表則更為直觀。

• 相對剩餘工作量顯示不正確

  根據上方圖表，還需要工作 3 天。實際上只有 2 天，在 休息日， 也許有人打算休息。

當然，有些人會覺得這些細節無關緊要。但必須理解，每一位 團隊 成員都只會用眼角餘光掃一下這張圖表，而它必須傳達最大量的 有用 資訊。