迭代评审、迭代回顾和项目复盘都发生在迭代管理语境中，但回答的问题不同：评审看这一迭代交付了什么、是否符合预期；回顾看团队怎么工作、下个迭代改什么；复盘看整个项目为什么得到这个结果。本文按目的、输入、参与人、产出四个维度逐项对照，并说明三者在迭代周期中的衔接方式与常见混淆点。
要点总览（TL;DR）
- 迭代评审回答“这一迭代交付了什么、是否符合预期”，以可演示增量和验收标准为输入，产出接受结论与待办调整。
- 迭代回顾回答“团队怎么工作、下个迭代改什么”，输入是过程数据与协作观察，产出少量可执行的改进项。
- 项目复盘回答“整个项目为什么得到这个结果”，输入是项目目标、里程碑与各迭代记录，产出可复用的组织经验。
- 三者在迭代内通常先评审后回顾，评审结论进入下一迭代计划，回顾改进项进入跟踪，两者的记录共同成为项目复盘的输入。
- 三者不能互相替代：只评审不回顾问题会反复出现，只回顾不评审交付缺少外部确认，两者都做但不复盘项目经验难以沉淀。
一句话区分：三个会议各自回答什么问题
把三者放在一起时，最有效的区分主线是“各自回答什么问题”。问题不同，会议的准备材料、到场人员和结束时的产物就会自然分开。
迭代评审回答“这一迭代交付了什么、是否符合预期”。它以可演示的增量为中心，由产品负责人和团队向干系人展示完成情况，对照验收标准确认哪些工作被接受，收集反馈并据此调整待办。评审的判断对象是交付物本身。
迭代回顾回答“团队如何改进工作方式”。它面向团队自身的协作过程，检视本迭代中哪些做法有效、哪些环节出现阻碍，最终形成少量可执行的改进项。回顾的判断对象是工作方式，而非交付物是否合格。
项目复盘回答“整个项目为什么得到这个结果”。它站在项目全程的高度，对照项目目标、里程碑和最终结果，分析关键决策与偏差的成因，沉淀可复用的经验。复盘的判断对象是项目整体。
三者不能互相替代，核心原因在于判断对象和时点不同。评审确认的是增量是否被接受，无法回答团队协作哪里出了问题；回顾改进的是工作方式，不承担验收职责；复盘总结的是项目级经验，粒度太粗，无法替代每个迭代的运行检查。缺少任何一个，都会留下信息盲区：只评审不回顾，问题会反复出现；只回顾不评审，交付质量缺少外部确认；两者都做但不复盘，项目层面的经验难以沉淀。
定义与边界：各自管到哪里为止
明确边界比记住定义更能防止会议走形。以下分别说明每个概念覆盖什么、到哪里停止。
迭代评审：聚焦本迭代增量与验收
迭代评审的范围是本迭代计划承诺的增量。团队展示已完成的工作，干系人对照验收标准给出接受或反馈意见，产品负责人据此调整待办优先级。评审到“增量是否被接受、待办如何调整”为止。对于未完成的工作，需要在评审中重新评估其价值和优先级，再决定是否纳入后续迭代，不能默认自动结转到下一迭代。把评审开成单纯的演示会，或者跳过验收标准只做功能展示，都会让评审失去确认交付的作用。
迭代回顾：聚焦团队协作过程与改进动作
迭代回顾的范围是团队在本迭代中的协作方式、流程执行和阻碍因素。它讨论的是“我们怎么一起工作的”，产出是改进项及其负责人。回顾不承担交付验收职责，也不对需求本身的价值做判断——那属于评审和待办梳理的范畴。把回顾开成追责会，把个人失误当作主要议题，会让团队防御性上升、真实问题被隐藏。
项目复盘：聚焦项目整体目标与结果
项目复盘的范围是项目从启动到收尾的整体表现，包括目标达成情况、里程碑偏差、关键决策的得失。它回答的是项目级问题，不替代具体迭代的运行检查，也不重复每个迭代的评审结论。复盘容易写成流水账，按时间罗列发生了什么，却缺少对原因的分析和对可复用经验的提炼。
需要说明的是，敏捷项目管理框架层面的概念、产品待办（Backlog）的梳理与优先级方法属于相邻主题，本文不展开；未完成工作是否结转的具体规则也因团队而异，本文只强调“需重新评估”这一原则。
目的、输入、参与人、产出：四维对照
下表用同一组维度横向比较三者，便于逐行对照。时点与范围一并列出，帮助判断每个会议在什么阶段发生。
| 维度 | 迭代评审 | 迭代回顾 | 项目复盘 |
|---|---|---|---|
| 目的 | 确认本迭代增量是否符合预期、是否被接受，收集反馈并调整待办 | 检视团队协作过程，形成下个迭代的改进项 | 分析项目整体结果及成因，沉淀可复用经验 |
| 输入 | 可演示的增量、验收标准、验收与测试结果、待办列表 | 迭代过程数据（进度、质量、协作观察）、上一轮改进项的跟踪情况 | 项目目标、里程碑记录、结果数据、关键决策记录、各迭代的评审与回顾记录 |
| 参与人 | 产品负责人、开发团队、测试人员及相关干系人 | 团队自身（含产品负责人，视团队约定） | 项目相关方，覆盖产品、研发、测试及业务方代表 |
| 产出 | 对增量的接受结论、干系人反馈、待办调整项 | 少量可执行的改进项，明确负责人和验证方式 | 经验结论、改进建议、可复用的组织资产 |
| 时点与范围 | 每个迭代结束时，范围为本迭代增量 | 每个迭代结束时，范围为本迭代协作过程 | 项目收尾或关键里程碑，范围为项目全程 |
从表中可以看出，参与人的差异最直观：评审需要外部干系人参与才能完成确认，回顾以团队内部为主，复盘则要覆盖项目相关方。产出的层级也逐级上升：评审产出的是本迭代的交付结论，回顾产出的是工作方式改进，复盘产出的是组织级经验。
机制与组成：三者如何在一个迭代周期里衔接
三者的联系体现在信息流动上：它们共享同一批事实记录，并在交接点上互相供给输入。理解这条链路，比单独记住每个会议的定义更有用。
迭代内：先评审后回顾的常见顺序
多数团队在一个迭代结束时先开评审、再开回顾。理由在于，评审确认了本迭代实际交付了什么、哪些被接受、哪些被退回，这些事实是回顾讨论协作问题的前提。如果先回顾，团队对“交付结果”还没有形成共同认知，讨论改进时容易各说各话。评审结束后，团队已经清楚本迭代的完成情况和外部反馈，回顾可以在此基础上聚焦过程问题。
评审产出如何进入下一迭代计划
评审形成的接受结论和待办调整项，是下一迭代计划的直接输入。产品负责人根据干系人反馈调整优先级，把被接受的需求关闭，把需要返工或补充的需求重新评估后纳入待办。未完成的工作在这一环节重新判断价值，而非自动顺延。
回顾改进项如何被跟踪和验证
回顾产出的改进项需要有负责人和验证方式，并在下个迭代的过程中被跟踪。常见的做法是把改进项登记为独立的工作项，在下次回顾时逐条检查是否落实、是否产生预期效果。缺少跟踪的改进项容易停留在会议记录里，下个迭代重复讨论同样的问题。
项目复盘如何汇总迭代记录
项目复盘站在更高层级，把多个迭代的评审结论和回顾改进项作为输入。评审记录提供了每个迭代的交付与验收事实，回顾记录提供了过程问题的演变轨迹，两者结合才能解释项目结果的形成原因。事实记录——工作项状态、验收结果、改进项的处理情况——是三者共享的底层数据。
在工具承载层面，这些记录需要在同一套工作项与文档体系中留痕，交接时才不至于靠回忆拼凑。以 ONES 为例，迭代完成并发布后可召开迭代回顾会，借助燃尽图、工时日志、持续集成报告等数据报表检视迭代进度、质量和成本偏差，讨论改进建议；迭代结束后还可以用 ONES Wiki 将经验沉淀为团队知识库。迭代规划阶段，产品负责人按优先级把待办需求规划至对应迭代，与团队就需求与验收标准达成一致，设计、研发、测试人员再用子任务拆分需求以便跟踪；测试环节依据验收标准编写并执行用例，未通过的用例可转为缺陷提交并指派修复。这些记录共同构成评审、回顾与复盘可复用的事实基础。
容易混淆的相邻概念：评审与验收、回顾与复盘
实际使用中，最容易混用的是两组概念。下面逐组说明差别。
迭代评审与迭代验收
迭代验收聚焦“是否满足验收标准”，是一个判定动作，通常由测试或质量角色依据用例执行结果给出结论。迭代评审的范围更宽：它在验收结果之上，加入干系人对增量的反馈，并据此调整待办。验收回答“合不合格”，评审回答“是否符合预期、接下来怎么调整”。把评审开成验收会，会丢掉反馈和待办调整这两个关键产出。
迭代回顾与项目复盘
两者都带“回看”的意味，但范围、时点、参与人和产出层级不同。回顾发生在每个迭代结束时，参与人以团队为主，产出是下个迭代的改进项；复盘发生在项目收尾或关键里程碑，参与人覆盖项目相关方，产出是可复用的组织经验。用复盘替代回顾，粒度太粗，无法支撑每个迭代的持续改进；用回顾替代复盘，则缺少项目级的整体判断。
回顾会与日常站会
站会每天进行，议题是当前进度、当天计划和阻碍，目的是快速对齐；回顾会每个迭代一次，议题是本迭代的协作过程和改进方向。两者频率和议题都不同，站会上暴露的阻碍可以作为回顾的素材，但不能在站会上完成改进项的讨论和定责。
复盘与事故复盘
事故复盘由特定事件触发，范围聚焦该事件的经过、原因和纠正措施；项目复盘按项目周期触发，范围覆盖项目全程的目标、决策和结果。事故复盘的结论可以作为项目复盘的输入之一，但两者触发条件和覆盖范围不同。
具体例子与常见误解
下面用一个演示情景说明三者如何各司其职。情景为虚构示例，仅用于说明配合方式。
一个迭代内的评审与回顾
某团队的两周迭代结束时，计划完成的八项需求中有六项达到验收标准、一项部分完成、一项未开始。评审会上，团队演示了六项已完成功能，测试人员出示用例执行结果，干系人对其中一项提出交互调整意见。评审产出：六项被接受，一项部分完成的需求重新评估后拆分为两项纳入下个迭代，交互调整意见进入待办并调整优先级。随后召开回顾会，团队查看燃尽图发现中期进度明显滞后，讨论后确认原因是需求拆分过粗导致估时偏差。回顾产出两条改进项：需求拆分细化到半天以内、每日站会增加估时复核环节，各指定负责人，下个迭代跟踪验证。
项目收尾时的复盘
项目结束时，复盘组织者调取各迭代的评审记录和回顾改进项：评审记录显示交付节奏和验收通过率的变化，回顾记录显示估时偏差问题在第三个迭代后明显改善。复盘据此分析项目整体延期的主要原因，区分出需求变更、估时方法和外部依赖三类因素，形成结论并沉淀为团队知识库中的条目，供后续项目参考。
三条常见误解与纠正
- 把回顾开成批斗会。纠正做法：回顾的议题对准流程和协作机制，讨论“哪个环节让问题得以发生”，把个人失误转化为流程改进项，并明确负责人。
- 把评审开成演示会。纠正做法：评审前准备好验收标准和验收结果，演示后逐项确认接受与否，并把干系人反馈当场转化为待办调整，形成书面结论。
- 把复盘写成流水账。纠正做法：复盘围绕“目标—结果—原因—可复用经验”组织，每一条结论都要对应到具体证据（评审记录、回顾改进项、结果数据），并给出后续可执行的动作。
三个会议各司其职的关键，是让每个会议只回答自己的问题，并把产出准确地交给下一个环节。评审的结论进入计划，回顾的改进项进入跟踪，两者的记录进入复盘，这条链路顺畅了，迭代管理的信息才不会在交接处丢失。
常见问题
迭代评审和迭代验收能不能合并成一个会议？
可以放在同一场会议里完成，但两个动作的产出要分开记录。验收依据用例执行结果判定需求是否满足验收标准，回答“合不合格”；评审在此基础上加入干系人对增量的反馈，并据此调整待办，回答“是否符合预期、接下来怎么调整”。合并时建议先逐项确认验收结论，再收集反馈并当场形成待办调整项，避免只留下“通过/不通过”的结论而丢掉后续动作。
团队规模较小、迭代周期很短时，回顾会可以省略吗？
迭代周期短并不意味着过程问题会消失，省略回顾会让同类阻碍反复出现。周期短时可以把回顾压缩到二三十分钟，聚焦一到两个最影响下个迭代的问题，产出少量改进项并指定负责人。关键是把改进项登记下来、下个迭代检查落实情况，而不是追求会议形式完整。若团队连续多个迭代没有可改进项，也应记录这一判断的依据，便于项目复盘时回溯。
项目复盘时发现各迭代的评审和回顾记录缺失，怎么补救？
先用手头可得的证据重建事实：工作项状态变更、验收与测试结果、发布记录、缺陷处理情况，这些能还原交付节奏和质量变化。再组织参与过项目的成员做一次补充访谈，把关键决策和偏差成因补齐，并标注哪些结论来自回忆、哪些来自记录。补救完成后，把“评审结论与回顾改进项需在迭代内留痕”作为改进项写入后续项目的做法，避免下次复盘再遇到同样问题。
回顾产出的改进项总是落实不了，问题通常出在哪？
常见原因有三类：改进项写得过于笼统，无法判断是否完成；没有明确负责人，大家默认别人会推动；缺少检查时点，下个迭代直接进入新任务。对应做法是把改进项写成可观察的动作，指定一名负责人，并在下个迭代的回顾中逐条检查落实情况和效果。改进项数量控制在团队能承受的范围内，一次改太多往往一项都落不实。
项目复盘和事故复盘需要分别做吗？
两者触发条件和范围不同，通常分别进行。事故复盘由特定事件触发，聚焦该事件的经过、原因和纠正措施，追求尽快闭环；项目复盘按项目周期或关键里程碑触发，覆盖项目全程的目标、决策和结果。事故复盘的结论可以作为项目复盘的输入之一，帮助解释项目结果中的异常波动，但项目复盘还需要覆盖目标达成、里程碑偏差等更宽的内容。
