第3章  

敏捷原则

在深入研究Scrum的机理之前，先理解推动并影响Scrum方法的基本原则是很有帮助的。

本章讲述构成Scrum基础的敏捷原则并将它们与传统计划驱动的顺序产品开发的原则进行对比。通过这种方式，本章将帮助大家理解Scrum与各种传统产品开发方式的差异，为后面几章对 Scrum实践的条分缕析打下基础。

概述

我发现，在介绍Scrum基本原则时，如果把这些原则与推动传统计划驱动的顺序开发活动理念进行对比，会得到更大的启发。人们更容易理解Scrum与自己已知的方法有哪些异同。

把敏捷原则与传统开发原则进行对比，目的不是为了说明Scrum好而计划驱动的顺序开发不好。这两种方法都是专业开发人员工具箱中的工具。没有不好的工具，只有使用时机不当的工具。在第1章介绍Cynefin框架背景时我曾简单说过，Scrum与传统计划驱动的顺序开发分别适用于解决不同类型的问题。

在比较这两种方法的时候，我采用纯正的或“教科书式”的方式来描述计划驱动的顺序开发方法。从这个视角描述传统开发方式，可以更好地提炼出两者的区别并更清晰地阐明Scrum开发的基本原则。

纯正而传统的计划驱动开发常常称为“瀑布开发”（参见图3.1）。不过，计划驱动过程（也称为“传统开发”、“顺序式开发”、“预想式开发”、“预言式开发”或“说明性开发过程”）的类别很广泛，瀑布开发只是其中的一个例子。

图3.1  瀑布过程

计划驱动的开发来源于人们总是希望计划和预测工作内容（客户希望最终产品包含哪些特性），确定最佳工作方式（这些特性以哪一种最合适的方式完成）。它的思路是：计划制定得越好，对产品的理解就越好，执行也就越好。计划驱动过程常称为“顺序过程”，因为每个实际工作者按照顺序依次执行，在完整的需求分析之后是完整的设计、编码∕构建，然后是测试。

对于明确定义、可预测且不可能发生任何重大变更的问题，计划驱动开发方式是很适用的。问题是，大多数产品开发工作根本就不可预测，刚开始的时候尤其如此。因此，虽然计划驱动过程让人感觉有条理、可以解释清楚、可以度量，但这种印象会产生一种错误的安全感。毕竟，产品开发很少是按照计划进行的。

对很多人来说，计划驱动的顺序过程是合情合理的：首先是理解问题，然后设计、编码、测试、部署，全部都按照明确制定的计划执行。他们相信传统开发过程是可行的。如果使用计划驱动的方法没有效果，大多数人都会觉得一定是我们自己做错了事。即使计划驱动的过程反复产生令人失望的结果，但很多组织仍然还在沿用，傻乎乎地相信只要能够做得更好一些，结果就会有所改善。然而，问题并不在于执行。问题在于计划驱动方法所奉行的理念根本无法适应大多数产品开发工作所固有的不确定性。

另一方面，Scrum则奉行另一套不同的理念，该理念很好地处理了高不确定性而导致很难做出宏观预测这个问题。本章所描述的敏捷原则来源较多，包括敏捷宣言（Beck et. al，2001）、精益产品开发（Reinertsten 2009b；Mary and Tom Poppendieck，2003）和《Scrum指南》（Schwaber and Sutherland, 2011）

如图3.2所示，这些原则可以分为如下几类。

我们先讨论产品开发固有的可变性和不确定性的相关原则。再讨论如何平衡预测和适时调整之间的关系。然后着重讨论认知原则和半成品的管理原则。本章结束时再重点介绍进度和性能的相关原则。

可变性和不确定性

Scrum巧用产品开发的可变性和不确定性来产生创新解决方案。下面四个原则与这个主题相关。

l  积极采用有帮助的可变性。

l  采用迭代和增量开发。

l  通过检视、调整和透明来利用可变性。

l  同时减少各种各样的不确定因素。

图3.2  敏捷原则的分类

积极采用有帮助的可变性

计划驱动开发过程把产品开发当作制造业，它们避免任何变数，鼓励遵从规程。但问题是，产品开发和制造业完全不同。在制造业中，我们的目标是遵循大家都理解的一套顺序步骤，根据一套固定的需求，每次都（在明确制定的偏差范围内）生产出同样的产品（参见图3.3）。

