传统的项目管理，通常是先确定范围(scoping)，然后是估算人天，给出交付时间，签合同。即使预留一些缓冲(buffer)，项目最后很难满足交付预期。通常有下面几种情况：

Scrum 框架下是如何解决这个问题的？首先敏捷合同认为，价值和质量是不可牺牲的，如上图可示，唯一可调整的元素或者项目的约束条件永远是预算(budget)，范围(scope)和时间(schedule)。项目的成功更多是度量是否交付价值给客户；质量是否可靠，运维成本是否很低。这里我们先不纠结项目和产品的区别。 

如何保证质量是可靠的？Scrum 中有一个完成的定义(DoD)。Scrum 团队在项目准备期就定义一个大家做事情的规范，比如从开发，测试，文档和部署的角度一起看看哪些工作我们必须做的，比如单元测试做到什么程度，如何处理bug等等。DoD 是团队的交付能力的体现，也是为了保障质量，这是Scrum 团队约定在Sprint 中必须遵守的清单。比如回归测试，建立必要的设计文档等等。这样团队对Done有一个共同的理解和约定。DoD 保证了一个最小的质量范围，同时Undone的工作也可视化，我们清晰地知道理想状态的Done 和Sprint done 的边界和gap。

质量不单单是测试部门和QA 的事情了，而是Scrum 团队共同负责，测试工作尽多的成为DoD 的部分。测试工作不再是阶段性的，敏捷项目要求在迭代中尽早尽多地测试，暴露问题，尽早地曝光，每日站会，持续集成等工程实践都会让问题即使显现出来。一句话，Shared 责任。这方面有时候我们称作内在质量(quality built in)，正确的方式方法做事。另外一个维度是需求的验收标准(AC)，也是要提前开始沟通,  我们称作外在质量。通过进一步的澄清需求，保证质量把事情做正确。外在质量的建立(从外部来看质量)。这里我们姑且先不讨论验收标准，接受标准，满意条件的不同内涵。

在需求澄清这件事上，是一个持续对话的过程，我们有时隐喻为PO 与团队的“三次握手”。注意到LeSS 里面鼓励团队承担大多的需求澄清工作，澄清这件事情应该有团队更多的承担，这里我们不讨论LeSS。第一次握手，比如一个客户的需求是以用户故事的形式作为载体或容器简单的表述下来(Card)，但用户故事不是需求规格说明书，PO 和团队面对面的对话去理解需求 (Conversation)。然后把需求的范围从业务和用户的视角纪录下来(Confirmation)，见下图。第一次握手通常发生在产品待办列表的梳理会上。

那验收标准是不是合同？我们能不能通过一次对话就搞定？第二次握手发生在Sprint 计划会议的Topic 1，PO 有可能对上次沟通的用户故事有新的理解和更新，同时团队也会提出一些问题，所以Scrum 要求PO 必须参加Sprint 计划会议。

这个需求在迭代的执行过程中是不是就一定清晰明了，也不一定，即使我们通过卡片或工具记录下来，但还会有对话和进一步澄清的空间和可能。一句话，验收标准不是合同，即使我们在两次的握手中已充分交流，不排除开发团队成员在具体执行过程中有对验收标准的疑问，这也是我们说的第三次握手。有了至少这三次的面对面的对话和Handshake，任何一个需求不会有太大的偏颇。这与传统的过重依赖文档的沟通方式有天壤之别。

最后一个额外问题，应该有多少细节包括在用户故事的验收标准(满足条件)中? 答案是没有统一的标准。刚开始使用用户故事的团队不清楚具体的细节到什么程度。我的建议是让团队自己先思考先定义，再与PO 对话，这样的做法使故事主动进入就绪状态(Ready)，对Sprint 的执行中促进工作流(flow)很有必要。通常经过5次Sprint，在把握一个适当的细节级别上，团队会越来越有感觉，最终能够可靠完成工作。

“DoD”的定义表达了做事情的“正确的方法”，是关于维护产品质量和交付团队技能的一个清单。“三次握手”澄清验收标准就绪的用户故事，或功能需求代表了“正确的事”。

当然Scrum 团队如果引入XP 的工程实践也会大大提高质量，比如TDD，Pair Programming，Refactoring，code standard。

小结一下，Scrum框架下保证质量的机制：

Jim Wang王军   

写于2020年2月19日疫情期间  

参考资料：

（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 Editionby Jim Highsmith (Author)