采用迭代和增量开发

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

然而，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不需要事先确定迭代次数。在增量开发产品时，持续不断的反馈能做到迭代次数合理，经济合理。