迭代回顾记录要能支撑下一轮核对行动项，至少保留五组信息：会议基本信息、回顾输入、讨论结论、行动项和记录状态。字段齐全只是底线，每条行动项都写清具体动作、负责人、截止时间和验证方式，记录才真正可用。下面给出字段清单、记录步骤、角色分工、填写示例和归档前检查方法。
要点总览（TL;DR）
- 迭代回顾记录按五组字段组织：会议基本信息、回顾输入、讨论结论、行动项、记录状态，每组字段都服务于下一轮核对行动项是否落地。
- 记录顺序分四个阶段：会前整理输入材料、会中先核对事实再收敛行动项、会后补齐期限并确认归档、下一轮开始前核对上轮行动项。
- 主持人负责结论收敛，记录人如实记录，参与人确认内容与本人行动项，行动项负责人按期推进并反馈，团队负责人或 Scrum Master 检查闭环。
- 行动项至少写清具体动作、负责人、截止时间和验证方式，模糊表述要改写到下一轮可直接判断是否完成。
- 归档前按检查清单逐项核对，必填字段、行动项质量、与迭代目标和上轮行动项的对应关系、归档位置与跟踪入口未通过时，记录不归档为完成状态。
一份可用的迭代回顾记录包含哪些字段
回顾记录的内容范围可以按五组字段界定。每组字段承担不同任务：会议信息解决“这次回顾对应哪个迭代、谁在场”，回顾输入解决“讨论基于什么事实”，讨论结论解决“团队判断了什么”，行动项解决“接下来谁做什么”，记录状态解决“这份记录是否被确认、在哪里能找到”。字段不必多，但关键项缺失会让记录失去追溯价值。
| 分组 | 字段名 | 填写要求 | 是否必填 |
|---|---|---|---|
| 会议基本信息 | 迭代名称或编号 | 与迭代计划中的标识一致，便于跨记录检索 | 必填 |
| 会议日期与时长 | 写明实际召开日期，时长用于后续调整议程 | 必填 | |
| 参与角色 | 列出到场的角色或人员，缺席的关键角色需注明 | 必填 | |
| 主持人 | 对议程和结论收敛负责的人 | 必填 | |
| 记录人 | 实际执笔的人，便于后续补充澄清 | 必填 | |
| 回顾输入 | 迭代目标 | 引用迭代开始时确定的目标，不改写为事后总结 | 必填 |
| 实际交付结果 | 已完成、未完成的需求或任务清单，未完成项注明原因 | 必填 | |
| 关键过程数据 | 燃尽情况、缺陷数量、延期情况等与本次讨论相关的数据 | 建议填写 | |
| 上一轮行动项完成情况 | 逐条标注完成、未完成或部分完成，未完成项说明原因 | 必填 | |
| 讨论结论 | 做得好的方面 | 写具体做法和产生的结果，避免只写“配合不错” | 必填 |
| 待改进问题 | 按影响程度排序，控制在团队本轮能处理的数量内 | 必填 | |
| 原因判断 | 区分流程、协作、需求变化、技术等来源，标注判断依据 | 必填 | |
| 行动项 | 具体动作 | 写成可执行的动作，说明改什么、改到哪里 | 必填 |
| 负责人 | 落到具体个人，不写“团队”或“相关同学” | 必填 | |
| 截止时间 | 写明日期，跨迭代的行动项注明检查节点 | 必填 | |
| 验证方式 | 说明如何判断完成，如产出物、检查项或数据变化 | 必填 | |
| 记录状态 | 确认人 | 参与人对记录内容确认后署名或标注确认时间 | 必填 |
| 归档位置 | 固定目录或知识库位置，团队可访问 | 必填 | |
| 跟踪入口 | 行动项在何处跟踪，与记录保持对应 | 必填 |
“关键过程数据”列为建议填写，是因为不同团队关注的指标不同：有的团队重点看交付节奏，有的更关注质量波动。原则是只记录本次讨论实际引用过的数据，避免把回顾记录变成报表堆叠。
按什么顺序记录：从会前准备到归档的操作步骤
记录工作从会前就开始了。会中才动手整理输入，讨论容易停留在印象层面；会后不补齐责任和期限，行动项就会悬空。以下四个阶段各有明确的输入、动作、输出和完成标志。
会前：整理回顾输入材料
- 输入：迭代目标、迭代内工作项状态、上一轮回顾记录。
- 动作：导出或整理已完成与未完成事项，核对上一轮每条行动项的实际状态，把关键数据放进同一份材料。
- 输出：一份会前输入材料，包含目标、结果、数据和上轮行动项状态。
- 完成标志：主持人确认材料能支撑讨论，参与人提前可读。
会中：先核对事实，再讨论原因，最后收敛行动项
- 输入：会前输入材料。
- 动作：开场先逐条核对输入事实，对数据口径的异议当场澄清；再围绕待改进问题讨论原因；最后把结论收敛为数量有限的行动项，当场确定负责人。
- 输出：讨论结论与行动项初稿。
- 完成标志：每条行动项都有负责人，待改进问题与行动项能一一对应。
会后：补齐期限、确认、归档并登记跟踪入口
- 输入：行动项初稿。
- 动作：记录人补齐截止时间和验证方式，发给参与人确认；确认后归档到固定位置，并把行动项登记到团队日常跟踪的地方。
- 输出：确认后的完整记录和可跟踪的行动项。
- 完成标志：参与人完成确认，归档位置和跟踪入口在记录中写明。
下一轮开始前：核对上轮行动项
- 输入：上一轮回顾记录及其行动项。
- 动作：逐条核对完成情况，未完成项分析原因，判断是继续推进、调整做法还是关闭。
- 输出：更新后的行动项状态，作为新一轮回顾的输入。
- 完成标志：每条行动项都有明确状态和处理结论，未完成工作经过重新评估，而非默认顺延。
记录归档后，团队通常需要让文档与迭代工作项保持对应关系。ONES Wiki 支持文档关联任务，也可以插入 ONES Project 的工作项列表，回顾记录因此能和对应迭代的需求、任务放在同一处查看；迭代结束后的经验也可以用 ONES Wiki 沉淀为团队知识库。行动项的具体承载方式按团队现有工作项管理习惯安排即可。
谁负责记录与跟踪：角色分工与交付物
回顾记录涉及四类角色，各自交付物不同。分工清楚，记录才不会变成记录人一个人的事。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 主持人 | 控制议程节奏，先核对事实再讨论原因，推动结论收敛为有限行动项 | 议程、收敛后的结论与行动项清单 |
| 记录人 | 如实记录讨论与结论，区分事实、判断和待定事项，不当场评判观点 | 完整记录初稿 |
| 参与人 | 核对记录内容是否与讨论一致，确认本人承担的行动项 | 确认意见与本人行动项承诺 |
| 行动项负责人 | 在期限内推进动作，按约定方式反馈进展和完成情况 | 行动项进展说明与完成证据 |
| 团队负责人或 Scrum Master | 检查行动项是否按期推进，在下一轮回顾前核对闭环情况 | 行动项跟踪状态与闭环结论 |
记录人由团队成员轮换承担是常见做法，好处是每个人都熟悉记录要求。无论谁记录，主持人都要在会中确认结论已经收敛，避免记录人替团队做判断。行动项负责人的反馈频率可按行动项周期约定：周期短的在下一次站会同步，跨迭代的在下一轮回顾前给出状态。
示例：一次两小时回顾会的记录长什么样
以下为演示情景，用于说明字段写法，不对应真实团队数据。
基本信息与输入
- 迭代：第 12 迭代，日期 3 月 14 日，时长 2 小时；参与角色为产品、开发、测试；主持人为迭代负责人，记录人为开发成员 A。
- 迭代目标：完成订单查询页改版并上线。
- 实际结果：改版已上线；两个性能优化任务未完成，原因是联调环境在迭代中期不可用两天。
- 关键数据：迭代内新增缺陷 9 个，其中 3 个在提测后才发现；燃尽图显示后三天集中关闭任务。
- 上一轮行动项：共 3 条，完成 2 条；“补充接口文档”未完成，原因是负责人中途支援其他项目。
做得好的方面与待改进问题
- 做得好的方面一：提测前增加一轮冒烟检查，提测后阻塞类缺陷从上一轮的 5 个降到 2 个。
- 做得好的方面二：需求评审时产品提前给出验收示例，开发返工减少。
- 待改进问题一：联调环境不可用缺少备用方案，导致两个任务延期。
- 待改进问题二：接口文档更新滞后，测试只能口头确认字段含义。
行动项改写前后对照
| 改写前 | 改写后 |
|---|---|
| 加强联调环境保障 | 由开发成员 B 在 3 月 21 日前整理联调环境依赖清单，并约定环境不可用时的备用环境申请流程，产出清单文档并在下次回顾时核对是否发生过环境阻塞 |
| 把接口文档补起来 | 由开发成员 C 在 3 月 28 日前补齐订单查询相关 6 个接口的字段说明，测试成员按文档完成一次字段核对，核对记录附在文档末尾 |
改写后的行动项都包含具体动作、负责人、截止时间和验证方式，下一轮回顾时可以直接判断是否完成。
确认与归档信息
- 确认人：产品、开发、测试参与人于 3 月 15 日完成确认。
- 归档位置：团队知识库“迭代回顾”目录下按迭代编号存放。
- 跟踪入口：两条行动项登记在团队行动项清单中，关联第 12 迭代记录。
记录完成检查：怎样判断这份记录合格
归档前按以下清单逐项核对。标注为阻断项的条目未通过时，记录不应归档为完成状态。
| 检查项 | 通过标准 | 是否阻断 |
|---|---|---|
| 必填字段完整性 | 会议基本信息、回顾输入、讨论结论、行动项、记录状态五组必填字段均有内容 | 是 |
| 行动项负责人 | 每条行动项落到具体个人，无“团队”“相关同学”等模糊主体 | 是 |
| 行动项期限 | 每条行动项有明确日期，跨迭代项注明检查节点 | 是 |
| 行动项验证方式 | 每条行动项写明如何判断完成，可产出物、检查项或数据变化为依据 | 是 |
| 与迭代目标对应 | 回顾输入中的目标与实际结果能对应，未完成项有原因说明 | 是 |
| 与上轮行动项对应 | 上一轮每条行动项都有状态和处理结论 | 是 |
| 参与人确认 | 关键参与人完成确认，缺席角色的信息已补充 | 否，但需注明 |
| 归档位置固定 | 记录存放在团队约定目录，参与人可访问 | 是 |
| 跟踪入口明确 | 记录中写明行动项在何处跟踪，且与记录可对应 | 是 |
检查通过后，记录即可作为下一轮回顾的输入。若某项行动项在下一轮核对时仍未完成，应在记录中补充原因和新的处理结论，保持同一条行动项的状态连续可查。
常见问题
回顾会开完，行动项负责人迟迟不反馈进展，记录里该怎么处理？
在下一轮回顾核对时，把该行动项标注为未完成并写明原因，同时给出新的处理结论：继续推进并约定新的检查节点、调整做法，或者确认关闭。记录中保留原行动项和新结论，状态连续可查，避免同一件事在多轮记录里反复出现却看不出变化。
如果行动项跨迭代，可以在记录里注明中间检查节点，由团队负责人或 Scrum Master 在节点处核对一次状态，不必等到下一轮回顾才发现停滞。
团队规模小、回顾会时间短，字段能不能精简？
可以精简，但有几项不建议省略：迭代标识与日期、迭代目标与实际结果、上一轮行动项状态、本轮行动项及其负责人、截止时间和验证方式、归档位置与跟踪入口。这些字段决定了记录能否被下一轮直接使用。
参与角色、关键过程数据、原因判断的详略可以按讨论深度调整。原则是记录本次实际讨论过的内容，不为了填满字段而补写没有讨论过的判断。
上一轮行动项没做完，是直接顺延到下一轮吗？
不建议默认顺延。下一轮回顾时应逐条核对未完成项，分析原因后重新评估：是继续推进、调整做法还是关闭。重新评估的结论写进本轮记录，与上一条行动项对应，这样团队能看清这件事为什么没完成、接下来怎么处理。
未完成工作本身也需要重新评估，而不是自动结转到新迭代。回顾记录承担的作用正是留下这个判断过程。
回顾记录放在文档里，行动项放在工作项里，两边怎么保持对应？
在记录中写明行动项的跟踪入口，例如登记在哪个行动项清单或哪类工作项中，并让每条行动项在文档与跟踪位置使用一致的表述和负责人。归档位置固定后，下一轮核对时从记录出发就能找到对应的工作项状态。
ONES Wiki 支持文档关联任务，也可以插入 ONES Project 的工作项列表，回顾记录因此能和对应迭代的需求、任务放在同一处查看。具体承载方式按团队现有的工作项管理习惯安排即可。
缺席回顾会的成员，其负责的行动项怎么确认？
记录中注明缺席的关键角色，会后由记录人或主持人把与其相关的结论和行动项单独同步，请其在确认环节补充意见。参与人确认一项在检查清单中不作为阻断项，但需要注明，避免出现无人认领或信息不对称的行动项。
如果缺席成员本人就是行动项负责人，应在同步时确认负责人、期限和验证方式，确认结果补记到记录中。
