传统的项目管理，通常是先确定范围(scoping), 然后是估算人天，给出交付时间，签合同。即使预留一些缓冲（buffer）, 项目最后很难满足交付预期。通常有下面几种情况：
（1）前期的估算是有偏差的，因为人们对新项目的理解和知识是有限的。
（2）需求总是不断变更。
（3）在这种范围和交付日期固定的情况下，甚至有些团队的人员也不稳定。多数情况下，合同上交付时间的压力会让我们自动牺牲质量。比如系统有一大堆的bug, 开发的产品运维成本很高，代码质量差，等等。这些会产生大量的技术债务。甚至质量的问题会把团队拖死。即使我们有QA部门，但现实的状况是QA保证不了质量。尽管他们有趣的title是质量保证部门(Quality Assurance) , 而且传统的项目交付，测试工作通常在项目的晚期才进行，测试变成一个阶段性的工作，导致质量问题很晚才暴露出来。然后就是“死亡行军”，无休止的加班。这基本上是我们这个行业的一道“风景线”或者叫“合同陷阱”。
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框架下保证质量的机制：
（1）团队整体对质量负责，集体的质量意识 (Shared Responsibility)
（2）完成的定义(DoD), 质量的底线和团队当前交付能力的透明化
（3）验收标准的“三次握手”（Ritualized Behavior –“程序化行为“）
理解Scrum框架对产品开发的质量保证设计机理，对于我们持续不断的交付产品增长非常重要。Scrum是一个指导帮助我们在交付团队，PO和利益相关者三者之间的如何有效协作、建立信任，持续反馈和学习改进，践行敏捷思维，能马上落地的框架。
——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 Edition
by Jim Highsmith (Author)
原创文章，作者：ItWorker，如若转载，请注明出处：https://blog.ytso.com/295366.html