完成定义（Definition of Done，简称 DoD）是团队对“一项工作达到什么状态才算真正做完”的共同约定，用一组可检查的标准统一团队、评审者和相关方的判断口径。它既可以约束单个需求或任务，也可以约束一个迭代产出的增量。本文解释完成定义的含义、内容范围、运行方式，并对照验收标准与日常口语中的“完成”，最后给出一个可参照的示例和常见误解。
要点总览（TL;DR）
- 完成定义（Definition of Done，DoD）是团队共同约定的完成标准，回答“一项工作达到什么状态才算真正做完”，适用于单个条目和迭代增量两种粒度。
- 典型内容包括代码提交与评审、测试通过、文档更新、可部署等可核验项；单个需求特有的业务验收条件、排期与资源安排不属于完成定义。
- 完成定义由团队共同制定并公开可见，在迭代开始前确定、迭代中不随意放宽，条目完成时逐项检查，迭代评审时用于判断增量是否可交付，并随团队能力提升逐步加严。
- 完成定义是团队级通用门槛，验收标准是条目级具体条件，两者叠加使用；日常口语中的“完成”通常只指开发动作结束，缺少可核验依据。
- 常见误解包括把完成定义等同于验收标准、认为写下后不能调整、把它当成形式文档而不进入评审，后果是完成状态回到个人判断、缺陷和返工被推到后续迭代。
完成定义的核心含义
完成定义是一组由团队共同约定、公开可见的完成标准，用来回答“什么算做完”。它描述的是工作成果在质量与完整性上必须跨过的门槛，而不是某个人主观上觉得“差不多了”。在敏捷项目管理中，完成定义通常以清单形式存在，每一项都可以被检查、被举证，而不是一句笼统的口号。
完成定义适用于两种粒度。第一种是条目级：一个用户故事、一个缺陷修复或一项技术任务，在标记为完成之前要满足哪些条件。第二种是增量级：一个迭代结束时，团队交付的增量整体要满足哪些条件，才能被认为可以交付给相关方查看或使用。两种粒度可以共用一套基础标准，增量级通常在此基础上增加集成、回归、发布说明等要求。
它解决的问题是判断口径不一致。开发人员认为代码写完就算完成，测试人员认为用例跑完才算完成，产品负责人认为业务价值可验证才算完成，三种理解并存时，迭代评审就容易变成争论“这到底算不算做完”。完成定义把这些判断提前写清楚，让完成状态有据可依。
完成定义包括什么、不包括什么
完成定义的典型内容围绕“成果是否达到可交付的质量门槛”展开。团队可以根据自身情况选择条目，但每一项都应当是可核验的，而不是需要主观评价的。
- 代码完成并已提交到约定的代码库分支，符合团队的编码规范。
- 经过同行评审或代码评审，评审意见已处理。
- 单元测试、集成测试或回归测试按约定执行并通过。
- 相关文档已更新，包括接口说明、使用说明或变更记录。
- 成果已部署到约定的环境，或具备可部署的条件。
- 必要的产品负责人或相关方确认已完成。
完成定义不包括单个需求特有的业务验收条件。比如“用户可以用手机号加验证码登录”“订单金额满 200 元免运费”，这些是某个条目自己的验收标准，不属于团队通用的完成门槛。完成定义也不包括排期、资源安排和优先级判断，那些属于计划和取舍问题，与“做完的质量标准”是两件事。
内容边界会随团队成熟度和产品风险调整。团队刚建立时，完成定义可以只覆盖代码评审和基本测试；随着自动化测试、持续集成能力提升，可以逐步加入自动化回归、性能检查、安全扫描等条目。面向高风险产品（如涉及资金或个人信息）的团队，完成定义通常比内部工具团队更严格。这种差异是合理的，关键是团队对当前采用的标准有共识。
完成定义如何发挥作用
完成定义要真正起作用，需要经历制定、使用和演进三个环节，每个环节都有具体的动作和产物。
制定：由团队共同完成并公开可见。完成定义不应由某一个人单独写下后下发，而应由开发、测试、产品等角色一起讨论，确认每条标准在当前条件下可执行。讨论的产物是一份团队认可的清单，放在团队容易看到的位置，新成员加入时也能直接查阅。制定时逐条问一句“我们能不能举出证据证明它做到了”，无法举证的标准应当改写或删除。
使用：在迭代开始前确定，迭代中不随意放宽。迭代计划阶段，团队按当前完成定义评估工作量；迭代进行中，如果发现某条标准难以满足，应当记录并讨论，而不是临时把标准调低来让条目“完成”。条目完成时，以完成定义作为检查依据，逐项确认后再流转状态。迭代评审时，完成定义用于判断增量是否达到可交付状态，评审者可以据此提出具体问题，而不是凭印象评价。
演进：随团队能力提升逐步加严。完成定义是活的文件。团队在回顾中如果发现某类问题反复出现，可以把对应的检查项补进完成定义；自动化能力提升后，可以把人工检查替换为自动校验。调整应当在迭代边界进行，并让所有相关角色知晓，避免标准在无人注意时漂移。
当完成定义落到具体的工作项管理上，团队需要让完成状态与检查项对应起来。ONES 支持编写需求、自定义需求状态与多种属性，并可将需求和相关任务规划至迭代、分配负责人；迭代中团队通过敏捷看板管理任务状态，测试人员可依据迭代要完成的需求与验收标准编写测试用例，未通过的用例可转换为缺陷提交至项目。这些能力承载的是“按约定标准检查、按检查结果流转”的管理动作，完成定义本身仍需团队自己约定并逐项核对。
完成定义与验收标准、完成的区别
完成定义、验收标准和日常说的“完成”经常被混用，三者的作用层级并不相同。完成定义是团队级通用门槛，对所有条目一视同仁；验收标准是条目级具体条件，只针对某一个需求或故事；口语中的“做完了”通常只表示开发动作结束，既不保证质量门槛，也不保证业务条件满足。
| 对照项 | 完成定义 | 验收标准 | 口语中的“完成” |
|---|---|---|---|
| 作用层级 | 团队级通用门槛 | 单个条目级条件 | 个人对进度的主观描述 |
| 适用范围 | 所有需求、任务与迭代增量 | 某一个具体需求或故事 | 不固定，随说话人变化 |
| 典型内容 | 评审、测试、文档、可部署等 | 该条目特有的业务行为与结果 | 开发编码动作结束 |
| 判断依据 | 可逐项检查的清单 | 可演示或可验证的业务场景 | 缺少可核验依据 |
完成定义与验收标准可以叠加使用：一个条目要先满足完成定义，再满足自身的验收标准，才算真正完成。举例来说，一个“购物车支持批量删除”的故事，完成定义要求代码评审通过、回归测试通过、文档更新；验收标准要求勾选多件商品后一次删除成功且提示正确。两者都满足，条目才可以交给相关方确认。
完成定义还与迭代目标和增量可交付性直接相关。迭代目标描述这一轮要达成什么，完成定义描述达成的成果要达到什么质量状态。只有增量整体满足完成定义，团队才能理直气壮地说这个迭代产出了可交付的增量；否则只能说明哪些条目尚未达到门槛。
一个具体例子与常见误解
以下示例为演示情景，用于说明完成定义的写法，不代表任何真实团队的做法。某团队为一个用户故事设定了如下完成检查项：
- 代码已提交并通过同行评审，评审意见已闭环；
- 新增逻辑有对应的单元测试，相关回归用例全部通过；
- 接口或使用说明已更新到团队文档；
- 已部署到测试环境，产品负责人可在环境中演示；
- 该故事自身的验收标准逐条演示通过。
使用方式很直接：开发人员认为编码结束时，对照清单确认前几项；测试人员按用例验证并记录结果；产品负责人在迭代评审中按验收标准逐条确认。任何一项未满足，条目就停留在未完成状态，并说明卡在哪一项。这样评审讨论的是具体检查项，而不是“我觉得可以了”。
常见误解之一是把完成定义等同于验收标准。两者层级不同，完成定义管所有条目的质量门槛，验收标准管单个条目的业务条件，混用会导致团队要么对每个条目重复讨论通用标准，要么漏掉条目特有的验证。
常见误解之二是认为完成定义一旦写下就不能调整。完成定义应当随团队能力和产品风险演进，在迭代边界有依据地加严或细化是正常做法；真正需要避免的是迭代进行中为了赶进度临时放宽标准。
常见误解之三是把完成定义当成形式文档，写完就放进文件夹，评审时并不使用。这样做的后果是完成状态重新回到个人判断，未通过测试或未更新文档的条目被标记为完成，缺陷和返工被推到后续迭代，迭代评审也失去判断增量可交付性的依据。让完成定义进入每次条目完成检查和迭代评审，才是它发挥作用的起点。
常见问题
团队刚引入完成定义，应该从几条标准开始？
可以从团队当前实际能做到的检查项起步，例如代码评审和基本测试，先保证每条标准都能举出证据。标准数量少但被真正执行，比清单很长却在评审时被跳过更有价值。等团队在回顾中确认这些检查稳定运行后，再结合反复出现的问题和自动化能力，在迭代边界逐步补充条目。
迭代进行中发现某条完成标准难以满足，应该怎么处理？
建议把这条标准当作未完成项记录下来，在迭代内讨论是调整工作范围还是投入额外工作，而不是临时调低标准让条目通过。如果确实需要修改完成定义，放到迭代边界统一调整并告知所有相关角色。迭代中放宽标准会让完成状态失去可比性，也会把质量风险推到后续迭代。
完成定义需要产品负责人参与制定吗？
需要。完成定义约束的是团队交付成果的质量门槛，产品负责人参与可以确认这些标准与相关方对“可交付”的预期一致，避免团队按自己的理解完成后在评审中被质疑。开发、测试等角色同样要参与，确保每条标准在当前条件下可执行、可举证。
不同团队可以共用一份完成定义吗？
可以共用基础框架，但具体条目应结合产品风险和团队能力调整。面向资金或个人信息的团队通常需要更严格的测试与安全检查，内部工具团队的标准可以相对精简。共用一份完全相同的清单，容易出现某些团队标准过严难以执行、另一些团队标准过松无法覆盖风险的情况。
完成定义和迭代目标是什么关系？
迭代目标描述这一轮要达成什么，完成定义描述达成的成果要达到什么质量状态。两者结合才能判断迭代是否产出了可交付的增量：目标回答了“做了什么”，完成定义回答了“做到什么程度才算数”。评审时如果增量整体未满足完成定义，团队应说明哪些条目尚未达到门槛，而不是笼统地宣称迭代完成。
