第1章 从传统向敏捷软件开发的演进

在产品开发中，“敏捷”和“精益”这一对热词如影随形。精益产品开发离不开对敏捷软件开发的深入理解，所以我们的精益之旅也将从敏捷软件开发开始。本章讲述软件开发从传统进化到敏捷背后的业务动因以及敏捷软件开发实践体系。

传统软件开发方式面临的挑战

传统软件开发方法是与软件工程的概念一同诞生的（图1-1）。1968年，北约（NATO）召开全球第一届以“软件工程”命名的会议，这次会议通常被视为软件工程诞生的标志。会议上提出了“软件危机”的概念。随着软件复杂度的不断提高，软件项目普遍出现预算超支、质量低、性能差、不符合实际需求和延期等问题，造成所谓的“软件危机”。

当时，业界普遍认为，软件行业应该借鉴工程领域的经验，“系统地应用工程管理方法”，以此来应对软件危机。这是软件工程诞生的背景，在这一思路下产生的软件开发方法就是传统软件开发方法。它们共同的特点是强调计划、管控和结构化的工程方法，并遵循严格的生命周期概念，把软件开发分割为顺序阶段构成的过程，瀑布式开发方法是其中的代表之一。

相比作坊式的开发，传统方法开发方法进步明显。它让产品开发有矩可循，让项目和产品的成功可以重复，让组织的能力可以被评估，这些当然是好的。图1-1是传统开发方法的大致发展历程，到了上世纪90年代初，CMMI和PMI项目管理知识体系成为传统产品开发管理方法的典型代表。

然而，传统方法并没有从根本上解决软件危机，软件项目的失败率依然居高不下，甚至越来越糟糕。在这方面被引用得最多的是Standish Group定期发布的IT项目报告，该报告在1994年第一次发布时的数据显示，项目成功比例只有16%，有31%在发布前就被“砍掉”，剩下的53%平均超出了预算189%。

人们认识到，遵循严格生命周期的概念，把开发分割为顺序阶段构成的过程，实施起来不现实，造成了以下直接的危害。

• 希望通过对各个阶段设置关卡，严格控制，以期更早地发现问题，却滞后了集成和测试，让错误的发现延迟到最后，这是很多项目失败的根源。

• 希望一开始就能设定完整和正确的需求，这对软件产品越来越不可能，因为用户也不知道或说不清楚自己想要什么。事实上，对需求的挖掘和理解，应该是一个持续的过程，需要不断的反馈。

• 把成功定义为“遵循最初的计划和范围”。为了确保项目的“成功”而避免或拒绝进行合理的变更，却忽略了“达成商业目标才是真正的成功”。这已经成为业务成功的一个严重障碍。

另一方面，传统产品开发方法强调控制，所以一旦流程出现问题，自然的应对就是进一步加强管控，流程本身有自我复杂化的趋势，反而会压制关键软件开发人员的主观能动性。

面对以上问题，对传统软件开发方法的反思，几乎与其本身一样悠久。比如，瀑布模型的提出者Wiston Royce 1970年在他的论文中，只是把瀑布模型作为一个理论模型提出，并警告人们它绝对不适合用来进行大型软件开发。在论文的后半部分，Royce提出了一个包含原型和各阶段之间反馈的修正模型。遗憾的是，业界当时渴望的是一种建构式工程方法，瀑布模型迎合了这一要求，导致反对瀑布模型的Royce反倒被业界称为“瀑布模型之父”。至于Royce的忠告，也只有等到30年后敏捷运动兴起时才又被人们重新提起。

从传统到敏捷

面对传统软件工程方法的现实问题，一批轻量级的软件开发方法陆续涌现（图1-2），它们共同的特点是遵循演进和迭代的模型。其中，上世纪90年代出现的Scrum和极限编程在实践上最为成功，它们都是迭代和增量的软件开发框架。两者的区别是，Scrum只包含管理实践，而极限编程同时涵盖工程和管理实践。

上世纪90年代，另一个主要变化是PC软件流行和第四代编程语言的出现，面向对象和设计模式运动的兴起，使小型开发项目蓬勃发展，同时互联网应用和开源社区也在此时兴起，有别于传统的开发模式不断涌现，优秀个人在程序开发中的作用越来越明显。

这些因素都让非传统开发方法有了实验的土壤。其结果是，一方面质量问题层出不穷，促使源自全面质量管理体系的CMM/CMMI在这一时间迅速繁荣和推广；另一方面也产生了许多不同于传统方法的有效实践，让业界看到新的可能。敏捷运动这时呼之欲出，它既是对传统的反叛，也是对野蛮生长的规范。

2001年2月，17位轻量级软件工程方法的代表人物齐聚美国犹他州的雪鸟滑雪胜地，在两天的会议之后，发布了对后来产生巨大影响的《敏捷软件开发宣言》，如图1-3所示，敏捷宣言陈述了他们共同认可的软件开发方法理念，同样重要的是，他们找到“敏捷”这个词来总领这些理念。

