完成的定义 DoD 与验收标准 AC 的区别

【作者按】本文是“Scrum框架下如何保证质量”的续篇，原文写于疫情期间 2020 年 2 月 19 日，是我 2015 年初成为 CST 后承担 Scrum 教学任务后的第一篇文章，当时请教过吕毅老师有无 Scrum 与质量关系论述的文章。原创文章发表后有不少反响。随后，我胆子越来越大，利用疫情期间的空闲时间，写了好多文章，后来整理成两本书籍，《Scrum 实践精萃》和《敏捷教练成长手记》。现在重新审视“Scrum 框架下如何保证质量”这篇文章，感觉题目有点大，重新定位这个主题，改写为“完成的定义 DoD 与验收标准 AC 的区别” 可能更为贴切。最近几年的教学，我发现，好多 CSM 的学员对完成的定义 DoD 与验收标准 AC 混为一谈。这也是我重写这篇文章的动机之一。

铁三角“项目制”带给我们的困扰

传统的项目管理，通常是先确定范围(scoping)，然后是估算人天，给出交付时间，签定固定价格和交付时间的合同。见下图：

现实中，即使预留一些缓冲(buffer)，项目最后很难满足交付预期：

（1）前期的估算是有偏差的，因为人们最开始对新项目需求的理解和知识是有限的。

（2）需求总是不断变更，需求是涌现的。

（3）在这种范围和交付日期固定的情况下，有些团队成员不稳定。合同上交付时间的压力会让我们自动牺牲质量。比如有一大堆的 bug，开发的产品代码质量差，运维成本高。会产生大量的技术债务。甚至质量的问题会把团队拖死。即使我们有 QA 部门，但现状是 QA 保证不了质量。尽管他们的抬头是质量保证部门(Quality Assurance)，而且测试工作通常在项目的晚期才进行，测试变成阶段性的工作，导致质量问题很晚才暴露出来。就是“死亡行军”，无休止地加班。这个“合同陷阱” – 是项目失败的罪魁祸首。

好多企业从项目思维转向产品思维后豁然开朗，产品思维专注价值最大化，产品成功度量交付客户价值；质量可靠，低运维成本(DevOps)。预算范围时间三要素只是约束条件。

Scrum 的教学中我们强调 PO 首先是一个对的人(right person)，即有担责，敢于承担责任。PO 定义的需求代表了“正确的事情(right things)”。研发团队如何把正确的事情做对做正确呢？体现在产品功能的实现上，我们从两个维度完成的定义 DoD 和验收标准 AC 来考量。

完成的定义 DoD – 做正确的事情(do the right things)， “DoD”的定义严格表达了做事情的“正确的方法”，它体现开发团队当前交付产品增量需要的跨职能（多功能）技能的一个清单(checklist)。

完成的定义(DoD)，Scrum 团队在产品准备期由 ScrumMaster 引导团队约定一个大家做事情的规范，从开发，测试，文档，合规和部署的五个视角，一起看看哪些增值活动我们必须做，比如单元测试做到什么程度，如何处理 bug，回归测试，建立必要的设计文档等等。DoD 示例如下：

可以看出，DoD 是团队交付能力的体现，也是为了保障质量，这是 Scrum 团队约定在 Sprint 中必须遵守的清单和指南(guide)。这样团队对 Done 有一个共同的理解，Sprint 评审会上 PO 和干系人对增量的反馈，在质量标准有一个约定和预期。DoD 保证了对 Sprint 的核心交付物增量的最小质量治理(Governance)，同时 Undone 的工作也透明可视化，我们清晰地理解理想发布状态的增量 Done 和当前 Sprint 增量的 Done 的差距(gap)有多大。

敏捷测试要求左移(shift left)，测试工作不再是阶段性的，我们期待在迭代中尽早尽多地测试，尽早地暴露问题，比如持续集成让问题早早显现出来，开发和测试结对，尽早修复 bug。测试工作尽多的包涵在 DoD 的清单上，我们称之为内在质量(quality built in)。专业而正确的方式方法做交付。如果引入 XP 的工程实践也会大大提高质量。质量不单单是测试部门和 QA 的事情，而是 Scrum 团队共同担责。

