在SAFe和Scrum背景下应用燃尽图的实践

在本文中，我计划讲述我们在按照SAFe方法论工作的过程中，在实践中如何应用燃尽图（Burn Down Chart）

我想，还是从最有趣的部分开始吧。也就是：在SAFe中使用这张图，相对于在SCRUM中使用，不应该有任何特殊性。还是说应该有？

我们的SAFe与SCRUM的不同之处在于存在这样一个角色： RTE，而SCRUM中没有这个角色。燃尽图（Burn Down Chart）是跟踪冲刺工作量的工具，它首先是为SCRUM团队服务的，而不是为任何外部人员服务的，不是吗？

因此，尽管有上述种种，我还是回到我们如何使用燃尽图的话题，并且仍然身处SAFe框架之内。

我担任 Scrum Master 的角色，并努力每天向整个 Dev Team展示这张图。我使用的工具是团队聊天，通过“@”提及整个团队，并附上图表当前状态的截图。提及整个团队是一种相当微妙的工具，重要的是要尽可能少地使用它（毕竟，我们Scrum Master应该帮助团队在舒适的环境中工作，并尽可能减少分心，不是吗？）

最终，团队每天都能看到冲刺的当前状态，并能够跟踪以下事件

• 出现计划外工作
• 任务长时间滞留在未完成状态
• 过度预留风险
• 了解工作是否以正确的节奏进行

接下来，我将尝试展开上述每一个事件，并列举自己实践中的例子。

出现计划外工作

在这张图上可以非常清楚地看到新工作是如何出现的（在为期两周的冲刺的第二个星期二）。

实践案例：“一名开发者，作为认同敏捷原则的scrum团队成员，与Product Owner直接进行了很好的互动。Product Owner告诉他，这个需要赶紧做出来，你自己也明白，这里很快，风险最小。

这名开发者很优秀，他了解敏捷的一切，也了解交付业务价值的重要性，于是去把backlog中的一个故事扔到了看板上，团队评估为6个故事点。

团队的其余成员（除了开发者和Product Owner）在早晨更新图表时注意到了这一点。在站会上，团队决定如何处理这种情况。最有可能的是，这个故事被从冲刺中移除，团队让Product Owner和开发者明白不能这样做，Product Owner如有需要可以将这个故事放入下一个冲刺。

当然，理想情况下，团队应该在站会上、即使没有图表也能注意到新工作的出现。但图表是一个很好的指示器，它能把错过这种对整个团队都很重要的变化的风险降到最低。

这里需要明白的是，根据团队水平的不同，情况可能会朝不同方向发展。在优秀的团队中，产品负责人不太可能这样做，即使这样做了，也不会以“这个可以赶紧做出来”为理由，而是会说“我估计，如果现在做这个，有55%的概率能在下个月让我们的利润增加20%”或者某个其他可衡量的指标。

任务长时间滞留在未完成状态

这里我们看到，工作很长时间都没有完成，甚至没有部分完成。这可能 表明 存在各种问题，我列举其中一些

• 任务分解不佳

  很多时候，新手团队会说无法进行分解。他们所有事情 都在 最后一天才爆发，工作无法并行等等。当然，Scrum Master 需要 处理这个问题， 并向团队解释分解的价值。

• DOD 表述不够优化

  DOD（Definition of Done）——冲刺中 User Story 就绪标准的描述。 有时 根本没有这些标准，或者描述得非常抽象。这很可能就是一个问题， 当然， Scrum Master 应该帮助解决

过度预留风险

在这种情况下，我们看到团队过度预留了风险。

可能某个故事被 高估了。也可能这是一个更系统性的问题，需要在 冲刺规划时 增加工作量。 无论如何，这种情况都不正确。毕竟业务方计划的是 冲刺的任务 会被完成，而且正是在冲刺结束时完成。取决于依赖关系是如何规划的， 这里很可能需要召开会议来调整预期。

在我的实践中，这种情况出现在找到了比评估时讨论的 更快的解决方案时。 整个团队讨论了在冲刺结束前能关闭哪个故事，并在回顾会上 约定，我们会尽量在梳理时查看代码。结果发现，只需要 看一眼代码就能明白，解决方案要简单得多。

理解——工作是否以正确的节奏进行

这里我想提请注意图形上不成功的 Burn Down Chart 展示方式

图片上半部分给出了一个不算最成功的图形实现示例，原因有两个， 我将在下面说明。

• 新的 SP 进入冲刺不明显

  这里，在上面的图表上，几乎看不出增加了 计划外的工作。下面的图表则更直观。

• 相对剩余工作量显示不正确

  根据上面的图表，还需要工作 3 天。实际上只有 2 天，在 休息日， 可能有人计划休息。

当然，有些人会觉得这些细节不重要。但需要明白，每个 团队 成员都只会用眼角瞥一眼这个图表，而它应该传达最大量的 有用 信息。