在我最近的培训课上，有一位学生问：“验收条件（Acceptance Criteria，AC） 和 完工标准（Definition of Done，DoD） 究竟有什么不同呢？”
当他得知“完工标准”竟然是 Scrum 中的一个必要元素时，他表示非常诧异。他的团队在将产品待办项发布至生产环境之前，一定会确保所有验收条件已经满足，他以为这已经足够了。这两个概念看听来很相似，但并不是一回事，它们的目的各有不同。
必要元素 vs. 补充实践
完工标准（Definition of Done，DoD ）是 Scrum 的必要元素，完工标准是 Scrum 团队对他们的工作质量所做的承诺。如果缺少对于完工标准的定义，那么增量的状态就缺少了透明度。没有了足够的透明度，我们就无法及时朝着创造有价值的产品的方向进行检视和调整。完工标准适用于产品增量。
当产品待办项满足完工标准时，增量就产生了。 —— Scrum指南
验收条件（Acceptance Criteria，AC）并不是 Scrum 里要求的。验收条件是一个补充实践，很多团队觉得比较实用，但它并不是必不可少的，即使缺少验收条件，团队也能正常工作。验收条件通常适用于用户故事。如果工作成果满足完工标准，即使并非所有验收条件都达成了，也能够创建产品增量。
质量 vs. 范围
完工标准强调的是质量。当 Scrum 团队说一个产品待办项已经完成时，他们指的是这项功能已经通过完整的测试，并且是可用的。它能与之前的所有产品增量集成 —— 新功能不能破坏既有的功能。完工标准反映了团队对于工作质量的信心。
这里是一些完工标准的示例：
- 代码经过至少一名团队成员审查并通过
- 所有自动化测试均已通过
- 必要的文档都已完成
这远不是一个完善的清单，但你能够看出来，这样的清单适用于任何一个待办项。
而验收条件强调的则是范围。验收条件反映了某个功能的预期工作方式。它帮助确保功能是按照满足客户需要的方式实现的。
以下是一些验收条件的样例：
- 在登录功能中，要求使用有效的邮箱地址和密码才能访问系统。
- 搜索功能需要批量返回结果，每批结果不大于25个项目。
- 在用户下单前，购物车中需要展示含税和含运费的总价格。
这些验收标准是适用于某个特定功能的，而不是团队开发的所有功能。
不可协商 vs. 可协商
完工标准是团队对质量最低标准的承诺，任何不满足完工标准的工作内容都不能在迭代评审中发布或演示，团队不能决定在质量上偷工减料。
然而，并未达成所有验收条件的工作项，团队是可以选择展示或发布的，只要所有完工标准已满足，就有了坚实的质量基础。除非团队给自己设下“陷阱”，有的团队会在他们的完工标准中加上一条：满足所有验收条件。
好消息是，在迭代期间，随着团队了解到更多的信息，验收标准是可以协商的。如果发现产品待办项的规模比预期要大，可以对它进行进一步拆分，团队完成能处理的部分，剩余未完成的工作项则返回到产品Backlog中。如果它仍有价值，团队可以进行梳理并纳入未来的迭代中。
这就是能摆脱“满足所有验收条件”陷阱的方法。当然，针对AC进行协商，会使得DoD中的这一项失去意义，所以何苦要定义这么一条呢。
记住，迭代的工作范围总是可以协商的，如果需要，我们可以从迭代中删除待办项，也可以增加新的待办项。我们可以调整任何待办项的验收条件，只有迭代目标是不变的，增量的质量标准是不可协商的。
结 语
- 完工标准是 Scrum 的基本要求。验收条件不是必需的，但如果团队认为有帮助，也可以使用。
- 完工标准定义了产品的质量标准。验收条件描述了要完成的工作范围。
- 完工标准不能协商降低。验收条件是可以协商的。
如果一个 Scrum 团队使用了“验收条件”，但没有使用“完工标准”，那么他们就缺失了 Scrum 的一个重要组成部分。这就好比拥有一辆看起来很不错的汽车，但缺少了燃油滤清器。也许它当下还能跑，但终究是会出问题的。
你在创建和坚守“完工标准”时遇到过问题或挑战吗？欢迎在评论区分享你的经验和观点。
原文地址：https://www.scrum.org/resources/blog/acceptance-criteria-arent-enough
【作者】Sam Falco
Sam Falco来自美国，是Scrum.org的专业 Scrum 培训师。
Sam 拥有二十多年的软件研发经验，曾涉猎过出版，金融服务，审计，信息技术安全，运动服饰，保险等行业。他的目标是为组织和团队提供必要的工具，以实现可持续的、有影响力的变革，营造一个让人们发挥最佳能力的工作环境。
