迭代执行中的工作量估算表需要随任务进展持续校准。滚动更新的做法是以迭代为节拍，在计划会、每日同步、范围变更和评审回顾等固定节点触发更新，每次只改动受影响的工作项行，并记录更新前后数值、原因和责任人，让估算变化可追溯。本文给出触发机制、操作步骤、角色分工、示例和检查清单，聚焦投入预估的滚动更新，实际工时填报与产能指标分析不在本文范围。
要点总览（TL;DR）
- 滚动更新以迭代为节拍，在迭代计划会、每日同步、范围变更、评审回顾四类节点触发，每次只改受影响的工作项行。
- 版本记录至少保留更新日期、更新人、工作项编号、原估算、新估算、变更原因六项，原值不覆盖，历史可按迭代回溯。
- 用工作项编号把估算行与任务系统绑定，估算调整、任务拆分合并取消都要双向同步，避免两套数据各走各的。
- 迭代负责人、任务负责人、估算表维护人、评审角色分工明确，更新、核对、确认三项职责建议分离。
- 回顾时用六项检查清单核对行与任务对应、记录完整、结构同步、历史可回溯、节奏未中断、回写已核对。
滚动更新的基本机制：以迭代节拍驱动估算表变更
估算表在迭代执行期应当作为活文档使用。迭代开始时形成的估算值代表当时的判断，随着任务拆分、需求澄清、技术方案确定或范围调整，剩余工作量会发生变化。如果估算表停留在初始版本，它很快会失去参考价值；如果随时改动又不留记录，团队就无法解释估算为什么变化。滚动更新要解决的是这两个问题：让估算跟得上执行，同时让每次变化有据可查。
更新节奏建议绑定迭代内的固定节点，避免临时起意改表。常见有四类触发节点：
- 迭代计划会：确认本迭代纳入的工作项及其初始估算，形成本迭代的估算基线。
- 每日同步：任务负责人报告进展时，若发现剩余工作量与估算明显不符，提出调整需求，由维护人记录。
- 范围变更：需求新增、任务拆分、合并或取消时，同步调整对应估算行，这类变更不受每日同步节奏限制，发生时即处理。
- 迭代评审与回顾：核对本迭代估算与实际进展的偏差，确认变更记录是否完整，形成本次迭代的估算版本快照。
每次更新只改受影响的行，其余行保持不动。这样做的好处是比对成本低：回顾时只需查看有变更记录的行，就能还原估算调整的来龙去脉。版本记录至少包含六个字段：更新日期、更新人、工作项编号、原估算、新估算、变更原因。原值保留、新值另起一行或另存版本，不用新值覆盖旧值。工作项编号是估算行与任务系统之间的锚点，估算变化必须回写到对应任务，任务拆分或取消也要同步调整估算表，避免两套数据各走各的。
操作步骤：一次滚动更新怎么做
下面以一次常规的迭代内更新为例，说明从确认范围到通报确认的完整动作。每个步骤都给出输入、动作、输出和完成标志，便于维护人按序执行。
步骤一：确认本次更新范围
输入：本次触发节点（如每日同步或范围变更）涉及的工作项清单。动作：从任务系统导出受影响工作项的当前状态、负责人和原估算，筛出需要核对的行。输出：一份待核对的工作项列表。完成标志：列表中的每个工作项都能在估算表中找到对应行，没有遗漏也没有多余行。
步骤二：逐行核对估算与实际进展
输入：待核对列表、任务负责人提供的进展说明。动作：对每一行判断剩余工作量是否仍符合原估算，区分“无需调整”“需要上调”“需要下调”“任务已拆分或取消”四种情况。输出：每行的判断结论。完成标志：待核对列表中的每一行都有明确结论，没有悬而未决的行。
步骤三：填写新估算与变更原因
输入：步骤二的判断结论。动作：对需要调整的行填写新估算值和变更原因，原估算值保留在记录中不覆盖；对拆分或取消的任务，注明拆分后的子任务编号或取消原因。输出：更新后的估算表及变更记录。完成标志：每条变更都能看到原值、新值、原因、更新人和日期五项信息。
步骤四：同步回写任务系统
输入：更新后的估算表。动作：把调整后的估算值回写到任务系统对应工作项，核对任务状态、负责人与估算表一致。输出：估算表与任务系统数据一致的状态。完成标志：抽查若干行，估算表与任务系统中的数值和状态完全对应。
步骤五：在迭代例会上通报变更
输入：本次变更记录汇总。动作：在每日同步或迭代例会上说明哪些工作项估算发生变化、变化原因及对迭代目标的影响，请相关角色确认知悉。输出：会议记录中的变更通报条目。完成标志：受影响任务的负责人和迭代负责人确认已知悉变更，无异议或异议已记录待处理。
在工具承载层面，ONES Project 支持将需求和相关任务规划至迭代并分配负责人，也提供任务工时统计用于估算任务持续时间，看板和燃尽图可帮助团队在执行中观察进度变化。若估算表以文档形式维护，ONES Wiki 支持文档关联任务，并可插入 ONES Project 的工作项列表，便于把估算行与工作项放在同一处对照。估算值与工作项字段之间的同步方式、历史版本留存能力，建议在选型或配置时结合实际版本确认。
角色分工与交付物
滚动更新能否持续，取决于责任是否落到具体角色。以下分工适用于中小型迭代团队，团队规模或协作方式不同时可合并角色，但更新、核对、确认三项职责建议保持分离。
| 角色 | 主要职责 | 交付物 | 时点 |
|---|---|---|---|
| 迭代负责人 | 组织更新节奏，确认变更范围，判断变更是否影响迭代目标 | 迭代估算基线、变更范围确认记录 | 计划会、范围变更发生时、评审会 |
| 任务负责人 | 提供任务进展与剩余工作量判断，提出估算调整需求 | 进展说明、调整申请 | 每日同步、任务状态变化时 |
| 估算表维护人 | 执行填写，归档版本，核对估算表与任务系统一致性 | 更新后的估算表、变更记录、版本快照 | 每次更新后、迭代结束时 |
| 评审角色 | 在回顾中确认变更合理性，检查记录完整性 | 回顾结论、改进项 | 迭代回顾会 |
维护人通常由迭代负责人或项目助理兼任，关键要求是每次更新后完成一致性核对，而不是等到迭代结束再补。评审角色可以由迭代负责人、技术负责人或质量角色承担，重点看变更原因是否成立、记录是否齐全，不必逐行复核数值。
示例：一个迭代内的估算表滚动更新过程
以下为演示情景，用于说明版本如何累积，数值仅为示意。
某迭代计划纳入 8 个工作项，计划会上形成初始估算：工作项 A 估 5 人天、B 估 3 人天、C 估 8 人天，其余工作项合计 12 人天，迭代总估算 28 人天。估算表按工作项编号逐行登记，每行记录原估算、当前估算和更新日期。
执行到第 3 天，任务负责人发现工作项 C 需要拆分为 C1 和 C2 两个子任务。维护人在估算表中保留 C 的原行，标注“已拆分”，新增 C1 估 5 人天、C2 估 4 人天两行，变更原因写“原估算未覆盖接口联调部分”。此时迭代总估算变为 29 人天，变更记录显示 C 的原值 8、拆分后合计 9、更新人和日期齐全。
第 5 天，需求方撤下一个低优先级工作项 D（原估 2 人天）。维护人将 D 行标注“已取消”并注明原因，不删除该行，迭代总估算相应下调。同一天新增一个缺陷修复工作项 E，估 1 人天，按新行登记并回写任务系统。
迭代结束时，维护人导出本次迭代的估算版本快照，包含初始基线、全部变更记录和最终估算。回顾会上，评审角色对照快照检查：每条变更都有原因和前后值，拆分和取消都已同步，估算表行与任务系统工作项一一对应。快照归档后，下一迭代在此基础上重新建立基线。
避免估算表与实际任务脱节的检查项
滚动更新是否做到位，可以用以下清单逐项核对。建议在每次迭代回顾时执行一遍，发现问题记入改进项。
- 行与任务一一对应：估算表中每一行都能找到对应的工作项编号，任务系统中每个纳入估算的工作项也都有对应行，没有孤立行或缺失行。
- 变更记录完整：每次调整都能看到更新日期、更新人、工作项编号、原估算、新估算和变更原因，六项信息缺一不可。
- 结构变化已同步：任务发生拆分、合并或取消时，估算表已做相应标注或新增行，原行保留而非直接删除。
- 历史可回溯：按迭代可以调出当时的估算版本，历史数值未被覆盖，能够还原任一工作项的估算变化过程。
- 节奏未中断：更新动作与计划会、每日同步、评审回顾等节点绑定，没有出现连续多日甚至整个迭代未更新的情况。
- 回写已核对：估算表与任务系统中的估算值、任务状态一致，抽查若干行无差异。
清单中任何一项不通过，都说明估算表与任务之间出现了缝隙。常见原因是更新责任不明确或回写环节被跳过，处理方式是把对应动作重新绑定到具体角色和固定节点，而不是在迭代结束后集中补录。
常见问题
迭代进行到一半，需求方临时撤下或新增任务，估算表应该什么时候改？
范围变更不受每日同步节奏限制，发生时即处理。维护人先确认变更涉及的工作项编号，在原行上标注“已取消”或新增行，写明变更原因和更新人，再回写任务系统。原行保留不删除，这样回顾时能看出迭代中途发生过哪些范围调整，以及这些调整对总估算的影响。
估算表维护人由谁兼任比较合适？如果团队没有专职项目助理怎么办？
维护人通常由迭代负责人或项目助理兼任，关键要求是每次更新后完成一致性核对，而不是等到迭代结束再补。小团队没有专职助理时，可以由迭代负责人承担填写与归档，但一致性核对建议交给另一名成员抽查，避免同一人既改表又核表。团队规模或协作方式不同时可合并角色，更新、核对、确认三项职责尽量保持分离。
估算表用文档维护还是放在项目管理工具里，哪种更利于保留历史版本？
两种方式都能做滚动更新，差别在版本留存和回写成本。文档形式便于按迭代另存快照、逐行记录变更原因，ONES Wiki 支持文档关联任务，并可插入 ONES Project 的工作项列表，便于把估算行与工作项放在同一处对照。工具内维护则回写更直接，ONES Project 支持任务工时统计用于估算任务持续时间，也支持将需求和相关任务规划至迭代并分配负责人。估算值与工作项字段之间的同步方式、历史版本留存能力，建议在选型或配置时结合实际版本确认。
每日同步都改估算，会不会让估算表变得过于频繁、失去参考意义？
每日同步是提出调整需求的节点，不等于每天都改。任务负责人报告进展时，只有剩余工作量与原估算明显不符才提出调整，维护人判断后记录。多数工作项在迭代内估算保持稳定，真正发生变更的行是少数。如果发现几乎每天都有大量行变动，通常说明初始估算拆分粒度太粗或需求澄清不足，应在回顾中作为改进项处理，而不是靠频繁改表掩盖。
迭代回顾时发现估算表与任务系统对不上，应该怎么补救？
先按工作项编号逐行比对，找出缺失行、孤立行和数值不一致的行，判断是回写环节被跳过还是任务结构变化未同步。补录时保留原值、注明补录原因和补录日期，避免把补录记录混入正常变更。补救完成后，把对应动作重新绑定到具体角色和固定节点，例如在每次更新后增加抽查核对，防止下一迭代再次出现同样缝隙。
