迭代结束时，未关闭的工作项需要逐项重评，不能默认顺延到下一迭代。重评的核心是先按验收标准判断完成状态，再估算剩余工作量，给出继续、拆分、退回待办或关闭的结论，最后按下一迭代的实际容量重新排入。本文给出可直接执行的口径、五步流程、角色分工、完整示例和完成检查清单。
要点总览（TL;DR）
- 重评以验收标准判定完成状态，工时投入只作参考；只要有一条验收条件未满足，就归入未完成。
- 按五步推进：盘点未关闭工作项、核对验收标准、估算剩余量、给出继续/拆分/退回待办/关闭四类结论、按下一迭代容量重新排入。
- 产品负责人判断价值与优先级，开发团队核对产出并估算剩余量，Scrum Master或项目负责人组织重评、记录结论并跟踪排入。
- 重评做到位的标志是：每项都有结论和原因、剩余量有估算依据、排入总量不超容量、相关干系人已知晓。
重评前先定口径：什么算未完成
重评争议大多来自口径不一致：有人按工时判断“做了大半”，有人按验收标准判断“还不能交付”。迭代重评应统一采用验收标准作为完成判定依据，工时投入只作为参考信息，不改变完成状态。
具体判定时，把工作项对照其验收标准逐条核对。全部验收条件满足，且产出已提交到约定位置（如代码合并、文档定稿、测试通过），才算完成；只要有一条验收条件未满足，就归入未完成，进入重评流程。部分完成的工作项要区分“已完成部分”和“剩余部分”：已完成部分写清实际产出，剩余部分单独估算，避免把已投入的工时误当成已完成的价值。
重评记录建议统一使用以下字段，保证每项结论可追溯、可复核：
| 字段 | 填写内容 | 填写要求 |
|---|---|---|
| 工作项 | 编号与名称 | 与迭代内原始条目一致 |
| 原计划 | 原定范围与验收标准 | 引用迭代开始时确认的版本 |
| 实际进展 | 已完成的具体产出 | 写产出物，不写投入工时 |
| 剩余量 | 剩余工作的估算值 | 注明估算单位与依据 |
| 结论 | 继续、拆分、退回待办或关闭 | 四类结论选其一 |
| 原因 | 结论的依据 | 说明阻塞、范围变化或价值调整等 |
口径确定后，重评会议只需围绕这张记录表逐项过，讨论集中在“验收标准是否满足”和“剩余量是否合理”，减少反复解释。
逐项重评的操作步骤
重评按固定顺序推进，每一步都有明确输入、动作、输出和完成标志，避免会议开成漫谈。
第一步：盘点迭代内未关闭工作项
输入是迭代看板或工作项列表。动作是把迭代结束时状态未达到“完成”的所有条目导出成清单，包括进行中、待验证和被阻塞的条目。输出是一份完整的未完成清单，完成标志是清单条目数与迭代内实际未关闭数一致，没有遗漏。
第二步：核对验收标准与实际产出
输入是清单中每项工作的验收标准和实际产出。动作是逐条对照，确认哪些验收条件已满足、哪些未满足，并把实际产出记录到“实际进展”字段。输出是每项工作的完成状态判定。完成标志是清单中每一项都有明确的“完成/未完成”判断，且判断有验收条件作为依据。
第三步：估算剩余工作量
输入是未满足的验收条件和当前产出。动作是由熟悉该工作的人估算完成剩余条件所需的工作量，注明估算单位和依据，例如按故事点、人天或任务数。输出是每项未完成工作的剩余量。完成标志是剩余量有估算依据，且与已完成部分分开记录。
第四步：给出四类处理结论
输入是完成状态判定和剩余量。动作是结合价值、优先级和阻塞情况，为每项工作选择一种结论：
- 继续：工作仍有价值、剩余量清晰，直接排入下一迭代继续推进。
- 拆分：剩余量偏大或包含多个可独立交付的部分，拆成更小的工作项，只把下一迭代能完成的部分排入。
- 退回待办：当前优先级下降或依赖外部条件暂不具备，退回产品待办列表，等待重新排序。
- 关闭：需求已失效、被其他方案替代或确认不再需要，直接关闭并记录原因。
输出是每项工作的结论和原因。完成标志是清单中不存在“待定”条目，每项都有四类结论之一。
第五步：按下一迭代容量重新排入
输入是结论为“继续”和“拆分”的工作项，以及下一迭代的可用容量。动作是把这些工作项按优先级排入下一迭代，核对总剩余量与容量的匹配情况，超出容量的部分留在待办列表。输出是下一迭代的初始工作项集合。完成标志是排入总量未超出容量，且每项排入工作都能对应到重评记录中的结论。
这五步的结论需要落到工作项状态和迭代视图中，才能被后续执行直接引用。在ONES中，可以在迭代视图内筛选未关闭工作项，逐项更新状态、剩余工作量和处理结论，并把拆分后的子工作项与退回待办、关闭的条目分别归位，使下一迭代的排入结果与重评记录保持一致。
角色分工与各自交付物
重评涉及价值判断、技术估算和组织记录三类工作，角色不清会导致结论悬空或记录缺失。以下分工适用于采用Scrum的团队，其他组织方式可按职责对应调整。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 产品负责人 | 判断未完成工作的价值与优先级，决定退回待办或关闭 | 每项工作的价值判断与优先级结论 |
| 开发团队 | 核对实际产出与验收标准的差距，估算剩余工作量，提出拆分建议 | 完成状态判定、剩余量估算、拆分方案 |
| Scrum Master或项目负责人 | 组织重评会议，维护重评记录，跟踪结论排入下一迭代 | 完整的重评记录表、下一迭代排入清单 |
三个角色的产出在同一张记录表上汇合：开发团队提供事实判断，产品负责人给出价值结论，Scrum Master或项目负责人保证记录完整并推动排入。若团队规模较小、角色由同一人兼任，仍应分别完成这三类判断，避免用技术判断替代价值判断。
示例：一个未完成需求的完整重评
以下为演示情景，用于说明重评过程，不代表真实项目数据。
背景与工作项描述：某团队迭代结束时，“订单导出功能”仍处于进行中。原计划包括三项验收条件：支持按日期范围导出、导出文件包含指定字段、导出任务完成后有站内通知。迭代内已完成前两项，第三项未开始，原因是通知服务依赖的另一团队接口尚未就绪。
核对验收标准后的结论：三项验收条件满足两项，按口径判定为未完成。已完成部分记录为“日期范围导出与字段配置已提交测试”，剩余部分为“站内通知的触发与展示”。
剩余工作量估算与拆分方式：开发团队估算剩余工作约需两天，其中通知触发逻辑一天、展示与联调一天。由于通知依赖外部接口，团队把原工作项拆成两个：一个保留已完成的导出能力并标记完成，另一个单独承载通知功能，剩余量记为两天，并注明依赖外部接口就绪。
重新排入下一迭代的依据：产品负责人确认导出能力本身已有用户价值，通知功能优先级保持；下一迭代容量允许排入两天工作量，因此把通知工作项排入下一迭代，并在记录中注明依赖条件。若接口届时仍未就绪，该工作项在下一迭代重评时再按同样流程处理。
完成检查：重评是否做到位
重评结束后，用以下清单逐项核对，全部满足才算完成：
- 迭代内每项未关闭工作都有明确结论，没有“待定”或空白项。
- 每项剩余工作量都有估算值和估算依据，且与已完成部分分开记录。
- 每项结论都记录了原因，包括阻塞、范围变化或价值调整等具体依据。
- 下一迭代排入的工作量总和不超出可用容量，超出部分已留在待办列表。
- 拆分产生的新工作项与原工作项的对应关系清晰，退回待办和关闭的条目已从迭代中移出。
- 产品负责人、开发团队和相关干系人已知晓重评结论，对下一迭代的排入结果无异议。
清单核对完成后，重评记录与下一迭代的工作项集合即作为下一轮执行的起点；后续如需调整，也应在记录中补充原因，保持结论可追溯。
常见问题
迭代结束时，一项工作只差联调，能不能直接算完成？
按验收标准判断。如果验收条件里包含联调通过或测试通过，而联调尚未完成，这项就归入未完成，进入重评流程。已完成的部分写进实际进展，剩余部分单独估算，避免把已投入的工时当成已完成的价值。
剩余工作量估算没有历史数据参考，怎么给出依据？
由熟悉该工作的人按未满足的验收条件逐条估算，注明估算单位和依据，例如按故事点、人天或任务数。依据可以是剩余条件涉及的具体动作，例如“通知触发逻辑一天、展示与联调一天”。估算值不必精确到小时，但要能说明是怎么得出的，便于下一迭代重评时对照修正。
拆分后的工作项和原工作项怎么对应，才能不丢信息？
拆分时保留原工作项的编号和名称作为来源记录，把已完成部分归入一个可标记完成的工作项，剩余部分单独建项并注明剩余量和依赖条件。重评记录中写明拆分前后的对应关系，下一迭代排入时只排剩余部分，原工作项不再重复排入。
退回待办的工作项，下一迭代还要不要再评一次？
退回待办意味着当前优先级下降或外部条件暂不具备，它离开本迭代，回到产品待办列表等待重新排序。当它再次被排入某个迭代时，按当时的验收标准和剩余量重新判断，不沿用本次结论。本次重评记录保留原因，便于后续追溯优先级变化。
团队规模小、角色由一人兼任，重评流程可以简化吗？
可以按职责对应调整，但三类判断仍要分别完成：完成状态与剩余量的事实判断、价值与优先级的结论、记录与排入的跟踪。由同一人兼任时，建议在记录表上分别填写，避免用技术判断替代价值判断，也避免结论只停留在口头。
