选迭代燃尽图工具，关键要核对三件事：燃尽数据是否直接取自迭代内工作项的剩余工作量或剩余工时，更新由工作项变更触发还是按小时、按天定时重算，以及迭代起止、工作日历、容量与范围变更口径能否配置。本文以ONES、Jira、Azure DevOps、GitLab、Linear、YouTrack为候选，用同一组口径对照，并给出试用中可逐项执行的核验方法。
要点总览（TL;DR）
- 燃尽图是否可信，先看数据来源：曲线应直接取自迭代内工作项的剩余工作量或剩余工时，另建手工表在录入不及时的团队里容易失真。
- 更新频率要区分打开图表时读取最新数据与后台定时重算两类，并记录从工作项变更到曲线反映的实际延迟；短周期迭代对延迟更敏感。
- 配置能力重点核对迭代起止日期、工作日历、团队容量，以及迭代中途增删范围后曲线如何重算。
- 试用时用四项动作验证：改动剩余量看曲线是否同步、记录刷新延迟、模拟中途增删范围与调整工作日历、检查已结束迭代能否回看与复算。
- 试点建议用一个完整迭代覆盖计划、每日跟进和回顾，把范围变更与延迟记录在同一张表里，再与厂商确认版本、集成与价格事项。
候选工具与燃尽图数据口径快速对照
下面六款工具都具备迭代或周期管理能力，也都提供与迭代进度相关的图表视图。把它们放在一起比较时，先统一口径：燃尽数据从哪里取、什么时候刷新、迭代范围和工作日历怎么配、范围变更后曲线怎么处理、历史迭代能否回看。这五项决定了一张燃尽图在每日站会和迭代回顾中是否可用。
| 工具 | 燃尽数据来源 | 更新触发与刷新频率 | 迭代范围与工作日历配置 | 范围变更处理 | 历史迭代回溯 |
|---|---|---|---|---|---|
| ONES | 燃尽图与迭代内需求、任务同处一个项目环境，任务工时统计可用于估算持续时间；燃尽曲线具体取剩余工时还是工作项数量，待核实 | 官方资料说明看板、燃尽图用于实时掌控当前进度；燃尽图自身的刷新触发方式与延迟上限，待核实 | 支持将需求和相关任务规划至迭代并分配负责人；迭代起止、工作日历、容量是否参与燃尽基准计算，待核实 | 迭代中途增删范围对曲线的重算方式，待核实 | 迭代回顾可使用燃尽图等报表；已结束迭代曲线的保留期限与复算方式，待核实 |
| Jira | 通常由Sprint内问题的剩余工作量汇总，工作量来自故事点或时间估算字段 | 随问题字段和状态变更更新，打开或刷新图表时呈现当前汇总结果 | Sprint有明确起止日期，燃尽按Sprint周期展开；非工作日排除方式需确认 | 新增或移除问题时曲线体现范围变化，可区分原始范围与变更后范围 | 已关闭Sprint的燃尽数据通常可回看，保留策略需向厂商核实 |
| Azure DevOps | 以Sprint内工作项的剩余工作量为主要输入，通常由任务上的剩余工作字段汇总 | 随工作项字段保存而更新，打开或刷新图表时呈现当前累计结果 | 依附已配置的Sprint迭代路径与起止日期，工作日历影响理想线计算 | 范围调整后曲线随之变化，工作项历史变更记录可辅助回溯 | 按Sprint保存迭代数据，可切换查看过往迭代燃尽情况 |
| GitLab | 基于迭代内工作项及其估算信息生成，权重或估算值参与剩余量计算 | 随工作项状态、估算值和迭代范围变更更新，属事件驱动方式 | 时间轴与迭代起止日期绑定；按节假日调整曲线的能力需核实 | 增删工作项改变剩余工作量，可结合议题变更记录回溯 | 已关闭迭代数据保留在项目中，保留期限与导出方式需核实 |
| Linear | 来自Cycle内Issue的完成情况，按Issue状态判定完成 | 随Issue操作写入，燃尽视图读取当前Cycle状态；按数量还是按估算点数计算需核实 | Cycle有明确起止日期；按自然日还是工作日推进需在试用中确认 | Cycle进行中可调整Issue归属，曲线随之变化，变更记录方式需团队约定 | 已结束Cycle保留Issue集合与完成情况，可回看对比 |
| YouTrack | 通常基于迭代内问题的剩余工作量汇总，来自时间估算或故事点类字段 | 由问题字段变更触发，页面打开或手动刷新时重新计算，缓存延迟需实测 | 敏捷看板支持配置迭代周期与起止日期；工作日历、时区切分需核实 | 增删问题后总工作量线是否跳变、历史数据点是否重算需模拟验证 | 已结束迭代图表是否保留、保留期限是否受部署方式影响需确认 |
表中标注“待核实”的项，表示现有资料未给出明确说明，需要在演示或试用中确认，不能据此判断工具缺少该能力。六款工具的共同趋势是燃尽数据取自迭代内工作项，差异集中在刷新机制、工作日历的细化程度和范围变更的呈现方式上。
迭代燃尽图工具统一深评
ONES
ONES 在迭代管理场景中的定位，是把需求、任务、看板与燃尽图放在同一套项目协作数据里，让团队围绕迭代范围推进工作，并在每日跟进和迭代回顾时用图表对齐进度。对于正在挑选迭代燃尽图工具的团队，ONES 的相关性主要体现在：燃尽图与迭代内需求、任务状态同处一个工作环境，团队在敏捷看板上更新任务状态后，可以在同一项目内查看燃尽趋势，减少在多个工具之间核对进度的工作。
燃尽数据来源与迭代范围。ONES Project 支持编写需求、自定义需求状态与多种属性，并把需求和相关任务规划至迭代、分配负责人。迭代执行中，团队成员围绕迭代要完成的需求拆解任务，通过敏捷看板管理任务状态。燃尽图因此建立在迭代规划与任务状态更新的工作流之上，评估数据来源时，可以重点确认燃尽曲线取的是迭代内工作项数量、剩余工时还是其他口径，以及任务工时统计与燃尽剩余量之间的计算关系。ONES 提供任务工时统计，用于估算任务持续时间，但工时数据如何进入燃尽计算，需要在试用或实施时与团队现有估算习惯对照验证。
更新触发与刷新频率。ONES Project 提供看板、燃尽图等工具，用于实时掌控当前进度；同时支持自定义数据范围和维度，以多种图表形态呈现项目表现。对燃尽图来说，关键核验点是曲线随任务状态变更后的刷新方式：是打开图表时读取最新数据，还是按固定周期刷新，以及是否存在可感知的延迟。团队在每日站立会议中借助敏捷看板对齐进度与风险，如果燃尽图能在会议前反映当天状态，跟进节奏会更顺畅。具体刷新机制与延迟上限，建议在试用环境中用一次任务状态变更来观察。
迭代范围、工作日历与历史回溯。迭代范围由规划至迭代的需求与任务构成，迭代中途增删需求或任务时，燃尽曲线按什么口径调整，是选型时需要明确的配置项。工作日历、迭代起止时间和团队容量是否参与燃尽基准线计算，也应在试用中确认。迭代完成并发布后，团队可以通过燃尽图、工时日志、持续集成报告等数据报表复盘迭代进度、质量和成本偏差，这说明燃尽图在 ONES 中承担回顾场景的输入角色；已结束迭代的曲线保留多久、是否支持按当前口径复算，则需要向服务方核实。
适配建议。如果团队已经在 ONES 中管理需求池、规划迭代并用敏捷看板推进任务，燃尽图可以直接作为迭代跟进和回顾的视图使用，适合每日站会对齐进度、迭代结束后复盘偏差。落地时建议先统一任务工时或剩余量的填写规则，明确迭代范围变更的记录方式，再用一个完整迭代验证燃尽曲线与团队实际进度是否一致。对于需要严格审计刷新时点或跨项目统一燃尽口径的组织，应把刷新机制、工作日历配置和历史迭代复算能力列入试用核验清单，确认后再决定推广范围。
Jira
Jira 是 Atlassian 推出的项目与问题跟踪工具，在敏捷团队中使用广泛。围绕迭代燃尽图这一任务，它通常以 Sprint（冲刺）为组织单位，把问题的工作量估算、状态流转和完成情况汇总为燃尽曲线。对于已经用 Jira 管理需求、任务和缺陷的团队，燃尽图可以直接建立在同一套问题数据上，减少在多个工具之间同步进度的成本。评估时应重点确认三件事：燃尽数据从哪里来、什么时候刷新、迭代范围和工作日历如何配置。
燃尽数据来源。Jira 的燃尽图通常由 Sprint 中问题的剩余工作量汇总而成，工作量一般来自问题上的故事点或时间估算字段，完成状态则来自工作流中的状态流转。这意味着数据质量取决于团队是否在迭代开始前完成估算、是否在迭代过程中及时更新剩余工作量。评估时需要确认：燃尽图读取的是哪个估算字段，子任务和缺陷是否计入，未估算的问题如何处理。这些口径会直接影响曲线起点和走势，建议在试用环境中用一批真实问题验证汇总结果。
更新触发与刷新频率。Jira 的燃尽数据随问题字段和状态的变更而更新，图表在打开或刷新时呈现当前汇总结果。团队需要关注的是业务上的更新节奏：成员是否每天更新剩余工时，状态流转是否及时。若团队习惯在每日站会后集中更新，燃尽曲线会呈现阶梯式变化，这属于使用习惯带来的数据特征，评估时应把更新责任和时点写入团队约定，避免把曲线波动误判为进度异常。
迭代范围与工作日历配置。Jira 的 Sprint 有明确的开始和结束日期，燃尽图按 Sprint 周期展开。评估时要确认非工作日是否从曲线中排除、Sprint 起止日期与实际迭代节奏是否一致，以及跨时区团队的工作日历如何处理。这些配置会影响理想燃尽线的斜率，进而影响对实际进度的判断。建议在正式使用前用一到两个迭代校准日历设置。
范围变更处理与历史回溯。迭代中新增或移除问题时，Jira 会在燃尽图上体现范围变化，评估时需确认团队希望看到范围调整后的曲线，还是希望区分原始范围与变更后范围。历史迭代方面，已关闭 Sprint 的燃尽数据通常可以回看，便于复盘。具体的历史保留策略、图表导出方式以及不同版本间的功能差异，建议向厂商或管理员核实后再确定使用方案。
适配建议：Jira 适合已经以问题为单位管理迭代工作、并愿意维护估算和状态更新的团队。落地时先统一估算字段和完成定义，再约定每日更新时点，最后校准 Sprint 日历和范围变更规则。若团队的问题数据分散在其他系统，需要先评估数据同步方式，再判断燃尽图能否反映真实进度。
Azure DevOps
Azure DevOps 是微软提供的研发协作平台，迭代燃尽图属于其 Boards 中的 Sprint 视图能力，适合已经在 Azure Boards 中维护产品待办、任务和工时，并希望把迭代进度与工作项状态放在同一套系统中查看的团队。评估这类工具时，数据来源和更新频率决定了燃尽曲线能否反映真实进展，Azure DevOps 的燃尽数据直接建立在工作项字段之上，理解这些字段的填写方式，比单纯看曲线形态更重要。
燃尽数据来源方面，Azure DevOps 的迭代燃尽图以 Sprint 内工作项的剩余工作量为主要输入，通常由任务上的“剩余工作”字段汇总得出，工作项状态变化会带动剩余量变化。这意味着曲线质量取决于团队是否在任务层级维护剩余工时，以及完成工作时是否及时把剩余量归零。若团队只更新工作项状态、不维护剩余工时，燃尽图反映的是按数量统计的完成情况，与按工时统计的曲线会有差异。选型核验时可以确认：团队计划用故事点、任务数还是剩余工时作为燃尽口径，并检查该口径对应的字段是否被纳入日常更新习惯。
更新触发与刷新频率方面，Azure DevOps 的燃尽数据随工作项字段的保存而更新，图表在打开或刷新时呈现当前累计结果，属于由工作项变更驱动的更新方式，而非独立采集的实时数据流。这一机制适合每日站会前集中核对剩余工时、在迭代过程中按天观察趋势的使用节奏。需要核验的是团队更新剩余工时的时点：如果集中在迭代末期补录，曲线会在末端出现陡降，难以支撑过程中的偏差判断。建议把剩余工时更新纳入每日站会或任务关闭动作，使数据更新频率与迭代复盘节奏匹配。
迭代范围与工作日历配置方面，燃尽图依附于已配置的 Sprint 迭代路径和迭代起止日期，工作日历影响曲线中理想线的计算方式。团队在创建 Sprint 时需要设定准确的开始与结束日期，并根据团队实际工作节奏确认周末与假期的处理方式。跨时区或存在非标准工作周的团队，应提前核验迭代日期与工作日设置是否与团队排班一致，避免理想线与实际可用工时出现系统性偏差。
范围变更处理方面，迭代中途新增或移出工作项会改变剩余工作总量，燃尽曲线随之调整。Azure DevOps 保留工作项的历史变更记录，便于回溯范围变化发生的时间点，但燃尽图本身呈现的是调整后的累计结果。团队可以结合迭代回顾查看范围变更记录，判断曲线波动来自实际进展还是范围调整。适配建议是：在迭代计划时明确范围变更的确认方式，把新增需求与移出项记录在 Sprint 待办中，使燃尽图的变化能够对应到具体工作项。
历史迭代回溯方面，Azure DevOps 按 Sprint 保存迭代数据，团队可以切换查看过往迭代的燃尽情况，用于对比不同迭代的进度节奏和范围稳定性。回溯时建议同时查看对应迭代的工作项明细和剩余工时记录，把曲线形态与当时的范围变更、人员投入结合起来解读。对于希望用燃尽图支撑迭代改进的团队，Azure DevOps 的适配点在于工作项、迭代和燃尽视图同源，减少跨系统核对数据的动作；使用前提是团队愿意在任务层级持续维护剩余工作量，并把迭代日期与工作日历配置准确。
GitLab
GitLab 是面向软件研发全流程的一体化 DevOps 平台，迭代燃尽图是其迭代管理能力的一部分。对于关注燃尽图数据来源与更新频率的团队，GitLab 的特点在于燃尽数据直接来自平台内的工作项与迭代记录，减少跨工具同步带来的口径差异。以下结合选型关注点说明其相关能力与使用条件。
燃尽数据来源。GitLab 的燃尽图基于迭代（Milestone/Iteration）内的工作项及其估算信息生成，工作量变化、状态流转和完成情况都记录在同一平台内。团队在规划迭代时把议题（Issue）关联到迭代并填写权重或估算值，燃尽曲线就能反映这些工作项的剩余量。选型时需要确认团队是否已经在 GitLab 中维护迭代与估算习惯，因为燃尽图的可信度取决于录入的完整度；估算口径（按议题数、权重还是时间）应在团队内统一，并在配置时保持一致。
更新触发与刷新频率。燃尽数据随工作项状态、估算值和迭代范围的变更而更新，属于事件驱动的更新方式，而非固定周期的批量同步。这意味着看板的实时性依赖成员及时更新议题状态。评估时应重点核验两点：一是团队日常操作是否在 GitLab 内闭环，避免在外部工具改状态后再手工回填；二是查看燃尽图时留意数据反映的是当前记录状态，历史快照的保留方式需向厂商确认。对于需要分钟级刷新或跨系统聚合燃尽数据的场景，应提前确认集成方案。
迭代范围与工作日历配置。燃尽图的时间轴与迭代起止日期绑定，团队需要在创建迭代时准确设置开始和结束日期。工作日历方面，GitLab 的燃尽展示以迭代周期为基准，是否支持按团队节假日或非工作日调整曲线，属于需要核实的配置项。选型时可准备一个包含周末和假期的迭代样例，实际查看曲线在非工作日的呈现方式，判断是否满足团队对“有效工作日燃尽”的解读需求。
范围变更处理与历史回溯。迭代中途增删工作项会改变剩余工作量，燃尽曲线随之变化，这为观察范围蔓延提供了依据。团队可以结合迭代内的议题变更记录，回溯范围调整发生的时间点。历史迭代方面，已关闭迭代的数据保留在项目中，便于对比多个迭代的燃尽形态；具体的历史数据保留期限和导出方式建议向厂商核实。适配建议是：把燃尽图作为迭代回顾的输入之一，配合议题变更记录一起解读，避免只看曲线形态下结论；对于估算习惯尚不稳定的团队，先统一估算口径再依赖燃尽趋势判断进度。
Linear
Linear 是面向研发团队的项目与迭代管理工具，核心对象是 Issue、Cycle（迭代周期）和 Project。团队用它安排每个迭代要做的 Issue、跟踪完成进度，燃尽图就建立在 Issue 状态变化和 Cycle 时间范围这两类数据上。评估它的燃尽数据是否可靠，重点看 Issue 状态流转是否规范、Cycle 起止日期是否配置准确，以及团队是否在同一套工作流里更新任务状态。
燃尽数据来源。Linear 的燃尽数据来自 Cycle 内 Issue 的完成情况：Issue 被移入某个 Cycle 后计入该迭代范围，状态进入已完成类状态时计为完成。燃尽曲线随 Issue 状态变化而变动，因此数据质量取决于团队是否及时把 Issue 状态改到对应阶段。若团队习惯在迭代末尾集中关闭 Issue，曲线会在末期陡降，反映的是操作节奏而非真实进展。使用前应统一各团队的完成状态定义，并约定状态更新的时点。
更新触发与刷新频率。Linear 中的数据随 Issue 操作实时写入，燃尽视图读取当前 Cycle 的 Issue 状态，通常无需手动触发同步。需要核验的是视图的刷新机制和统计口径：燃尽按 Issue 数量还是按估算点数计算，历史数据点是否按天留存。这些细节建议在试用时用一个小规模 Cycle 实际观察，确认曲线随状态变更的呈现方式符合团队预期。
迭代范围与工作日历配置。Cycle 有明确的起止日期，燃尽图以该时间窗口为横轴。团队需要按实际迭代节奏设置 Cycle 长度，并确认燃尽计算是否按自然日还是工作日推进；Linear 的 Cycle 配置以日期区间为主，工作日历的细化程度需在试用中核实。跨时区团队还应确认日期边界按哪个时区计算，避免曲线起止点与团队认知不一致。
范围变更处理与历史回溯。迭代中途新增或移出 Issue 会改变燃尽基准。Linear 允许在 Cycle 进行中调整 Issue 归属，燃尽曲线会随之变化，团队应约定范围变更的记录方式，例如通过标签或评论说明变更原因，便于事后解释曲线波动。已结束的 Cycle 会保留其 Issue 集合和完成情况，可回看历史迭代的燃尽表现，用于对比各迭代的交付节奏。适配建议：先用一个真实迭代跑通状态规范、Cycle 日期和范围变更约定，再将该口径推广到多个团队；涉及估算点数、工作日历和刷新频率的具体行为，以试用观察和厂商说明为准。
YouTrack
YouTrack 是 JetBrains 推出的项目管理与问题跟踪工具，在敏捷团队中常被用于管理迭代（Sprint）、任务和缺陷。围绕迭代燃尽图这一主题，它适合希望把任务状态、工时估算与迭代周期放在同一套问题跟踪体系里管理的团队，尤其是研发团队已经在使用 JetBrains 开发工具链、希望减少工具切换的场景。评估时应重点确认燃尽数据如何从问题字段汇总、图表何时刷新，以及迭代范围与工作日历如何配置。
燃尽数据来源。YouTrack 的燃尽图通常基于迭代内问题的剩余工作量汇总，剩余工作量一般来自问题上的估算字段（如时间估算或故事点类自定义字段）。这意味着数据准确性取决于团队是否在任务拆分后及时填写估算、是否在每日更新剩余工时。选型时需要核实：燃尽图读取的是哪个字段、是否支持按问题类型过滤、子任务工时是否汇总到父任务。若团队习惯用故事点而非工时，需要确认图表能否按点数绘制，以及点数与工时混用时口径是否一致。
更新触发与刷新频率。燃尽图的数据更新一般由问题字段变更触发，图表在页面打开或手动刷新时重新计算。评估时要确认变更后图表是实时反映还是存在缓存延迟，以及跨天时剩余工作量是否按工作日自动递减。对于每日站会使用燃尽图的团队，刷新延迟会直接影响当天判断，建议在试用环境中修改一个问题的工作量并观察图表变化时点，记录实际表现。
迭代范围与工作日历配置。YouTrack 的敏捷看板支持配置迭代周期和起止日期，燃尽图按迭代时间轴展开。需要核实的是：工作日历能否排除周末和节假日、迭代起止时间是否支持非整周对齐、跨时区团队按哪个时区切分每日数据。这些配置直接影响燃尽线的斜率和每日数据点位置，选型时应把团队的实际作息和假期安排代入试用。
范围变更处理。迭代中途增加或移除问题时，燃尽图是否同步调整总工作量、是否保留范围变更的痕迹，是判断图表可信度的关键。评估时可模拟一次迭代中新增任务和移出任务，观察总工作量线是否跳变、历史数据点是否被重算。若团队需要复盘范围蔓延，还要确认能否导出或留存变更前后的对比。
历史迭代回溯。燃尽图的价值之一是跨迭代对比。需要确认已结束迭代的图表是否保留、能否按迭代筛选查看、数据保留期限是否受版本或部署方式影响。YouTrack 提供云端和自托管两种部署方式，自托管场景下数据保留取决于团队自身的备份与归档策略，这部分应在部署方案中一并确认。
适配建议。如果团队已经在用 YouTrack 管理问题和迭代，燃尽图可以作为迭代健康度的日常视图，前提是估算字段填写规范、每日更新剩余工作量形成习惯。选型核验时建议按以下顺序试用：先配置一个短周期迭代并填入带估算的任务，再模拟中途增删任务，最后检查迭代结束后图表是否可回溯。价格、版本差异和具体刷新机制以厂商当前说明为准，试用阶段记录实际表现比依赖文档描述更可靠。
数据来源与更新频率的核验清单
对照表和产品说明只能建立初步判断，燃尽图是否可信要在试用环境里动手验证。下面四项核验动作按顺序执行，每项都给出通过标准，建议用同一个真实迭代的数据完成，记录实际观察结果而不是依赖宣传描述。
核验一：改动剩余量，观察曲线是否同步
在迭代内选一个已估算的任务，把剩余工时从原值改为一半，再改回原值，每次改动后查看燃尽曲线对应数据点。通过标准是曲线随剩余量变化而调整，且变化幅度与改动量一致；如果曲线不动，说明燃尽数据可能来自另一张手工表或需要额外触发同步。同时确认子任务工时是否汇总到父任务、未估算的工作项是否计入，这两点决定曲线起点是否准确。
核验二：确认刷新触发条件与延迟上限
记录一次状态变更的准确时间，然后每隔一段时间查看图表，直到曲线反映该变更，得到实际延迟。通过标准取决于团队节奏：每日站会前需要看到当天状态的团队，延迟应控制在一个可接受的小时级范围内；短周期迭代可以要求更短。还要区分两种刷新方式——打开图表时读取最新数据，与后台按固定周期重算，前者在页面停留期间可能不更新，后者存在固定的时间窗口。把观察到的延迟写进选型记录，作为与厂商确认的依据。
核验三：迭代中途增删范围与调整工作日历
在迭代进行到一半时新增一个带估算的任务，观察总工作量线和剩余线如何变化：是整体上移后继续下降，还是只调整剩余线。再移除一个任务，确认曲线是否回退。随后把迭代周期内的一个工作日设为非工作日，查看理想燃尽线的斜率是否相应调整。通过标准是范围变更和工作日历调整都能在曲线上体现，并且团队能解释每一次跳变的原因；如果曲线在范围变更后完全重算历史数据点，需要确认这是否符合团队复盘时的解读习惯。
核验四：已结束迭代的曲线保留与复算
找一个已经结束的迭代，查看其燃尽图是否仍可打开、数据点是否完整。再尝试按当前口径重新生成或导出该迭代的燃尽数据，确认结果与当时看到的是否一致。通过标准是历史曲线可回看、可导出，用于迭代回顾时能与其他报表（如工时日志）对照。若历史数据只保留有限时间，需要把保留期限纳入选型条件，尤其是需要跨季度对比迭代效率的团队。
按团队节奏做选择与试点建议
核验结果要放回团队自身的迭代节奏里判断。一周或两周的短周期迭代，每天的有效工作时间占比高，燃尽图延迟半天就可能让站会讨论基于过期状态，这类团队应把更新触发方式和延迟上限放在筛选顺序的前面，优先选择工作项变更后能较快反映到曲线的工具。迭代周期较长、以周为单位跟踪的团队，对延迟的容忍度更高，可以把注意力更多放在数据来源口径和工作日历配置上。
数据录入纪律是另一个分水岭。成员习惯在任务完成后才补填工时的团队，燃尽曲线容易出现末期陡降，此时应优先看数据来源是否自动取自工作项状态和剩余量，减少对手工维护表的依赖；同时把剩余量更新纳入每日站会或任务关闭动作，让数据更新频率与团队习惯匹配。估算口径尚未统一的团队，先确定按工时还是按工作项数量燃尽，再比较工具，否则不同工具的曲线差异很难归因。
试点建议按以下方式推进：
- 范围：选一个节奏稳定、成员配合度较高的团队，用一个完整迭代试用，覆盖迭代计划、每日跟进和迭代回顾三个环节。
- 观察周期：至少一个完整迭代，短周期团队可连续观察两到三个迭代，比较曲线形态是否稳定。
- 判断依据：以核验清单的四项结果为准，结合团队在站会上是否能直接依据曲线做判断，而不是只看图表是否美观。
- 记录方式：把每次范围变更、工作日历调整和刷新延迟记录在同一张表里，试点结束后与厂商确认未明确的能力项。
进入采购或推广前，还需要向厂商确认版本差异、与现有代码仓库或需求池的集成方式，以及价格与部署形态。这些事项随版本和时间变化，本文不给出确定结论，建议在试点同期索取当前版本的说明材料，并与试用观察结果交叉核对。燃尽图只是迭代跟进的一个视图，选型时把它放回团队的迭代管理流程中评估，比单独比较图表功能更能得到可用的结论。
常见问题
燃尽图的数据来自手工维护的表格，还能用吗？
可以用，但要先评估维护成本与失真风险。手工表的问题在于曲线质量完全取决于录入是否及时：成员在迭代末期集中补填，曲线会在末端陡降，站会上据此判断进度容易误判。如果团队暂时只能用手工表，建议把剩余量更新固定到每日站会或任务关闭动作中，并指定一人核对数据完整性。选型阶段则应优先考察燃尽数据能否自动取自迭代内工作项的剩余量或剩余工时，减少一层人工环节。
打开图表才刷新的工具，和后台定时重算的工具，选哪种更合适？
两种方式各有适用场景。打开图表时读取最新数据，适合成员分散在不同时区、查看时点不固定的团队，但页面停留期间数据可能不更新，需要重新打开确认。后台按固定周期重算，数据口径更稳定，适合每日固定时点开站会的团队，代价是存在一个固定的时间窗口，变更不会立即体现。判断依据是团队在什么时点依赖这张图：站会前需要看到当天状态，就把延迟上限作为硬性条件；以周为单位跟踪进度，对延迟的容忍度更高。
迭代中途新增需求，燃尽曲线整体上移，这算正常吗？
属于常见处理方式，关键是团队能否解释每一次跳变。范围增加后总工作量上移、剩余线继续下降，反映的是范围变更后的真实剩余量；另一种做法是区分原始范围与变更后范围，让读者看到范围蔓延的幅度。两种口径都能用，但要在迭代开始前约定清楚，并在回顾时结合工作项变更记录解读曲线。如果工具在范围变更后重算了全部历史数据点，需要确认这是否符合团队的复盘习惯，必要时保留变更前的截图或导出记录。
团队估算习惯不统一，先统一口径还是先选工具？
建议先统一口径再比较工具。按工时燃尽和按工作项数量燃尽会得到形态不同的曲线，如果团队内一部分任务填工时、一部分只改状态，换任何工具都难以得到可解释的趋势。可以先在一个迭代内确定用哪种口径、哪些工作项必须估算、完成状态如何定义，再拿这个口径去试用候选工具，观察曲线是否与团队认知一致。口径稳定后，工具之间的差异才容易归因。
已结束迭代的燃尽图保留时间有限，会影响选型吗？
取决于团队复盘的跨度。只做单迭代回顾的团队，保留最近几个迭代的数据通常够用；需要跨季度对比迭代效率、或向管理层提交周期性报告的团队，应把历史数据保留期限和导出能力列入选型条件。试用时可以打开一个较早结束的迭代，确认曲线是否完整、能否导出，并询问保留策略是否受版本或部署方式影响。自托管部署的场景下，数据保留还与团队自身的备份归档安排有关，需要在部署方案中一并确认。
