开源敏捷管理平台的燃尽图与累积流图怎么看

迭代进入后半程，团队每天都在关任务，燃尽图却接近一条平线；看板上卡片没有减少，累积流图里的测试色带却越来越厚。此时只盯完成率，很容易把数据滞后、范围变化和流程瓶颈混为一谈。燃尽图回答还剩多少工作，累积流图回答工作卡在哪个环节、流动是否稳定。在开源敏捷管理平台里，把两张图放在同一迭代中对照，才能从进度判断走到流程诊断。下面按读数顺序、异常形态、组合信号和日常机制展开。

一、先统一语境：两张图量的不是同一件事

1. 燃尽图看单次迭代的剩余量

燃尽图（Burndown Chart）以时间为横轴、剩余工作量为纵轴，通常用于一个Sprint。纵轴可以是故事点、剩余工时或任务数，但同一张图必须保持同一单位。它只反映剩余量，不直接说明工作质量、交付价值或范围变化。敏捷联盟也强调，这类图更适合判断趋势。

理想线从初始总量匀速降到零，日燃尽速率=初始剩余工作量÷工作日数。实际线由每天结束时的剩余量连成。

2. 累积流图看跨状态的流动

累积流图（Cumulative Flow Diagram，CFD）以时间为横轴、累计工作项数为纵轴，每种颜色对应一个流程状态。色带的纵向厚度代表该状态的在制品（WIP），完成线斜率代表吞吐率，进入与完成边界的水平距离可近似看作前置时间。

3. 数据同源，图才可比

两张图必须共享同一批工作项、同一套状态定义和同一个每日快照时点。如果成员隔几天才批量更新，任何形态都可能只是记账结果，而不是团队节奏。

二、燃尽图的读数顺序：先验数据，再看偏差

1. 读图前核对数据

先查剩余工作量是否每日更新、完成项是否按完成标准关闭、迭代中途新增或移出的工作是否留痕。范围变了而基线没变，实际线高于理想线就不能直接归因于效率低。

2. 连看三到五个点再判断

单日波动受任务拆分和更新时点影响，至少连看3到5个工作日。持续贴近理想线，说明节奏稳定；持续在上方且斜率变缓，说明剩余量消耗不及计划；持续在下方，可能是进度提前，也可能是估算偏高。看趋势，不拿一个点下结论。

3. 四种形态对应四种动作

平台期通常意味着阻塞或完成项未关闭；上跳多半来自范围增加或估算上调；末段陡降常见于批量关单或赶工。陡降不等于高效，必须抽查验收标准。低于理想线也不必然是好事，剩余任务没拆清楚时，曲线会过于乐观。

三、累积流图的读数顺序：带宽、斜率与水平距离

1. 纵向看WIP

先看顶部边界是否抬升：抬升代表总范围增加，下降代表范围移出。再看各色带厚度：某状态连续变厚，说明进入速度大于流出速度。测试带变厚而开发带变薄，不一定是测试效率低，也可能是上游一次交付过多。

2. 斜向看吞吐

完成线的斜率表示单位时间内完成的工作项数。短期变平可能是阻塞或批量更新；连续多个周期变缓，才更像吞吐能力下降。不要用一天的斜率判断团队产能。

3. 横向看前置时间

从进入流程到完成的水平跨度，可近似反映前置时间；若开始定义为进入开发，则更接近周期时间。跨度逐渐拉长，通常说明队列在积累，哪怕完成数量没有下降。

四、组合判读：把信号变成动作

燃尽图显示结果压力，累积流图显示过程结构。两者合起来，才能区分做得慢、进得多和出不去。下表按四类常见组合给出排查顺序。

表后解读：先排除记录口径问题，再决定是否调整范围、限制在制品或处理瓶颈。两张图指向同一环节时，优先处理该环节；信号冲突时，先核对数据。每次只做一个改进实验，下一迭代用同一口径复测。

五、把读图变成固定动作

1. 日更核对

站会前只看三件事：剩余量是否更新、哪段WIP在变厚、完成线是否连续。没有数据更新的图不参与判断。问题只记录事实和阻塞，不在站会上追责。

2. 周看趋势

每周比较一次连续5个工作日的斜率与带宽。测试带连续变厚时，先限制开发侧WIP，再评估测试容量；范围频繁抬升时，单列变更记录。调整WIP上限比要求全员加速更能暴露真实瓶颈。

3. 迭代复盘

复盘只选一个可观察的改进：缩小批量、设置WIP上限、统一完成标准或固定更新时间。下个迭代用同一口径复测。指标改善不等于交付价值提升，仍需结合验收结果和用户反馈。对使用开源敏捷管理平台的团队来说，固定字段、固定状态和固定更新节奏，比增加图表更重要。

六、常见问题

1. 迭代中途插入紧急需求，燃尽图基线要不要重画？

不要改写已经发生的实际线。保留原基线，单独标记新增范围，或同时补一张燃起图；下一次迭代再用新范围做计划。

2. 累积流图的色带越多，信息越完整吗？

不一定。只保留有明确责任、动作和完成标准的流程状态；纯审批或纯等待的列如果没有管理动作，合并后更容易看出真实瓶颈。

3. 新团队要积累多久数据才能判断趋势？

至少覆盖一个完整迭代，最好观察2到3个迭代。前几天的数据只能用于发现记录问题，不足以判断稳定产能。

4. 燃尽图正常，为什么交付仍然延期？

燃尽图只统计迭代内剩余工作量，可能漏掉集成、验收、发布等待等跨团队环节。回到开源敏捷管理平台的工作项与状态记录，先补齐完成边界和更新节奏，才能定位交付链条上的排队。