迭代回顾常有记录，行动项却停在会议文档里：没人认领、没有截止时间，下次回顾时无人核对。问题通常不在会议本身，而在行动项缺少可跟踪的字段和责任机制。本文按“登记—推进—检查—复核”的链路，给出行动项从回顾结束到下次回顾核对的完整做法，包括字段写法、角色分工和闭环检查清单。行动项数量增多后，可以借助工作项系统承载状态与逾期可见性，ONES 可作为这类承载工具之一。
要点总览（TL;DR）
- 把回顾行动项从会议记录转为可跟踪工作项：每条在回顾结束前写清负责人、截止时间、验收标准和来源问题，缺一项就难以检查。
- 负责人写具体个人，截止时间写到日期并与迭代节奏对齐，验收标准写成可观察的完成状态，来源问题与回顾问题一一对应。
- 回顾主持人负责登记与格式把关，行动项负责人推进并更新状态，团队负责人或 Scrum Master 每周检查逾期项，下次回顾开场逐条核对上轮行动项。
- 行动项数量增多后，可用工作项系统承载状态与逾期可见性；ONES 可作为承载工具之一，具体字段与工作流配置需按团队实际开通情况确认。
- 闭环的标志是每条行动项都有明确状态和结论：完成的有关闭依据，未完成的有人说明原因并给出继续、改期或关闭的处理意见，不默认结转。
行动项从记录到闭环的核心做法
让行动项真正被跟进，关键动作是在回顾会结束前把它从“讨论结论”转成“可跟踪的工作项”。一条行动项只有同时具备负责人、截止时间、验收标准和来源问题，才具备被检查的条件；缺少任何一项，后续都容易变成无人认领的待办。
完整链路分为四步，每一步都有明确的输入、动作和输出：
- 回顾结束前完成登记。输入是回顾会中形成的改进建议和问题清单；动作是逐条确认是否转化为行动项，并当场补齐四个要素；输出是一份团队共用的行动项清单，每条都有唯一标识。完成标志是：会议结束前，所有行动项都已登记，且没有一条缺少负责人或截止时间。
- 负责人按截止时间推进并更新状态。输入是分配给自己的行动项；动作是在约定节点更新进展，遇到阻碍时说明原因；输出是每条行动项的最新状态（未开始、进行中、已完成、受阻）。完成标志是：截止时间前，状态有更新记录，而非到期才第一次查看。
- 按固定节奏检查逾期项。输入是行动项清单中的逾期和受阻项；动作是回顾主持人或指定检查人每周查看一次，对逾期项确认原因并给出处理意见；输出是逾期项的处理记录。完成标志是：每个逾期项都有明确的下一步，而不是停留在清单里。
- 下次回顾开场逐条核对上轮行动项。输入是上轮行动项清单；动作是逐条确认完成情况，未完成的重新评估是继续、改期还是关闭；输出是核对结论和新一轮行动项。完成标志是：上轮每条行动项都有明确结论，没有默认结转。
这四步构成一个循环：登记保证行动项可被跟踪，状态更新保证过程可见，定期检查保证逾期不被忽略，下次回顾核对保证闭环。团队规模较小、迭代周期较短时，检查频率可以随迭代节奏调整，但“下次回顾开场核对上轮行动项”这一步建议固定保留，它是闭环能否成立的关键节点。
行动项字段怎么写：负责人、截止时间与验收标准
行动项写得模糊，是后续无法跟踪的直接原因。“提升代码质量”“加强沟通”这类表述没有负责人、没有完成标志，到期也无法判断是否完成。字段填写规则的核心是：每条行动项都能被一个具体的人在一个具体日期前完成，并能用可观察的状态判断是否完成。
| 字段 | 填写规则 | 不合格示例 | 合格示例 |
|---|---|---|---|
| 负责人 | 写具体个人姓名，一条行动项只对应一个负责人；需要多人协作时拆成多条，或明确一人为第一负责人 | “开发团队”“后端组”“相关同学” | “张明（后端）” |
| 截止时间 | 写到具体日期，并与迭代节奏对齐：能在本迭代内完成的写本迭代结束前，跨迭代的写明确日期并说明原因 | “尽快”“下个迭代”“有空时” | “本迭代结束前（3月14日）” |
| 验收标准 | 写成可观察的完成状态，能通过查看产物、记录或数据确认 | “提高评审质量”“优化流程” | “代码评审清单模板发布到团队文档，并在最近两次评审中使用” |
| 来源问题 | 与回顾中提出的问题一一对应，写清问题描述和来源迭代，便于下次回顾追溯 | 无来源，或只写“回顾会提到” | “来源：第12迭代回顾，问题为‘评审意见集中在格式问题，遗漏逻辑缺陷’” |
四个字段之间存在约束关系。负责人是个人，截止时间才有意义；验收标准可观察，负责人才能自行判断是否完成；来源问题清晰，下次回顾核对时才能判断这条行动项是否仍然必要。填写时建议按“来源问题→验收标准→负责人→截止时间”的顺序确认：先明确要解决什么问题、完成到什么程度，再确定由谁在什么时间完成。
截止时间与迭代节奏的关系需要提前约定。团队可以在回顾会上明确一条规则：行动项默认在本迭代内完成；确实需要跨迭代的，在登记时注明原因和预计完成日期，并在下次回顾时单独核对。这样既避免所有行动项都被推到“下个迭代”，也让跨迭代事项有据可查。
角色分工：谁登记、谁推进、谁检查
行动项无人跟进，往往不是缺少意愿，而是职责没有落到具体角色。把登记、推进、检查、核对四类动作分配给明确的人，并约定各自的交付物，跟踪机制才能持续运转。
| 角色 | 主要职责 | 交付物 | 时间节点 |
|---|---|---|---|
| 回顾主持人 | 在回顾会结束前登记全部行动项，检查四个字段是否齐全，格式是否统一 | 完整的行动项清单 | 回顾会结束前 |
| 行动项负责人 | 推进自己负责的行动项，按节点更新状态，遇到阻碍时说明原因 | 状态更新记录、完成产物 | 截止时间前，按约定节点更新 |
| 团队负责人或 Scrum Master | 每周检查一次逾期项和受阻项，确认原因并推动处理，必要时升级 | 逾期项处理记录 | 每周固定时间 |
| 下次回顾主持人 | 开场逐条核对上轮行动项，组织团队对未完成项重新评估 | 上轮行动项核对结论 | 下次回顾会开场 |
回顾主持人的把关动作发生在会议现场，重点是“登记完整”，而不是会后代为补全。如果会上无法确定负责人或截止时间，应当场明确由谁在什么时间补齐，并把补齐本身作为一条行动项登记，避免出现“待定”长期挂起。
团队负责人或 Scrum Master 的检查动作要形成固定节奏，例如每周一查看一次逾期清单。检查的输出不是催促，而是处理记录：逾期原因是需求变化、资源冲突还是行动项本身不合理，分别对应改期、调整负责人或关闭。下次回顾的核对由主持人组织，但结论由团队共同确认，未完成项是否继续、改期或关闭，应在会上明确记录，不默认结转到下一迭代。
示例：一条行动项从提出到关闭的完整记录
以下为演示情景，用于说明字段填写和状态流转方式，不代表真实团队数据。
提出背景与来源问题。某团队在第12迭代回顾中发现：代码评审意见大量集中在命名和格式上，逻辑缺陷反而在测试阶段才暴露。来源问题记录为“第12迭代回顾：评审意见集中于格式问题，逻辑缺陷遗漏到测试阶段”。
字段填写。行动项内容为“制定并启用代码评审检查清单”。负责人写“张明（后端）”；截止时间写“第13迭代结束前（3月14日）”；验收标准写“检查清单模板发布到团队文档，并在第13迭代至少两次评审中使用，评审记录中可见清单项被逐条确认”；来源问题与上述回顾问题对应。
中间状态更新与逾期处理。张明在3月7日将状态更新为“进行中”，说明模板初稿已完成、待团队评审；3月14日状态仍为“进行中”，原因是团队评审时间冲突。Scrum Master 在每周检查中发现该逾期项，记录处理意见：与张明确认改为3月18日完成，并在下次回顾中说明延期原因。3月17日张明更新状态为“已完成”，附上模板文档链接和两次评审记录。
下次回顾核对结论。第13迭代回顾开场，主持人逐条核对上轮行动项。该行动项状态为已完成，验收标准中的模板发布和两次评审使用均有记录，核对结论为“关闭”。团队同时讨论清单使用效果，决定新增一条行动项“在评审记录中统计清单项确认率”，进入下一轮跟踪。
这个示例说明：行动项的价值不只在完成，更在于每条状态变化都有记录、每次逾期都有处理意见、每个结论都能在下次回顾中被核对。字段填写清楚，核对时就不需要回忆和争论。
用工作项系统承载行动项跟踪
行动项较少时，一份共享表格可以支撑跟踪；当行动项数量增多、跨多个迭代并行时，表格容易遗漏状态更新和逾期提醒。此时可以把行动项作为工作项登记到团队已有的工作项系统中，让状态、负责人和截止时间成为结构化字段，而不是文档里的自由文本。
承载方式可以从三个检查点设计：
- 登记类型与字段。为行动项设置独立的工作项类型，至少包含负责人、截止时间、验收标准、来源迭代四个字段。来源迭代字段用于区分行动项属于哪一轮回顾，便于下次回顾按来源筛选。
- 状态流转与逾期可见性。为行动项配置未开始、进行中、已完成、受阻等状态，并通过列表或看板按截止时间排序，让逾期项在每周检查时直接可见。状态变更保留操作记录，便于核对时追溯。
- 按来源迭代筛选核对。下次回顾前，按来源迭代筛选出上轮全部行动项，逐条核对状态和验收标准，核对结论记录在回顾文档中。
ONES 在这条链路上可以承担工作项承载的角色。ONES Project 适配任务管理、迭代管理等场景，支持将需求和相关任务规划至迭代并分配负责人，看板、燃尽图等工具用于实时掌控进度；团队可以把行动项作为工作项登记，分配负责人和截止时间，通过看板查看状态。ONES 敏捷研发管理解决方案覆盖迭代回顾场景，支持在迭代完成后召开回顾会，结合燃尽图、工时日志等数据复盘迭代进度、质量和成本偏差，讨论改进建议；回顾结论和核对记录可以用 ONES Wiki 沉淀为团队知识库，Wiki 支持文档关联任务，并可插入 ONES Project 的工作项列表，便于在回顾文档中直接查看行动项状态。
需要说明的是，行动项是否作为独立工作项类型、逾期提醒如何配置、状态流转如何自定义，取决于团队在 ONES 中的实际配置和开通情况，建议在启用前与管理员确认字段和工作流设置。工具承载的是状态和可见性，负责人确认、逾期处理和下次回顾核对仍需按前述角色分工执行。
完成检查：行动项跟踪是否真的闭环
判断跟踪机制是否有效，不看清单有多长，而看每条行动项是否都能回答“谁负责、何时完成、完成到什么程度、下次回顾怎么核对”。以下清单可在每次回顾结束后和下次回顾开场前逐项核对。
| 检查项 | 核对方式 | 通过标准 |
|---|---|---|
| 每条行动项是否都有负责人和截止时间 | 查看行动项清单或工作项字段 | 无空缺，负责人为具体个人，截止时间为具体日期 |
| 每条行动项是否有可观察的验收标准 | 逐条阅读验收标准 | 能通过文档、记录或数据确认完成状态 |
| 逾期项是否有处理记录 | 查看每周检查记录 | 每个逾期项都有原因说明和下一步安排 |
| 下次回顾是否逐条核对上轮行动项 | 查看回顾会议记录 | 上轮每条行动项都有核对结论 |
| 未完成项是否重新评估 | 查看核对结论 | 明确继续、改期或关闭，无默认结转 |
| 行动项与来源问题是否对应 | 抽查行动项的来源字段 | 每条行动项都能追溯到具体回顾问题 |
这份清单可以在每轮回顾结束时花几分钟过一遍，重点看前两项：负责人和截止时间是否齐全、验收标准是否可观察。这两项决定了后续检查是否有依据。如果连续多轮出现逾期项无处理记录，说明检查节奏或角色分工需要调整，而不是行动项本身的问题。
闭环的标志不是所有行动项都按时完成，而是每条行动项都有明确的状态和结论：完成的有关闭依据，未完成的有人说明原因并给出下一步。做到这一点，回顾记录才真正转化为团队的改进行动。
常见问题
回顾会上无法当场确定负责人或截止时间，怎么办？
当场明确由谁在什么时间补齐，并把“补齐负责人和截止时间”本身作为一条行动项登记，写清补齐人和补齐日期。这样“待定”不会长期挂起，下次检查时也有据可查。如果一条行动项连续两轮都无法确定负责人，通常说明它对应的改进方向还不清晰，建议回到来源问题重新讨论，或先关闭、等条件成熟再提出。
行动项跨迭代才能完成，截止时间和下次回顾核对怎么处理？
登记时注明跨迭代原因和预计完成日期，截止时间仍写到具体日期，不写“下个迭代”。下次回顾核对时，这类行动项单独列出，确认进展是否符合预期、预计日期是否仍然成立。跨迭代行动项同样需要在下次回顾中有核对结论，结论可以是继续、改期或关闭，避免因为周期长而脱离检查范围。
每周检查逾期项由谁做，检查频率可以调整吗？
通常由团队负责人或 Scrum Master 承担，交付物是逾期项处理记录，而不只是提醒。检查频率可以随迭代节奏调整：迭代周期短、行动项少的团队可以并入每次站会或每周一次；行动项多、跨团队协作多的团队建议固定每周一次。无论频率如何，“下次回顾开场逐条核对上轮行动项”这一步建议保留，它是闭环成立的关键节点。
用工作项系统承载行动项时，需要先确认哪些配置？
建议先确认三件事：行动项是否作为独立工作项类型登记，负责人、截止时间、验收标准、来源迭代四个字段是否齐全；状态流转是否覆盖未开始、进行中、已完成、受阻，逾期项能否在列表或看板中直接看到；下次回顾前能否按来源迭代筛选出上轮全部行动项。ONES 可作为承载工具之一，ONES Project 支持将任务规划至迭代并分配负责人，看板用于查看状态；具体字段、工作流和提醒的配置方式取决于团队实际开通情况，启用前与管理员确认。
行动项长期完不成，是跟踪机制的问题还是行动项本身的问题？
先看逾期处理记录。如果每个逾期项都有原因说明和下一步安排，说明跟踪机制在运转，问题可能出在行动项本身：验收标准过大、负责人没有相应资源，或改进方向与当前迭代目标冲突。这时应在下次回顾中重新评估，拆小、改期或关闭。如果连续多轮出现逾期项无处理记录，则说明检查节奏或角色分工需要调整，例如检查人缺位、状态更新没有约定节点。
