迭代评审记录和迭代回顾记录都在迭代结束前后产生，名称相近，实际承担的任务却不同。前者回答“这次迭代交付了什么、是否被接受”，后者回答“团队这次怎么协作、下次怎么改进”。本文从目的、记录内容和后续使用三个角度说明两者的区别，并给出字段对照和具体例子，帮助团队在同一个迭代中把两类记录分开写、分别用。
要点总览（TL;DR）
- 迭代评审记录回答“这次迭代交付了什么、是否被接受”，面向产品负责人和干系人确认增量；迭代回顾记录回答“团队这次怎么协作、下次怎么改进”，面向团队自身反思过程。
- 记录内容上，评审记录写迭代目标、完成项、演示要点、验收结论、干系人反馈和待调整事项；回顾记录写做得好的、待改进、问题根因、改进项、责任人和跟进时间。
- 后续使用上，评审记录用于确认增量、调整待办和对外同步交付状态；回顾记录的核心是改进项跟踪，在下一次回顾会上逐条检查落地情况。
- 未完成工作需在评审时重新评估，判断退回、拆分或调整范围，不能默认自动结转到下一个迭代。
- 两类记录在同一个迭代中前后衔接：评审发现的交付偏差可以成为回顾的讨论素材，回顾形成的改进项又影响下个迭代的评审表现。
直接答案：两类记录各自回答什么问题
迭代评审记录回答的是交付结果问题：本次迭代承诺了什么、实际完成了什么、演示中干系人看到了什么、验收结论是什么、哪些反馈需要带回待办。它把迭代产出的增量摆到产品负责人、业务方和相关干系人面前，形成一次可追溯的确认。
迭代回顾记录回答的是工作方式问题：团队在协作、流程、工具和沟通上哪些做法有效、哪些环节出现阻碍、问题背后的原因是什么、下一个迭代准备改什么、由谁负责、何时跟进。它面向团队自身，讨论对象是工作过程，而非某个具体功能是否通过验收。
一句话区分：评审记录对结果，回顾记录对过程。评审记录让干系人确认增量并给出反馈，回顾记录让团队识别改进点并形成可跟踪的行动。两者可以出现在同一个迭代周期内，但不能用一份记录同时承担验收确认和过程改进两种职责。
定义与边界：哪些内容属于、哪些不属于
迭代评审记录的范围围绕“增量验收”展开。常见内容包括：本次迭代目标、计划完成项与实际完成项、演示的功能或成果要点、验收结论（接受、有条件接受或退回）、干系人提出的反馈、需要调整的待办事项。记录的对象是交付物和验收判断，写清楚“做了什么、给谁看、结论如何”即可。
迭代回顾记录的范围围绕“过程改进”展开。常见内容包括：做得好的方面、待改进的方面、问题的根因分析、改进项描述、责任人、跟进时间。记录的对象是团队协作方式和流程环节，写清楚“哪里顺、哪里卡、为什么、下一步改什么”即可。
两类记录都有明确的排除项。产品 Backlog 的长期梳理、优先级排序和需求池维护属于需求池管理的范畴，不写进单次迭代的评审记录或回顾记录；敏捷框架层面的概念定义、角色职责和会议规则属于敏捷项目管理的范畴，也不在两类记录中展开。此外，迭代中未完成的工作需要在评审时重新评估，判断是退回待办、拆分后放入后续迭代，还是调整范围，不能默认自动结转到下一个迭代。把未完成项直接带入下个迭代而不做评估，会让评审记录失去对交付状态的准确反映。
记录内容对照：字段与写法差异
两类记录在字段设置上有明显差异。评审记录偏向事实陈述和结论确认，回顾记录偏向原因分析和行动约定。下表列出常见字段，团队可按自身迭代节奏增减。
| 对照维度 | 迭代评审记录 | 迭代回顾记录 |
|---|---|---|
| 核心字段 | 迭代目标、完成项、演示要点、验收结论、干系人反馈、待调整事项 | 做得好的、待改进、问题根因、改进项、责任人、跟进时间 |
| 记录对象 | 交付物、增量、验收判断 | 协作过程、流程环节、团队行为 |
| 主要读者 | 产品负责人、业务方、相关干系人 | 团队成员、Scrum Master 或迭代负责人 |
| 写法倾向 | 陈述事实与结论，如“某功能通过验收”“某需求退回” | 描述现象与原因，如“联调等待时间偏长，原因是环境准备滞后” |
| 输出形态 | 验收结论清单与反馈事项 | 改进项清单与跟进计划 |
同一件事在两类记录中的写法不同。以“测试环境不稳定导致联调延迟”为例，评审记录中写成“某需求因联调延迟未在本次迭代完成，经评估退回待办，下个迭代重新排期”，重点在交付状态和后续安排；回顾记录中写成“联调阶段环境准备平均等待两天，根因为环境申请流程缺少固定责任人，改进项为指定环境管理员并设定申请响应时限，责任人某某，下个迭代第二次回顾时检查”，重点在原因和改进动作。前者回答“交付到哪一步”，后者回答“流程哪里需要改”。
后续使用：记录写完之后分别流向哪里
评审记录写完后，主要流向三个方向。第一，作为本次迭代增量的确认依据，产品负责人据此判断哪些需求可以关闭、哪些需要继续跟进。第二，干系人反馈和待调整事项进入待办梳理，影响后续迭代的范围和优先级。第三，对外同步交付状态时，评审记录可以作为与业务方沟通的事实基础，减少口头转述带来的偏差。
回顾记录写完后，核心流向是改进项跟踪。每条改进项应有责任人和跟进时间，进入团队的行动清单，在下一次回顾会上逐条检查完成情况：已完成的说明效果，未完成的说明原因并决定是否继续。回顾记录的价值体现在改进项是否真正落地，而非会议当天写得多完整。
两类记录在迭代节奏中前后衔接。评审会确认本次交付结果，回顾会在此基础上反思交付过程中暴露的协作问题。评审中发现的交付偏差，往往成为回顾会的讨论素材；回顾中形成的改进项，又会影响下一个迭代的评审表现。团队可以把评审记录中的待调整事项与回顾记录中的改进项放在同一处查看，避免验收结论和改进动作各自散落。使用 ONES 时，迭代相关工作项可以在 ONES Project 中管理，回顾会可以结合燃尽图、工时日志等数据复盘进度、质量和成本偏差；迭代结束后可用 ONES Wiki 沉淀经验，ONES Wiki 支持文档关联任务并插入工作项列表，便于把改进项与对应工作项放在一起查看。
具体例子与常见误解
假设一个两周迭代，团队承诺完成五个需求。评审会上，三个需求通过验收，一个需求因联调延迟未完成，一个需求在演示后收到业务方反馈需要调整交互。评审记录写明：迭代目标、三个通过项及演示要点、未完成项的退回与重新排期决定、业务方反馈的具体内容、待调整事项清单。回顾会上，团队讨论联调延迟的原因，发现环境申请缺少固定责任人，同时演示前准备时间偏紧。回顾记录写明：做得好的方面是需求拆分较细、测试介入较早；待改进的是环境申请流程和演示准备节奏；根因分别是责任人不明确和准备清单缺失；改进项为指定环境管理员、建立演示前检查清单，各设责任人和跟进时间，下次回顾逐条检查。
常见误解之一是把回顾会上的过程问题写进评审记录，例如在验收结论旁写“联调流程需要优化”。这会让评审记录混入与交付确认无关的内容，干系人难以判断哪些是验收结论、哪些是团队内部改进。常见误解之二是把验收结论当成改进项，例如把“某需求退回”直接列为回顾改进项，却没有分析退回背后的流程原因，导致改进动作停留在结果层面。
这些混淆会带来两个后果：改进项缺少责任人和跟进时间，下次回顾时无人核对，过程问题反复出现；评审记录中验收结论与过程讨论混在一起，交付状态对外传达不清，干系人无法准确了解本次迭代实际交付了什么。分开记录、分别跟踪，是让两类记录各自发挥作用的基本做法。
常见问题
迭代评审记录和迭代回顾记录可以由同一个人整理吗？
可以由同一个人整理，但两类记录的信息来源和确认方式不同。评审记录的事实基础是演示和验收过程，验收结论应由产品负责人和干系人确认；回顾记录的内容来自团队讨论，改进项和责任人也需要团队共同认可。同一个人执笔时，建议分别使用不同的记录模板，并在会后把评审结论和回顾改进项分别发给对应的读者确认，避免两类内容混在同一份文档里。
迭代评审中发现的交付偏差，应该写进评审记录还是留到回顾会讨论？
两处都需要，但写法不同。评审记录中写交付状态和后续安排，例如“某需求因联调延迟未完成，经评估退回待办，下个迭代重新排期”，让干系人清楚本次迭代实际交付了什么。回顾记录中写偏差背后的过程原因和改进动作，例如环境申请缺少固定责任人、改进项为指定环境管理员并设定响应时限。评审记录保留结论，回顾记录处理原因，两者分工明确。
改进项在下次回顾时没有完成，记录上应该怎么处理？
在下次回顾会上逐条核对时，对未完成的改进项说明原因，并决定是继续保留、调整做法还是关闭。记录中保留原改进项、责任人、跟进时间以及本次核对的结果，形成连续的跟踪痕迹。未完成本身不构成记录失败，关键是让团队看到改进项的真实进展，避免同一问题在多个迭代中反复出现却无人跟进。
团队规模较小、迭代周期很短时，两类记录可以合并成一份吗？
不建议合并成一份记录，但可以简化字段。评审记录至少保留完成项、验收结论和待调整事项；回顾记录至少保留待改进项、改进动作和责任人。即使迭代只有一周，验收确认和过程改进仍是两件不同的事，合并后容易出现验收结论与过程讨论混杂、改进项无人跟踪的情况。团队可以缩短记录篇幅，把两类记录放在同一处查看，分别保留各自的结论和行动。
用 ONES 承载这两类记录时，评审结论和改进项分别放在哪里比较合适？
评审结论和待调整事项与具体工作项关系紧密，可以在 ONES Project 中结合迭代工作项进行管理，便于产品负责人据此关闭需求或调整后续排期。回顾形成的改进项和经验总结，可以用 ONES Wiki 沉淀，ONES Wiki 支持文档关联任务并插入工作项列表，便于把改进项与对应工作项放在一起查看。团队也可以结合燃尽图、工时日志等数据在回顾会上复盘进度、质量和成本偏差。具体字段和模板设置需结合团队实际配置。
