完成定义（DoD）需要随团队成熟度定期评审和演进，才能持续支撑交付质量。本文从建立现状基线开始，说明定义老化的常见原因，给出按成熟度分层调整的路径，以及评审、变更记录和效果验证的具体做法。文末会自然衔接ONES在验收标准与迭代回顾中的承载方式。
要点总览（TL;DR）
- 先给完成定义建立基线：逐条记录来源、颗粒度和实际执行情况，并区分团队级DoD与单条工作项的验收条件。
- DoD老化多因缺少评审节奏、条目只增不减、颗粒度与成熟度错位、写完不用于验收，评审时要对照证据逐条判断保留、修改、新增或删除。
- 按起步、成长、成熟三个阶段调整条目颗粒度与评审频率：起步每两到三个迭代评审一次，成长与成熟阶段以每季度为主，流程变更或质量事故时额外触发。
- 每次评审后记录版本、生效时间、适用范围和责任人，并在验收环节实际使用，DoD才具备约束力。
- 用遗漏项、返工次数、验收争议和缺陷逃逸等指标对照评审前后若干迭代的变化，同时区分人员、需求等其它因素的影响。
当前做法与目标：先给完成定义建立基线
演进的第一步是看清现状。很多团队的DoD写在某份文档里，条目来源混杂：一部分来自敏捷培训模板，一部分是某次质量事故后临时补的，还有一部分是某位资深成员的个人习惯。条目颗粒度也不统一，有的写“代码已提交”，有的写“通过集成测试且无P1缺陷”。如果不先梳理，后续评审很容易变成在模糊基础上继续叠加。
建立基线时，建议把现有DoD逐条列出，并标注三项信息：条目来源（模板、事故复盘、团队约定）、颗粒度（可自动验证、需人工检查、仅口头确认）、实际执行情况（每次交付都检查、偶尔检查、写完未用）。这份清单不需要很长，但要真实反映团队当前状态。
同时要区分两个层次。团队级DoD描述“一个工作项被认为完成时，团队共同要求满足的条件”，适用于所有进入交付的工作项；单条工作项的验收条件描述“这个具体需求做到什么程度算完成”，由需求本身决定。两者混在一起，会导致DoD越来越长、越来越像需求说明书。团队级DoD保持精简稳定，单条验收条件随需求变化，是后续演进的基本结构。
演进目标可以归纳为三点：减少交付遗漏和返工，让完成标准可以被检验，让定义与团队当前能力匹配。条目数量本身不是目标，条目多不等于质量高，条目少也不等于不严谨。判断标准是：每条都能回答“谁来检查、用什么证据判断、不满足时怎么处理”。
完成基线清单后，团队会得到一份现状记录：现有条目、执行偏差、目标改进方向。这份记录是后续每次评审的对照起点。
完成定义为什么会老化：常见瓶颈与误区
DoD老化通常不是一次发生的，而是几个小问题叠加。最常见的是缺少固定评审节奏：定义在项目初期建立后，再没有人主动回看，团队人员换了几轮，条目还停留在最初版本。另一种情况是条目只增不减，每次出问题就加一条，几年后变成几十条清单，执行时没人逐条核对，反而失去约束力。
团队成熟度提升后，原有条目会出现两种错位。一种是过粗：早期团队可能只要求“自测通过”，当团队具备自动化测试能力后，这条标准无法区分基本自测和回归验证。另一种是过细：早期为了建立纪律，要求每个小改动都走完整评审，成熟后这类条目会增加不必要的检查成本，需要合并或调整触发条件。
更隐蔽的问题是DoD与实际交付检查脱节。定义写在文档里，验收时却只看需求描述和演示效果，DoD从未进入验收动作。这种情况下，即使条目写得合理，也无法影响交付质量，评审时也缺少真实执行证据。
| 现象 | 常见成因 | 对交付的影响 |
|---|---|---|
| DoD长期停留在初建版本 | 没有固定评审节点，无人负责发起 | 标准与团队能力脱节，新成员按旧标准执行 |
| 条目只增不减 | 每次问题后追加，缺少合并与删除机制 | 清单过长，执行时选择性忽略 |
| 条目过粗或过细 | 未随成熟度调整颗粒度 | 过粗漏检风险，过细增加检查负担 |
| 写完不用于验收 | 验收流程与DoD分离，缺少检查动作 | 定义失去约束力，问题重复出现 |
按成熟度分层：完成定义如何随阶段调整
成熟度分层不是给团队贴标签，而是帮助判断当前DoD应该关注什么。下面按起步、成长、成熟三个阶段给出调整方向，团队可以对照自身情况选择起点，不必严格逐级推进。
起步阶段，团队对交付节奏和协作方式还在磨合，DoD应少而明确，聚焦可交付和基本质量底线。典型条目包括：需求已实现并自测、代码已合入主干、相关方已确认演示结果。这个阶段条目数量控制在五到八条，每条都能被直接观察。评审频率可以设为每两到三个迭代一次，调整幅度以增删一两条为主。
成长阶段，团队已有稳定迭代节奏，开始出现跨角色协作和交付一致性要求。DoD可以补充测试、评审、文档等检查项，并明确责任角色。例如：测试用例已执行并记录结果、接口变更已同步下游、必要的使用说明已更新。这个阶段要避免把所有好实践都写进DoD，优先纳入与近期返工和遗漏直接相关的条目。评审频率可设为每季度一次，或在流程变更后触发。
成熟阶段，团队具备较好的工程实践和数据基础，DoD条目可以细化到可自动或可证据化验证。例如：持续集成流水线通过、关键路径有自动化回归覆盖、缺陷修复附带回归用例。这个阶段的重点从“补条目”转向“验证条目是否仍被执行”，评审时更多讨论删除过时条目和调整检查方式。评审频率保持每季度一次即可，重大流程变化时额外评审。
| 成熟度阶段 | DoD颗粒度与检查项 | 评审频率 | 调整幅度 |
|---|---|---|---|
| 起步 | 少而明确，聚焦可交付与基本质量底线，条目可直接观察 | 每两到三个迭代 | 每次增删一两条 |
| 成长 | 补充测试、评审、文档检查项，明确责任角色 | 每季度或流程变更后 | 围绕近期返工和遗漏增删 |
| 成熟 | 细化到可自动或可证据化验证，关注执行一致性 | 每季度，重大变化时额外评审 | 以删除过时条目、调整检查方式为主 |
定期评审与演进的操作步骤
评审要落到具体动作，关键是明确谁发起、在什么节点评审、怎么改、怎么生效。以下步骤可以作为团队的操作清单，按实际情况裁剪。
第一步，设定评审触发点。固定周期建议每季度一次，与迭代回顾错开，避免回顾会时间被占满。事件触发包括：交付流程发生变更、出现重复性质量事故、交付模式调整（如从单体发布转为持续交付）、团队人员结构明显变化。触发点写进团队约定，由Scrum Master或团队负责人负责提醒。
第二步，在回顾会或专门评审会中逐条讨论。评审依据是证据，不是印象。可以提前收集上个周期的遗漏项、返工记录、验收争议和缺陷逃逸情况，对照现有DoD逐条判断：这条是否仍被执行、是否仍能区分完成与未完成、是否需要合并或删除。讨论时给每条结论标注处理方式：保留、修改、新增、删除。
第三步，记录变更。每次评审后更新DoD文档，写清版本号、生效时间、适用范围和责任人。变更记录不需要复杂，一张表即可：变更日期、变更条目、变更原因、生效迭代、负责人。这样下次评审时可以回看条目演变，判断哪些调整真正起了作用。
第四步，宣导并在验收环节使用。新版本生效前，在迭代计划会或团队例会上说明变更内容和原因。验收时把DoD作为检查依据，逐条确认或记录未满足项。只有进入实际验收动作，DoD才具备约束力，评审时也才有执行证据可看。
在工具承载上，团队可以把DoD文档放在ONES Wiki中，与迭代或工作项关联，评审时直接对照文档和交付记录讨论；需求与验收标准在迭代计划阶段达成一致后，测试人员依据验收标准编写和执行测试用例，未通过用例可转为缺陷提交并指派修复，这些记录可以作为下轮评审的证据来源。迭代回顾时，团队可以结合燃尽图、工时日志等报表复盘进度与质量偏差，并把评审结论沉淀回Wiki，形成可追溯的变更记录。
适用前提与代价：演进需要投入什么
定期评审DoD需要几个前提。团队对完成标准要有基本共识和执行力，如果成员对“完成”的理解差异很大，评审会容易变成争论而不是改进。团队需要能拿到交付证据，包括测试记录、缺陷数据、验收反馈，否则评审只能凭印象。还需要有人负责发起和记录，这个角色可以由Scrum Master、团队负责人或轮值成员承担。
代价主要体现在时间上。每次评审和变更记录会占用回顾会或专门会议的时间，按团队规模不同，通常需要半小时到一小时。条目过细会增加日常检查成本，每条都要求证据化验证时，团队需要在交付速度和检查深度之间权衡。跨团队或依赖外部交付时，DoD协调成本更高，需要对齐多个团队的完成标准，变更也要同步通知相关方。
这些投入是否值得，取决于团队当前的质量风险。如果返工和验收争议频繁，评审投入通常能换来明显改善；如果交付一直稳定，评审可以保持较低频率，以维护为主。
效果验证：如何判断演进是否有效
验证演进效果，建议以评审前后若干迭代为观察窗口，对照一组可观察指标：遗漏项数量（验收时发现但DoD未覆盖的问题）、返工次数、验收争议次数、缺陷逃逸情况（交付后发现的缺陷）。这些指标在评审前先记录基线，评审后按同样口径继续记录，比较变化趋势。
比较时要注意区分其他因素。人员变动、需求规模变化、外部依赖调整都可能影响上述指标，不能把全部变化归因于DoD调整。可以结合变更记录，看某条新增或修改的条目是否对应了特定问题的减少。如果某条新增后相关遗漏明显下降，说明这条有效；如果新增后执行率很低，说明条目本身或检查方式需要再调整。
还要定期回看变更记录，判断条目是否仍被执行。执行率是比条目数量更直接的信号：一条从未被检查的条目，无论写得多好都不产生作用。评审时可以抽查最近几个迭代的验收记录，确认DoD条目是否实际进入检查动作。发现长期不执行的条目，要么调整检查方式，要么删除，避免定义继续膨胀。
常见问题
团队规模很小，也需要按季度评审完成定义吗？
评审频率可以按团队实际情况调整。小团队沟通成本低，起步阶段每两到三个迭代评审一次即可；进入稳定期后，如果返工和验收争议很少，可以降低到每季度一次，以维护为主。关键是保留固定触发点，避免定义长期无人回看。流程变更、重复性质量事故或人员结构明显变化时，仍应额外安排评审。
完成定义和单条需求的验收条件应该怎么分工？
团队级DoD描述所有进入交付的工作项共同要求满足的条件，应保持精简稳定；单条工作项的验收条件由需求本身决定，随需求变化。两者混在一起，DoD会越来越长、越来越像需求说明书。评审时可以先判断某条内容属于哪一层，属于具体需求的移入验收条件，属于团队通用要求的留在DoD中。
评审会上讨论DoD，应该依据哪些材料？
依据证据而不是印象。可以提前收集上个周期的遗漏项、返工记录、验收争议和缺陷逃逸情况，对照现有条目逐条判断是否仍被执行、是否仍能区分完成与未完成。在ONES中，需求与验收标准在迭代计划阶段达成一致后，测试人员依据验收标准编写和执行测试用例，未通过用例可转为缺陷提交并指派修复，这些记录可以作为评审的证据来源；迭代回顾时还可结合燃尽图、工时日志等报表复盘进度与质量偏差。
新增的DoD条目执行率很低，应该怎么处理？
先判断原因：如果条目本身合理但检查方式太重，可以简化验证手段或调整触发条件；如果条目与实际质量风险关联不大，可以考虑删除。评审时抽查最近几个迭代的验收记录，确认条目是否实际进入检查动作。长期不执行的条目会稀释整份定义的约束力，需要及时清理或改造。
跨团队协作时，完成定义的协调要注意什么？
跨团队或依赖外部交付时，需要对齐多个团队的完成标准，变更也要同步通知相关方。协调成本主要体现在对齐会议和通知环节，建议把各方共同认可的条目写成共享基线，各团队再在此基础上补充自身条目。变更生效前留出通知时间，避免一方已按新标准验收、另一方仍按旧标准交付。
