不只要看，还要看懂，如何使用燃尽图发现Scrum反模式

　　一、介绍

　　在Scrum敏捷实践中，会通过使用燃尽图来分析团队每个迭代的完成情况。一个燃尽图是以可视化的方式跟踪团队剩下的工作与可用时间的进展情况。与报告状态相比，更有趣的是，燃尽图还可以可视化团队或其组织的反Scrum模式。

　　了解有关反模式的更多信息，从系统性问题，例如团队能力范围之外需求池大小、其他组织的债务以及团队在敏捷实践中的敏捷程度。下图是燃尽图的理想状态。

　　

　　燃尽图理想状态

　　二、燃尽图可视化Scrum反模式

　　燃尽图目前已变得很流行，可以为团队成员和利益相关者提供易于理解的状态展示，是否完成了冲刺目标。（不过，对于燃尽图的批评者可能会指出，无论是否可以实现冲刺目标，Scrum团队都应该有一种直觉。）

　　因此，本文主要关注燃尽图的另一个有用方面：它们同样非常适合在团队级别和组织级别提供对各种障碍的更多见解。

　　下列显示了可以通过燃尽图轻松检测到的四种典型反模式：

　　1.后期验收

　　下面这张图是产品负责人仅在冲刺后期才接受或拒绝任务：

　　

　　后期验收

　　此钟行为问题的根源可能是，例如：

　　缺少产品负责人：团队很少有产品负责人来澄清问题和接受工作。这正在创建一个人为的等待队列，通过延迟任务的必要澄清或任务本身的交付，对团队交付价值的能力的影响逐渐减弱。代理产品负责人：团队正在远程设置中，产品负责人不在团队其他成员的现场。（注意：代理产品负责人通常不是解决方案，因为他或她只会增加反馈时间并增加沟通问题。）结果：可能会溢出到下一个冲刺，因为反馈循环没有足够的时间来解决冲刺中的问题。团队可能不会达到冲刺目标。如果这不是孤立的事件而是持久的模式，则需要采取措施。

　　2.进展缓慢

　　在这种情况下，该图位于整个sprint长度的预期进度线的上方：

　　

　　进展缓慢

　　导致这种情况的原因可能会有：

　　雄心勃勃的团队：冲刺目标过于雄心勃勃，团队仅在冲刺阶段才意识到它不会实现冲刺目标。（注：可以将目标设定的比较高然后失败，但是，这不应成为常规模式，因为它会对组织对团队的信任产生负面影响。）顺从的团队：从工程的角度来看，冲刺目标过于雄心勃勃。但是，团队没有大声疾呼，而是设法使其实现，从而在冲刺结束时失败了。 容量问题：冲刺开始后，团队的能力会发生变化，例如，团队成员生病或发出通知并离开团队。（注：不可否认，这是很难计划的。）更改优先级：团队需要解决一个关键问题-可能是一个Bug-使得完成最初的sprint目标的能力降低。（注：根据干扰的严重程度，可以考虑是否取消冲刺。至少，团队需要缩小原始的冲刺范围-这可能需要对冲刺进行重新规划，以确定减少的冲刺积压是否会仍然可以达到最初的冲刺目标。）外部依赖关系：团队在冲刺计划期间无法预见其影响范围之外的依赖关系。（注：典型的系统性功能障碍。）

　　3.扩大范围

　　下面这张图是在冲刺过程中，工作范围不断扩大，冲刺目标无法完成：

　　

　　扩大范围

　　在大多数情况下，这种模式可归因于准备不足：

　　细化失败：Scrum团队未能准确地细化任务，结果发现创造有价值的产品增量的努力比最初预期的要高。（注意：如果这在冲刺过程中多次发生，则团队在Story未完全理解的情况下就安排到本次冲刺中。这指出了产品backlog细化过程中的严重问题，或者与产品负责人的协作中存在的严重问题。）动态Sprint Backlog：紧迫的任务被塞进Sprint或在没有补偿的情况下进入Sprint。（注意：根据任务的大小，取消当前的Sprint并专注于看似更有价值的新问题可能是更好的选择。当然，除非这些新问题正在影响Sprint计划的混乱过程。此行为的示例：经理拉线以使他或她的任务进入冲刺，或者将任务伪装成需要立即修复的严重错误。）

　　4.提早完成

　　下面这张图是团队提前完成了Sprint目标的方式：

　　

　　当然，如果团队想出了如何以比预期少的精力完成任务的方法，那么尽早采取反模式。或者可以通过减少计划的任务来实现冲刺目标。

　　但是，这个积极的消息也可能隐藏了一些问题。同样，这种现象的原因是多方面的，最有可能的原因是：

　　团队过于谨慎：团队可能会高估其预测的安全性。（请注意：这可能表明，管理层仍将速度作为衡量团队成员贡献的重要指标，尽管用处有限。或者组织注重产出，不接受“失败”作为选择。在这种情况下，组织设置了错误的激励措施。）闲暇时间的黑客：团队留出了缓冲时间来解决技术债务，会与需求或其他不经常引起注意的问题一起处理，因此设法尽早完成。（注意：这可能表明当前的资源分配忽略了团队的长期健康状况以及代码库。此外，请注意 要素工厂 综合症，其中团队的利用率和产出比长期的影响更大结果。）

　　三、结论

　　在每次回顾会上使用燃尽图模式来分析团队每个冲刺的完成情况是个不错的方式，因为它可以轻松地识别团队的问题或系统功能异常。而且，以这种能力利用燃尽图甚至不需要切换到故事点本身—可以计算相等大小的故事点数作为y轴的尺寸。

　　使用其他数据（例如上下文和事件）以及提前时间和周期时间值增强燃尽图的好处。

　　说到这：在团队级别，我建议创建一个团队成员轮换计划，以每天更新燃尽图。这是团队的工作，而不是Scrum管理员的工作。

　　最后，无论您使用燃尽图的目的是什么，都要避免陷入一个常见的陷阱：开始计数子任务。这种核算将很快使您走上放弃完成定义的轨道。相反，您将开始将任务标记为已完成90％，这与瀑布式方法有何不同呢？