敏捷概念在2001年出现，可谓适逢其时。当时一方面，传统方法变得越来越臃肿笨重，却没有解决软件危机；另一方面，人类正在进入互联网时代，软件业对响应变化和创新的要求迅速升级，这是更根本的原因，毕竟需求才是行业发展最好的助推剂。很快，敏捷成为一场运动，被迅速推广和应用。

理解敏捷必须回归业务视角

《敏捷宣言》属于价值观层面的宣导，对敏捷的推广和公众的认知起到了很大的作用。但对于敏捷是什么，却从来没有统一的定义。2010年，软件工程大师Ivar Jacobson在一篇博文中这样说：“过去你问我支不支持敏捷，我会说哪些支持，哪些不支持，并给出我的理由。但现在你再问，我就只能回答支持。因为，如今敏捷的意思已经演变成“软件开发中一切好的东西（Everything good about software development）。”

Ivar一语道破了真相。如图1-4所示，敏捷成了一个集合性的概念，一切好的，都归入敏捷，而一切失败，都归于不敏捷。这在商业上或许不错，却不利于概念的明晰和有效实施。毕竟，要真正理解敏捷，还是要回归业务目标。产品开发的最终目标是业务成功，这是没有异议的。接下来我们将从目标出发，理解敏捷的意义所在，并以此来指导我们具体落实敏捷实践。

敏捷产品开发的业务目标一：更早地交付价值

我们经常把敏捷与传统瀑布开发方法相对应。如图1-5所示，瀑布开发方法按顺序的阶段推进项目，到最后一次性交付全部的价值，在此之前的产出都是半成品。这无法适应今天市场竞争的要求。

IT行业的人都熟知摩尔定律：“18个月后，同样的钱，能买到相对今天两倍的产品——如计算能力、存储量、晶元数等。”我们今天讲的是反摩尔定律，它是2006年时任谷歌CEO的施密特提出的。如图1-6所示，反摩尔定律是摩尔定律的镜像，正如施密特所说的：

“如果我们18个月后卖出的产品和今天相同，那么得到的收入就只能是今天的一半。”

—— 反摩尔定律，施密特，Google前CEO，现执行董事长

反摩尔定律给我们的启示是，越早交付价值，其价值越高；反之越迟交付，则价值越低。IT行业就是这样残酷，如果身处硬件行业，必须跟得上摩尔定律的步伐，否则就会被反摩尔定律吞噬。

软件或服务行业会好一些吗？其实问题更甚。尤其是在移动互联时代，如图1-7所示，价值交付的延迟，让你无法享受早期的红利。更有甚者，错过时间窗口，可能意味着完全一无所获。

面对这些事实，敏捷开发给出的答案非常简单，迭代交付价值。如图1-8所示，在迭代开发模式下，每个迭代交付一部分价值。根据反摩尔定律，相对最后交付，这也是更多的价值。由此，我们得出敏捷开发的第一个业务目标：

从业务视角看敏捷的业务目标一：更快（早）地交付价值。

值得注意的是，“更快”并不是绝对速度的快，而是指时间上的早，即通过迭代交付，实现分批和更早交付。

敏捷产品开发的业务目标二：灵活地应对变化

继续从业务的角度来看传统到敏捷开发方法的变化。图1-9描述了传统开发模式下知识的积累历程。横坐标是项目从开始到结束的时间，纵坐标是团队对项目和产品的相关知识。随着时间的进展，团队不断积累相关的知识，比如用户要什么，最合适的产品和技术方案，最大的风险，等等。越往后，团队对项目和产品的知识越丰富和准确，团队知识最丰富的时刻显然是项目后期。

然而，关于项目的决策是什么时间做出呢？是在项目一开始的时候，比如确定需求范围、产品方案、实现方式、实施计划等决策。在知识最不充分的时候，做出了最重要的决定，并把它作为此后的基准，这就是传统开发下知识累积和决策时间间的悖论。在需求、市场和技术方案越来越不确定的移动互联时代，这是个生死攸关的大问题。

敏捷开发方法对这个问题的回答依然是迭代。如图1-10所示，迭代开发模式下，初始时，团队仍然需要做出一些决定，比如确定总体目标和初始方案。随着每个迭代的进展，团队获取新信息，比如市场和用户对产品的反馈、技术环境和竞争对手策略的变化等，团队通过这些新信息，建立新的认知，并在随后的迭代计划中做出调整，响应这些变化。

获取反馈，灵活响应变化，不断调整优化，在充满不确定性、变化和竞争激烈的时代，这是团队做出符合用户及市场要求与竞争产品的必由之路。由此，我们得出敏捷产品开发的第二个业务目标：

从业务视角看敏捷的业务目标二：更灵活地响应变化。

总结以上两个点，我们可以得出如下的结论：

敏捷的业务目标：打造组织更早地交付价值和更灵活地应对变化的能力。

