迭代评审在迭代结束前进行，用可运行的成果和明确的验收标准，对本次迭代完成的工作做一次集体检查。会前要划定评审范围、确认准入条件，会上逐项判定通过、有条件通过或不通过，会后把未通过项和未完成工作重新评估后再决定去向。本文按准备、开会、分工、结论落地、示例和检查清单的顺序展开，帮助团队组织一次有结论、能执行的评审。
要点总览（TL;DR）
- 迭代评审在迭代结束前进行，用可运行成果和验收标准逐项判定，产出通过、有条件通过、不通过三类结论及后续动作。
- 会前准备决定评审质量：划定评审范围、按“有可演示成果、验收标准明确”筛出准入项，并提前验证演示环境与测试数据。
- 评审会按开场对齐、成果演示、逐项判定、反馈分类、结论确认五步推进，新需求与缺陷分开记录，避免范围蔓延。
- 未通过项记录原因、责任人与复评时点；未完成工作回到待办重新评估优先级和工作量后再决定去向，不默认自动结转。
- 用范围覆盖、验收判定、结论去向、状态同步、角色通知五项清单核对，缺少验收标准、无可演示成果或结论未落地时应先补齐。
迭代评审要解决什么问题，边界在哪里
迭代评审的核心任务有三个：确认迭代目标是否达成，对照验收标准确认增量是否可接受，把评审中暴露的风险和分歧摆到台面上。评审的产出是一组有证据支撑的判定结果，以及由此产生的后续动作。判定结果需要落到具体工作项上，不能停留在会议纪要里的笼统评价。
评审与回顾容易混淆，两者的分工可以这样区分：评审看成果与验收，回答“这次迭代交付了什么、是否达到约定标准”；回顾看过程与改进，回答“团队协作方式哪里需要调整”。评审中发现的流程问题可以记录，留到回顾环节讨论；回顾中形成的改进措施，则可能影响下一次迭代的规划。把两件事放在同一个会议里处理，往往导致验收讨论被过程反思挤占，或者改进建议缺少后续跟进。
从迭代节奏看，评审处在几个环节的衔接位置。迭代规划阶段确定迭代目标和验收标准，每日跟进阶段持续暴露进度与风险，评审阶段对这两者的结果做一次集中确认，评审结论又成为下一次迭代规划的输入。评审不是孤立的质量关卡，它依赖规划和跟进阶段留下的信息：验收标准不清晰，评审就缺少判定依据；日常进度不透明，评审时才发现大量工作未完成。
本文聚焦具体迭代运行中的评审操作，包括会前准备、会中执行、角色分工和结论处理。敏捷框架的理论体系、产品待办列表的梳理方法与优先级排序、技术集成与工具选型，属于其他主题的范围，本文不展开。读者可以把本文当作一份操作手册，按章节顺序准备和执行一次评审。
评审前要准备什么：范围、准入与材料
评审质量很大程度上由会前准备决定。准备工作的目标是让会议有明确的讨论对象、可判定的标准和可演示的环境，避免会上临时确认范围或争论验收口径。
确定评审范围
评审范围以本次迭代的目标和工作项清单为基础。组织者需要列出本迭代承诺完成的需求、任务和缺陷修复项，标注每项当前的状态，并区分“已完成待评审”“未完成”“已取消或移出”三类。范围确定后提前发给参与者，让每个人知道会上要检查哪些内容。范围之外的工作项，即使有进展，也不占用评审时间。
确认准入条件
进入评审的工作项需要满足两个条件：有可演示的成果，验收标准已明确。可演示成果指能在演示环境中运行、操作或查看的增量，包括功能、界面、接口响应或修复后的缺陷表现。验收标准应在迭代规划时与团队达成一致，如果某项工作的验收标准缺失或模糊，应在会前补齐，无法补齐的则标记为“有条件评审”，在会上说明缺口。
准备材料与环境
会前需要准备的材料包括：迭代目标说明、工作项清单及状态、每项的验收标准、演示环境与测试数据、必要的验证证据（如测试记录、构建结果）。演示环境要提前验证可用，测试数据要覆盖主要演示路径，避免会上因环境问题中断。涉及多个交付者的，提前约定演示顺序和时长。
通知参与角色与时间
评审需要产品负责人、开发与测试人员、迭代负责人和关键干系人参加。会前发出通知，写明时间、时长、议程和需要各自准备的内容。对干系人，可以提前说明本次评审涉及的业务范围，便于他们带着具体反馈参会。
| 准备项 | 具体内容 | 完成标志 |
|---|---|---|
| 评审范围 | 迭代目标、工作项清单、状态分类 | 范围清单已发出，参与者无异议 |
| 准入条件 | 可演示成果、明确的验收标准 | 每项工作标注准入判定结果 |
| 材料与环境 | 验收标准、演示环境、测试数据、验证证据 | 演示路径可走通 |
| 参与人与时间 | 角色名单、议程、时长 | 通知已发出并确认参会 |
评审会怎么开：从演示到逐项判定的操作步骤
评审会按固定顺序推进，每个步骤都有明确的输入、动作和输出。控制节奏的关键是让判定围绕验收标准展开，把新想法和争议记录后另行处理。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 开场对齐 | 迭代目标、评审范围、议程 | 主持人说明本次评审目标和判定规则 | 参与者对范围和规则达成一致 | 无人对评审范围提出补充 |
| 成果演示 | 可运行增量、演示环境 | 交付者按顺序演示，说明实现范围 | 每项成果的实际表现被看到 | 范围内工作项均已演示或说明无法演示的原因 |
| 逐项判定 | 验收标准、演示结果、验证证据 | 对照标准逐条确认，给出判定 | 通过、有条件通过、不通过及原因 | 每项工作都有明确判定 |
| 反馈收集 | 干系人意见 | 记录反馈，区分新需求与缺陷 | 反馈清单及分类 | 反馈已记录并标注类型 |
| 结论确认 | 判定结果、反馈清单 | 复述结论，明确后续责任人和时点 | 评审结论与行动项 | 参与者确认结论无遗漏 |
开场对齐迭代目标与评审规则
主持人先用几分钟复述迭代目标和本次评审范围，说明判定规则：每项工作对照验收标准给出通过、有条件通过或不通过，判定依据以演示结果和验证证据为准；会上提出的新想法记录为反馈，不在现场展开方案讨论。规则说清楚，后续判定会顺畅很多。
演示成果并逐项判定
交付者按约定顺序演示，先说明该项工作的验收标准，再展示实际成果。演示应尽量使用真实数据和可操作路径，让参与者看到功能如何被使用。判定时对照验收标准逐条确认，避免用“看起来差不多”代替具体判断。有条件通过适用于主要功能可用但存在明确遗留问题的情况，需要写清遗留内容和补齐时点；不通过则要记录原因和复评安排。
收集反馈并区分类型
干系人的反馈是评审的重要输入，但需要分类处理。属于验收标准范围内未满足的，归为缺陷或不通过原因；超出本次范围的新想法，归为新需求，进入待办列表等待后续评估。现场分类可以避免新需求挤占验收讨论，也避免缺陷被当作改进建议搁置。
结束前确认结论与责任人
会议结束前，主持人复述每项工作的判定结果、未通过项的原因、有条件通过项的遗留内容，以及每项后续动作的责任人和时点。参与者当场确认，有异议的当场澄清。结论确认后，评审记录即可作为后续跟踪的依据。
角色与交付物：谁在评审中做什么
评审涉及多个角色，职责清晰可以减少重复确认和遗漏。下表按角色列出主要职责和交付物。
| 角色 | 主要职责 | 交付物 | 交接对象 |
|---|---|---|---|
| 产品负责人 | 确认验收标准，判定业务价值是否达成，决定有条件通过项的取舍 | 验收判定意见、需求优先级调整建议 | 迭代负责人、开发团队 |
| 开发人员 | 演示可运行成果，说明实现范围和已知限制 | 演示环境、功能增量、技术说明 | 评审参与者 |
| 测试人员 | 提供测试执行结果和缺陷验证证据，确认修复项的实际表现 | 测试记录、缺陷状态、验证结论 | 产品负责人、开发人员 |
| 迭代负责人（Scrum Master 等） | 组织会议、控制节奏、记录判定结果和行动项 | 评审记录、行动项清单 | 全体参与者、下一次迭代规划 |
| 干系人 | 提供业务反馈，确认需求方向是否符合预期 | 反馈清单、新需求线索 | 产品负责人 |
角色之间有几处关键交接：测试人员的验证结论是产品负责人判定的依据之一；产品负责人对有条件通过项的取舍，决定该项工作进入修复还是延后；迭代负责人整理的评审记录和行动项，是下一次迭代规划的输入。交接关系明确后，评审结论才能顺畅地转化为后续工作。
未通过项与未完成工作怎么处理
评审结论的价值在于落地。未通过项和未完成工作需要重新评估，再决定去向，默认自动结转到下个迭代会让待办列表逐渐失真，也会掩盖迭代承诺与实际交付之间的差距。
未通过项的处理
未通过项要记录三件事：不通过的具体原因、修复责任人、复评时点。原因应指向验收标准中的具体条目，便于修复后对照复评。复评可以在修复完成后单独安排，也可以并入下一次评审，取决于问题的影响范围。修复期间该项工作保持未完成状态，不进入已完成统计。
未完成工作的重新评估
未完成工作先回到待办列表，由产品负责人和团队一起重新评估优先级、工作量和依赖关系，再决定是否放入下个迭代。评估时要考虑：这项工作是否仍然有价值，拆分后能否缩小交付粒度，是否与其他工作存在依赖。重新评估的结果可能是进入下个迭代、拆分后部分进入、延后或取消，每种结果都需要记录理由。
有条件通过项的跟踪
有条件通过项需要明确遗留内容和补齐时点，指定责任人跟踪。补齐完成后补充验证证据，再将状态更新为通过。遗留内容如果影响业务使用，应在评审结论中标注风险，让干系人知情。
结论同步到工作项与待办
评审结束后，判定结果要同步到工作项状态，行动项进入待办列表并分配责任人。状态更新和待办调整应在会后尽快完成，避免结论停留在会议记录中。团队使用工作项管理工具时，可以在评审记录中直接关联对应工作项，把判定结果、原因和后续动作写在同一处，方便复评时追溯。ONES 的敏捷研发管理覆盖迭代规划、迭代开发、缺陷追踪和迭代进度跟进等场景，工作项可规划至迭代并分配负责人，缺陷可提交至对应项目或迭代跟踪修复情况；评审结论落地时，可以借助这些工作项状态和缺陷跟踪能力记录判定与后续动作，具体配置以团队实际使用的版本为准。
示例：一次迭代评审的完整记录
以下为演示情景，用于说明评审从准备到结论落地的过程，不代表真实客户案例。
示例背景
某团队的两周迭代目标是完成订单查询功能的三个子项：查询条件筛选、结果列表分页、导出按钮。迭代范围包括这三项需求和一个历史缺陷修复。迭代结束时，筛选和分页已完成，导出按钮完成界面但导出文件格式未按验收标准实现，历史缺陷已修复待验证。
会前准备与准入判定
迭代负责人整理工作项清单：筛选、分页标记为“已完成待评审”，导出按钮标记为“有条件评审”，缺陷修复标记为“已完成待验证”。验收标准在迭代规划时已确认，演示环境提前验证可用，测试数据覆盖筛选组合和分页边界。通知发出后，产品负责人和两名干系人确认参会。
会中演示与逐项判定
开发人员依次演示：筛选功能按验收标准逐条操作，判定通过；分页功能演示边界数据，判定通过；导出按钮演示时发现导出文件为纯文本而非约定的表格格式，产品负责人判定有条件通过，遗留内容为文件格式，补齐时点定在迭代结束后三个工作日内；缺陷修复由测试人员提供验证记录，判定通过。干系人提出希望增加按日期范围筛选，主持人记录为新需求，进入待办列表。
未通过项与未完成工作的处理
导出按钮的格式问题由原开发人员负责修复，三个工作日后复评，复评通过前该项不计入已完成。新需求由产品负责人评估优先级后决定是否纳入下个迭代。评审记录中关联了对应工作项，判定结果、遗留内容和复评时点均已写入。
示例可迁移的规律
这个示例体现了几条可迁移的做法：会前按准入条件分类工作项，让会议时间集中在需要判定的内容上；判定对照验收标准逐条进行，避免笼统评价；新需求与缺陷分开记录，防止范围蔓延；有条件通过项写清遗留内容和时点，保证结论可跟踪。示例的适用边界在于：团队规模、迭代长度和工具使用方式不同，具体会议时长和记录形式需要按实际情况调整。
完成检查：评审是否做到位
评审结束后，可以用以下清单逐项核对。清单中的阻断项如果出现，说明本次评审需要补充或重做。
| 检查项 | 核对内容 | 判定 |
|---|---|---|
| 范围覆盖 | 评审范围覆盖本次迭代目标涉及的全部工作项 | 是 / 否 |
| 验收判定 | 每项成果都有对照验收标准的判定和证据 | 是 / 否 |
| 结论去向 | 未通过项和未完成工作已重新评估并明确去向 | 是 / 否 |
| 状态同步 | 结论已同步到工作项状态和待办列表 | 是 / 否 |
| 角色通知 | 相关角色已收到结论和行动项 | 是 / 否 |
需要特别关注的阻断项有三个：工作项缺少验收标准，导致无法判定；没有可演示成果，评审退化为口头汇报；结论未落地到工作项和待办，后续无人跟踪。出现任一情况，应先补齐再确认评审完成。清单核对通过后，评审记录归档，作为下一次迭代规划和回顾的输入。
常见问题
迭代评审和迭代回顾可以合并成一个会开吗？
可以合并安排在同一时间段，但建议分成两个环节，各自保留独立的议程和产出。评审环节聚焦成果与验收，回答本次迭代交付了什么、是否达到约定标准；回顾环节聚焦过程与改进，回答协作方式哪里需要调整。
合并时容易出现两个问题：验收讨论被过程反思挤占，导致部分工作项没有明确判定；改进建议缺少后续跟进。如果时间紧张，可以先完成评审并记录结论，再单独安排回顾，或把回顾缩短为聚焦一两个关键改进点。
验收标准在迭代规划时没有写清楚，评审前还来得及补吗？
来得及，但需要在会前完成，并由产品负责人确认。补齐的方式是针对该项工作列出可观察、可验证的判定条目，例如功能在什么条件下表现为什么结果、边界数据如何处理。补齐后同步给开发和测试人员，确保演示和验证围绕同一套标准进行。
如果会前确实无法补齐，可以把该项标记为“有条件评审”，在会上说明标准缺口和补齐计划，判定结果按有条件通过处理，写清遗留内容和复评时点。缺少验收标准的工作项不宜直接判定通过。
评审会上干系人提出的新需求，应该当场讨论方案吗？
不建议当场展开方案讨论。评审的时间应该留给验收判定，新需求现场讨论方案会挤占判定时间，也容易让范围在会议中悄悄扩大。
更合适的做法是记录为新需求，标注提出人和业务背景，会后由产品负责人评估优先级，再决定是否进入待办列表等待后续规划。如果新需求与本次迭代目标直接相关且影响验收结论，可以当场说明影响，但仍把方案讨论放到会后。
未完成的工作直接放到下个迭代，会有什么问题？
默认自动结转会让待办列表逐渐失真，也会掩盖迭代承诺与实际交付之间的差距。未完成工作回到待办后，需要由产品负责人和团队一起重新评估优先级、工作量和依赖关系，再决定去向。
评估结果可能是进入下个迭代、拆分后部分进入、延后或取消，每种结果都记录理由。拆分时可以考虑缩小交付粒度，让下个迭代的承诺更可控。重新评估的过程本身也是下一次迭代规划的输入。
团队规模小、角色由一人兼任时，评审分工怎么安排？
角色可以兼任，但职责需要在会上明确说出来。例如同一人既承担开发又承担测试时，演示环节说明实现范围，判定环节提供验证证据，两个动作分开进行，避免自己演示自己判定、缺少核对。
产品负责人的验收判定职责建议由对该业务结果负责的人承担，即使他同时兼其他角色，也要在结论确认环节明确表达判定意见。迭代负责人的会议组织和记录职责可以轮换，但每次评审都要有人负责收口结论和行动项。
