工作量估算表在迭代执行中怎么滚动更新

迭代执行中的工作量估算表需要随任务变化持续校准，才能作为排期和交付判断的依据。做法是：迭代计划时锁定估算基线，执行中只更新受影响的条目，每次改动留下原值、新值、原因、变更人和日期，并用同一套任务编号把估算条目与看板任务对应起来。这样估算表既能反映最新投入预期，也能回溯每个数字是怎么变过来的。

要点总览（TL;DR）

• 迭代计划时锁定估算基线版本，原始估算值不再直接改写，后续变化以追加变更记录的方式保留，复盘时才有对照点。
• 约定四类更新触发点——范围变更、任务拆分、发现遗漏、偏差超阈值，出现其一才发起更新，避免随时改表或漏改。
• 每次变更记录原值、新值、原因、变更人、日期，并关联任务编号和版本号，形成可回溯的版本链。
• 把更新动作固定到计划、中检、收尾三个时点，任务负责人提变更、迭代负责人确认、记录人维护日志，职责落到具体角色。
• 估算条目与看板任务共用同一套任务编号，用剩余工作量驱动进度判断，收尾时按原因归类偏差并形成下一轮校准动作。

滚动更新的核心做法：基线加变更记录

滚动更新要解决两个问题：一是估算值随执行变化，二是变化过程可追溯。基线版本和变更记录分别承担这两个职责。基线回答“我们当初按什么口径承诺”，变更记录回答“后来为什么改、改成了多少”。两者配合，估算表才是一份可解释的活文档，而非一张随时被覆盖的静态表格。

迭代开始时锁定估算基线

迭代计划会结束时，把当次确认的估算条目整理成一个基线版本：每条任务有唯一任务编号、负责人、原始估算值、估算口径（人时还是人天、是否含测试与联调）和版本号。基线一旦锁定，原始估算值不再直接改写，后续变化以新增变更记录的方式追加。基线的作用是给复盘提供对照点，避免迭代结束时只剩一个“最终数字”，说不清偏差从哪来。

明确四类更新触发点

估算表不宜随时改，也不宜等到迭代结束才改。建议约定以下触发条件，出现其一才发起更新：

• 范围变更：需求增减或验收标准调整，导致条目工作量变化。
• 任务拆分：一条估算在执行中被拆成多条子任务，需要把原估算分配到子任务并保留父子关系。
• 发现遗漏：执行中识别出计划时未考虑的工作，如数据准备、环境配置、回归验证。
• 实际偏差超阈值：剩余工作量与原始估算的差距超过团队在计划时约定的比例，例如偏差超过20%时触发复核。阈值由团队自行约定，关键是提前写清楚，执行中按同一标准判断。

每次更新记录五个字段

变更记录至少包含：原值、新值、变更原因、变更人、变更日期，并关联任务编号和版本号。原因要写到可判断的程度，例如“接口联调依赖第三方环境，延后两天，剩余工作量由6人时调整为14人时”，而不是只写“有调整”。记录字段固定后，版本链自然形成：基线版本加若干次变更，构成当前有效版本。

用任务编号打通估算与任务

估算条目和看板任务使用同一套任务编号，是避免两套数据脱节的前提。任务拆分时子任务继承父任务编号前缀，新增任务先建编号再补估算，关闭任务时同步把剩余工作量归零。这样从估算表能定位到具体任务，从看板也能反查该任务的估算变更历史。ONES Project 支持将需求和相关任务规划至迭代并分配负责人，并提供任务工时统计与看板、燃尽图，适合把估算条目、任务状态和进度放在同一套工作项体系里维护；估算表的多版本留存方式则需结合团队实际配置确认。

按迭代节奏安排更新动作：计划、中检、收尾

把更新动作固定到迭代的三个时点，可以减少临时改表和漏改。每个时点都明确输入、动作、输出和完成标志，更新就从“想起来才做”变成流程中的固定环节。

