迭代燃尽图工具需要哪些配置能力

迭代燃尽图工具的配置能力，主要看四个方面：数据来源与统计口径能否按故事点、工时或事项数切换，剩余工作量如何计算；更新频率是实时、定时还是手动重算；图形展示是否支持理想线、范围线、节假日与时间轴粒度；迭代中增删事项和未完成项如何处理。团队可以先用一个已结束的真实迭代回溯验证，确认工具能还原出可信的剩余工作量曲线，再决定是否采用。

要点总览（TL;DR）

• 燃尽图的配置能力先看统计口径：工作量单位选故事点、预估工时还是事项数量，剩余值按未完成项、进行中折算还是子任务汇总，决定曲线能否反映真实消耗。
• 更新频率分实时、定时、手动重算三类：每日站会前看图的团队用定时刷新即可，站会中边讨论边改状态的团队才需要实时刷新，手动重算要防止数据过期。
• 图形配置至少覆盖理想线、范围线、时间轴粒度与节假日休息日设置，范围变更要在曲线上留下可识别的调整，历史点不被静默改写。
• 迭代结束时未完成工作应进入重新评估，由团队决定结转、拆解还是放回待办，不默认自动结转。
• 验证方法是用一个已结束的真实迭代回溯，检查范围变更点是否可识别、抽样日期剩余值是否与实际一致，三项通过再决定采用。

先明确燃尽图要回答的问题与统计口径

燃尽图回答的是迭代内剩余工作量随时间下降的趋势，它展示的是“还剩多少”，进度百分比只是由剩余值推算出来的结果。选型前先把这个问题定义清楚，才能判断工具的配置项是否够用。同一个迭代，用不同口径画出的曲线可能完全不同，配置能力首先要服务于口径的可选择性。

工作量单位的选择

故事点适合需求相对稳定、团队已形成估算共识的迭代，优点是估算成本低、不受人员投入波动影响；预估工时适合跨职能协作、需要按人核算投入的团队，代价是录入和维护成本更高；事项数量最直观，适合事项颗粒度较均匀、以交付数量为主要跟踪目标的场景，但大项和小项被同等计数，曲线容易失真。工具至少要允许团队在项目中选定一种主口径，并说明切换口径后历史数据如何处理。

剩余工作量的计算口径

常见算法有三种：只统计未完成事项的估算值；对进行中事项按完成比例折算；按子任务完成情况向上汇总。三种算法在迭代中段差异最大，选型时要确认工具是否明确展示所用算法，以及能否在图表说明中标注。理想线是从迭代总工作量到零点的直线，代表均匀消耗的参照；实际线由每日剩余值连成，两者的偏离才是团队需要解读的信息。

据此可以先形成一份统计口径确认清单：主口径是什么、剩余值怎么算、进行中事项是否折算、子任务是否参与汇总、理想线按日历日还是工作日绘制。后续对照工具配置时，逐项打勾即可。

燃尽图工具的核心配置能力清单

把配置能力拆成可逐项核验的条目，比看演示图更可靠。下表给出评估框架，团队可直接作为试用时的检查表使用。

能力项	判断标准	验证方式
数据来源	事项状态、预估字段、子任务、工时记录中，至少一种可作为燃尽数据源，且来源可配置	在测试项目中修改预估字段，观察曲线是否随之变化
更新频率	支持实时刷新、定时刷新或手动重算中的一种，机制对用户可见	修改一个事项状态，记录曲线更新所需时间
图形配置	可显示理想线、范围线，时间轴粒度可选按天或按迭代阶段，节假日与休息日可设置	调整时间轴粒度，检查曲线刻度与站会节奏是否匹配
范围变更处理	迭代中新增或移除事项时，曲线有可识别的调整，历史点不被静默改写	在迭代中段新增一个事项，观察总工作量线与剩余线的变化
未完成项处理	迭代结束时未完成工作进入重新评估环节，去向由团队决定	结束一个含未完成项的测试迭代，检查系统提示与后续状态
权限与可见范围	可区分查看者与修改者，燃尽相关字段的编辑权限可控制	用不同角色账号登录，核对可见图表与可编辑字段

这张表的价值在于把“有没有燃尽图”推进到“燃尽图能不能按团队规则工作”。其中范围变更和未完成项两项最容易被忽略，却直接决定曲线在迭代后期是否还值得信任。

按团队节奏选择更新频率与数据来源

更新频率没有统一最优解，取决于团队在什么场合看这张图。每日站会前需要看到截至前一天的状态，定时刷新（例如每日一次）通常足够；如果站会中要边讨论边调整事项状态，实时刷新更顺手，但它依赖数据录入的及时和规范，状态滞后会直接反映成曲线滞后。手动重算适合迭代周期较长、数据变更集中在固定时点的团队，风险是有人忘记重算，图上显示的是过期数据。

数据来源的取舍同样要结合维护成本。以工时记录为数据源，曲线更贴近实际投入，但要求成员每天填写工时，漏填和事后补填都会造成偏差；以事项状态为数据源，维护成本低，粒度却受状态划分限制，一个事项从“进行中”到“完成”之间没有中间态，曲线会呈现台阶式下降。迭代较短（如一周）时，台阶效应更明显，此时可考虑引入子任务或按完成比例折算来平滑曲线。

一个实用的匹配建议是：两周及以上迭代、有估算习惯的团队，用故事点加每日定时刷新；事项颗粒度均匀、以交付数量为主的团队，用事项数加实时刷新；跨职能投入差异大的团队，用预估工时，同时把工时填写纳入每日站会的固定动作。