回到敏捷（agile）这个词，在朗文词典中它的解释是：“Able to move quickly and easily”，指的是迅速行动和响应的能力。因此，我们可以说：“敏捷就是敏捷。”第一个敏捷是“敏捷开发”，第二个敏捷是“敏捷这个词的原始含义”，它与我们所说的敏捷业务目标是一致的。

敏捷实践体系

实践上，迭代交付模式是敏捷开发的核心要素，它使更早交付和更灵活应对变化成为可能。然而，迭代交付模式与瀑布开发模式的区别，使很多过去可行的实践变得不再可行。

要落实敏捷开发方法，需要构建与之匹配的团队组织方式、开发管理方法和技术实践体系。例如，Scrum提供了迭代管理和持续改进的框架，极限编程则奠定了早期敏捷开发技术实践的基础。在实施过程中，敏捷的实践体系不断完善，针对不同问题形成了较为完备的实践集。

• 如何管理迭代交付过程呢？对应的有Scrum、特性驱动开发和极限编程中的管理实践等迭代管理框架。

• 每个迭代交付什么？怎么规划？对应的有用户故事、用户故事地图和产品待办事项等敏捷需求实践。

• 怎样组织团队才能让他们直接面对用户的需求？对应的有跨功能、跨职能和自组织的敏捷团队组织方式。

• 如何在迭代模式下，更有效地组织需求澄清及验收过程？对应的实践有实例化需求、行为驱动开发或验收测试驱动开发等实践。

• 怎么应对持续增加的集成和回归测试？对应的实践有自动验收测试及持续集成等。

• 如何在迭代模式下保障设计的一致性和持续演进？对应的实践有代码共有、简单设计、测试驱动开发、持续重构和领域驱动设计等。

图1-11总结了敏捷实践以及它们要解决的问题，这并不是最终完整的实践列表，敏捷实践是在解决问题的过程中不断成长的。

我并没有把微服务架构、容器技术等最新的技术实践包含在内，是因为它们已经被DevOps的框架所容纳，后面介绍DevOps时还会提到它们。当然，你也可以把DevOps看成敏捷的延续或升级。重要的是不忘初心，记住敏捷的业务目标：更早地交付价值；更灵活地应对变化。

小结

相对作坊式的软件开发，传统软件开发方法进步明显，但也问题重重，更满足不了软件业日益提高的对及早交付和灵活应变的要求；敏捷产品开发的业务目标是为了更早地交付价值和更灵活地响应变化，理解业务目标，让我们更容易达成一致的理解，也为针对性地实施具体敏捷实践提供了依据。

本章要点

• 传统的软件开发方法诞生于上世纪60年代末的软件危机，它借鉴了传统工程管理的思想和方法。

• 对传统开发方法的反思从未停止过，上世纪90年代各类轻量级软件开发方法开始形成，发布于2001年的《敏捷软件开发宣言》汇总了这些轻量级软件开发背后的价值观和原则。

• 敏捷开发的业务目标是更早地交付价值和更灵活地应对变化。

• 敏捷开发实践应该服务于业务目标。

常见问题

问题：敏捷适用于所有组织吗？

回答：敏捷首先是目标，而不是具体的方法。作为目标，提升组织及早交付价值和灵活应变的能力，这当然是正确的，也是所有组织想追求的。只不过，不同类型的组织对这一目标的迫切程度不一样。

如果从事移动互联网产品的开发，敏捷和迭代交付就是必然之选，是这个行业的基本模式。不这么做，你根本无法参与市场竞争。相对传统的行业，对敏捷的需求要弱一些，但趋势也十分明显。如电信设备提供商在全面云化和网络虚拟化的冲击下，不得不面对互联网厂商的竞争，因而应用敏捷开发实践的需求也越来越强烈；过去认为传统的金融行业，面临互联网金融的颠覆，就更不必多说了。

问题：传统组织变得敏捷会有哪些困难，应该怎么做？

回答：使用传统开发方法的组织，其组织文化、团队结构、技术手段、流程工具还有考评和认可体系都会向传统方法优化，所以要想变得敏捷，会遇到各种问题。各个问题之间相互关联和牵扯会进一步放大问题，比如流程变了，考评和认可体系却没变，或者反之，都会造成组织无法运转顺畅。

另一方面，技术基础设施和遗留代码也可能成为变得更敏捷的障碍。这些从传统变得敏捷过程中遇到的问题，都会表现为敏捷的弱点，也是我们需要正视的问题。

实施敏捷很困难，这是一个事实。组织要想清楚要不要变得敏捷，对这个问题的肯定回答已经成为大部分组织的共识，因为它关系到组织的竞争力，甚至生死。如果变得更敏捷是组织的选择，那么接下来就是如何正确实施，正视和应对变革过程中的困难，并找到一条相对有效的和便捷的变革路径。我们在本书第II部分和第III部分讲的精益方法和实施，可以为实现敏捷变革提供一个有效的路径。