下载掌阅APP，畅读海量书库
立即打开
从古至今，人类创造了许多伟大奇迹，例如，中国的万里长城和京杭大运河等。我们无法知道当初人们是怎样在不具备现代化设备的情况下建造出这些令人叹服的人类奇迹的，但可以确定的是，人们一定有一套行之有效的方法来管理这些浩大的工程，只是由于时代久远没有保留下相关的资料。1776年，英国的亚当·斯密在《国富论》中首次提出劳动分工的概念，成为工程管理相关思想的萌芽和发展的里程碑。到了20世纪初，美国的泰勒及吉尔布雷斯夫妇等工程师们经过不断研究和探索，提出了科学管理和提高生产力的原则，为工业工程的发展做出了极大贡献，而泰勒更被誉为“工业工程之父”。
最早享受到工业工程带来的巨大好处的公司是一家汽车制造企业——美国著名的福特公司。1913年，福特公司实验了第一条汽车流水线，如图1-1所示。流水线使汽车的组装制造时间大大缩短，工人的效率也极大提升，福特公司的T型车产量因此占据当时全世界汽车总产量的一半以上。
图1-1 福特汽车流水线
工业工程的实践探索为后来软件工程的发展提供了理论基础和借鉴，甚至在现在流行的敏捷开发模式中，很多好的理念和实践也来自工业制造业，如包含JIT（Just-In-Time）的精益理念和看板（Kanban）等。
软件工程是在20世纪60年代提出的，但是世界上第一个程序早在1842年就被设计出来了，负责设计程序的人是Ada Lovelace。如果对这个名字感到陌生，那么她的父亲、英国著名诗人拜伦的名字你一定听过。Ada设计了一种计算伯努利数字的算法，这个算法被认为是世界上第一个计算机程序，而Ada也因此成为历史上首位程序员，同时也是历史上首位女程序员。为了纪念Ada对后世做出的贡献，美国国防部主持开发了一款新的高级计算机编程语言并以她的名字命名，这就是著名的Ada语言。
20世纪40—50年代，随着计算机的出现，计算机软件的概念也开始形成。当时人们对于软件开发没有太多的方法，态度也比较随意，更多的是以一种软件作坊的方式进行开发。随着软件数量的急剧增加，需求复杂度和软件维护难度也越来越高，但软件的质量却越来越低，开发成本不断增加，失败的项目越来越多，导致了软件危机的发生。1968年，为了解决软件开发的混乱状态，当时的北大西洋公约组织（NATO）在德国小城举行了一次学术会议，这次会议被命名为“软件工程大会”，标志着软件工程学科的诞生。
1970年，美国计算机科学家温斯顿·罗伊斯（Winston Royce）在发表的文章《管理大型软件系统的开发》中首次提出了著名的瀑布模型，如图1-2所示。这是在软件危机之后提出的第一个软件开发模型，而且在之后的几十年中，瀑布模型一直是众多企业软件开发的首选模式。瀑布模型的核心思想是把软件开发的生命周期按工序思想划分成不同的阶段，每个阶段都有输出物，而每个阶段的输出物都会成为下一阶段的输入依赖。同时，每个阶段只有在经过严格的评审、验证确认通过之后，才能结束并进入下一阶段。这种模型使软件开发的无序状态变得规范化、标准化和体系化，使软件质量得到了保证。
图1-2 瀑布模型
在20世纪90年代，由于业务系统具有不确定性，以及市场变化使需求频繁变化，原来的瀑布模型受到了很大的挑战，其存在以下3个严重问题。
瀑布模型在各阶段遵循固定的执行顺序，只有通过了测试评估，在上线部署时，客户才能看到真实可用的产品，在之前的几个月，甚至几年的时间里，客户接触不到真实产品。这种方式带来了很大的风险：如果在项目的最初阶段没有正确理解客户的意图，做出来的产品不满足客户需求，那么只能在项目的最后阶段才发现，这时再想做任何形式的修补都为时已晚。
瀑布模型比较适用于前期需求明确固定且后期不会出现频繁变动的场景，基于这一前提，我们可以在需求阶段确定和基线化需求，并把它作为后续开发和测试的基准，这就是典型的预定义过程控制模式。当然，瀑布模型也并非不能出现任何需求变动，但是所有的需求变动都必须遵循一套严格的需求变更控制流程，以此保证因需求变化带来的影响能够得到控制。随着软件行业的迅速发展，以及商业环境竞争的日益残酷，这种需求的不确定性及频繁变化不可避免，并且愈演愈烈，如果还继续遵循瀑布模型的变更控制方式，那么在应对这种频繁变化的不确定需求时将感到非常吃力。
在产品还没上线时，我们在瀑布模型的各阶段都看不到真实的产品，所以每个阶段都需要有大量的文档来描述所做的工作，而这些文档又成为下一阶段的工作输入。例如，在需求阶段需要有需求规格说明书，在设计阶段需要有概要设计说明书和详细设计说明书等。但这些文档对于用户来说其实没有太大的价值，用户需要的是可用的产品，而不是一堆项目人员花费很大精力做出来的工作文档。
业界的一些软件开发实践者在意识到瀑布模型的局限和问题后，就开始抛弃这种方式，并且思考和探索新的开发模式，以应对新时代环境下对软件开发的要求。
鉴于瀑布模型的种种弊端，自20世纪90年代开始，许多软件行业领袖和从业者开始进行各种轻量级软件开发模式的探索和实践。1994年，英国一个由17家公司发起的联盟提出了动态系统开发方法（Dynamic Systems Development Method，DSDM）；1995年，美国软件开发专家Jeff Sutherland和Ken Schwaber共同提出了Scrum开发框架；1996年，美国软件开发大师，同时也是JUnit作者的Kent Beck提出了极限编程（Extreme Programming，简称XP）；同年，Alistair Cockburn和Jim Highsmith共同提出了水晶方法（Crystal）；1997年，Jeff De Luca、Eric Lefebvre和Peter Coad一起提出了特性驱动开发（Feature Driven Development，FDD），等等。一时间，各流派的理论与实践百花齐放。
2001年，17位来自DSDM、Scrum、XP、FDD等流派的专家代表在美国犹他州一个名为雪鸟的滑雪胜地齐聚一堂，分享了各自的想法。虽然参会者推崇的框架和实践存在互相竞争的可能，但是这些框架相对于瀑布模型来说都属于轻量级的软件开发模式，其核心思想都是使用更简单、更快捷的开发模式来适应快速变化的环境。参会者们虽然没有在方法上实现统一，但其中一位参会者正好在看 Agile Competitors and Virtual Organizations：Strategies for Enriching the Customer 这本书，他提出使用“敏捷”（Agile）一词作为这次运动的名称，得到了大家的一致认同。最终，17位行业专家共同起草和发表了著名的敏捷软件开发宣言，“敏捷”一词在软件业内正式流传开来。敏捷软件开发宣言如图1-3所示。
图1-3 敏捷软件开发宣言
在雪鸟会议后，专家们又通过几个月的时间制定了敏捷宣言遵循的12条原则，如图1-4所示。这些原则更具体、更有操作指导性，使得敏捷宣言在贯彻时有了更清晰的准则。
图1-4 敏捷宣言遵循的12条原则
在雪鸟会议后，敏捷运动收获了越来越多人的支持和追随，敏捷也在全世界迅速传播。进入VUCA时代（VUCA由四个单词的首字母组成，即Volatile、Uncertain、Complex、Ambiguous，其起源于军事术语，现在被用来描述已成为“新常态”的、混乱的和快速变化的商业环境），敏捷开发更是成为众多软件企业进行软件开发的首选模式。
那么，究竟什么是敏捷？其定义可以概括为以下三句话。
（1）敏捷是一系列方法，如XP、Scrum、Lean等的总称，其目的是通过迭代和增量的开发，以及经常性地检视和调整来提升项目的管理和交付水平。
（2）敏捷不只是一个新的流程，还要用新的文化方式来进行软件开发。
（3）需求和解决方案通过自组织、跨职能团队之间的协作而发展。
我们先来解读第一句话。
首先，敏捷并不是某种具体的方法，而是各种方法的总称。业界经常用敏捷伞来表示敏捷和各种具体方法（框架）的关系。如图1-5所示，敏捷就像一把伞，各种各样的框架和实践都被覆盖在伞下。
图1-5 敏捷伞
其次，敏捷是通过迭代和增量的方式来进行开发的。很多人或许都听说过迭代开发和增量开发，但不一定能准确地说出它们之间的区别。尽管增量和迭代都是分步进行开发的，但其实是两种不同的开发方式，而且适用的场景和使用目标也不同。迭代开发主要应对产品内部的不确定因素，如一开始根本不知道未来要构建的产品是什么样的，这种情况在当前的互联网行业非常普遍。我们不能指望一次就能构建出准确的产品，而是可以通过迭代的方式，先开发一个基础版本，然后投放到市场上观察效果，根据市场的反馈进行修改和优化，之后再次投放市场，再根据反馈优化，精益求精，最终打造出客户想要的产品。迭代开发如图1-6所示，如果用一个词语来形容这个过程，就是“渐进明细”，即产品随着不断迭代而越来越清晰。
图1-6 迭代开发
而增量开发应对的是产品之外的不确定因素，如在资源短缺的情况下，当资金或人员不能一步到位时，我们需要分步开发。在这种情况下，我们对于如何开发产品其实已经心中有数了，只是外部因素的限制让我们只能以增量的方式开发，如图1-7所示。如果用一个词语来形容这个过程，那就是“胸有成竹”，也就是一开始就需要对要开发的产品有比较清晰的认识。
图1-7 增量开发
而敏捷则是结合了两种开发方式的优点，同时使用增量和迭代的方式进行开发。敏捷开发如图1-8所示。
图1-8 敏捷开发
最后，敏捷通过经常性地检视和调整来提升项目管理和交付水平，这一点道出了传统瀑布式开发和敏捷开发的一个重大区别。传统瀑布式开发主要是采用预定义的过程控制方式，就像火箭发射一样，需要预先计算和设定好发射运行轨道，才能确保将卫星准确送入太空；而敏捷开发更多地是采用经验性的过程控制方式。经验性过程控制方式包括适应性、灵活性、自下而上等原则，其核心是根据不同的环境和相关的经验不断自我调整，以适应当前变化，就像开车一样，要根据道路的实际情况不断灵活地调整路线。
我们再来解读第二句话。
很多组织或项目以为把一个Scrum框架搬进项目，再按照流程执行就是敏捷，这其实是一个错误的认识。敏捷涉及的不仅是流程，还有文化、理念、组织等方面的转变，如果这些方面没有做出相应的改变而只是实施了流程，那么可以想象，这种转型是不会成功的，很有可能会成为所谓的“伪敏捷”（Fake-Agile），这一点将在3.2节进行深入讨论。
最后再来解读第三句话。
这句话强调敏捷团队需要是自组织且跨职能的团队，因为只有跨职能的团队才能最大限度地提升沟通和执行效率，这一点将在3.3节进一步展开讨论。
有些人认为敏捷就是指Scrum，这其实是一种错误的认识，敏捷并不等同于Scrum。我们从1.2节中已经了解到，敏捷其实是一系列方法如XP、Scrum、FDD、Lean等的总称。很多人认为敏捷就是Scrum的一个很重要的原因是在敏捷众多的方法中，Scrum是被使用得最多的一种。根据CollabNet VersionOne在2019年公布的第13届年度敏捷状态报告，Scrum在敏捷方法的使用占比高居第一，达到了54%，如图1-9所示。其实Scrum只是敏捷的一个实践框架，它们是包含关系，而不是等同关系。
Scrum一词原意是在英式橄榄球比赛中，当发生意外犯规或球出界后，在犯规地点重新开始比赛时要先进行对阵争球，两队队员在橄榄球前围成一圈，互相将胳膊搭在一起准备争球。Scrum在软件产品开发领域的应用可以追溯到1986年《哈佛商业评论》中的一篇文章。当时，日本学者竹内弘高和野中郁次郎在其文章《新型的新产品开发策略》中写道：“传统的接力赛一样的开发模式已经不能满足快速灵活的市场需求，而整体或‘橄榄球式’（Scrum）的方法——团队作为一个整体前进，在团队的内部传球并保持前进，可以更好地满足当前激烈的市场竞争。”
图1-9 CollabNet VersionOne关于敏捷方法的使用占比统计
1995年，Jeff Sutherland和Ken Schwaber根据这篇文章的理念，结合增量开发、迭代开发和经验性过程控制等实践，创建了轻量级的软件开发管理框架Scrum。Scrum相对轻量级的流程框架让使用者在执行和操作时都获得了较大便利，其流程框架如图1-10所示。
图1-10 Scrum的流程框架
敏捷业内人士喜欢用“3355”来总结Scrum的核心内容。所谓“3355”，是指Scrum框架体系里面的3个重要角色、3个重要工件、5个重要事件和5个价值观，如图1-11所示。
图1-11 Scrum框架“3355”
在Scrum中，一个Scrum团队只存在以下3个角色。
（1）产品负责人（Product Owner）：其主要职责是确定产品待办列表中需求的优先级，督促团队优先开发最具价值的功能，确保最具价值的开发需求始终被安排在最近的Sprint中。
（2）Developers：其主要职责是找出在一次Sprint中可以将迭代待办列表转化为潜在可交付的产品增量的方法，并且通过管理自身工作实现目标。产品负责人设定目标和方向，Developers对每次迭代和项目负责。在Developers中可能包含架构师、开发人员和测试人员等，但是他们的工作职责不会再有明确的界定，他们都属于一个团队，有共同的目标，那就是在规定的迭代时间内完成每次迭代需要实现的产品增量。
（3）Scrum Master：其主要职责是维护Scrum流程，确保团队与产品负责人对Sprint的目标保持一致。
在Scrum中，还有如下3个非常重要的工件。
（1）产品待办列表（Product Backlog）：即产品的需求列表，由PBI（Product Backlog Item）组成。PBI一般包括新特性、变更、缺陷或技术改进需求等。Scrum并没有为PBI指定任何标准格式，但是一般倾向以用户故事（User Story）的形式来表述每个需求，具体内容详见4.1节。
（2）迭代待办列表（Sprint Backlog）：这是每次Sprint迭代需要完成的需求列表集，以及这些需求被分解成的要具体实现的每组任务列表。这些需求需要在本次迭代中实现。
（3）产品增量（Increment）：这是在当次迭代中完成的可交付的工作输出件。每个产品增量都是实现产品目标的一块坚实的垫脚石。
在Scrum中，有以下5个重要事件会在每次sprint中循环出现。
（1）Sprint：Sprint是所有其他事件的容器。它是时长固定的事件，通常为期一个月或更短的时间，以保持一致性。前一次Sprint结束后，下一次Sprint立即开始。
（2）Sprint计划会（Sprint Planning Meeting）：这是在每次迭代开始时举行的计划会，在会上将确定本次迭代的目标和需要完成的需求，同时确定实现本次目标所需完成的任务和对工作量进行估算。
（3）每日站会（Daily Scrum Meeting）：一般为15分钟站立会议，每位成员主要回答3个问题：昨天做了什么？今天要做什么？有什么需要帮助的地方？
（4）Sprint评审会（Sprint Review Meeting）：团队成员向产品负责人及其他干系人演示本次迭代内完成的工作。
（5）Sprint回顾会（Sprint Retrospective Meeting）：周期性的回顾，总结工作经验和教训，同时一起讨论哪些工作应该开展，哪些应该停止，以及哪些需要继续保持。
另外，还有一个活动，虽然在《Scrum指南》（ Scrum Guide ）2020版中没有被提到，但却非常重要，那就是需求梳理（Requirement Refinement）。需求梳理是对下次迭代需要处理的需求进行梳理和细化，其中包括确定和细化需求、对需求进行估算和进行优先级排序等。进行需求梳理时需要遵从“DEEP”原则，如下所示。
·适当的细节（Detail Appropriately）：将马上要开发的需求放在列表顶部，稍后开发的需求放在底部。待开发的需求需要细化，而未来才开发的需求可以暂时以粗粒度的形式存在，所以不用在一开始就要求所有需求都很详细，原则上是刚好够用（Just-In-Time）。
·不断涌现（Emergent）：只要有正在开发或维护的产品，产品待办列表就永远不会是完成或冻结状态。随着时间的推移，产品待办列表将渐渐变得有条理。
·经过估算（Estimated）：需求需要进行估算。靠近产品待办列表顶部的需求小、内容详细，所以估算要更细致、更精确，可以用故事点来表示需求的大小，靠近列表底部的大条目需求一般比较粗糙，暂时还无须细化，此时以故事点来表示并不恰当，可以考虑以T恤衫的尺码进行类比，例如，以S、M、L、XL等进行粗略估算。
·经过排序（Prioritized）：产品待办列表是一个排列好优先顺序的需求列表。当然，不可能所有需求都已经排好优先顺序，为远期条目排列优先顺序就是在浪费时间。
在Scrum中，我们还必须坚持以下5个价值观。
（1）勇气（Courage）：团队成员都需要有勇气面对和接受挑战。
（2）公开（Openness）：团队所有的状态、问题、风险和阻碍等都得是公开的、可视的，对所有人透明，这样才能随时暴露问题。
（3）专注（Focus）：每次迭代只专注该次迭代要完成的事情，尽量避免受到来自外部环境的干扰，在有限的时间内专注于最有价值的事情。
（4）承诺（Commitment）：自组织团队在迭代开始时就要做出承诺，并且尽最大努力完成迭代任务。
（5）尊重（Respect）：团队成员互相尊重、理解和信任，有问题随时沟通。
我们知道Scrum团队的人数一般为5～9人，亚马逊公司最早将其称为“two-pizza”团队，意思是2张比萨饼刚好能喂饱的人数。显然，这是小团队的规模，这种规模的团队沟通非常高效。但是，随着软件行业的不断发展，软件在众多企业中扮演了越来越重要的角色，现在很多软件项目的团队规模已经远不止5～9人，不少已经达到数十人，甚至数百人。在如此庞大的人员基数下，如果还是用Scrum这种小规模团队的开发管理方式，项目在进行时将会举步维艰。因此，业界许多专家开始研究在大规模团队下的敏捷该如何进行，主要解决团队扩展和协调的问题。目前的规模化敏捷主要有3套比较流行的框架，分别是SAFe框架、Scrum@Scale框架和LeSS框架。
SAFe是Scaled Agile Framework的简写，该框架的主导设计者Dean Leffingwell曾经工作于Rational公司（后被IBM公司收购），他是公认的需求领域的权威人士，曾经主导开发了需求管理工具RequisitePro，对于大型企业软件开发的特点非常了解。SAFe框架如图1-12所示。
图1-12 SAFe框架
SAFe对于大规模团队管理的核心理念是，通过在Scrum的基础上增加不同的层级和角色来应对大项目、大型复杂解决方案，甚至是产品组合管理对于敏捷的需要。SAFe分层结构是从团队级（Team Level）到项目群级（Program Level）再到价值流级（Value Stream Level），最后到投资组合级（Portfolio Level），并且在此过程中糅合了精益-敏捷、质量内建、系统思考、排队论等知识体系。
Scrum@Scale框架如图1-13所示。对于Scrum@Scale框架的创建者Jeff Sutherland，大家更熟悉的可能是他和Ken Schwaber共同创建的Scrum框架，两人在规模化敏捷方面其实专注的是不同的研究领域，Sutherland主要研究Scrum@Scale框架，而Schwaber主要研究另一个规模化框架Nexus。
图1-13 Scrum@Scale框架
Scrum@Scale框架的基础是Scrum，是一个对Scrum进行扩展的框架，通过使用Scrum来扩展Scrum，并且彻底简化了规模扩展。在Scrum@Scale框架中存在2个循环：Scrum Master循环（Scrum Master Cycle）和产品负责人循环（Product Owner Cycle）。Scrum Master循环整合了如何做事，也就是“How”的问题；而产品负责人循环整合了做什么事，也就是“What”的问题。Scrum@Scale框架可以扩展到整个组织，这是一个为组织的整体扩展而设计的规模化敏捷框架。
LeSS框架是基于Scrum扩展的另一个规模化敏捷框架，如图1-14所示。
图1-14 LeSS框架
LeSS是Large Scale Scrum的简写，由Bas Vodde和Craig Larman共同设计并率先在诺基亚公司的网络部门进行实践。他们还合著了 Large-Scale Scrum：More with LeSS 等LeSS相关的书籍。
LeSS框架的基础是Scrum，其核心理念是尽量保持在原有的Scrum基础框架上，在尽量不增加内容的同时，解决大规模团队的问题。LeSS框架认为“less is more”，并且不随意增加角色，因为增加一个角色容易，但是“请神容易送神难”，以后想要去掉这个角色就会非常困难，所以，LeSS框架的理念和SAFe框架存在很大不同。
除了前面提到的3个主流规模化敏捷框架，还存在其他框架，如DAD、Spotify、Nexus等。根据CollabNet VersionOne在2019年公布的第13届年度敏捷状态报告，SAFe框架在众多规模化敏捷体系中的占比最高，达到30%，如图1-15所示。
图1-15 规模化敏捷框架占比统计
本章讨论了软件工程的发展及敏捷的由来，并且简单介绍了敏捷Scrum及规模化敏捷等相关内容。
本章的主要内容如下。
（1）瀑布模型的核心思想是把软件开发生命周期按工序思想划分成不同的阶段，每个阶段都有输出物，而每个阶段的输出物都会成为下一阶段的输入依赖。
（2）传统方法基于预定义过程控制模式，而敏捷方法基于经验性过程控制模式。
（3）敏捷不等同于Scrum，敏捷其实是一系列方法如XP、Scrum、Lean等的总称，其目的是通过迭代开发和增量开发，以及经常性地检视和调整来提升项目的管理和交付水平。
（4）增量开发应对的是产品之外的不确定因素，需要“胸有成竹”；迭代开发应对的是产品之内的不确定因素，需要“渐进明细”。
（5）敏捷Scrum中的“3355”是指Scrum框架体系里面的3个重要角色、3个重要工件、5个重要活动和5个价值观。
（6）规模化敏捷包括SAFe、Scrum@Scale、LeSS等主流框架，其目的主要是解决团队扩展和协调的问题。