完工标准（DoD）与验收条件（AC）究竟有什么不同？

在我最近的培训课上，有一位学生问：“验收条件（Acceptance Criteria，AC） 和 完工标准（Definition of Done，DoD） 究竟有什么不同呢？”

当他得知“完工标准”竟然是 Scrum 中的一个必要元素时，他表示非常诧异。他的团队在将产品待办项发布至生产环境之前，一定会确保所有验收条件已经满足，他以为这已经足够了。这两个概念看听来很相似，但并不是一回事，它们的目的各有不同。

必要元素 vs. 补充实践

当产品待办项满足完工标准时，增量就产生了。

—— Scrum指南   

质量 vs. 范围

这里是一些完工标准的示例：

• 代码经过至少一名团队成员审查并通过；

• 所有自动化测试均已通过；

• 必要的文档都已完成。

这远不是一个完善的清单，但你能够看出来，这样的清单适用于任何一个待办项。

而 验收条件强调的则是范围。 验收条件反映了某个功能的预期工作方式。它帮助确保功能是按照满足客户需要的方式实现的。

以下是一些验收条件的样例：

• 在登录功能中，要求使用有效的邮箱地址和密码才能访问系统；

• 搜索功能需要批量返回结果，每批结果不大于25个项目；

• 在用户下单前，购物车中需要展示含税和含运费的总价格。

这些验收标准是适用于某个特定功能的，而不是团队开发的所有功能。

不可协商 vs. 可协商

完工标准是团队对质量最低标准的承诺，任何不满足完工标准的工作内容都不能在迭代评审中发布或演示，团队不能决定在质量上偷工减料。

然而， 并未达成所有验收条件的工作项，团队是可以选择展示或发布的，只要所有完工标准已满足，就有了坚实的质量基础。除非团队给自己设下“陷阱”，有的团队会在他们的完工标准中加上一条：满足所有验收条件。

好消息是，在迭代期间，随着团队了解到更多的信息， 验收标准是可以协商的。如果发现产品待办项的规模比预期要大，可以对它进行进一步拆分，团队完成能处理的部分，剩余未完成的工作项则返回到产品Backlog中。如果它仍有价值，团队可以进行梳理并纳入未来的迭代中。

这就是能摆脱“满足所有验收条件”陷阱的方法。当然，针对AC进行协商，会使得DoD中的这一项失去意义，所以何苦要定义这么一条呢。

记住，迭代的工作范围总是可以协商的，如果需要，我们可以从迭代中删除待办项，也可以增加新的待办项。我们可以调整任何待办项的验收条件， 只有迭代目标是不变的，增量的质量标准是不可协商的。

结 语

• 完工标准是 Scrum 的基本要求。验收条件不是必需的，但如果团队认为有帮助，也可以使用。

• 完工标准定义了产品的质量标准。验收条件描述了要完成的工作范围。

• 完工标准不能协商降低。验收条件是可以协商的。

如果一个 Scrum 团队使用了“验收条件”，但没有使用“完工标准”，那么他们就缺失了 Scrum 的一个重要组成部分。这就好比拥有一辆看起来很不错的汽车，但缺少了燃油滤清器。也许它当下还能跑，但终究是会出问题的。

你在创建和坚守“完工标准”时遇到过问题或挑战吗？欢迎在评论区分享你的经验和观点。