任务完成标准、验收标准和Definition of Done都在回答“做到什么程度算完成”，但作用对象不同：一个管单项任务能否关闭，一个管交付成果能否被接受，一个管团队对同类工作项的统一约定。本文只讨论单项任务执行闭环内的区分与配合，不涉及组织级流程制度设计。
要点总览（TL;DR）
- 任务完成标准回答“这条任务什么时候可以关闭”，对象是单项任务的执行闭环。
- 验收标准回答“这个交付成果满足什么条件才算被接受”，对象是可检验的成果质量。
- Definition of Done回答“团队约定的一类工作项必须满足哪些共同条件”，是团队级统一清单。
- 三者可以同时存在：DoD是共同底线，验收标准补充本任务成果条件，任务完成标准把两者合并为可关闭条件。
- 完成百分比只描述进度，阶段门和质量门针对阶段或里程碑，都不能替代单项任务的完成判断。
一句话区分：三者各自回答什么问题
把三个概念放进同一个提问框架，区别会立刻清晰：它们判断的对象不同，判断发生的时点也不同。
- 任务完成标准回答“这条任务什么时候可以关闭”。它针对一条具体任务，判断的是任务本身的执行闭环是否走完，比如代码已提交、文档已更新、相关评审已完成。
- 验收标准回答“这个交付成果满足什么条件才算被接受”。它针对任务产出的成果，判断的是成果质量，比如某个功能在指定条件下返回预期结果、某份报告包含约定的数据口径。
- Definition of Done（完成定义，简称DoD）回答“团队约定的一类工作项必须满足哪些共同条件”。它针对一类工作项，比如所有用户故事或所有缺陷修复，是团队层面的统一清单。
三者可以同时存在于一条任务上，作用层级不同：DoD是团队共同底线，验收标准是本任务成果的接受条件，任务完成标准是把前两者落到这条任务上的可关闭判断。理解这一点，就能避免把三者当成同义词互换使用。
定义与边界：各自管什么、不管什么
三个概念容易混用，往往是因为只看到“完成”二字，忽略了各自的对象和边界。下面逐项界定。
任务完成标准：管单项任务的执行闭环
任务完成标准的对象是单项任务，关注这条任务从开始到可关闭的全过程是否走完。它通常包含动作性条件，例如“相关代码已合并”“使用说明已更新”“对接人已确认收到交付物”。它的边界在任务执行闭环：任务关闭之后的事情，比如上线后的运营效果、后续迭代安排，不属于它的范围。
验收标准：管可交付成果的接受条件
验收标准的对象是任务产出的可交付成果，关注成果要满足哪些可检验的条件才算被接受。好的验收标准通常可以转化为测试或检查动作，例如“在并发100的条件下，接口平均响应时间低于200毫秒”“报表中每个字段都有口径说明”。它的边界在成果本身：任务内部如何分工、用了多少工时，不属于验收标准要管的内容。
Definition of Done：管一类工作项的共同约定
DoD的对象是一类工作项，属于团队级统一约定。它规定这类工作项在什么条件下才算完成，例如“所有用户故事必须通过代码评审、有自动化测试覆盖、文档已更新”。DoD的价值在于减少逐条协商，让同类工作项的完成口径保持一致。它的边界是团队约定层面：某条任务特有的验收细节，应由该任务的验收标准补充，不必写进DoD。
需要说明的是，三者都不负责组织级流程制度设计，也不承担会议决议与行动项的跟踪落实。这些属于相邻的管理主题，与本文讨论的完成判断不是同一层面。
| 概念 | 作用对象 | 判断时点 | 不覆盖的范围 |
|---|---|---|---|
| 任务完成标准 | 单项任务 | 任务准备关闭时 | 任务关闭后的运营与后续安排 |
| 验收标准 | 可交付成果 | 成果提交接受时 | 任务内部分工与工时投入 |
| Definition of Done | 一类工作项 | 团队约定形成时，逐项适用 | 单条任务的特有验收细节 |
三者如何组合：从团队约定到单项任务关闭
三者的关系可以理解为一条从团队到任务的落地链路：团队先约定共同底线，具体任务再补充自身条件，最后合并成可关闭判断。
第一步：团队约定同类工作项的DoD
团队针对一类工作项形成统一清单，作为所有同类任务的共同底线。DoD应当稳定、可复用，条目数量适中，便于逐项核对。它是团队对“这类工作项做到什么程度算完成”的公开承诺。
第二步：具体任务补充本任务的验收标准
在DoD之上，每条任务根据自身成果补充验收标准。DoD保证底线一致，验收标准保证这条任务的成果质量有明确、可检验的接受条件。两者是叠加关系，验收标准不需要重复DoD中已有的通用条目。
第三步：任务完成标准合并为可关闭条件
任务完成标准把DoD与验收标准落到这条任务上，形成一组可核对的关闭条件。例如：DoD要求的评审已完成、本任务验收标准中的检查项已通过、交付物已交接给对接人。三项都满足，任务才具备关闭条件。
关闭判断需要证据支撑
完成判断应基于可查看的记录，而非口头确认。评审意见、测试结果、交付记录、检查清单的勾选状态，都是证据。团队可以在工作项中记录完成条件与对应证据，让关闭动作有据可查。以ONES为例，测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，未通过的用例可快速创建缺陷任务并在测试与研发团队间流转，测试报告可自动生成多维度结果。这些能力可以为验收标准中的检查项留下可追溯的执行记录，帮助关闭判断建立在证据之上。完成条件清单本身如何配置，需结合团队实际约定与工具现有能力确定。
容易混淆的相邻概念：与阶段门、质量门、完成百分比的区别
除了三者之间的区分，还有几类常见说法容易被当成完成标准，需要单独说明。
完成百分比描述进度，不构成完成判断
完成百分比反映的是投入进展，比如“已完成80%”。它回答“做了多少”，不回答“做到什么程度算完成”。80%的任务可能仍未满足任何一条验收标准，100%的进度标记也不能替代关闭条件的核对。进度用于跟踪，完成判断需要具体条件。
阶段门或质量门针对阶段或里程碑
阶段门、质量门设置在阶段转换或里程碑节点，判断的是整个阶段能否进入下一环节，范围大于单项任务。一条任务可以关闭，但所在阶段未必通过阶段门；反之，阶段门通过也不意味着每条任务都已满足各自的完成标准。两者层级不同，不能互相替代。
验收标准与验收测试的关系
验收标准是条件描述，验收测试是验证这些条件的手段。一条验收标准可以对应一个或多个测试用例，测试结果作为是否满足验收标准的证据。把验收标准写成可直接测试的形式，能让验收测试有明确依据；只有测试动作而没有事先约定的标准，接受判断就容易变成事后争论。
DoD与团队规范、编码规范的区别
团队规范和编码规范规定“应该怎么做”，属于工作方式约束；DoD规定“做到什么状态才算完成”，属于完成判断。二者相关但不同：遵守编码规范是DoD中“代码通过评审”这类条目的前提，但规范本身不直接构成完成清单。把规范条文整段搬进DoD，会让完成判断变得臃肿且难以核对。
具体例子：一条需求任务的三层标准怎么写
下面以一条“新增订单导出功能”的需求任务为例，展示三层标准分别怎么写、如何共同支撑关闭判断。示例为演示情景，实际条目需按团队约定调整。
团队DoD示例条目
- 代码已通过至少一名同事评审
- 新增逻辑有对应的自动化测试，且测试通过
- 相关使用文档已更新
- 无未处理的阻塞级缺陷
该需求任务的验收标准示例条目
- 支持按时间范围导出订单，导出字段与页面展示字段一致
- 单次导出1万条订单时，文件在30秒内生成完成
- 导出文件格式为约定的表格文件，表头包含字段说明
- 无导出权限的用户看不到导出入口
该任务的完成标准示例条目
- 团队DoD四项均已核对并留有记录
- 上述四条验收标准均通过验收测试，测试结果已关联到本任务
- 导出功能已交付给提出需求的产品负责人确认接收
- 本任务关联的缺陷均已关闭或转为后续任务并注明
这三层标准的关系是：DoD提供共同底线，验收标准定义这条任务成果的接受条件，完成标准把两者合并成可逐项核对的关闭条件。核对时逐条查看证据，全部满足才关闭任务。
常见误解纠正
第一种误解是把DoD当成单个任务的验收清单。DoD是同类工作项的共同约定，不包含某条任务特有的成果条件；只核对DoD就关闭任务，容易漏掉本任务应有的验收要求。第二种误解是用完成百分比代替完成判断。“进度90%”不能说明验收标准是否通过，也不能说明交付物是否被接收。第三种误解是把验收标准写成模糊表述，如“导出功能好用”，导致无法验证。把条件写成可检查的形式，三者的配合才能真正落地。
常见问题
团队还没有正式约定DoD，单条任务还能写完成标准吗？
可以。DoD是团队层面的统一约定，形成之前，单条任务仍可以写自己的完成标准，只是需要把原本由DoD承担的通用条目临时并入其中，例如评审、测试、文档更新等。这样做的代价是同类任务之间口径可能不一致，逐条协商的成本也会上升。更稳妥的做法是先在团队内就一类工作项的共同条目达成简单共识，再逐步沉淀为正式DoD。
验收标准写多少条比较合适，写多了会不会拖慢关闭？
条数没有统一规定，判断依据是这条任务的成果需要哪些可检验的接受条件。条目过少，成果质量缺少约束；条目过多且包含大量通用要求，核对成本会明显上升。一个实用的做法是把通用要求放进DoD，验收标准只保留本任务特有的成果条件，并确保每条都能对应检查或测试动作。这样关闭时逐条核对证据，速度取决于条件是否清晰，而非条数本身。
任务关闭后才发现验收标准没满足，应该怎么处理？
先判断缺口属于哪一层：如果是成果条件未满足，说明关闭判断依据不足，应重新打开任务或新建任务补齐，并把未通过的检查项记录清楚；如果是DoD中的通用条目被遗漏，说明团队核对环节有漏洞，需要补充核对机制。无论哪种情况，都建议保留原关闭记录和后续处理记录，让这次偏差成为调整标准的依据，而不是只做口头补救。
不同工作项类型可以用同一份DoD吗？
可以共用一份基础DoD，再按工作项类型补充差异条目。缺陷修复和用户故事的完成条件通常不同：前者更关注复现验证与回归测试，后者更关注验收条件与文档。把共性条目放在基础清单里，把类型特有的条目单独列出，既能保持口径一致，也避免一份清单过长而难以核对。关键是每类工作项的DoD都要明确、可逐项检查。
用ONES记录完成条件和验收证据，需要额外配置吗？
ONES的测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，未通过的用例可创建缺陷任务并在测试与研发团队间流转，测试报告可自动生成多维度结果，这些能力可以为验收标准中的检查项留下执行记录。完成条件清单本身如何组织、放在工作项的哪个字段或检查项中，需要结合团队约定和工具现有配置确定，建议先小范围试用再推广。