时点	输入	动作	输出	完成标志
迭代计划	需求清单、历史偏差数据、团队可用投入	逐条确认估算口径，分配任务编号与负责人，锁定基线版本	基线版估算表、口径说明	所有纳入迭代的任务均有编号、估算值和负责人，基线版本已标记
执行中检	看板状态、剩余工作量、新增或拆分需求	按固定频率（如每周一次，或每日站会后处理异常项）核对偏差，触发条件满足的条目发起变更并记录	变更记录、更新后的当前版本	偏差超阈值条目均已复核，新增与拆分任务已补估算，变更记录字段完整
迭代收尾	基线版本、当前版本、任务完成情况	对比基线与最终值，分析偏差原因，归档版本，提炼可复用的估算规律	归档版本、偏差分析结论、下一轮估算校准建议	版本已归档可查，偏差结论落到具体条目和原因分类，改进建议进入下轮计划输入

执行中检的频率要与迭代长度匹配：两周迭代可安排一次周中检查和一次迭代前检查；一周迭代可在每日站会后处理异常项，不再单独设中检。检查的重点是偏差条目和新增条目，未受影响的条目保持原值，避免整表重估带来的额外负担。收尾阶段的偏差分析按原因归类，例如需求理解偏差、遗漏工作、外部依赖延迟、估算方法偏保守，积累几轮后就能看出团队的系统性偏差方向，用于校准下一轮估算。

角色分工与交付物：谁改表、谁确认、谁归档

滚动更新失效的常见原因是“大家都以为别人会改”。把职责拆到具体角色，并给每个角色定义交付物，更新才有责任人。

角色	职责	交付物
任务负责人	发现触发条件时提出变更，更新本人负责条目的剩余工作量和原因说明	条目级变更申请，含原值、新值、原因
迭代负责人或估算协调人	审核变更是否合理、口径是否一致，确认基线变更，控制更新频率	变更确认记录，更新后的当前版本
记录人	维护版本号与变更日志，检查字段完整性，保证旧版本可查	变更日志、版本清单
迭代负责人（收尾）	牵头版本对比与偏差复盘，组织归档	归档版本、偏差分析结论、校准建议

小团队可以合并角色，例如迭代负责人兼任记录人，但“提出变更”和“确认变更”建议由不同人承担，形成一次简单复核。任务负责人最了解执行细节，负责提变更；迭代负责人掌握整体节奏和口径，负责确认。记录人可以是兼职，关键是每次变更当天完成登记，避免事后补记导致原因失真。归档责任落在迭代负责人身上，确保每个迭代结束时都有一个可查的封存版本。

工具层面，ONES Wiki 支持文档关联任务并插入 ONES Project 的工作项列表，可以把估算表与任务清单放在同一文档中维护，减少两处对照的成本；变更日志的版本留存与对比方式，建议在选型或配置时向厂商确认具体实现。

一个迭代内的滚动更新示例

以下为演示情景，用于说明更新过程，数据为示意值。

某团队进行两周迭代，计划纳入8条任务，基线版本记为V1.0，总估算为96人时。其中任务T-03“订单查询接口改造”估算16人时，负责人为后端工程师；任务T-05“报表导出优化”估算8人时。

• 第3天，任务拆分：T-03在执行中发现需同时改造两个查询入口，拆为T-03-1和T-03-2，原16人时分配为10人时和8人时，合计增加2人时。记录：原值16，新值18（分列两条），原因“拆分后识别出第二个入口的适配工作”，变更人为任务负责人，日期为第3天，版本升至V1.1。
• 第5天，发现遗漏：T-05缺少导出文件的权限校验，新增任务T-05-1，估算4人时。记录：新增条目，原因“计划时未考虑权限校验”，版本升至V1.2，总估算变为102人时。
• 第8天，偏差超阈值：T-03-1剩余工作量由6人时变为12人时，偏差超过约定的20%阈值。迭代负责人复核后确认是第三方接口文档延迟，记录原值6、新值12、原因和变更人，版本升至V1.3。
• 第10天，收尾复盘：对比V1.0与V1.3，总估算由96人时变为108人时，偏差12人时。归类为：拆分识别不足2人时、遗漏工作4人时、外部依赖6人时。结论是下轮计划时为涉及第三方接口的任务预留依赖缓冲，并在拆分环节增加入口清点检查。V1.3归档，变更日志随版本一并保存。

这个示例的关键在于：每次变化都有触发原因、有记录、有版本号，收尾时能按原因归类，而不是只看到一个总数变化。团队可以照此结构替换为自己的任务和数值。

