完成定义（Definition of Done，简称 DoD）是团队对“一项工作做到什么程度才算真正完成”达成的一致标准，通常以一组可检查的条件呈现，适用于某个工作项、某个迭代或某类交付物。本文解释它的含义、范围边界、组成分层，并说明它与验收标准、迭代目标的区别，最后给出一个可迁移的例子和落地方式。
要点总览（TL;DR）
- 完成定义（Definition of Done）是团队共同约定的一组可检查条件，用来判断工作项或交付物是否达到完成门槛。
- 它覆盖质量、测试、文档、部署等完成条件，不负责决定本次迭代做哪些内容，也不替代单条需求的验收标准。
- 完成定义通常按工作项级、迭代级、发布级分层，不同交付物类型可以维护不同的条件集。
- 完成定义、验收标准、迭代目标回答三个不同问题：质量门槛、业务判定、迭代结果，三者同时存在、互相补充。
- 落地时把完成定义沉淀为团队文档，与工作项状态流转对应，在评审中逐条核对留痕，并在回顾中调整更新。
完成定义到底指什么
完成定义是敏捷团队共同约定的完成门槛：当一项工作项或一个交付物满足这组条件时，团队才认为它“完成”。它的英文全称是 Definition of Done，中文常译为“完成定义”，也有团队叫“完成的定义”。这个术语的关键不在“定义”二字，而在“完成”——它把模糊的“做完了”转换成一组可以逐条核对的条件。
理解这个概念，需要抓住三个要点。
第一，它是一组可检查的条件，而非一句口号。“代码写完”无法核对，“代码已合并到主干并通过持续集成构建”可以核对。条件的价值在于评审时每个人能得出相同结论，减少“我以为完成了”的争议。
第二，它的判断对象是工作项或交付物是否达到完成门槛。判断发生在工作即将被标记为完成的那一刻，回答的是“这件东西够不够格算完成”，而非“这件东西值不值得做”或“这个迭代要做到哪里”。
第三，它由团队共同约定，并随实践调整。完成定义反映团队当前的质量共识和流程成熟度，团队在回顾中发现问题、补充条件、收紧或放宽门槛，都是正常演进。把它当成一次写定、永久不变的制度，反而会削弱它的作用。
用一句话复述：完成定义是团队约定的、用于判断工作项或交付物是否达到完成门槛的一组可检查条件。
完成定义包括什么、不包括什么
完成定义的边界容易和相邻概念混淆。它覆盖的是“做到什么程度算完成”的质量判断，不覆盖“这次要做哪些内容”的规划决策，也不覆盖“这条需求是否值得做”的取舍判断。下表按常见内容做范围对照。
| 内容 | 是否属于完成定义 | 说明 |
|---|---|---|
| 代码已评审并合并 | 属于 | 可观察的交付动作，评审时可核对 |
| 自动化测试通过、关键用例已执行 | 属于 | 可验证的质量条件 |
| 文档或使用说明已更新并可交接 | 属于 | 面向交接的完成条件 |
| 已部署到约定环境并可访问 | 属于 | 可观察的交付状态 |
| 本次迭代要交付哪几条需求 | 不属于 | 属于迭代规划与迭代目标的范畴 |
| 某条需求的业务规则细节与验收口径 | 不属于 | 属于该需求的验收标准 |
| 某条需求是否进入待办池、优先级排第几 | 不属于 | 属于需求准入与优先级判断 |
需要说明的是，这条边界随团队与交付物类型变化。一个只做内部工具的团队，可能把“完成”定义为代码合并加基本自测；一个面向外部客户的团队，可能要求文档、培训材料、上线检查一并满足。边界的具体位置由团队约定，但“质量门槛”这一性质不变。
完成定义由哪些条件组成
完成定义的条件应可观察、可验证。写条件时可以用一个简单检验：评审者能否在不询问作者的情况下，通过查看系统状态、文档或测试结果判断这一条是否满足。做不到这一点的条件，通常需要改写得更具体。
实践中，完成定义常按层级组织，不同层级回答不同粒度的问题。
- 工作项级：单个需求、任务或缺陷被标记完成前需要满足的条件，例如代码评审通过、单元测试通过、相关文档更新。
- 迭代级：一个迭代被视为完成时需要满足的条件，例如迭代内工作项均达到工作项级完成定义、迭代评审已进行、遗留问题已记录。
- 发布级：一次对外发布需要满足的条件，例如回归测试通过、上线检查清单完成、回滚方案就绪、发布说明已发布。
不同交付物类型可以有不同条件集。纯软件功能、数据报表、硬件交付、合规文档的完成条件差异明显，团队可以维护一份通用条件加若干专项条件，避免用一套条件硬套所有工作。
条件还应与团队实际流程环节对应。团队有代码评审环节，就写评审条件；有提测环节，就写提测与测试通过条件；有上线审批，就写审批完成条件。条件脱离实际流程，评审时就无法逐条核对，完成定义会退化为文档摆设。
最后，条件需要能被评审时逐条核对。这意味着条件数量不宜过多，表述尽量短，最好能对应到系统中的某个状态、某份文档或某次测试记录。逐条核对的过程本身也是发现流程缺口的机会。
完成定义与验收标准、迭代目标的区别
这三个概念经常被混用，混用会带来具体偏差：把验收标准当完成定义，团队可能只关注业务功能而忽略质量与交接；把完成定义当验收标准，评审时容易用通用条件替代对单条需求的业务判断；把迭代目标当完成定义，则会把“做到哪里”和“做到什么质量”搅在一起。下表按同一口径对照。
| 概念 | 回答的问题 | 作用对象 | 使用时机 |
|---|---|---|---|
| 完成定义 | 这项工作达到什么质量门槛才算完成 | 工作项、迭代、发布等交付物 | 工作即将标记完成、迭代评审、发布前核对 |
| 验收标准 | 这条需求的具体业务判定是什么 | 单条需求或用户故事 | 需求评审、测试用例设计、需求验收 |
| 迭代目标 | 本次迭代要达成什么结果 | 整个迭代 | 迭代规划、迭代评审与回顾 |
三者可以同时存在且互相补充。迭代目标确定方向，验收标准确定单条需求的业务正确性，完成定义确定交付质量的下限。一条需求通过验收标准，说明业务上符合预期；它同时满足完成定义，才说明它在质量、文档、部署等维度也达到了团队认可的状态。
一个具体例子与常见误解
假设团队有一个用户故事：“作为注册用户，我可以重置密码，以便在忘记密码时恢复访问。”这条需求的验收标准可能包括：输入已注册邮箱后收到重置邮件、链接在约定时间内有效、新密码符合强度规则、旧密码失效。这些是业务判定。
团队的工作项级完成定义则可能是这样一组条件：
- 代码已通过评审并合并到主干；
- 单元测试与相关集成测试通过，持续集成构建成功；
- 测试人员按验收标准执行用例并通过，未通过项已转为缺陷并修复；
- 接口文档与用户帮助说明已更新；
- 已部署到测试环境，产品负责人可访问验证；
- 相关监控或日志已配置，异常可被发现。
评审时，团队逐条核对：在系统中查看合并记录与构建结果，查看测试用例执行记录与缺陷状态，打开文档确认更新，访问测试环境验证，检查监控配置。每条都有对应的可查证据，核对结论不依赖个人记忆。演示情景中，这样的核对通常只需几分钟，却能把“以为完成”与“确实完成”区分开。
围绕完成定义，常见的误解有三类。
把完成定义当成验收标准。表现是评审时只讨论功能是否符合业务预期，不再检查代码评审、测试通过、文档更新等条件。纠正方式是在评审流程中把两类检查分开：先按验收标准判断业务正确性，再按完成定义逐条核对质量条件。
条件写得笼统无法判断。“代码质量良好”“测试充分”这类表述无法核对，不同人理解不同。纠正方式是改写为可观察的状态，例如“静态检查无新增严重问题”“关键路径用例已执行并记录结果”。
写完就固定不变。团队流程变化、质量要求提高后，旧条件可能不再适用，却没人更新，导致完成定义与实际做法脱节。纠正方式是把完成定义的检视放进迭代回顾，发现反复出现的质量问题时补充或调整条件，并让调整对全员可见。
把完成定义落到协作流程中的管理动作
完成定义要真正起作用，需要从一份约定变成流程中的可执行动作。可以按“沉淀—对应—核对—调整”四个动作来组织。
第一步，把完成定义作为团队约定文档沉淀。文档写清适用范围（工作项级、迭代级、发布级）、条件清单和责任人，放在团队都能访问的位置。使用 ONES Wiki 时，可以把完成定义文档与相关工作项关联，并在文档中插入工作项列表，让约定和实际工作放在同一处查看，减少文档与任务彼此隔绝的情况。
第二步，让工作项状态流转与完成条件对应。团队在迭代规划时对齐需求与验收标准，并把工作拆分到可跟踪的粒度；执行过程中通过敏捷看板管理任务状态。状态从“进行中”走向“完成”时，对应的完成条件应已有可查证据。ONES 敏捷研发管理方案覆盖需求、研发、测试的流程衔接，测试人员可依据需求与验收标准编写并执行用例，未通过项转为缺陷指派修复，这些记录本身就是核对完成条件的依据。
第三步，在评审环节逐条核对并留痕。迭代评审或工作项完成确认时，按条件清单逐条检查，把核对结果记录在评审记录、工作项评论或相关文档中。留痕的价值在于后续回顾时有据可查，也能发现哪些条件经常不满足，从而定位流程薄弱环节。
第四步，条件调整时做好版本与通知。完成定义变更后，更新文档并标注生效时间，在团队会议或协作空间中通知全员，避免有人按旧条件执行。迭代回顾是调整的合适时机，团队可以结合燃尽图、工时日志、持续集成报告等数据复盘质量与进度偏差，把改进结论写回完成定义文档，形成团队知识积累。
这四个动作的核心，是让完成定义始终与工作项、评审记录和团队文档保持连接。工具承载的是约定的可见性与核对证据的留存，完成门槛本身仍由团队约定和判断。
常见问题
完成定义需要每个团队单独写一份吗，还是可以直接套用通用模板？
可以参考通用模板起步，但最终版本应由团队自己约定。完成定义反映的是团队当前的质量共识和流程环节：有代码评审就写评审条件，有提测环节就写测试通过条件。直接套用别人的清单，容易出现条件与实际流程对不上、评审时无法逐条核对的情况。比较稳妥的做法是先列一份覆盖常见维度的初稿，在迭代评审和回顾中按实际执行情况增删调整。
完成定义和验收标准在评审时应该先看哪个？
两者检查的对象不同，建议分开进行。先按验收标准判断这条需求的业务正确性，确认功能行为符合预期；再按完成定义逐条核对质量条件，例如代码评审、测试执行、文档更新、部署状态。顺序上先业务后质量，可以避免业务讨论占用全部评审时间，导致质量条件被跳过。两类检查的结论都应记录，便于后续回顾时追溯。
团队流程变了，旧的完成定义条件还要保留吗？
需要定期检视，不必原样保留。流程环节调整、质量要求提高或工具链变化后，旧条件可能不再对应实际做法，继续沿用会让完成定义与实际执行脱节。可以把完成定义的检视放进迭代回顾，结合燃尽图、工时日志、持续集成报告等数据看哪些条件反复不满足，据此补充或收紧条件。调整后更新文档、标注生效时间并通知全员，避免有人仍按旧版本执行。
完成定义写得越细越好吗？
条件的关键是可观察、可验证，数量本身不是目标。条件过多会让评审变成逐项填表，团队容易流于形式；条件过于笼统，例如“代码质量良好”，又无法得出相同结论。比较实用的做法是控制条件数量，每条尽量对应系统中的某个状态、某份文档或某次测试记录，让评审者不询问作者也能判断是否满足。专项条件可以按交付物类型单独维护，避免用一套长清单覆盖所有工作。
在协作工具里，完成定义的核对结果怎么留痕？
常见做法是把核对结果记录在评审记录、工作项评论或相关文档中，让每条条件的判断都有可查依据。ONES 敏捷研发管理方案覆盖需求、研发、测试的流程衔接，测试人员可依据需求与验收标准编写并执行用例，未通过项转为缺陷指派修复，这些记录可以作为核对完成条件的证据；ONES Wiki 支持文档关联任务并插入工作项列表，便于把完成定义文档与实际工作放在同一处查看。工具承载的是约定的可见性与证据留存，完成门槛本身仍由团队约定和判断。
