- Jim Wang王军
- 2024-12-06
- 来源：原创
完成的定义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.