避免估算表与实际任务脱节的检查项

迭代中检和收尾时，可用以下清单逐项核对。每项都应有明确的是或否判断，出现“否”时指定整改人和完成时间。

• 编号对应：估算表中的每条记录都能在任务系统中找到同编号任务，任务系统中的每个进行中任务都有对应估算条目，无孤立条目。
• 变更留痕：所有与原值不同的条目都有变更记录，且原值、新值、原因、变更人、日期五项齐全，原因可判断。
• 剩余量一致：估算表中的剩余工作量与看板任务状态、燃尽图走势一致，已完成任务的剩余量已归零，无“已完成但仍显示剩余”的条目。
• 版本可回溯：基线版本和历次变更版本均可查询，能还原任一时刻的有效估算值。
• 偏差有动作：收尾偏差分析按原因归类，并形成至少一条进入下一轮计划的具体改进动作，而非只记录偏差数字。
• 口径统一：全表使用同一估算单位和同一包含范围，拆分或新增条目沿用原口径，未出现人时与人天混用。

清单不必每次全量检查，可在周中检时抽查编号对应和剩余量一致两项，收尾时全量核对。连续几个迭代都通过的团队，可以把检查频率降为每迭代一次，把精力放回估算判断本身。

常见问题

迭代进行到一半，需求范围调整了，估算表应该整表重估还是只改受影响的条目？

只改受影响的条目。整表重估会让未变化的任务也产生新的估算值，版本链变长却缺少对应的变更原因，复盘时难以判断偏差来自哪里。做法是：范围调整涉及哪几条任务，就只对这几条发起变更，记录原值、新值、原因、变更人和日期，其余条目保持基线值不动。如果范围调整大到影响过半条目，更合适的处理是结束当前基线、另起一个新版本，并在版本说明中写清调整依据。

团队规模小、没有专职记录人，版本和变更日志怎么维护才不流于形式？

小团队可以合并角色，由迭代负责人兼任记录人，但“提出变更”和“确认变更”仍建议分开，保留一次简单复核。维护成本主要来自补记，所以关键是要求变更当天完成登记，原因写到可判断的程度，例如写明具体依赖或遗漏项，而不是只写“有调整”。记录载体用团队已有的文档或工作项即可，字段固定为原值、新值、原因、变更人、日期五项，不必额外增加字段。连续几个迭代稳定运行后，再考虑是否引入更细的版本管理方式。

估算表里的剩余工作量和看板状态对不上，通常是什么原因造成的？

常见原因有三类：一是任务关闭时没有同步把剩余工作量归零，导致已完成任务仍显示剩余；二是任务拆分后子任务新建了编号，但估算条目没有跟着拆分，父子对应关系断了；三是执行中口头调整了工作量，没有走变更记录，估算表停留在旧值。核对时可以先抽查编号对应关系，再比对已完成任务的剩余量是否归零，最后检查近期变更是否都有记录。把这三项纳入周中检的抽查范围，能较早发现脱节。

偏差阈值定多少合适，定得太低会不会增加很多无效更新？

阈值没有统一标准，取决于团队历史偏差的分布和迭代长度。初次设定可参考过去几个迭代的偏差情况，取一个能区分“正常波动”和“需要复核”的比例，例如偏差超过20%时触发复核，执行两三个迭代后再根据实际触发频率调整。阈值定得过低，确实会让大量正常波动进入复核流程，增加协调成本；定得过高，则偏差积累到收尾才暴露，失去滚动更新的意义。关键是阈值在迭代计划时写清楚，执行中按同一标准判断，而不是临时凭感觉决定要不要改。

滚动更新产生的历史版本，收尾后还需要保留多久？

保留期限由团队的管理需要决定，没有统一要求。通常建议至少保留到下一轮迭代的估算校准完成，因为偏差规律需要跨迭代对比才有参考价值。如果团队需要做季度或半年度的估算能力回顾，可以把归档版本按迭代集中存放，保留基线版本、最终版本和变更日志三部分即可，中间过程版本可按需精简。归档时在版本说明中写清偏差原因分类和改进动作，比单纯保存数字更有复用价值。