Definition of Done（DoD）老化，通常表现为条目长期不变、评审流于形式、缺陷在交付后集中暴露。要避免这种情况，需要把 DoD 当作一份有版本、有责任人、有触发条件的团队约定：先记录现状基线与执行偏差，再设定固定评审节奏和事件触发条件，评审后逐条小步调整，并用交付质量指标验证改动是否有效。本文按这六个环节给出可落地的评审机制。
要点总览（TL;DR）
- 先给 DoD 建立现状基线：记录条目、版本、最近修改时间，并收集条目被跳过、被口头放宽等执行偏差，作为判断老化的依据。
- 评审机制用固定节奏加事件触发：按迭代做轻量检查、按季度做完整评审，遇到质量事故、流程变更或团队规模变化时随时发起。
- 评审产出应是逐条改动而非整篇重写，每次调整少量条目，记录版本与生效时间，保留旧版本以便回退。
- 改动后用交付后缺陷、返工次数、条目跳过率等指标在固定观察窗口内验证，并区分人员变动、需求规模等其他因素。
- 这套机制适合已有成文 DoD 且愿意投入评审时间的团队，代价是会议与文档维护成本，以及改动初期的执行波动。
当前 DoD 的现状基线与老化信号
判断 DoD 是否老化，先要有一份可对照的现状记录。没有基线，评审时只能凭印象争论，改动也无法验证。建议团队用一张表把当前 DoD 固定下来，包含条目内容、版本号、最近一次修改时间、责任人和适用范围。
基线表之外，更重要的是收集执行偏差。DoD 写在文档里和实际执行之间往往有差距，这些差距正是老化的直接证据。可以从三个渠道收集：迭代回顾会上团队成员的反馈、代码评审和测试记录中的实际检查项、交付后缺陷所暴露的遗漏环节。
| 记录项 | 填写内容示例 | 用途 |
|---|---|---|
| DoD 条目 | “所有新增接口需有自动化测试覆盖” | 作为逐条评审的对象 |
| 版本与修改时间 | v1.2，最近修改于三个月前 | 判断条目是否长期未变 |
| 执行偏差 | 该条目在近三个迭代中被跳过两次，一次口头约定“下个迭代补” | 识别条目与实际流程的脱节 |
| 老化信号 | 评审会连续两次未讨论 DoD；交付后缺陷集中在未覆盖的接口 | 触发评审或调整的依据 |
常见的老化信号包括：条目超过半年未修改；评审会开了但没有产生任何变更；团队对新成员解释 DoD 时说法不一致；交付后缺陷集中出现在 DoD 未覆盖的环节；条目被频繁口头放宽。把这些信号列成清单，每次评审前对照检查，比凭感觉判断更可靠。
DoD 老化的常见瓶颈与误区
DoD 老化很少是单一原因造成的，按性质可以归为三类：机制缺失、节奏缺失、内容失配。区分原因有助于选择对应的改进动作，避免把所有问题都归结为“团队不重视”。
| 原因类别 | 典型表现 | 后果 |
|---|---|---|
| 机制缺失 | DoD 是一次性文档，没有责任人，没有变更入口，改动靠口头传播 | 条目与实际流程逐渐脱节，无人察觉 |
| 节奏缺失 | 评审与迭代回顾脱节，没有固定时点，也没有质量事故等触发条件 | 问题积累到交付事故才被提起 |
| 内容失配 | 条目只增不减；照搬其他团队模板；条目描述模糊无法检查 | 条目过多导致执行疲劳，或条目与自身流程不匹配 |
机制缺失是最容易被忽视的一类。很多团队在项目启动时认真讨论出 DoD，之后就没有明确的修改入口，谁都可以提意见，但没有人负责收口。结果是条目要么僵化不动，要么被零散口头修改，版本无法追溯。
节奏缺失表现为评审依赖临时起意。质量事故发生后团队会讨论一轮，事故过去后讨论也随之停止。把评审挂到固定的回顾节奏上，再补充事件触发条件，才能保证既不遗漏也不过度频繁。
内容失配常见于两种极端：一是条目只增不减，每次出问题就加一条，最终 DoD 变成一份没人完整执行的清单；二是直接照搬行业模板或其他团队的 DoD，条目看似完整，却与自身的技术栈、发布方式和质量要求不匹配。另一个误区是把评审等同于重写，每次评审都推翻重来，团队无法判断哪次改动起了作用。小步调整、逐条验证，比一次性重写更容易观察效果。
定期评审的节奏、触发条件与角色分工
评审机制要同时解决“什么时候评”和“谁来评”两个问题。固定节奏保证评审不被遗忘，事件触发保证问题出现时能及时响应，两者配合使用。
固定节奏方面，可以按迭代设置轻量检查、按季度设置完整评审。轻量检查放在迭代回顾中，用十到十五分钟对照基线表和老化的信号清单，确认是否有条目需要调整；完整评审每季度一次，逐条审视全部条目，结合缺陷与返工数据做增删改。团队规模较小或交付节奏较慢时，也可以只保留季度评审，避免会议负担过重。
事件触发条件建议明确写下来，出现以下情况时不必等到固定时点，直接发起评审：出现交付后严重质量事故；发布流程、技术栈或测试方式发生变更；团队规模明显变化或新成员比例较高；连续多个迭代出现同一条目被跳过。触发条件写清楚，可以减少“要不要开会”的反复讨论。
| 角色 | 职责 |
|---|---|
| 提议人 | 任何团队成员均可根据老化信号或触发条件提出评审请求 |
| 评审参与者 | 产品、开发、测试等实际执行 DoD 的角色共同参与，确保条目可检查 |
| 批准人 | 通常由团队负责人或质量负责人确认改动，避免条目被随意放宽 |
| 记录人 | 维护版本号、生效时间和变更理由，保证旧版本可查可回退 |
评审输入应提前准备，包括现状基线表、上一周期的缺陷与返工数据、条目跳过记录以及团队反馈。输入齐备，评审才能围绕证据讨论，而不是停留在感受层面。
这些记录需要有稳定的承载位置。ONES Wiki 支持文档关联任务，并支持插入 ONES Project 的工作项列表，团队可以把 DoD 条目、版本记录和评审结论放在同一份文档中，并与相关的缺陷、测试工作项关联，让评审输入和结论保持可追溯。
优先改进动作：逐条演进 DoD 的操作步骤
评审的产出应当是一组具体的条目改动，而不是一份新的完整文档。逐条处理可以控制改动幅度，也便于后续验证。
- 逐条判断动作。对每个条目给出保留、修改、新增或删除的结论，并写明理由。理由要指向具体证据，例如“近三个迭代该条目被跳过两次，且对应环节未出现交付缺陷，建议删除或降级为建议项”。
- 控制单次改动量。每次评审调整少量条目，例如三到五条，便于在下个迭代观察执行情况。改动过多会让团队难以判断哪一条起了作用。
- 记录版本与生效时间。每次改动生成新版本号，写明生效时间，旧版本保留可查。回退时可以直接指向旧版本，不需要重新讨论。
- 同步到团队可见位置。把新版本放到团队日常查看的位置，并在下一次迭代开始时说明改动内容，确保执行者知道当前有效的是哪一版。
- 在下一次迭代中试用。新条目先在小范围试用，观察是否可检查、是否增加不必要的负担，再决定是否固化。
| 条目 | 动作 | 理由 | 版本 | 生效时间 |
|---|---|---|---|---|
| 所有新增接口需有自动化测试覆盖 | 修改 | 原条目未区分接口类型，改为“对外接口需有自动化测试，内部接口需有单元测试” | v1.3 | 下个迭代开始 |
| 每次发布需完成回归测试 | 保留 | 近三个迭代执行稳定，交付后无相关缺陷 | v1.3 | 不变 |
| 所有需求需有完整设计文档 | 删除 | 与实际流程脱节，团队已改用轻量设计说明，条目长期被跳过 | v1.3 | 下个迭代开始 |
变更记录表本身就是评审的交付物。它让每次改动都有据可查，也为效果验证提供了对照基础。
适用前提与代价
这套机制适合已经有一份成文 DoD、并且团队愿意投入固定时间维护的团队。如果 DoD 尚未建立，或者团队还没有稳定的迭代节奏，建议先完成基础建设，再引入定期评审。
需要付出的代价主要有三项：评审与维护占用团队时间，按迭代的轻量检查加上季度完整评审，全年累计是若干小时的会议与记录工作；改动初期可能带来执行波动，新条目需要适应期，团队可能短暂出现执行不一致；记录版本和变更理由增加了文档维护工作，需要有人持续负责。
边界也需要说明：Sprint 规划、执行与回顾的具体做法属于迭代管理范畴，需求池的维护属于需求池管理范畴，本文只讨论 DoD 本身的评审与演进。把这些边界分清，可以避免评审会变成对整个研发流程的泛泛讨论。
效果验证：如何判断 DoD 评审是否有效
验证的目标是判断改动是否带来了可观察的改善，而不是证明评审本身有价值。建议在改动前确定观察窗口，例如改动生效后的两到三个迭代，并记录改动前后的指标取值。
| 指标 | 改动前 | 改动后 | 观察窗口 | 结论 |
|---|---|---|---|---|
| 交付后缺陷数 | 每迭代若干条，集中在接口测试缺失环节 | 待记录 | 改动后两个迭代 | 待评估 |
| 返工次数 | 待记录 | 待记录 | 改动后两个迭代 | 待评估 |
| 条目跳过率 | 部分条目每迭代被跳过 | 待记录 | 改动后两个迭代 | 待评估 |
解读指标时要区分其他因素的影响。同期可能发生了人员变动、需求规模变化或发布流程调整，这些都会影响缺陷和返工数据。比较稳妥的做法是结合具体缺陷的分布来判断：如果交付后缺陷确实集中在改动所针对的环节，并且数量下降，才能初步认为改动起了作用。
ONES 系统自动记录和统计资源投入、缺陷分布、工作项滞留时间等研发过程数据，可以作为验证的参考来源之一。具体指标口径仍需团队根据自身情况定义。
如果指标没有改善，或者执行阻力明显增大，例如新条目频繁被跳过、团队反馈负担过重，应按版本回退到上一版，重新评估改动理由。回退不是失败，而是验证机制正常工作的表现。每次验证的结论应带回下一次评审，作为下一轮调整的输入，让 DoD 的演进形成闭环。
常见问题
团队还没有成文的 DoD，能直接开始定期评审吗？
建议先完成基础建设。定期评审的对象是一份具体的条目清单，没有成文 DoD 时，评审会容易变成对质量标准的泛泛讨论，结论也难以记录和验证。可以先用一次工作坊把当前实际执行的质量要求写下来，形成第一版 DoD 和基线表，再引入固定节奏与触发条件。如果团队连稳定的迭代节奏都还没有，也可以先只保留季度完整评审，等节奏稳定后再增加按迭代的轻量检查。
评审会上条目争议很大、无法达成一致时怎么处理？
把争议条目单独拿出来，先明确它要解决的具体问题，再决定动作。常见做法是：暂时保留原条目，同时指定一名成员在下个迭代收集该条目相关的执行记录和缺陷数据，下次评审带着证据再讨论。这样可以避免在缺乏依据的情况下反复争论，也防止条目被情绪化地放宽或删除。如果争议涉及多个角色对质量标准的理解差异，可以让实际执行该条目的开发、测试人员先给出可检查的表述，再交由批准人确认。
DoD 条目应该控制在多少条比较合适？
没有统一的数量标准，判断依据是条目能否被完整执行和检查。如果团队频繁跳过某些条目，或者新成员需要很长时间才能记住全部条目，说明条目数量或表述已经超出可执行范围。可以在评审时逐条追问：这一条在上个迭代是否真的被检查过、由谁检查、依据什么证据。长期无法回答这些问题的条目，考虑合并、改写为可检查的表述，或降级为建议项。条目数量本身不是目标，可执行和可验证才是。
改动 DoD 后团队执行不到位，应该先回退还是先加强推行？
先判断执行不到位的原因。如果是条目本身不可检查、与现有流程冲突或负担明显过重，应按版本回退并重新评估改动理由；如果是团队对新条目还不熟悉，可以给一个迭代的适应期，在下一次迭代开始时明确说明改动内容和检查方式，再观察执行情况。两种情况的区分依据是执行记录：条目被跳过时，是因为做不到、不知道怎么做，还是单纯遗忘。把原因记录下来，带回下一次评审，比笼统地强调“要重视”更有助于解决问题。
多个团队共用一份 DoD 时，评审节奏怎么协调？
可以分层处理：组织级或项目级共用的条目由跨团队的代表按季度评审，各团队在此基础上补充自己特有的条目，并按迭代做轻量检查。共用条目的改动需要提前通知受影响的团队，并给出统一的生效时间，避免各团队执行版本不一致。各团队的补充条目则在本团队的回顾中处理，不必上升到跨团队评审。无论哪种层级，版本记录和变更理由都应保留在团队可访问的位置，方便追溯和回退。