图3.3  规程

然而，在软件产品开发行业，我们的目标不是制造产品，而是创建产品的单个实例。单个实例类似于独一无二的配方。我们不希望同样的配方得搞两次，太浪费钱了。相反，我们要为新产品创建独特的配方。每次在生产不同产品的时候，都必然存在一些变数。实际上，在产品中构建的每个特性都不同于该产品的其他特性，所以即使在产品层面也存在可变性。先有配方，我们才能制造产品，这对于软件产品来说，就像复制字节一样简单。

话虽如此，但制造业中的有些思想对软件开发还是挺适用的，软件开发能够并且应该利用这些思想。例如我稍后就会讲到一点：识别和管理WIP不仅对制造业非常重要，对软件开发也如此。然而就工作的本质而言，软件开发和产品制造完全不一样，所以需要完全不同的过程。

采用迭代和增量开发

计划驱动的顺序开发方式假设我们事先就能把事情做对，大多数或者所有产品部件到后期再集成。

然而，Scrum基于迭代开发和增量开发。这两个术语经常被用作一个概念，但它们俩实际是有区别的。

迭代开发承认我们在把事情做对之前有可能做错，在把事情做好之前有可能做坏（Goldberg and Rubin，1995）。迭代开发本身是一种有计划的修改策略。通过多次开发来改善正在构建的特性，逐步得出一个完善的解决方案。例如，对一个知之甚少的产品，开始时可以先创建原型以获得重要知识。接着可以创建一个更好一点的修订版，再接下来是一个相当好的版本。例如，在本书写作过程中，我在收到反馈以及对如何表达主题有了更深刻的理解后，每章都修改过好几次。

在产品开发过程中，迭代开发是改进产品的一种非常好的方法。迭代开发最大的缺点是在遇到不确定性因素时，很难事先确定（计划）需要改进多少次。

增量开发基于一个古老的原则：先构建部分，再构建整体。我们避免到最后才冒出一个大的、爆发式的活动，集成所有组件和交付整个产品。相反，我们把产品分解成更小的特性，先构建一部分，再从中了解它们在目标使用环境中的具体情形，然后根据更多的理解来做出调整，构建更多的特性。在本书写作过程中，我每次只写一章，在每章完成后都拿去评审，而不是等整本书都写完后再收集反馈意见。这样一来，我就有机会在后面几章的写作中采纳这些反馈，调整语气、风格或按需交付。这也使我有机会进行增量学习，把在前面几章所了解到的东西应用于后面几章的写作中。

增量开发提供了重要的信息，使我们能够适应开发工作并改变工作方式。增量开发最大的缺点是逐步构建的过程中，有迷失全局的风险（见木不见林）。

Scrum综合迭代和增量这两种开发方式的优点，消除了单独使用其中任何一种方式的缺点。Scrum使用一系列固定时长的适应性迭代来同时利用这两种方法的思想，这种迭代便是冲刺。如图3.4所示。

在每个冲刺都执行所有的必要活动，创建可工作的产品增量（产品的一部分而不是全部）。图3.4说明了每个冲刺完成一部分分析、设计、构建、集成和测试工作。这种“蜂拥式”（all-at-once）开发方法是有好处的，可以快速验证我们在开发产品特性时所做的假设。例如，我们做一些设计决策，在决策的基础上写代码，然后对

图3.4  Scrum采用迭代和增量开发

设计和代码进行测试，这些全部在同一个冲刺中进行。在冲刺中做完相关的所有工作，这样能快速修改特性，体会到迭代开发的好处，同时又不必特意为后面的迭代制定计划。

对冲刺思想的一种误用是，每个冲刺只集中做一种类型的工作——例如，冲刺1（分析）、冲刺2（设计）、冲刺3（编码）和冲刺4（测试）。这种做法简直就是想为Scrum披上瀑布式工作分解结构的皮。对于这种误导方法，我常常把它戏称为WaterScrum，也有人称之为Scrummerfall。

