在我最近的培训课上,有一位学生问:“验收条件(Acceptance Criteria,AC) 和 完工标准(Definition of Done,DoD) 究竟有什么不同呢?”
必要元素 vs. 补充实践
当产品待办项满足完工标准时,增量就产生了。 —— Scrum指南
质量 vs. 范围
-
代码经过至少一名团队成员审查并通过
-
所有自动化测试均已通过
-
必要的文档都已完成
这远不是一个完善的清单,但你能够看出来,这样的清单适用于任何一个待办项。
而验收条件强调的则是范围。验收条件反映了某个功能的预期工作方式。它帮助确保功能是按照满足客户需要的方式实现的。
-
在登录功能中,要求使用有效的邮箱地址和密码才能访问系统。
-
搜索功能需要批量返回结果,每批结果不大于25个项目。
-
在用户下单前,购物车中需要展示含税和含运费的总价格。
这些验收标准是适用于某个特定功能的,而不是团队开发的所有功能。
不可协商 vs. 可协商
完工标准是团队对质量最低标准的承诺,任何不满足完工标准的工作内容都不能在迭代评审中发布或演示,团队不能决定在质量上偷工减料。
然而,并未达成所有验收条件的工作项,团队是可以选择展示或发布的,只要所有完工标准已满足,就有了坚实的质量基础。除非团队给自己设下“陷阱”,有的团队会在他们的完工标准中加上一条:满足所有验收条件。
好消息是,在迭代期间,随着团队了解到更多的信息,验收标准是可以协商的。如果发现产品待办项的规模比预期要大,可以对它进行进一步拆分,团队完成能处理的部分,剩余未完成的工作项则返回到产品Backlog中。如果它仍有价值,团队可以进行梳理并纳入未来的迭代中。
这就是能摆脱“满足所有验收条件”陷阱的方法。当然,针对AC进行协商,会使得DoD中的这一项失去意义,所以何苦要定义这么一条呢。
记住,迭代的工作范围总是可以协商的,如果需要,我们可以从迭代中删除待办项,也可以增加新的待办项。我们可以调整任何待办项的验收条件,只有迭代目标是不变的,增量的质量标准是不可协商的。
结 语
-
完工标准是 Scrum 的基本要求。验收条件不是必需的,但如果团队认为有帮助,也可以使用。
-
完工标准定义了产品的质量标准。验收条件描述了要完成的工作范围。
-
完工标准不能协商降低。验收条件是可以协商的。
如果一个 Scrum 团队使用了“验收条件”,但没有使用“完工标准”,那么他们就缺失了 Scrum 的一个重要组成部分。这就好比拥有一辆看起来很不错的汽车,但缺少了燃油滤清器。也许它当下还能跑,但终究是会出问题的。
你在创建和坚守“完工标准”时遇到过问题或挑战吗?欢迎在评论区分享你的经验和观点。
原文地址:https://www.scrum.org/resources/blog/acceptance-criteria-arent-enough
【作者】Sam Falco