用真实迭代验证配置是否可信

演示环境里的曲线通常很漂亮，验证要看工具能否还原团队自己的历史。选取一个已结束的真实迭代做回溯，把当时的事项、估算和状态变更录入或导入，再对照当时的实际情况检查曲线。

1. 检查范围变更点：迭代中新增或移除的事项，是否在曲线上形成可识别的调整，而不是被抹平。
2. 核对剩余值：抽取迭代中段的两三天，比较图上剩余值与当时实际未完成工作的估算之和是否一致。
3. 确认未完成项去向：迭代结束后，未完成事项是否进入重新评估，团队能否决定是结转、拆解还是放回待办。
4. 记录配置与结论：把每个配置项的设置值、验证结果和遗留问题写进试用记录表，作为选型依据。

通过标准可以设为：范围变更在曲线上可识别、抽样日期的剩余值误差在团队可接受范围内、未完成项处理符合团队规则。三项都通过，说明这套配置能产出可信曲线；任一项不通过，先确认是配置问题还是流程约定缺失，再判断工具是否适配。

在迭代进度跟进和回顾环节，ONES 提供看板、燃尽图等工具用于掌握当前进度，团队可通过燃尽图评估研发效率，并在迭代回顾时结合燃尽图、工时日志等报表复盘进度与成本偏差。ONES Project 支持任务工时统计和自定义需求状态与属性，可把需求和相关任务规划至迭代并分配负责人。对于需要先统一字段与状态约定、再让燃尽图按口径出数的团队，这些能力可以作为落地时的承载基础；具体统计口径与图形配置项，建议在试用中按上一节的验证步骤逐项确认。

选择与落地建议

评估结果要转成行动，先排优先级。多数团队的痛点集中在两处：曲线更新不及时，或者范围一变曲线就失去解释力。前者优先确认刷新机制和数据录入规范，后者优先确认范围变更在曲线上的呈现方式。图形美观度、导出格式等属于次要项，可在核心配置满足后再比较。

落地前需要统一的约定包括：迭代内使用哪一种工作量单位、哪些状态算完成、进行中事项是否折算、子任务是否参与汇总、迭代结束未完成项由谁评估去向。这些约定写进团队的工作规则，燃尽图的配置才有稳定输入。

燃尽图要嵌入既有节奏才有用：站会看昨日剩余值与理想线的偏离，讨论阻塞而非逐条念数；回顾会对照整条实际线与范围变更点，判断估算偏差来自哪里。上线后建议每个迭代回顾时抽查一次曲线可信度，重点看范围变更是否被记录、剩余值是否与实际一致，发现口径漂移及时修正配置。配置能力评估表、试用验证记录和这份落地清单放在一起，就构成了一次完整的选型依据。

常见问题

迭代周期很短（比如一周），燃尽图用事项数量还是故事点更合适？

一周迭代里，事项数量口径的台阶效应最明显：一个事项从进行中到完成没有中间态，曲线会突然下降一格。如果事项颗粒度比较均匀，事项数量仍可用，但建议在迭代中把大事项拆成子任务，让曲线有更多中间点。若团队已有估算习惯，故事点在短迭代里反而更稳，因为估算值不随人员投入波动。无论选哪种，先确认工具允许在项目中固定一种主口径，并说明切换口径后历史数据如何处理。

实时刷新的燃尽图看起来更及时，为什么还要考虑定时刷新？

实时刷新把数据录入的及时性直接暴露在曲线上：成员当天没更新状态，曲线就停在昨天的位置，站会上容易被误读为进度停滞。定时刷新（例如每日固定时点重算一次）给团队留出补录窗口，曲线反映的是截至该时点的稳定状态，更适合作为站会讨论的基准。选择时看团队的数据维护习惯：状态更新及时、站会中要边讨论边调整的团队用实时刷新；更新集中在固定时点的团队用定时刷新，并约定重算时点。

迭代中临时加进来一个紧急需求，燃尽图上应该怎么体现？

这属于范围变更，处理方式取决于工具的配置和团队约定。可接受的做法是：新增事项计入总工作量，总工作量线相应上移，剩余线在变更当天出现跳升，历史点保持不变，这样回顾时能看出曲线抬升来自范围变化而非估算错误。选型时要专门测试这一点——在测试迭代中段新增一个事项，观察总工作量线与剩余线是否同步调整、此前日期的数据点是否被改写。若曲线被静默重算抹平，范围变更就失去了可解释性。

试用阶段只有一个演示项目，怎么判断燃尽图配置可信？

演示项目的曲线通常很漂亮，验证要看工具能否还原团队自己的历史。选取一个已结束的真实迭代，把当时的事项、估算和状态变更录入或导入，然后做三项检查：迭代中新增或移除的事项是否在曲线上形成可识别的调整；抽取迭代中段两三天，比较图上剩余值与当时实际未完成工作的估算之和是否一致；迭代结束后未完成事项是否进入重新评估环节。三项都通过说明配置可用，任一项不通过，先分清是配置问题还是团队流程约定缺失。

燃尽图上线后，怎么防止曲线逐渐失真？

失真通常来自口径漂移：有人改了完成状态的定义，有人开始用另一种单位估算，或者范围变更没有记录。建议把关键约定写进团队工作规则——迭代内用哪种工作量单位、哪些状态算完成、进行中事项是否折算、未完成项由谁评估去向——并在每个迭代回顾时抽查一次曲线可信度，重点看范围变更是否被记录、剩余值是否与实际一致。发现偏差就修正配置并同步规则，而不是等到曲线完全失去参考价值再重做。