在Scrum中，并不是每次做一个阶段的工作，而是每次做一个特性。这样一来，在冲刺结束时就可以创建一个有价值的产品增量（产品的部分特性但不是全部）。这个增量需要包含前期已开发的特性，或者需要与前期已开发的特性进行集成与测试，否则就不能被认为完成。例如，在图3.4中，增量2包含增量1的特性。在冲刺结束时，可以把新近完成的特性与已经完成的特性放到一起并获得反馈。这有助于我们纵观全局，获得其他方法可能得不到的见解。

在收到对冲刺结果的反馈后，我们可以进行调整。在接下来的冲刺中可以选择开发其他特性或是修改用于构建下一组特性的过程。在某些情况下，我们可能认识到，尽管完成的产品增量在技术上令人满意，但实际上并没有达到要求。如果是这种情况，作为对迭代开发和持续改进承诺的一部分，在今后的冲刺中可以安排重新修改这个特性。这有助于解决事先不知道需要改进多少次的问题。Scrum不需要事先确定迭代次数。在增量开发产品时，持续不断的反馈能做到迭代次数合理，经济合理。

通过检视、调整和透明充分利用可变性

计划驱动过程和Scrum在几个维度上存在根本的区别（参见表3.1，基于Reinertsen建议的维度，2009a）。

表3.1  计划驱动过程和Scrum过程的对比

计划驱动的顺序开发过程假设产出物的可变性很小或不存在。这种开发方式遵循一套明确的步骤并只在过程后期才用到极少数反馈意见。相比之下，Scrum积极主动地接受这样的事实：在产品开发中，只要是构建新东西，就必然存在一定的可变性。Scrum还假设产品创建过程很复杂，无法事先给出详尽、严密的完整定义。而且，Scrum尽早、频繁的反馈过程，可以确保构建的产品是正确的，构建产品的方式是正确的。

Scrum的核心原则是检视、调整和透明性（Schwaber and Beedle 2011中将它们统称为“经验过程控制”）。在Scrum中，我们不仅要检视和调整正在构建的产品，还要检视和调整构建产品的方式（参见图3.5）。

为了更好地检视与适应，我们依赖于透明性：参与创建产品的每一个人都必须能够得到与WIP相关的所有重要信息。信息透明，才能进行检视，而检视又是调整的前提。信息透明能让每个相关人员看到并了解正在发生的事情。它能带来更多的沟通并同时在过程和团队成员中建立互信。

图3.5  Scrum过程模型

同时减少各种各样的不确定因素

开发新产品是一个很复杂的工作，具有很高的不确定性。这种不确定性可以分为以下两大类（Laufer 1996）。

l  结果不确定性（不确定做什么）——围绕最终产品特性的不确定性；

l  方法不确定性（不确定怎样做）——围绕产品的开发过程和技术的不确定性。

特定环境或特定产品还可能有客户不确定性（不确定用户是谁）。例如，哪些人才是这款产品真正的客户，对此，初创公司（包括开发新产品的大企业）也许只能靠猜。这种不确定性一定要处理，否则最后可能会出现好产品误入“养在深闺无人识”的境地。

传统的顺序开发过程事先全部定义需要构建哪些特性，先重点消除结果的不确定性，后处理方法的不确定性。

这种简单、线性的方法并不适用于降低不确定性，因为在产品开发这个复杂领域中，我们采取的行动与所处的环境相互制约。例如我们决定构建一个特性（我们的行动）；接下来向客户展示这个特性。客户在看到展示之后，却改变原来的想法或意识到自己之前并没有说清楚特性的细节（我们的行动引发环境的响应）；然后，我们根据反馈修改设计（环境的响应影响我们，使我们采取另一个之前无法预知的行动）。

在Scrum中，我们不会限制自己只在处理完一类不确定性之后才处理另一类不确定性。相反，我们采取更全面的方法，重点关注于同时减少所有不确定性（结果不确定性、方法不确定性和客户不确定性等）。当然，在任何时刻，我们可能会更侧重于关注某一类不确定性。通过迭代开发和增量开发，并在经常性的检视、适应和透明度指导之下，可以同时解决多种类型的不确定性。在出现未知的未知（我们不知道自己不知道的事情）时，这种方法能让我们抓住机会探测和探索周围的环境，识别和了解未知的未知。