迭代回顾记录要能支撑下一次回顾核对行动项，因此核心是行动项字段和状态，其余信息围绕它组织。一份可用的记录至少保留五类信息：迭代基本信息、回顾过程信息、结论信息、行动项信息，以及未完成工作的处理结论。下面给出可直接套用的字段表、会前会后操作步骤、角色分工、填写示例和完成检查清单。
要点总览（TL;DR）
- 回顾记录至少保留五类信息：迭代基本信息、回顾过程信息、结论信息、行动项信息、未完成工作的处理结论，其中行动项字段和状态是核心。
- 行动项建议保留描述、负责人、截止时间、验收标准、关联工作项和状态六项，下次回顾才能逐条核对。
- 记录在会前准备数据与议题、会中记要点和结论、会后当天补齐验收标准并归档，行动项录入工作项跟踪。
- 主持人负责确认行动项，记录人负责定稿归档，跟进人负责跟踪状态，团队较小时记录人与跟进人可兼任。
- 未完成工作逐条重新评估，写明继续、拆分、降级或取消的理由与去向，避免默认结转造成积压。
迭代回顾记录的核心字段清单
字段设计的目标是让三个月后的人也能看懂：这次迭代发生了什么、为什么得出这个结论、谁在什么时候完成什么。五组字段中，基本信息、行动项、未完成工作处理为必填；过程信息和结论信息按会议实际展开程度填写，但结论信息中的“待改进项”与“根因判断”建议必填，否则行动项缺少来源。
| 分组 | 字段 | 填写内容 | 用途 | 必填/选填 |
|---|---|---|---|---|
| 基本信息 | 迭代名称与编号 | 与迭代计划一致的名称、编号 | 关联计划、需求与工作项 | 必填 |
| 起止时间 | 计划起止与实际起止 | 判断延期与节奏问题 | 必填 | |
| 参与人 | 姓名与角色，注明缺席者 | 确认结论的共识范围 | 必填 | |
| 回顾会议时间与地点/方式 | 日期、时长、线上或线下 | 追溯记录形成过程 | 选填 | |
| 过程信息 | 议题清单 | 本次讨论的几个议题及顺序 | 说明记录覆盖了哪些讨论 | 必填 |
| 讨论要点 | 每个议题的主要观点，标注提出人 | 保留判断依据，避免结论无出处 | 必填 | |
| 数据依据 | 引用的燃尽图、缺陷数、交付周期、线上问题等数据及口径 | 让结论可复核 | 选填，涉及数据结论时必填 | |
| 结论信息 | 做得好的 | 值得保持的做法及具体表现 | 沉淀可复用经验 | 必填 |
| 待改进的 | 问题现象与影响 | 行动项的来源 | 必填 | |
| 根因判断 | 对问题原因的分析结论，注明是共识还是待验证假设 | 避免行动项只治标 | 必填 | |
| 行动项 | 行动项描述 | 具体动作，写清改什么、改到哪 | 可执行 | 必填 |
| 负责人 | 单一责任人姓名 | 明确归属 | 必填 | |
| 截止时间 | 具体日期 | 便于下次回顾核对 | 必填 | |
| 验收标准 | 完成的可观察标志 | 判断是否真正完成 | 必填 | |
| 关联工作项 | 对应的工作项编号或链接 | 把改进落到日常跟踪中 | 必填 | |
| 状态 | 未开始/进行中/已完成/已取消 | 下次回顾逐条核对 | 必填 | |
| 未完成工作处理 | 未完成事项清单 | 本迭代未完成的需求、任务、缺陷 | 避免遗漏 | 必填 |
| 重新评估结论 | 继续、拆分、降级、取消，并说明理由 | 防止默认结转造成积压 | 必填 | |
| 去向 | 进入哪个迭代或需求池，关联新工作项 | 保证有承接 | 必填 |
字段数量可按团队规模裁剪，但行动项的描述、负责人、截止时间、验收标准、关联工作项和状态六项建议保留完整，它们是下次回顾能逐条核对的依据。
从回顾会到记录归档的操作步骤
记录工作在会前就开始了。会前准备不足，会中只能记感受；会后不整理，行动项就停留在口头。下面按三个阶段说明输入、动作、输出与完成标志。
会前准备：把数据和议题摆上桌
- 输入：本迭代的迭代计划、完成情况、缺陷与线上问题记录、上一条回顾的行动项清单。
- 动作：记录人提前收集数据并注明口径；主持人整理议题，把上次行动项的完成情况列为固定议题；提前发出记录模板。
- 输出：带数据的议题清单和空白记录模板。
- 完成标志：议题与数据在会前发出，参与者能提前看到上次行动项的当前状态。
会中记录：记要点、记结论、记分歧
- 输入：会前议题清单与数据。
- 动作：按议题逐条记录讨论要点，标注提出人；每个议题结束前当场归纳结论，区分“已达成共识”和“待验证假设”；行动项当场确认负责人和截止时间，验收标准写不出来的先记为待补充，会后当天补齐。
- 输出：包含讨论要点、结论和初步行动项的会议记录。
- 完成标志：每个议题都有结论或明确的“本次不结论”标记；每条行动项都有负责人。
会后整理：确认行动项并归档
- 输入：会中记录。
- 动作：记录人当天整理成正式记录，补齐验收标准和关联工作项；主持人或相关负责人在约定时间内确认；行动项录入日常工作项跟踪，未完成工作逐条给出重新评估结论和去向；记录归档到团队可检索的位置。
- 输出：定稿的回顾记录、已建工作项的行动项、未完成工作处理清单。
- 完成标志：所有行动项在工作项系统中可查且有状态，未完成事项均有去向，记录对全员可见。
行动项进入工作项跟踪后，回顾记录与日常执行就连起来了。在ONES中，可以把回顾记录作为团队文档维护，行动项直接建为工作项并指派负责人、设置截止时间，下次回顾时按状态筛选核对；未完成的需求或任务在重新评估后调整所属迭代或放回需求池，去向在记录中留痕。这样记录不必靠人工反复追问进度。
角色分工与交付物
回顾记录常见的失败是“有人记、没人认、没人跟”。把记录、确认、跟踪三件事分到具体角色，记录才有闭环。
| 角色 | 主要职责 | 在记录上的交付物 |
|---|---|---|
| 主持人 | 确定议题、控制节奏、当场归纳结论、组织行动项确认 | 议题清单、结论口径、行动项确认结果 |
| 记录人 | 会前准备模板与数据，会中记录要点与结论，会后整理定稿并归档 | 定稿的回顾记录、行动项清单 |
| 参与者 | 提供事实与数据，参与根因讨论，认领或确认行动项 | 讨论要点中的观点与数据来源、本人认领的行动项 |
| 跟进人（通常是主持人或迭代负责人） | 跟踪行动项状态，在下次回顾前汇总完成情况 | 行动项状态更新、下次回顾的核对输入 |
行动项的确认责任在主持人：会上确认负责人和截止时间，会后确认验收标准可判断。跟踪责任在跟进人，但每条行动项的执行责任在负责人本人。团队规模较小时，记录人与跟进人可由同一人兼任，主持人与记录人建议分开，避免讨论与记录互相打断。
一条行动项的记录示例
以下为演示情景，展示字段如何填满，而非空表。
背景：某迭代中多个需求在提测后集中返工，回顾讨论认为根因是提测前缺少自测确认环节。
| 字段 | 填写内容 |
|---|---|
| 行动项描述 | 在提测流程中增加开发自测确认环节，开发完成自测后填写自测结论再提交测试 |
| 负责人 | 开发负责人（单人） |
| 截止时间 | 下个迭代开始前 |
| 验收标准 | 下个迭代所有提测需求均附自测结论；提测后因基础功能缺陷导致的返工数量较本迭代下降 |
| 关联工作项 | 流程改进工作项一条，关联下个迭代的提测需求 |
| 状态 | 进行中 |
未完成工作的处理示例：本迭代有一个需求因依赖外部接口未完成。记录中写明：该需求重新评估后拆分，核心部分进入下个迭代并关联新工作项，依赖外部接口的部分放回需求池等待接口就绪，理由与评估人一并记录。这样处理避免了默认结转，也让下次回顾能核对拆分后的去向。
记录完成检查与常见遗漏
定稿前按下表逐项核对，能覆盖大部分返工。
记录完整性检查项
- 基本信息齐全，参与人与实际到场一致，缺席者已注明。
- 每个议题都有讨论要点和结论，或明确标注“本次不结论”。
- 待改进项都能对应到至少一条行动项，或说明暂不行动的理由。
- 根因判断注明是共识还是待验证假设。
- 记录已归档到团队可检索的位置，参与人可访问。
行动项可执行性检查项
- 每条行动项只有一个负责人，描述写清具体动作。
- 截止时间是具体日期，不是“尽快”。
- 验收标准可观察、可判断，不写成“加强”“提升”一类表述。
- 每条行动项都有对应工作项，状态可在系统中查询。
未完成工作处理检查项
- 未完成事项逐条列出，没有合并成一句“部分需求未完成”。
- 每条都有重新评估结论和理由，而非默认结转。
- 去向明确到具体迭代或需求池，并关联新工作项。
常见遗漏与补正方式
- 只记结论不记依据：补上讨论要点和数据口径，注明来源。
- 行动项没有验收标准：会后当天由负责人补充，主持人确认。
- 行动项停留在文档里：录入工作项跟踪，下次回顾按状态筛选核对。
- 未完成工作直接带入下个迭代：补做重新评估，记录结论与去向。
- 上次行动项无人核对：把行动项完成情况列为每次回顾的固定首项议题。
一份合格的回顾记录，标准很朴素：下次回顾时，团队能凭它逐条核对上次行动项是否完成、未完成工作去了哪里，并据此展开新一轮讨论。
常见问题
回顾记录里的行动项，验收标准写不出来怎么办？
会上先确认负责人和截止时间，验收标准可以标记为待补充，但要在会后当天由负责人补齐、主持人确认。判断标准是：换一个人看到这条标准，能独立判断完成与否。如果确实难以量化，可以改为可观察的交付物，例如“提测单中附自测结论”这类能直接检查的痕迹。
团队规模小，角色可以合并吗？
可以。记录人与跟进人常由同一人兼任，主持人与记录人建议分开，避免讨论与记录互相打断。合并角色时，确认行动项的责任仍留在主持人身上，跟踪责任留在跟进人身上，两条职责不因兼任而消失。
上次回顾的行动项没完成，这次回顾怎么处理？
把行动项完成情况列为每次回顾的固定首项议题，逐条核对状态。未完成的行动项要说明原因，并重新判断：继续保留并调整截止时间、拆分、降级或取消，结论写回记录。这样处理让行动项状态保持真实，也避免旧行动项长期悬空。
回顾记录要归档到哪里，保留多久？
归档到团队可检索、参与人可访问的位置，与迭代计划、工作项放在同一处便于对照。保留时长按团队习惯和合规要求确定，至少覆盖到下一次回顾核对完成为止。记录归档后，行动项的状态仍以工作项系统中的为准，文档记录作为结论与依据的留痕。
回顾记录需要写得多详细？
以“三个月后的人能否看懂”为尺度。讨论要点记主要观点和提出人，数据结论注明口径和来源，根因判断注明是共识还是待验证假设。过程信息可按会议展开程度裁剪，但待改进项与根因判断建议保留，否则行动项缺少来源，后续核对时难以判断是否对症。
