迭代评审要回答的核心问题是：这个迭代承诺了什么、实际交付了什么、没完成的工作怎么办、过程中暴露了哪些需要改进的问题。本文按会前准备、会上核对、结论形成、会后跟踪四步展开，给出可直接照做的流程、未完成项处置判断表、角色交付物对照表、完整示例和完成检查清单，帮助迭代负责人或产品负责人把评审从一次会议变成可跟踪的闭环。
要点总览（TL;DR）
- 迭代评审围绕四类判断展开：迭代目标是否达成、完成项是否有证据、未完成项如何处置、过程问题是否转为改进项；完成标志是形成有负责人和时限的结论清单。
- 操作按会前准备、会上核对、结论形成、会后跟踪四步推进，每步都有明确输入、动作、输出和完成标志，材料不齐和跟踪缺失是最常见的两个薄弱环节。
- 未完成项应逐项重新评估，归入仍需要继续做、优先级下降暂缓、拆分后继续、关闭四类之一，判断顺序先看价值、再看依赖、最后看剩余工作量，避免默认结转导致范围膨胀。
- 决策权与记录责任分开：产品负责人和迭代负责人承担决策，记录人如实记录；小团队可合并角色，但会前材料准备和会上主持不宜由同一人同时承担。
- 结论清单按事项、类型、负责人、时限、状态记录，跟踪节奏与迭代节奏对齐，复查时重点处理到期未完成和状态长期不变的事项。
迭代评审要回答哪几个问题
迭代评审围绕四类判断展开：迭代目标是否达成、完成项是否有证据支撑、未完成项如何处置、过程问题是否转化为改进项。这四个判断决定了会议材料、议程和结论清单的内容。评审的完成标志是形成一份有负责人和时限的结论清单，并同步给相关角色，会议本身结束不算完成。
四步流程如下，每一步都明确输入、动作、输出和完成标志。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 会前准备 | 迭代目标、迭代范围、工作项状态、完成项证据、遗留问题记录 | 负责人整理迭代范围清单，逐项标注完成状态并附证据；汇总未完成项及原因；收集过程问题 | 评审材料包：范围清单、完成项证据、未完成项列表、问题记录 | 材料在会前发出，参会人可提前阅读并补充 |
| 会上核对 | 评审材料包 | 按迭代目标逐项核对完成项与证据；对未完成项逐项讨论处置；对过程问题确认是否转为改进项 | 逐项核对记录：确认结论、争议点、待定事项 | 每个范围项都有明确结论，无悬空项 |
| 结论形成 | 核对记录 | 整理结论清单，写明事项、类型、负责人、时限；改进项单独列出 | 结论清单与改进项清单 | 每项结论都有负责人和时限，无“待定负责人” |
| 会后跟踪 | 结论清单 | 按节奏检查状态，到期复查，未闭环项进入下一迭代运行跟踪 | 状态更新记录、复查记录 | 所有事项状态为完成或已明确转入下一迭代 |
四步中最容易被压缩的是会前准备和会后跟踪。材料不齐会导致会上逐项追问状态，结论没有负责人和时限则会让清单停留在文档里。把这两步做扎实，会议时间通常可以控制在一小时内。
未完成工作如何重新评估而不是默认结转
未完成项默认结转会让迭代范围持续膨胀，也会掩盖估算偏差和依赖问题。评审时应对每个未完成项重新判断，给出四类处置结论之一，并记录判断依据。
| 处置类型 | 适用情形 | 判断依据 | 记录方式 |
|---|---|---|---|
| 仍需要，继续做 | 价值未变，依赖已具备，剩余工作量可在下一迭代内完成 | 业务价值、依赖状态、剩余工作量估算 | 进入下一迭代范围，注明剩余工作量和预计完成时间 |
| 优先级下降，暂缓 | 业务价值降低或被更高优先级事项挤占 | 与当前迭代目标和其他待办的价值比较 | 退回待办列表，注明暂缓原因和重新评估时点 |
| 拆分后继续 | 剩余工作量大或包含多个可独立交付的部分 | 剩余工作量、可拆分粒度、依赖关系 | 拆成若干子项，明确哪些进入下一迭代、哪些留在待办 |
| 关闭 | 需求取消、已被其他工作覆盖或不再具备价值 | 需求来源确认、替代方案确认 | 标记关闭并写明原因，保留记录便于回溯 |
判断顺序建议先看价值，再看依赖，最后看剩余工作量。价值判断由产品负责人主导，依赖和剩余工作量由开发与测试代表提供信息。处置结论要写进结论清单，进入下一迭代范围的事项同时更新迭代计划，避免评审结论和实际计划两张皮。
对于反复出现的未完成项，评审时应单独讨论原因：是估算偏乐观、依赖未就绪，还是范围在迭代中被临时扩大。原因不同，改进项也不同，这条信息应进入改进项清单而不是只记录“未完成”。
评审会上的角色分工与交付物
评审会的效率取决于角色是否清楚自己准备什么、决策什么、记录什么。决策权和记录责任要分开：决策由产品负责人和迭代负责人承担，记录人负责如实记录结论，不替决策者拍板。
| 角色 | 会前输入 | 会上职责 | 会后交付物 |
|---|---|---|---|
| 产品负责人 | 迭代目标、需求价值判断、待办优先级 | 确认完成项是否满足目标；对未完成项做价值判断和处置决策 | 未完成项处置结论、下一迭代范围建议 |
| 迭代负责人 | 迭代范围清单、工作项状态、完成项证据 | 主持议程，逐项核对，控制节奏；确认过程问题 | 评审材料包、结论清单初稿 |
| 开发代表 | 完成项的技术证据、剩余工作量估算、依赖状态 | 说明完成情况和证据；对未完成项提供工作量和依赖信息 | 剩余工作量估算、技术风险说明 |
| 测试代表 | 测试结果、缺陷状态、质量风险 | 确认完成项的质量证据；提出质量相关改进项 | 质量结论、测试相关改进项 |
| 记录人 | 评审材料包 | 记录逐项结论、争议点、待定事项和负责人 | 结论清单、改进项清单、会议纪要 |
小团队中角色可以合并，例如迭代负责人兼任记录人，但决策与记录仍应分开表达：谁做的决策写清楚，谁记录的也写清楚。角色合并时，会前材料准备和会上主持不宜由同一人同时承担，否则容易在核对环节跳过证据检查。
一个完整评审示例：从材料到结论清单
以下为演示情景，用于说明材料组织和结论写法，不代表真实项目数据。
迭代背景与范围。某团队进行为期两周的迭代，迭代目标为“完成订单查询接口改造并上线灰度”。迭代范围包含五项：接口改造、灰度发布配置、回归测试、监控告警补充、文档更新。迭代结束时，前三项完成，监控告警补充完成一半，文档更新未开始。
会前材料清单示例。
- 迭代目标与范围清单：五项工作项及各自状态。
- 完成项证据：接口改造的合并记录和自测结果、灰度配置的变更记录、回归测试的通过报告。
- 未完成项列表：监控告警补充（剩余两个告警规则）、文档更新（未开始），附原因说明。
- 过程问题记录：灰度配置依赖的环境申请延迟两天；回归测试中发现两处历史缺陷，已修复但占用了计划外时间。
会上逐项核对过程。主持人按范围清单逐项过：前三项对照证据确认完成；监控告警补充由开发代表说明剩余工作量约半天，产品负责人判断该告警对灰度上线有必要，结论为“仍需要，继续做”，进入下一迭代；文档更新由产品负责人判断可随下一迭代的功能文档一并完成，结论为“优先级下降，暂缓”，退回待办并注明重新评估时点。过程问题中，环境申请延迟转为改进项，负责人为迭代负责人，时限为下一迭代开始前梳理环境申请流程；计划外缺陷占用时间转为改进项，负责人为测试代表，时限为两周内给出回归测试范围建议。
结论清单与改进项写法。结论清单按“事项、类型、负责人、时限、状态”记录，例如：“监控告警补充剩余两个规则｜未完成项处置｜开发代表｜下一迭代第3天｜待开始”。改进项单独成表，写明问题描述、改进动作、负责人和完成时限，避免只写“加强环境申请管理”这类无法验收的表述。
评审结论如何跟踪到闭环
结论清单的价值在于被持续检查。建议为清单设定固定字段和复查节奏，让每项结论都有明确的状态推进路径。
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 事项 | 一句话描述结论内容，可独立理解 | 监控告警补充剩余两个规则 |
| 类型 | 完成确认、未完成项处置、改进项、风险 | 未完成项处置 |
| 负责人 | 具体到人，不写团队或角色代称 | 开发代表姓名 |
| 时限 | 具体日期或迭代内时点 | 下一迭代第3天 |
| 状态 | 待开始、进行中、已完成、已转入下一迭代、已关闭 | 待开始 |
跟踪节奏建议与迭代节奏对齐：每日站会检查进行中事项，迭代中期做一次清单复查，下一迭代评审前确认上一轮结论是否全部闭环。复查时重点看两类事项：到期未完成的，需要说明原因并重新约定时限；状态长期不变的，需要判断是否应关闭或调整负责人。
改进项与下一迭代计划的衔接方式是：改进项中涉及流程调整的，在下一迭代计划会上确认落地动作；涉及工作项变更的，直接进入待办列表并标注来源为评审改进项。这样下一轮评审时可以对照检查改进是否生效。
评审材料、结论清单和跟踪状态需要有承载的地方。ONES 可以用工作项记录未完成项处置和下一迭代范围，用文档沉淀评审材料与结论清单，并通过状态字段跟踪负责人和时限，使评审结论在迭代运行中持续可见。是否采用工具承载取决于团队已有的协作习惯，关键是清单字段完整、复查时点固定。
评审完成检查清单
以下清单用于会前自检和会后验收，逐项判断通过与否。
- 会前材料是否齐全：迭代范围清单、完成项证据、未完成项列表、过程问题记录是否在会前发出。
- 完成项是否有证据支撑：每项完成工作是否有可查看的记录、结果或报告，而非仅口头确认。
- 未完成项是否逐项有处置结论：每项是否归入仍需要、优先级下降、拆分后继续、关闭四类之一，并写明依据。
- 改进项是否有人和时限：每项改进是否有具体负责人和可验收的完成时限，表述是否可判断完成。
- 结论是否已同步给相关角色：结论清单和改进项清单是否发给参会人及相关干系人，待办列表和下一迭代计划是否已更新。
- 跟踪安排是否明确：复查时点、检查方式、状态更新责任人是否已约定。
六项全部通过，可以认为本次迭代评审完成；存在未通过项时，应在会后一个工作日内补齐，并在下一次复查时优先检查。
常见问题
迭代评审和迭代回顾有什么区别，能不能合并开？
两者关注对象不同：评审看的是迭代产出本身，即目标是否达成、完成项是否有证据、未完成项如何处置；回顾看的是团队协作过程，即哪些做法有效、哪些环节需要调整。合并开会时容易把产出核对和过程讨论混在一起，导致未完成项没有逐项结论。
如果迭代周期短、团队规模小，可以连续安排两段议程，先完成产出核对并形成结论清单，再进入过程讨论。关键是两类输出分开记录：产出结论进入结论清单，过程改进进入改进项清单，各自有负责人和时限。
迭代评审需要哪些人参加，客户或业务方要不要到场？
常规参会角色包括产品负责人、迭代负责人、开发代表、测试代表和记录人。产品负责人对未完成项做价值判断和处置决策，迭代负责人主持议程并核对范围，开发与测试代表提供证据、剩余工作量和依赖信息。
客户或业务方是否到场取决于评审目的。如果迭代产出需要业务方确认验收或调整优先级，邀请其参加对应环节即可，不必全程参与。涉及内部估算偏差和过程问题的讨论，可以放在业务方离场后进行，避免讨论变形。
未完成项在评审前由谁整理，整理到什么程度？
通常由迭代负责人整理未完成项列表，开发代表补充剩余工作量和依赖状态，产品负责人准备价值判断意见。整理程度以会上能直接讨论处置为准：每项写明当前状态、未完成原因、剩余工作量估算和依赖情况。
如果某项的剩余工作量在会上才临时估算，讨论容易失焦。建议会前把估算信息补齐，会上只做处置决策。反复出现估算偏差的，应把原因分析转为改进项，而不是每次评审重复讨论同一类问题。
评审结论清单需要长期保留吗，保留多久合适？
建议保留。结论清单记录了每个迭代的范围变化、未完成项处置理由和改进项来源，是后续复盘估算准确性、跟踪改进是否生效的依据。保留周期可与团队的迭代档案管理要求一致，至少覆盖若干个迭代，便于对照检查。
保留时注意两点：关闭类结论要写明原因，便于日后回溯需求取消或替代的背景；改进项要能对应到后续迭代中的落地动作，否则清单会积累大量无法验收的条目。
评审会上对某项完成情况有争议，当场定不下来怎么办？
可以标记为待定事项，但必须同时约定三件事：由谁在什么时点前给出结论、需要补充什么证据、结论出来后同步给谁。待定事项应进入结论清单并标注状态，不能只停留在会议记录里。
如果争议涉及验收标准本身不清晰，说明迭代开始时的目标定义存在问题，这类情况适合转为改进项，在下一迭代明确完成标准。评审的完成标志是每个范围项都有明确结论，待定事项也属于明确结论的一种，前提是有人和时限。
