在Scrum和SAFe背景下应用累积流量的实践

在本文中，我打算讲述我们在实践中如何 在按照框架工作的过程中，在Scrum中应用累积流量图 SAFe

我想先从这篇 文章 的链接开始——在我看来，这里很好地描述了它在标准形式下的用途，建议在阅读我的文章之前先研究一下。下面我将描述我们如何为Scrum流程（它最初用于Kanban）对其进行了调整，以及它在按冲刺工作时帮助我们解决了哪些问题。

此前，在 关于燃尽图的文章 中，我已经说过，在那里我们看到新工作的出现和旧工作的燃尽。燃尽图的问题在于，与累积流量图不同，在它上面我们看不到用户故事在各状态之间的移动。而当我们开始在累积流量图中观察各状态之间的移动时，我们开始看到每日的变化（燃尽图可能几天都不变化，在某些情境下这完全可能是正常的），并且能够注意到更细微的问题。

下面是它在动态中的样子（图中是基于真实数据构建的图表）。

在这个例子中，我们看到以下情况

• 冲刺的前7天，测试中的工作量非常小，而且没有变化
• 从DOR（这里是草稿）进入工作的用户故事相当均匀——这很好。
• 与燃尽图一样，我们看到根据趋势，用户故事不会在冲刺结束时完成

这3个观察综合起来得出以下结论。这里显然在早期阶段（大约在冲刺的第二到第三天），Scrum Master就应该注意到“测试”这一层，它太小且长时间没有变化（查明原因）。可以假设，准备好测试的工作量由于某些情况无法进行测试，但那就意味着测试人员处于闲置状态，因此至少应该在最近的站会上更仔细地听取他们的意见。

说到应用实践，例如，我每天在站会前在团队聊天中发布所有指标，并提及整个团队。

总的来说，不要忘记指标仍然需要正确解读。要能够看到真正的系统性问题（如果存在的话），不要把在您的情境中甚至可能是积极迹象的事情当作问题