迭代评审的依据由四类材料构成：迭代目标与承诺范围、实际执行证据、质量与验收证据、上一轮评审的遗留项与改进动作跟踪。评审时按“目标—承诺—实际—差异—结论”的顺序逐项核对，对未完成工作逐条重新评估，明确延期、拆分、退回待办还是取消，不默认自动结转到下一迭代。评审结论和未完成项处置需要形成可跟踪的记录，ONES可承载工作项状态与评审文档的关联管理。
要点总览（TL;DR）
- 迭代评审的依据分四类：迭代目标与承诺范围、实际执行证据、质量与验收证据、上一轮评审的遗留项与改进动作跟踪，四类材料分别回答承诺了什么、实际做了什么、质量是否达标、上轮问题是否闭环。
- 评审前1至2个工作日完成取数，由迭代负责人牵头，开发与测试分别提供状态、缺陷、测试与验收数据，差异项预标记清单提前发给参会人，会上只做核对和决策。
- 会议按“目标—承诺—实际—差异—结论”五步推进，每个未完成工作项当场给出延期、拆分、退回待办或取消四种处置之一，不默认自动结转到下一迭代。
- 评审记录按“工作项—原承诺—实际结果—处置方式—责任人—期限”逐条落库，未完成项转为可跟踪工作项，下一轮评审开场先回看上次结论的执行状态。
- 评审结束后用检查表自检：依据是否齐全、未完成项是否全部有处置、结论是否都有责任人和期限、上轮遗留是否逐项核对，缺失部分补齐即可，无需重开评审会。
迭代评审要准备哪些依据：一张清单说清
评审依据的作用是让每个结论都有可核对的事实支撑。四类材料分别回答四个问题：这一轮承诺了什么、实际做了什么、质量是否达标、上一轮的问题是否闭环。缺少任何一类，评审都容易变成口头汇报。
| 依据类别 | 具体材料 | 最低内容要求 | 支撑的评审结论 |
|---|---|---|---|
| 目标与承诺范围 | 迭代目标说明、已承诺的待办事项清单、每项的验收标准 | 目标可判断是否达成；每个承诺项有明确验收口径 | 目标达成与否、承诺范围是否发生变更 |
| 实际执行证据 | 工作项状态与完成记录、缺陷与阻塞记录、代码与构建提交记录 | 状态为评审时点的真实状态；阻塞项有原因和持续时间 | 哪些完成、哪些未完成、差异出在哪个环节 |
| 质量与验收证据 | 测试结果、验收结论、遗留问题清单 | 测试覆盖承诺项；验收结论明确通过或不通过；遗留问题有严重程度 | 完成项是否真正可交付、遗留问题是否影响发布 |
| 上轮遗留与改进项 | 上一轮评审的未完成项处置记录、改进动作及跟踪状态 | 每项有责任人和当前状态 | 上轮结论是否执行、改进是否有效 |
四类依据与结论的对应关系是固定的：目标与承诺用来判断“应该做成什么”，执行证据用来判断“实际做成什么”，质量证据用来判断“做成的是否可用”，上轮遗留用来判断“之前的决定是否兑现”。会上出现争议时，回到对应类别的材料核对，而不是靠记忆或印象裁决。
评审前怎么收集和核对依据
准备工作建议在评审会前1至2个工作日完成，由迭代负责人牵头，开发、测试各自提供本领域数据。核心原则是会上只做核对和决策，不在会议现场翻找数据。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 锁定承诺基线 | 迭代开始时确认的待办事项与验收标准 | 导出承诺清单，确认迭代期间的范围变更已记录在案 | 承诺基线清单（含变更标注） | 清单与迭代启动记录一致，变更项有变更说明 |
| 2. 取执行数据 | 工作项状态、缺陷记录、阻塞记录、代码与构建提交 | 按承诺项逐条对照实际状态，统计完成、进行中、未开始 | 执行状态对照表 | 每个承诺项都有明确状态，无“状态不明”项 |
| 3. 取质量数据 | 测试结果、验收记录、遗留问题清单 | 核对测试是否覆盖全部承诺项，验收未通过项单独列出 | 质量与验收汇总 | 完成项均有测试或验收结论，未通过项有原因 |
| 4. 预标记差异项 | 上述三份材料 | 标记未完成、范围变更、验收未通过三类差异，附初步原因 | 差异项预标记清单 | 每个差异项有类别、原因和涉及的工作项 |
| 5. 汇总上轮遗留 | 上轮评审记录 | 逐项核对处置动作的执行状态 | 上轮遗留跟踪表 | 每项标注已闭环或仍未闭环 |
核对口径要统一：工作项“完成”以验收标准满足为准，不以开发自测通过为准；缺陷数量按评审时点的未关闭数统计，并注明严重程度分布；范围变更以迭代期间正式记录的变更为准，口头调整不计入。准备完成的判断标志是：差异项预标记清单已发给参会人，且每个差异项都能在会上直接进入处置讨论，无需补充取数。
评审会上按什么顺序核对并形成结论
会议按“目标—承诺—实际—差异—结论”五步推进，每一步都有明确的产出，避免跳步讨论。
第一步，回顾目标。由产品负责人复述迭代目标，确认目标本身在迭代期间未发生实质变化。若目标已变更，先记录变更原因，再进入后续核对。
第二步，核对承诺。逐条过承诺清单，确认范围基线，包括迭代期间已记录的变更项。
第三步，对照实际。按承诺项逐一说明实际状态，完成项展示验收或测试结论，未完成项说明进展和阻塞原因。
第四步，聚焦差异。对预标记的差异项逐条讨论，范围变更项确认是否接受，验收未通过项确认返工范围。
第五步，形成结论。对每个未完成工作项当场给出处置，四种方式选其一：
- 延期：工作仍在本迭代目标内、剩余工作量可控，明确新的完成时间并保留在原迭代或顺延至指定迭代。
- 拆分：已完成部分可独立交付，剩余部分拆为新工作项，分别明确归属。
- 退回待办：优先级或前提条件发生变化，放回产品待办列表重新排序，不在本迭代继续。
- 取消：需求失效或价值不再成立，记录取消原因后关闭。
范围变更和验收未通过项同样要落记录：变更项写明变更内容、提出人和确认人；验收未通过项写明未通过的具体条款和返工责任人。会议结论的记录格式建议为“工作项—原承诺—实际结果—处置方式—责任人—期限”，每条一行，当场确认，不留“会后再定”的模糊项。
角色分工与各自交付物
评审的效率取决于会前分工是否清晰。以下分工适用于常见的十人左右研发团队，团队规模或组织结构不同时可合并角色，但决策权归属保持不变。
| 角色 | 准备阶段职责 | 会议阶段职责 | 交付物 |
|---|---|---|---|
| 产品负责人 | 确认承诺基线与验收标准，整理范围变更记录 | 复述目标，确认范围调整，决定退回待办与取消项 | 承诺基线清单、范围变更记录 |
| 迭代负责人 | 牵头组织准备，汇总执行数据与差异预标记清单 | 主持核对顺序，记录结论与处置 | 差异项预标记清单、评审记录 |
| 开发人员 | 更新工作项状态，说明阻塞原因，提供提交记录 | 说明未完成项的实际进展与技术原因 | 工作项状态更新、阻塞说明 |
| 测试人员 | 提供测试结果、验收结论与遗留问题清单 | 说明验收未通过项的具体问题 | 质量与验收汇总 |
| 干系人 | 了解迭代目标与承诺范围 | 提出关注问题，确认与其相关的范围调整 | 关注问题清单（如有） |
决策权归属需要明确：范围调整、未完成项的退回待办与取消由产品负责人确认；延期与拆分的技术可行性由迭代负责人和开发共同判断，最终处置由产品负责人拍板；验收是否通过以测试结论和验收标准为依据，产品负责人确认。干系人提供输入，不替代产品负责人做范围决策。
一个完整示例：两小时评审会怎么开
以下为演示情景，用于说明依据如何被使用。某团队进行两周迭代评审，迭代目标为“上线订单导出功能并完成支付流程的性能优化”，承诺范围共12个工作项。
目标与承诺。产品负责人复述目标，确认迭代期间新增一项“导出字段增加客户等级”的变更，已有变更记录，计入承诺基线。
实际与差异。执行数据显示：9项完成，2项进行中，1项未开始。质量证据显示：完成的9项中8项验收通过，1项“支付回调重试”验收未通过，原因是超时场景未覆盖；遗留问题清单中有2个中等级缺陷待修复。差异预标记清单列出4项：1项验收未通过、2项未完成、1项范围变更已并入承诺。
逐条处置。验收未通过的“支付回调重试”定为延期，测试补充超时场景用例，开发在3个工作日内修复并重新验收；进行中的“导出模板配置”拆分为已完成的基础配置和剩余的自定义模板两部分，后者转入下一迭代；未开始的“导出日志审计”退回待办，由产品负责人重新评估优先级；范围变更项确认接受，已包含在完成项中。
会后动作。评审记录按“工作项—原承诺—实际结果—处置方式—责任人—期限”逐条落库，4项处置全部转为可跟踪工作项，指定责任人和完成时间。下次评审开场先回看这4项的执行状态。
评审记录如何沉淀并在工具中跟踪
评审记录的价值在于可回看、可追责。一条完整的评审记录至少包含以下字段：
| 字段 | 内容要求 |
|---|---|
| 结论 | 目标是否达成、承诺项完成情况的一句话总结 |
| 处置方式 | 延期、拆分、退回待办、取消之一，或“已完成” |
| 责任人 | 单项唯一责任人，便于跟踪 |
| 期限 | 具体日期，延期项写新完成时间 |
| 关联工作项 | 指向原承诺项或拆分后的新工作项 |
未完成项与改进项应转为可跟踪的工作项，而不是停留在会议纪要的文字里。转为工作项后，状态变化可以被持续观察，下一轮评审时直接按上次记录的关联工作项回看执行结果，判断上轮结论是否兑现。
ONES在这类场景中的作用是承载评审结论与工作项的关联：评审记录以文档形式留存，结论中的处置项对应到具体工作项，工作项状态随执行更新，下一轮评审时可按上次记录逐项回看。这样评审依据、结论和执行状态处在同一条链路上，减少会前重新收集数据的工作量。
完成检查：这次评审算不算做到位
评审结束后，用以下清单自检，全部满足才算完成：
- 四类依据齐全：目标与承诺、执行证据、质量与验收证据、上轮遗留跟踪均有材料。
- 每个承诺项都有明确状态，差异项均有类别和原因。
- 每个未完成工作项都有四种处置之一，无“待定”项。
- 范围变更项和验收未通过项均有记录，写明内容和确认人。
- 每条结论都有责任人和具体期限，并已落库为可跟踪记录。
- 上轮遗留项已逐项核对，未闭环项已说明原因并重新安排。
通过标准是上述各项全部满足。出现以下情形需要返工：存在状态不明的工作项；未完成项只记录“继续跟进”而无具体处置；结论缺少责任人或期限；上轮遗留项未核对。返工范围限于缺失部分，补齐后无需重开评审会，由迭代负责人确认即可。
常见问题
迭代评审和迭代回顾有什么区别，依据能共用吗？
两者关注对象不同。迭代评审围绕交付物本身，核对承诺范围与实际结果，判断完成项是否可交付、未完成项如何处置；迭代回顾围绕团队的工作方式，讨论流程、协作和改进动作。依据可以部分共用，执行数据、质量证据和上轮遗留跟踪在两边都会用到，但评审更依赖承诺基线与验收标准，回顾更依赖过程记录和团队反馈。实际操作中可以先开评审再开回顾，评审产出的未完成项处置和改进项，正好成为回顾的输入。
迭代中途发生范围变更，评审时应该按原承诺还是变更后的范围核对？
按变更后的范围核对，但要把变更本身作为独立事项记录。准备阶段锁定承诺基线时，就应把迭代期间正式记录的变更项标注在清单上，写明变更内容、提出人和确认人。评审会上先确认变更是否被接受，再按接受后的范围判断完成情况。口头调整不计入承诺基线，如果确实发生了口头变更，应在评审时补记并明确是否追认，避免下一轮出现口径不一致。
未完成的工作项选择延期还是退回待办，判断标准是什么？
看两件事：工作是否仍服务于本迭代目标，以及剩余工作量是否可控。仍在本迭代目标内、剩余工作量可控的，选延期，明确新的完成时间；已完成部分可独立交付、剩余部分需要单独安排的，选拆分；优先级或前提条件发生变化、本迭代内不再有价值的，退回待办重新排序；需求失效或价值不再成立的，记录原因后取消。四种处置由产品负责人确认，技术可行性由迭代负责人和开发共同判断。
团队规模较小、角色合并时，评审分工怎么调整？
角色可以合并，决策权归属保持不变。例如产品负责人与迭代负责人由一人兼任时，承诺基线的确认和会议主持由同一人完成，但范围调整、退回待办与取消的决策仍需明确记录由谁拍板，避免自己准备、自己决策、自己记录而缺少核对环节。测试职责由开发兼任时，验收结论应有独立于实现者的核对动作，至少保证验收标准在评审前被逐条对照过。合并后要在评审记录中写清每个结论的确认人。
评审记录只写在会议纪要里，会带来什么问题？
会议纪要适合留存讨论过程，不适合作为跟踪载体。处置项停留在文字里，状态变化无法被持续观察，下一轮评审时需要重新翻找和人工比对，容易出现遗漏或口径不一致。更稳妥的做法是把每条结论转为可跟踪的工作项，记录处置方式、责任人和期限，并与原承诺项建立关联。这样下一轮评审可以直接按上次记录的关联工作项回看执行结果，判断上轮结论是否兑现。
