迭代评审要回答三个问题：这次迭代承诺了什么、实际做成了什么、差异为什么产生。围绕这三条线，评审依据可以归为四类：迭代目标与验收标准、Sprint Backlog 与任务完成状态、可运行的增量与演示环境、变更风险与质量证据。本文按准备、分工、会议执行、未完成项处置和完成检查的顺序展开，帮助团队在评审前把材料备齐，在会上用同一套依据形成结论。
要点总览（TL;DR）
- 迭代评审的依据按承诺、过程、结果、差异四类归组：迭代目标与验收标准、Sprint Backlog 与任务完成状态、可运行增量与演示环境、变更风险与质量证据。
- 依据准备按角色分工：产品负责人交目标与验收标准，开发负责人交增量与演示环境，测试负责人交测试结果与遗留缺陷，主持人在评审前一天完成汇总预检。
- 评审会按“目标逐条核对—演示对照验收标准—解释差异归因—记录结论”的顺序推进，每条需求给出接受、退回或待重新评估的明确结论。
- 未完成项逐条标注原因与当前状态，按价值、依赖与下一迭代容量重新评估，结论写入评审记录，不默认结转到下一迭代。
- 评审前用完成检查清单核对：验收标准逐条可对照、增量可演示、变更与风险记录完整、未完成项已有重新评估结论。
评审前先定依据清单：四类材料缺一不可
评审依据的作用是让“完成”与“未完成”都有可对照的凭据。准备时按四类归组，每类材料回答一个明确问题，避免会上临时找数据或凭印象判断。
| 材料类别 | 包含内容 | 回答的问题 |
|---|---|---|
| 承诺依据 | 迭代目标、本次纳入迭代的需求清单、每条需求的验收标准 | 这个迭代原本答应交付什么，做到什么程度算完成 |
| 过程依据 | Sprint Backlog、任务拆分与完成状态、工时或剩余工作量记录 | 团队实际推进到哪一步，哪些任务已关闭、哪些仍在进行 |
| 结果依据 | 可运行的增量、演示环境与演示脚本、部署或构建记录 | 做出来的东西能否实际运行和操作 |
| 差异依据 | 需求变更记录、范围调整说明、风险与阻塞记录、测试结果与遗留缺陷清单 | 目标与实际之间的差距由什么造成 |
四类材料中，承诺依据和结果依据是评审的主线，过程依据用于支撑判断，差异依据用于解释原因。缺少承诺依据，评审容易变成功能演示；缺少差异依据，未完成项的原因只能靠口头回忆，结论难以服人。准备清单建议在迭代结束前两到三个工作日确定下来，并明确每类材料的存放位置，让参会者在会前可以自行查阅。
按角色分工准备：谁交什么、什么时候交
依据准备落到人头上才可执行。分工的基本原则是：谁最接近这类信息，谁负责整理；评审主持人负责汇总和预检。下表给出一种常见分工，团队可按规模调整，但每类材料都应有明确负责人。
| 角色 | 交付材料 | 交付时点 |
|---|---|---|
| 产品负责人 | 迭代目标、需求清单与验收标准、迭代内的需求变更记录及变更原因 | 迭代结束前三个工作日 |
| 开发负责人 | 可运行增量、演示环境与演示脚本、Sprint Backlog 任务完成状态汇总 | 迭代结束前两个工作日完成环境准备，评审前一天完成演示预演 |
| 测试负责人 | 测试执行结果、用例通过情况、遗留缺陷清单（含严重程度与影响范围） | 迭代结束前两个工作日 |
| 评审主持人 | 材料汇总、预检结论、评审议程与记录模板 | 评审前一天完成预检，向参会者发出议程 |
预检的重点是核对材料之间能否对上：需求清单中的每条需求是否都有验收标准，任务完成状态是否与演示内容一致，遗留缺陷是否标注了对应的需求或功能。预检发现缺口时，由对应负责人在评审前补齐；确实无法补齐的，在评审记录中注明缺口及原因，作为结论的一部分，而不是留到会上解释。
当团队使用 ONES 开展迭代管理时，这些材料大多可以在同一套工作项中沉淀：需求与任务规划至迭代并分配负责人，任务状态通过看板更新，测试用例未通过可转为缺陷提交至项目并指派修复，评审前直接从迭代视图汇总完成情况与缺陷清单，减少跨工具收集材料的时间。具体功能范围以实际开通的配置为准。
评审会上的执行步骤：从目标核对到结论记录
评审会按固定顺序推进，每一步都对应一类依据，确保材料被实际使用而不是只做展示。
- 对照迭代目标逐条核对。主持人按需求清单逐条读出验收标准，由产品负责人确认该需求的状态：已满足、部分满足或未开始。这一步只做事实确认，暂不讨论原因。
- 演示增量并对照验收标准确认。开发负责人按演示脚本操作可运行增量，参会者对照验收标准判断是否达到完成定义。演示中发现的偏差当场记录，作为后续结论的依据。
- 解释差异。对未满足或部分满足的条目，由对应负责人依据变更记录、阻塞记录和缺陷清单说明原因，区分是范围调整、外部依赖阻塞还是质量问题，并说明影响范围。
- 形成并记录结论。每条需求给出一个明确结论：接受、退回或待重新评估。结论连同依据摘要、差异原因和后续动作写入评审记录，会后同步给相关方。
结论记录建议包含以下字段：需求编号与名称、验收标准、实际结果、结论类型、差异原因、后续动作与负责人。记录格式统一后，多个迭代的评审结论可以横向对比，也便于在回顾会中复盘评审质量。
未完成项怎么处理：重新评估而非默认结转
未完成项直接顺延到下一迭代，会让下一迭代的承诺范围在开始前就超出容量，也会掩盖计划或执行中的问题。评审时应把每个未完成项当作一个待决策事项处理。
第一步是逐条标注现状：当前完成到什么程度、剩余工作是什么、卡在哪个环节、是否已有部分成果可以交付。第二步是按三个维度重新评估：该项对用户或业务的价值是否仍然成立；它与其他工作是否存在依赖关系，延后是否会影响其他事项；下一迭代的可用容量是否足以容纳它。第三步是给出处置结论，常见选项包括纳入下一迭代、拆分为更小的条目后部分纳入、退回待办列表重新排序、或直接关闭。
重新评估的结论需要写入评审记录，字段包括：未完成项名称、未完成原因、评估结论、决策依据、若纳入下一迭代则注明对应迭代。留痕的意义在于，下一迭代计划会议可以直接引用这些结论，不必重新讨论；回顾会也能据此判断未完成是计划问题还是执行问题。
示例：一次迭代评审的依据组织
以下为演示情景，用于说明依据清单如何被准备和使用，不代表特定团队的真实数据。
某团队的两周迭代承诺完成六条需求，迭代目标是上线订单导出功能并优化列表加载速度。产品负责人在迭代结束前三个工作日整理出六条需求及各自验收标准，其中一条需求在迭代中期因业务方要求调整了导出字段范围，变更记录同步附上。开发负责人准备演示环境，按脚本演示导出功能和列表加载，并汇总任务完成状态：五条需求的任务全部关闭，一条需求的后端任务完成、前端任务仍在进行。测试负责人提交测试结果，导出功能相关用例全部通过，列表加载优化存在一个中等严重程度的遗留缺陷，影响大数据量场景。
评审会上，团队逐条核对：四条需求满足验收标准，结论为接受；调整过字段范围的导出需求按变更后的标准确认通过，结论为接受并注明变更依据；列表加载优化因遗留缺陷未达验收标准，结论为退回；剩余一条需求前端未完成，结论为待重新评估。差异解释环节，团队确认列表加载问题属于质量原因，需修复后重新验证；未完成的前端任务因外部接口联调延迟，属于依赖阻塞。
未完成项处理时，团队评估该前端任务的价值仍然成立，但依赖的接口在下一迭代初才能就绪，决定将其拆分为界面框架与数据对接两部分，界面框架纳入下一迭代，数据对接待接口就绪后再排期。两项结论均写入评审记录，并标注了决策依据。
完成检查：评审依据是否齐备可用
评审开始前，主持人可用以下清单逐项核对。全部通过即可开会；存在未通过项时，先补齐或在记录中注明缺口。
- 迭代目标与每条需求的验收标准是否逐条对应，没有缺验收标准的需求。
- 需求变更是否都有记录，包含变更内容、原因和确认人。
- Sprint Backlog 的任务状态是否为最新，完成状态与演示内容一致。
- 可运行增量是否能在演示环境中实际操作，演示脚本是否覆盖主要验收场景。
- 测试结果是否覆盖本次迭代的需求，遗留缺陷是否标注严重程度和影响范围。
- 风险与阻塞记录是否完整，未完成项是否都有原因说明。
- 每个未完成项是否已有重新评估结论，结论是否写入评审记录。
- 评审记录模板是否包含结论类型、差异原因和后续动作字段。
这份清单同时可以作为评审质量的复盘依据：连续多个迭代出现同类缺口，说明准备流程中的某个环节需要调整，可在回顾会中讨论改进。
常见问题
迭代评审和迭代回顾有什么区别，材料可以共用吗？
两者关注点不同。迭代评审围绕本次迭代的交付结果，用目标、验收标准、增量和质量证据判断“做成了什么、差异为什么产生”；迭代回顾关注团队的工作方式，复盘进度、质量和协作中的问题。材料可以部分共用，例如任务完成状态、缺陷清单和工时记录在两边都会用到，但评审记录中的结论类型、差异原因和后续动作是评审特有的输出，回顾会引用这些结论判断计划与执行质量，不必重新收集一遍。
迭代中途发生需求变更，评审时按原标准还是变更后的标准判断？
按变更确认后的标准判断，同时把变更记录作为差异依据附在结论里。评审前由产品负责人整理迭代内的需求变更，写明变更内容、原因和确认人；评审时对涉及变更的条目，先说明变更依据，再对照变更后的验收标准确认结果。这样结论既能反映实际交付，也能让参会者看清范围调整对目标的影响。变更没有留记录的，应在评审记录中注明缺口，作为后续改进准备流程的依据。
遗留缺陷较多时，评审会时间不够用怎么办？
把缺陷按严重程度和影响范围分层处理，会上只逐条确认影响验收结论的缺陷，其余缺陷以清单形式随评审记录同步。测试负责人在会前完成缺陷分级，标注每条缺陷对应的需求或功能；评审时对未达验收标准的条目，直接引用对应缺陷说明原因，不再展开技术细节。缺陷数量持续偏多时，可在回顾会中讨论测试介入时点和提测标准，从准备环节减少评审当天的解释成本。
未完成项被拆分成小条目后，评审记录应该怎么记？
以原未完成项为主记录，在结论中写明拆分结果和各自的去向。记录字段包括原条目名称、未完成原因、评估结论、拆分后的条目及各自安排（纳入下一迭代、待依赖就绪后排序或关闭）、决策依据。拆分后的条目在下一迭代计划时作为独立工作项管理，评审记录保留与原条目的对应关系，便于回顾时追溯这项工作从承诺到交付的完整过程。
团队规模较小、角色由一人兼任时，分工表还能用吗？
可以用，合并角色即可，关键是每类材料仍有明确负责人和交付时点。例如产品负责人与评审主持人由同一人担任时，预检环节建议邀请一名不直接负责交付的成员参与，避免自己核对自己的材料。交付时点可以按迭代长度等比压缩，但承诺依据和结果依据应在评审前至少一个工作日备齐，留出补齐缺口的时间。
