高项案例：燃尽图、燃起图和看板怎么分？一表讲透(燃尽小说讲的什么故事)

迭代已经过半，燃尽图上的剩余工作却几乎没有下降。项目经理立即判断：“团队效率太低，需要加班。”

这个结论可能下得太早。

剩余工作没有明显减少，可能是任务尚未达到完成标准，也可能是中途增加了范围、出现阻塞，或者工作拆分过大。今天把燃尽图、燃起图、看板和速度放在一个场景里讲清楚。

可以先抓住四个关键词：

燃尽看剩余，燃起看完成与范围，看板看流动，速度看交付节奏。

假设某团队开展为期10天的迭代，初始计划完成100个故事点。

理想情况下，剩余工作量会随着时间逐渐下降，最终接近0。

但实际燃尽图可能出现不同形态：

燃尽图反映现象，不能单独证明原因。

看到图线异常后，还需要结合任务状态、范围变化、缺陷和团队反馈进一步分析。

使用科科过软考高项导图复习时，可以在燃尽图旁边标注“纵轴是剩余工作量”。抓住这个核心，题目怎样变化都比较容易判断。

燃尽图中的剩余工作上升，可能是团队没有完成任务，也可能是总工作范围增加。只看一条剩余工作线，有时不容易区分。

燃起图通常会同时展示：

• 已完成工作量；
• 项目或迭代的总工作范围。

假设团队已经完成60个故事点，原总范围为100个故事点；随后新增20个故事点。燃起图中，完成线仍在60，而总范围线由100上升至120。

这时可以看出：团队完成量并没有倒退，只是目标范围发生了变化。

因此，题目强调“需要同时观察进展和范围变化”时，可以优先考虑燃起图。

不过，燃起图显示范围增加，不代表新增需求可以绕过相应管理。团队仍需按照适用的方法评估价值、优先级、容量和影响。

假设团队的看板设置了以下列：

待办→开发中→测试中→已完成

某天发现：

测试中堆积了12项，而开发人员还在不断启动新任务。这说明瓶颈可能位于测试环节。

此时继续增加“开发中”的工作，只会产生更多等待。团队可以分析测试能力、缺陷质量、环境或工作交接问题，并考虑限制在制品数量。

在制品限制的目的，是减少同时开展而未完成的工作，促进团队完成已有任务，再开始新任务。

案例答案不能只写“使用看板”。还要说明如何利用看板发现阻塞、控制在制品并改进工作流。

假设团队最近三个迭代分别完成：

• 第一个迭代：30个故事点；
• 第二个迭代：34个故事点；
• 第三个迭代：32个故事点。

其平均速度约为：

（30＋34＋32）÷3＝32个故事点/迭代

如果剩余工作为96个故事点，在团队组成、估算方式和工作条件相对稳定的情况下，可以初步预测还需要约3个迭代。

但速度不能机械使用：

1. 故事点不是工时；
2. 不同团队估算尺度可能不同；
3. 不能直接用速度比较两个团队谁更优秀；
4. 团队成员、技术难度和范围变化都会影响速度；
5. 单个迭代数据不能代表长期能力。

速度主要用于团队自身的规划和预测，不适合变成盲目追高的绩效指标。

迭代过半，燃尽图下降缓慢，可以按下面顺序检查：

1. 看燃起图，总范围是否增加；
2. 看看板，工作是否堵在某个环节；
3. 检查完成标准，任务是否真的完成；
4. 查看团队速度及近期变化；
5. 与团队沟通，确认是否存在技术或资源阻塞。

例如，总范围没有变化，看板却显示大量任务堆积在测试环节，那么问题可能是测试资源、环境或前期交付质量，而不能简单归因于开发人员不努力。

科科过软考案例资料可以按“图表表现—可能原因—进一步证据—改进措施”的顺序练习。图表提供信号，管理判断还需要其他信息支持。

下面是一段教学示例：

“迭代执行期间，我通过燃尽图跟踪剩余工作，发现中期下降速度低于预期。进一步检查看板后，发现多项功能集中在测试环节。团队分析认为，测试环境不稳定和提交质量不足造成了阻塞。随后，我们限制开发中工作数量，优先解决测试环境问题，并完善提交前检查。后续看板中的积压逐步减少。”

这段内容没有只写“使用敏捷工具”，而是说明了工具发现什么、团队如何分析，以及采取了什么措施。

正式论文还需要结合题目要求，补充项目背景、具体结果和相关绩效域之间的联系。

题目问“还剩多少工作”，想到燃尽图。

题目问“完成量和总范围是否变化”，想到燃起图。

题目问“工作堵在哪个状态”，想到看板。

题目问“根据历史迭代能力预测后续工作”，想到速度。

今天留一道判断题：

某项目新增了大量需求，管理层希望同时看到累计完成工作和总范围的变化，应该优先使用什么？

答案是：燃起图。

想继续梳理敏捷、混合型开发和案例分析，可以搜索科科过软考，或私信“敏捷工具”。看到图表以后，先判断它展示的变量，再分析图线背后的项目原因。