另外一个维度是需求的验收标准(AC)，或者称为接受条件或满意条件。

验收标准 AC --把事情做对做正确(do things right)，主要体现在对需求价值的理解和澄清。在需求澄清这件事上，是一个持续对话的过程，我们隐喻为 PO 与团队的“三次握手”。“三次握手”是指澄清验收标准就绪的用户故事，用户故事是 PBI 的一种，定义了需求的价值。Scrum 鼓励团队承担大多的需求澄清工作，应该由团队承担更多的需求澄清。

验收标准 AC 的三次握手

第一次握手通常发生在产品待办列表的梳理会(PBR)上。 我们所说的 3C 是指：客户的需求是以用户故事的卡片(Card)作为载体简单的表述，用户故事不是需求规格说明书，PO 和团队面对面的对话(Conversation)理解需求。然后把需求的范围以业务和用户的视角确认(Confirmation)下来，即验收标准和测试用例。见下图示例：

第二次握手发生在 Sprint 计划会议的话题 1+2(why+what)，PO 可能对上次 PBR 沟通的用户故事有新的理解和更新，同时团队也会对 AC 提出一些具体问题，Sprint 计划会议 PO 和团队持续的对话，PO 必须参加并做出决定。

第三次握手发生在迭代执行过程中，即使我们两次握手已充分交流，不排除开发团队成员在具体执行过程中对验收标准的疑问，这也是我们说的第三次握手。即使我们通过卡片工具记录下来，但还会有进一步澄清的空间和可能。有了这三次的面对面的对话，做对一个需求的可能性大大提高，这与传统的过度依赖文档的传递需求的方式有本质的不同。

有多少细节应该包括在用户故事的验收标准中? 没有统一的标准答案，刚开始使用用户故事的团队不清楚具体的细节到什么程度。 我的建议是让团队先思考定义 AC，由 PO 来澄清，使用户故事进入就绪状态(DoR – Definition of Ready)，Sprint 的执行中促进价值流动(flow)和交付。验收标准(AC)是基于 PO 和团队的相互信任，验收标准不是合同，AC 是双方持续对话谈判握手的结果。

Scrum 框架保证质量的机制：

两个维度把控质量，“DoD”的定义表达了做事情的正确打开方式，正确的方法和流程，在 Sprint 交付过程中严格执行，我们称作内在质量。验收标准(AC) 的第三次握手，提前沟通需求,  进一步的澄清和确认，把事情做正确。从外部用户和客户看质量，即外在质量。真正的完成是两个维度 DoD 和 AC，即 done+done。

（1）完成的定义(DoD)，划出了质量的底线和快照(snapshot)团队当前交付能力。我们对每个 Sprint 交付产品增量的承诺和持续不断对 DoD 范围的扩展，进化产品增量接近发布状态。 

（2）验收标准 AC 的“三次握手”，通过程序化的行为持续沟通，验收标准成为对话的工作方式，而不是“合同游戏”。

（3）团队全员对质量负责，集体的质量意识，共享 DoD 和 AC，共同担责。

在 CSM 课堂上我会带领大家一起模拟建立 Scrum 团队针对某一产品的 DoD，亲身体会这一重要的 Scrum 框架特有的 DoD 概念；在产品待办列表的梳理会上，举例讨论 AC，体验验收标准的共创和澄清以及细化的全过程。

——Jim Wang 王军 

 2024 年 12 月 4 日 

参考资料：

（1）Large-Scale Scrum: More with LeSS, Craig Larman, Bas Vodde

（2）Essential Scrum: A Practical Guide to the Most Popular Agile Process by Kenneth S. Rubin.

（3）Agile Project Management: Creating Innovative Products (2nd Edition) 2nd Edition by Jim Highsmith (Author)

（4）从 PMO 到 VMO 价值交付管理，Sanjiv Augustine.