团队对“完成”理解不一致，通常源于完成标准缺失、模糊或未被执行，表现为交付后频繁返工和评审争议。调整方向是把各自默认的“完成”写出来对照，改成可观察、可验证、有检查人的DoD条目，再嵌入计划、评审、验收和回顾环节持续校准，用返工记录验证效果。
要点总览（TL;DR）
- 先让每位成员写出自己判断“完成”的实际依据，用近期返工和评审争议定位缺口，把调整目标落到具体返工类型上。
- 把模糊表述改写为可判断通过/不通过、有检查方式和检查人的条目，区分团队级DoD与单条工作项的验收条件，条目数量优先覆盖返工最集中的环节。
- DoD要进入计划、开发完成、评审、验收各环节的实际动作，并在回顾会上依据返工记录增删修订，保留版本变化。
- 调整需要前期对齐会议和持续的检查时间投入，需求频繁变动或外部依赖多时保留弹性，标准过细会带来流程僵化风险。
- 用返工次数、返工类型分布和评审争议数量做调整前后对照，结合返工类型判断变化是否来自DoD覆盖的环节。
先看清当前“完成”是怎么被各自理解的
调整DoD的第一步是建立现状基线。团队口头说“做完了”，实际依据往往分散在不同角色和环节里：开发认为代码提交、自测通过即完成；测试认为用例执行完毕、无阻塞缺陷才算完成；产品负责人可能把演示通过当作完成。这些默认理解很少被写下来，直到评审或上线后才暴露差异。
建议用一次专门会议，让每位成员写出自己判断“完成”的实际依据，再汇总对照。清单可以按以下维度整理：
- 口头约定：站会上说过但未记录的条件，如“接口联调完就行”。
- 个人习惯：某位开发固定会补单元测试，另一位依赖测试兜底。
- 评审临时标准：评审时才提出“这个要加监控”“文档还没更新”，说明标准此前未明确。
接着用近期返工和交付争议定位缺口。例如某需求上线后因缺少回归测试返工，说明“相关用例通过”未被列为完成条件；某次评审因文档缺失被退回，说明“交付文档更新”只存在于个别人的习惯中。把每起返工对应到具体缺失或模糊的环节，现状清单就有了事实依据。
本次调整的目标要具体到可观察的范围，例如“减少因验收标准不清导致的评审退回”“减少上线后因遗漏测试或文档产生的返工”，避免写成“提升交付质量”这类无法验证的表述。
分歧集中在哪：DoD失效的常见原因
理解不一致背后通常有三类机制，区分它们才能对症调整。
| 原因类型 | 典型表现 | 调整方向 |
|---|---|---|
| 标准缺失 | 团队从未把完成条件写下来，全靠默契 | 补写条目，从返工最集中的环节开始 |
| 标准模糊 | 写了“代码质量良好”“文档齐全”，无法判断是否满足 | 改写为可判断通过/不通过的形式 |
| 标准未被执行 | 有DoD，但评审和验收不按它走，或只在形式上看一眼 | 明确检查人和检查时点，挂到验收环节 |
归类时要把返工归因到具体条目，避免笼统归为“态度不认真”。例如“上线后接口报错返工”应归到“接口异常场景已验证”这一缺失条目，而非归为开发粗心。归因越具体，后续改写越有针对性。三类原因可能同时存在，同一团队不同环节的短板也不同，逐条标注即可。
把DoD改成可检查的条目
改写的基本原则是每条标准都能被第三方判断通过或不通过，并说明用什么方式检查。模糊表述要替换为可观察的动作或产物，例如把“代码质量良好”改为“静态检查无新增严重告警，关键逻辑有对应单元测试且通过”；把“文档齐全”改为“接口文档已更新并与实现一致，变更说明已记录”。
同时要区分团队级DoD和单条工作项的验收条件。团队级DoD适用于所有工作项，如代码评审完成、相关测试通过、无阻塞缺陷；单条工作项的验收条件描述该需求特有的业务规则和边界场景，写在需求或任务上。两者分开管理，避免团队级DoD被个别需求的特例撑得过于臃肿。
每条标准还需明确检查人和检查时点。检查人可以是开发自检、评审人复核或测试确认，时点对应开发完成、提测、评审或验收。下表是一版改写后的条目表示例，可按团队实际填写：
| DoD条目 | 判断方式 | 检查人 | 检查时点 |
|---|---|---|---|
| 代码评审已通过且意见已处理 | 评审记录显示通过，遗留意见关闭 | 评审人 | 提测前 |
| 相关测试用例执行通过 | 用例结果无失败，阻塞缺陷为零 | 测试人员 | 验收前 |
| 接口文档与实现一致 | 对照接口清单逐项核对 | 开发自检、评审抽查 | 开发完成时 |
| 需求特有边界场景已验证 | 验收条件逐条勾选 | 产品负责人 | 验收时 |
条目数量要控制。优先覆盖返工最集中的两三个环节，先解决主要缺口，再逐步补充。一次写入二三十条会让执行成本过高，反而促使团队跳过检查。
让DoD进入日常流程并持续校准
DoD只有进入各环节的实际动作才有效。计划阶段，团队在拆分需求时对照团队级DoD确认哪些条件适用，并把需求特有的验收条件写清楚；开发完成时，开发按条目自检后再提测；评审和验收时，检查人逐条核对，不满足的条目直接退回或转为待办，而不是口头放行。
回顾会是校准DoD的主要场合。团队依据本迭代的返工记录和评审争议，讨论哪些条目缺失、哪些表述仍模糊、哪些检查动作流于形式，形成增删改的具体决定。修订要有触发条件和记录方式：出现同类返工两次以上、评审中对同一条件反复争议、外部依赖或流程变化导致原条目不再适用，都可以触发修订。每次修订保留版本和变更说明，便于追溯某条标准何时加入、为何调整。
在工具层面，DoD条目需要挂到工作项的验收环节，修订记录需要可留存。ONES Project 支持编写需求、自定义需求状态与多种属性，并可将需求和相关任务规划至迭代、分配负责人；团队可以把验收条件随需求一起维护，在提测和验收时对照检查。测试环节中，测试工程师可根据迭代要完成的需求与验收标准编写测试用例，未通过用例可转换为缺陷提交并指派修复，使验收标准与缺陷流转衔接起来。迭代回顾后，可用 ONES Wiki 将DoD版本和复盘结论沉淀为团队知识库，ONES Wiki 支持文档关联任务，便于条目与工作项对照。具体字段配置和报表口径以实际版本为准。
调整的代价与适用前提
推行调整后的DoD需要真实投入。前期梳理现状、逐条对齐表述、确定检查人和时点，通常要占用一到两次专门会议，加上会后整理；此后每个工作项的检查动作也会增加评审和验收时间。团队对检查动作的接受度直接影响执行质量，如果检查被视为额外负担，条目很快会退化为形式。
以下条件需要提前考虑：
- 需求频繁变动时，单条工作项的验收条件要保留调整空间，团队级DoD保持稳定，需求特有条件随变更同步更新。
- 外部依赖多时，可把“依赖方确认”写成带条件的条目，注明未满足时的处理方式，避免因外部阻塞让整个验收停滞。
- 标准过细会导致流程僵化，条目应聚焦影响交付结果的关键条件，把风格偏好类要求留在评审讨论中。
- 团队规模较小、协作默契度高时，可以从少量核心条目起步，逐步补充，不必一次求全。
这些前提说明DoD调整是渐进过程，先覆盖主要返工来源，再根据执行反馈扩展，比一次性制定完整清单更可持续。
怎么判断调整有效
效果验证要选可观察的指标并设定对照窗口。常用指标包括：单位时间内返工次数、返工类型分布（测试遗漏、文档缺失、评审退回等）、评审争议数量及涉及条目。调整前记录一个基线周期，例如两到三个迭代，调整后按同样长度观察，比较同类指标的变化。
判断时要注意区分DoD调整与其他因素的影响。需求规模变化、人员调整、外部依赖波动都可能影响返工数据，因此应结合返工类型分布看变化是否集中在DoD覆盖的环节。如果测试遗漏类返工明显下降，而文档类返工未变，说明条目覆盖不均衡，需要补充对应标准。
指标无改善时，复查方向包括：条目是否仍模糊、检查人是否实际执行、验收是否在压力下被跳过、返工记录是否完整。把复查结论带回回顾会，作为下一轮修订的输入，形成“记录—分析—修订—再观察”的循环，而不是把一次数据波动当作最终结论。
常见问题
团队已经有一份DoD，但评审时还是各说各话，问题出在哪？
常见原因是条目写了但无法判断是否满足，或者评审和验收不按它走。可以先做一次抽查：把现有DoD逐条拿出来，问“这条由谁在什么时点检查、依据什么判断通过”，答不上来的条目就是模糊或未执行的条目。对这类条目补上判断方式和检查人，并在下一次评审中实际逐条核对，比重新写一份新清单更有效。
团队级DoD和工作项的验收条件应该怎么分工？
团队级DoD适用于所有工作项，描述每次交付都要满足的通用条件，例如代码评审通过、相关测试执行通过、文档与实现一致；单条工作项的验收条件描述该需求特有的业务规则、边界场景和例外处理，写在需求或任务上。分开管理可以避免团队级DoD被个别需求的特例撑大，也便于在回顾会上分别修订：通用条目稳定演进，需求特有条件随需求变化同步更新。
需求变动频繁时，DoD会不会很快过时？
可以把稳定性放在团队级DoD上，把弹性留给单条工作项的验收条件。需求变更时，同步更新该需求的验收条件，团队级DoD保持相对稳定。外部依赖多的场景，可把“依赖方确认”写成带条件的条目，注明未满足时的处理方式，避免整个验收因外部阻塞停滞。修订时记录变更原因，便于后续判断哪些条目需要长期保留。
DoD条目是不是越细越好？
条目过细会抬高每个工作项的检查成本，团队容易在压力下跳过检查，反而削弱执行。建议先覆盖返工最集中的两三个环节，条目聚焦影响交付结果的关键条件，把风格偏好类要求留在评审讨论中。运行一段时间后，依据返工记录和评审争议再决定是否补充，比一次写入二三十条更可持续。
调整DoD后返工没有明显下降，应该先查什么？
先确认返工记录是否完整、分类是否一致，再看返工类型分布有没有变化。如果测试遗漏类返工下降而文档类未变，说明条目覆盖不均衡；如果各类返工都没有变化，需要检查检查人是否实际执行、验收是否在进度压力下被跳过、条目表述是否仍然模糊。把这些结论带回回顾会作为下一轮修订输入，并延长观察窗口，避免把一次数据波动当作最终结论。
