引言
谁动了你的“敏捷”
你们的敏捷试点彻底失败了，大家对敏捷的价值充满了怀疑。
你们热火朝天地敏捷了半年，业务部门依然认为你们没有敏捷。
在你们公司，老板把敏捷当作一个让员工加班的手段。
多个敏捷小组互相依赖，互相指责，“内卷”严重。
人越招越多，但效率却越来越低，原来的密切协作氛围再也找不到了。
你们的每日站会没有任何价值，大家每天都在行尸走肉。
大家认为敏捷就是开会，浪费了大量的时间。
计划会开了半天，制订了一份大家都不认可的计划。
每天忙于“救火”，在缺陷中找缺陷，每天都加班，大家疲惫不堪。
你们的持续集成亮红灯了，但好久没人修复，也没人关心。
需求优先级不断调整，相互冲突，每天一个说法。
你们也在不断地总结回顾，但是问题依然还有很多。
你们搭建了工具链，强迫大家使用，但敏捷还是老样子。
你们花大价钱请了咨询团队，他们一走，你们立刻回到老路。
……
对此，你是否也心有戚戚焉？
你抱怨！
你困惑！
你迷茫！
你失望！
谁动了你的“敏捷”？
也许你自己说不清，也许你更期待高人能指点迷津，或许我们可以先回顾一下敏捷的发展简史，从敏捷先哲的探索之路中找到答案。
寻找银弹
1967年，Conway提出了康威定律（Conway’s Law），他认为“系统的架构受制于产生这些设计的组织的沟通结构”。反过来理解就是“如果系统架构不支持，你无法建立一个高效的组织”。后来这条定律成为划分敏捷协同团队及产品架构设计的重要理论依据。[1]
[1]摘自头条号“振振有词abc”的文章《通过一篇文章来了解“敏捷”的发展历程》。
1970年，Winston Royce发表“Managing the Development of Large Software Systems”（管理大型软件系统的开发）论文，第一次正式描述了瀑布模型。如图0-1所示，瀑布模型将软件开发的各项活动规定为按照固定顺序连接的若干个阶段，一级一级，自上而下，形如瀑布流水，因此得名瀑布。
图0-1 瀑布模型
1974年，E. A. Edmods通过论文介绍了自适应性软件开发（Adaptive Software Development，ASD），提倡拥抱变化，借助协作和学习来应对复杂系统的开发。
1975年，Fred Brooks出版《人月神话》，提出软件开发“没有银弹”（No Silver Bullet），与此相关的软件危机问题激发起软件行业从业者对轻量级方法的探索。他提出的“Brooks定律”，即“投入更多的人到一项延迟的工作上，可以导致该项工作更加延迟”，虽然没有得到大多数人认同，但依然抑制不住大家向落后项目中增加人手的冲动。直到后来，动态系统开发方法（Dynamic System Development Method，DSDM）提出了著名的敏捷倒三角形模型，强调有限时间、有限资源情况下，只做有限需求，需要对需求进行优先级排序，方才有所缓解。
1976年，Glenford Myers的著作Software Reliability（《软件可靠性》）出版。这本书阐述了一条“公理”——“不应该由开发者来测试自己的代码”，这意味着需要多个角色协作才能保证质量，这跟后期的“全面质量管理”运动不谋而合。
1980年，由Harlan Mills主编的文集对增量开发进行了实质性讨论。Dyer在文章中明确指出“软件工程的原则是，每次迭代完成的功能要尽可能地与其他迭代解耦”。
1980年，源于丰田公司生产系统的“可视化控制”（visual control）概念是“信息辐射器”（information radiator）的最早概念，现在我们经常提及的“基于经验的过程控制”的三大支柱——透明、检视和调整，其实都跟可视化直接关联。
1984年，随着对“瀑布”顺序式开发模式的批判，作为替代物的“增量方法”变得越来越突出。一个很好的例子是《软件工程中基于知识的沟通过程》中的一篇文章倡导使用增量开发，具体原因是“不存在完整和稳定的需求规格”。
1985年，Tom Gilb提出了首个有明确命名的、用于替代“瀑布”的增量开发方法——进化交付模型（Evolutionary Delivery Model），绰号是“进化”（Evo）。
1986年，Barry Boehm提出了“软件开发和优化的螺旋模型”，提倡通过合适的方法（尽管展示的“典型”例子是基于原型，但不仅限于原型法）来识别和减少风险。
1986年，竹内弘高和野中郁次郎在《哈佛商业评论》发表了他们的文章“The New New Product Development Game”（新新产品开发游戏）。这篇文章描述了一种类似橄榄球队工作模式的方法，即“产品开发过程是在一个精心挑选的多职能团队的持续互动中产生的，团队成员从头到尾都在一起工作”“这种团队自我组织、自我管理，有能力决定如何开展工作，并获得了根据自己决定做事的授权”。据说这篇文章是Scrum框架的灵感来源。
1987年，Ivar Jacobson成立Objective Systems公司。他吸纳了增量迭代的思想，开发出Objectory过程，并且把过程当软件卖，单份售价达到2.5万美元[2]。
1988年，“时间盒”（timebox）被描述为Scott Schultz的“快速迭代开发成型”法的基石，这种方法应用于杜邦公司的副业——信息工程协会。现在笔者在讲述Scrum框架的起源时会经常提到时间盒。[3]
[2]1美元合7.24元人民币。
[3]参考Cyh的博客文章《敏捷十年简史回顾——影响敏捷开发历程的27件事》。
百家争鸣
1991年，James Martin在其著作《快速应用开发》中描述的RAD（Rapid Application Development，快速应用开发）方法或许是第一种把时间盒和迭代（较宽松意义上的“整个软件开发过程的一次重复”）紧密结合在一起的方法，第一次对时间盒进行了细节描述。
1992年，Larry Constantine在一次拜访Whitesmiths公司的过程中创造和报道了“活力二人组”（Dynamic Duo）这个术语，即“每一台终端前有两位程序员。当然，实际上只能由一位程序员操作键盘来编辑代码，但他们两个是并肩作战的”。这其实是关于结对编程最早的记录，现在我们经常用“你开车，我导航”来比喻，但是其中的核心是“并肩作战”。
1994年，在Rational公司工作的Rumbaugh和Booch开始合并OMT和Booch方法。随后，Jacobson带着他的OOSE方法学也加入了Rational公司，一同参与这项工作。他们3个人被称为“三友”（three amigo），一起开发UML，最终提出了“Rational Unified Process”（RUP，Rational统一过程）及4+1视图模型。RUP的中心思想是用例驱动、架构为中心、迭代和增量。RUP过程如图0-2所示，共分成4个阶段—初始（Inception）、细化（Elaboration）、构造（Construction）和交付（Transition）。这项工作对整个业界造成了很大的冲击，因为在此之前，各种方法学的拥护者都觉得没有必要放弃自己已经采用的方法，而接受统一的流程，但RUP在国内外还是影响了很大一批人。这也是吸引我后来加入IBM Rational团队的关键点。毕竟在软件工程领域，虽然RUP最终败给了敏捷，但IBM Rational团队在方法论及工具方面的沉淀，还是独领风骚很多年，因此，RUP成为软件开发团队中流传最广的软件过程模型，也成为团队学习软件工程和实施过程改进的重要资料。
图0-2 RUP过程
1995年，Alistair Cockburn发表文章“Growth of Human Factors in Application Development”（应用开发中人类因素的增长），提出迭代方法会逐渐被接受的主要原因之一是软件开发的瓶颈正在转向（个人和组织）学习，并且人类学习本质上是一个迭代和试错的过程。
1995年，在OOPSLA’95会议上，Sutherland和Schwaber联合发表了一篇论文。该论文系统地介绍了Scrum方法，这标志了Scrum的诞生。Scrum框架目前能够成为团队级敏捷的主流框架，跟它对各种关键实践的兼收并蓄有着极大关系。
1996年，Kent Beck为了挽救Chrysler Comprehensive Compensation（简称C3）项目而创建了XP（eXtreme Programming，极限编程）过程。虽然Chrysler最终取消了该项目，但是随着Ron Jeffries和Ward Cunningham等人参与到XP的工作中，从此奠定了XP的历史地位。
1997年，Ken Schwaber描述了“每日Scrum站会”（Daily Scrum）〔这在其早期的著作中并未出现，如1995年的文章“SCRUM Development Process”（Scrum开发过程），这项活动后来被Mike Beedle重新整理到第一本Scrum图书中，成为现在广为流传的实践。〕
1997年，Alistair Cockburn受IBM公司委托，开展了一个关于团队规模的研究项目，正式提出了Crystal（水晶）方法。Alistair建立了一个二维坐标系，其中，垂直因素是舒适度（C）、可自由支配资金（D）、基本资金（E）和项目寿命（L），水平因素是“团队规模”，划分出不同颜色的水晶，用于代表不同的团队规模。对水晶方法的细分能够帮助团队更加高效地完成软件开发与项目管理，其中透明水晶（Crystal Clear）是敏捷小团队的适宜模式。
1998年，Jeff De Luca和Peter Code正式提出FDD（Feature Driven Development，特性驱动开发）方法。FDD方法非常适用于团队成员水平参差不齐的情况，因为最有经验的可以做主要编程人员。不过，如果一个小团队中大家的水平都差不多，可能会出现资源浪费的情况。
1998年，持续集成和“每日站立”（daily stand-up）被列入极限编程的核心实践。
1999年，Martin Fowler的著作Refactoring: Improving the Design of Existing Code（《重构：改善既有代码的设计》）[4]出版，对敏捷开发中的“重构”实践首次进行系统化阐述。
[4]该书由人民邮电出版社引进出版，ISBN：978-7-115-36909-3。
1999年，Kent Beck在其著作Extreme Programming Explained（《解析极限编程》）中创造了术语“大可视化图表”（Big Visible Chart），尽管后来他把此归结于Martin Fowler。
2000年，Ken Schwaber在美国富达投资集团工作时，试图为Scrum团队提供一个简单的工具包，于是发明了“燃尽图”（burndown chart），并在其网站上正式描述相关概念。
2000年，术语“团队速率”（velocity）被添加到极限编程，用于替代先前被认为过于复杂的概念——“负载系数”（load factor）。
敏捷诞生
2000年春，Kent Beck组织了一次会议，地点是美国俄勒冈州的罗格里夫酒店，参会者包括极限编程的支持者和一些“圈外人”，正是这次会议促进了后来在雪鸟滑雪场举办的聚会。在罗格里夫酒店的会议上，参会者宣称对一系列“轻量”方法论的支持，但没有发表正式声明。2000年期间一系列论文都被归类到“轻”或“轻量”流程，其中很多都提到“轻量级方法论，如极限编程、适应性软件开发、水晶系列和Scrum”。大家交流后发现，没人真正喜欢“轻”这个名号，但这似乎是当时约定俗成的称呼。
2000年9月，来自芝加哥Object Mentor公司的Bob大叔用一封电子邮件吹响了下次会议的集合哨。“我想召集一个为期两天的小型会议，时间是2001年1月或2月，地点在芝加哥，目的是让所有轻量级方法论的领袖汇聚一堂。你们都被邀请了。如果你们觉得还有谁该来，请告诉我。”Bob建立了一个Wiki网站，大家开始在上面热烈讨论。很快，Alistair Cockburn通过一封书信加入了讨论，他表达了对“轻”这种提法的不满：“我不介意用‘轻’来描述方法论的轻重程度，但我并不愿意因参加一个轻量级方法学的会议而被看作轻量级的。这听起来有点像一群干瘦、低能且无足轻重的人在试图回忆起某个特定的日子。”关于会议地点的争论最为激烈。芝加哥让人不爽，既冷又无趣；犹他州的雪鸟，虽然也冷，但至少对那些想滑雪的人来说还挺有意思，像Martin Fowler，他在第一天滑雪时就摔了个脚朝天；加勒比的安圭拉岛，暖和又好玩，但路途太远。最后，还是可以滑雪的雪鸟胜出，不过有些人（例如Ron Jeffries）还是希望下次能去个暖和点的地方。
2001年2月11日至13日，在美国犹他州瓦萨奇山雪鸟滑雪胜地，17位从事软件开发或者帮助他人从事软件开发的人相聚一堂，交谈、滑雪、休闲，当然还有聚餐。他们试图找到共识，最终的成果就是Manifesto for Agile Software Development（《敏捷软件开发宣言》）。参会者包括来自极限编程、Scrum、DSDM、自适应软件开发、水晶系列、特性驱动开发、实效编程的代表们，还包括一些希望找到文档驱动、重型软件开发过程的替代品的推动者。如图0-3所示，由全体参会者签署的《敏捷软件开发宣言》成为重要标志，因为这么大一帮人能聚到一起实在不容易。只有英国人Martin Fowler表达了对“敏捷”这个词的担心，他认为多数美国人都不知道“敏捷”这个词如何发音。Alistair Cockburn和很多参会者一样，最初有很大的担忧。“我个人没有期望本次敏捷达人们的聚会能够达成任何实质性共识。”会后，他再次分享了自己的感受。“对我来说，很开心‘宣言’能够最终定稿。而让我感到惊讶的是其他人也同样开心，因此我们的确达成了某种实质性共识。”从此，敏捷方法正式诞生。[5]
[5]摘自Scrum中文网的文章《敏捷宣言诞生记》。
图0-3 《敏捷软件开发宣言》内容（来源：敏捷宣言网站）
百花齐放
2001年，Ken Schwaber和Mike Beedle出版第一本Scrum图书《Scrum敏捷软件开发》。该书系统地介绍了Scrum开发方法，这标志着Scrum方法得到完善。回想2004年，笔者也是一边读这本书，一边带着团队尝试Scrum，可谓无知者无畏。
2001年，Cruise Control作为第一款“持续集成服务器”（continuous integration server）在开源许可协议下发布。它能自动监测源代码仓库，触发构建和测试过程，并把执行结果和测试报告档案发送给开发人员。（注：虽然Jenkins目前更流行，但是Cruise Control代表着持续集成实践的真正落地，在后面内容中会展开介绍。）
2001年，Bill Wake在一篇文章中指出敏捷团队所使用的两种不同喜好的估算——相对估算（relative estimation）和绝对估算（absolute estimation）。
2002年，计划扑克的当前形式在James Grenning的一篇文章中被列出，这正是2001年相对估算方式的落地实践。
2002年，Bill Wake的早期文章提到团队成员对于一些常用术语的理解可能不一致的问题，例如“完成”（Done）。这一概念后来被扩展为“完成的定义”（Definition of Done）。
2003年，Mary和Tom Poppendieck夫妇的著作《精益软件开发》将“敏捷任务板”（Agile task board）描述为“软件看板系统”（software kanban system）。同时，他们提出了精益软件开发的7项原则（消除浪费、内建质量、创建知识、推迟决策、快速交付、对人尊重和整体优化），第一次将精益理念系统地引入软件开发中。
2003年，Bill Wake在一篇文章中介绍了可以用于快速评估用户故事的INVEST（Independent，独立的；Negotiable，可协商的；Valuable，有价值的；Estimatable，可评估的；Small，小的；Testable，可测试的）检查单。该文章还为用户故事分解得到的技术任务改写了SMART的缩写（Specific，具体的；Measurable，可衡量的；Achievable，可实现的；Relevant，相关的；Time-boxed，时间盒的）。（需要注意的是，这里的T与一般的SMART中的T不一样。）
2004年，Kent Beck将“完整团队”（Whole Team）作为之前名为“现场客户”的实践的新名称。这应该是把“现场客户”纳入完整团队来看待了。
2004年，INVEST准则成为Mike Cohn的著作User Stories applied（《用户故事与敏捷方法》）中推荐的技术之一。
2004年，David Aderson的第一个软件看板系统在微软公司XIT软件维护团队中实施。这为后续看板方法的提出奠定了实践基础。
2005年，计划扑克技术在Scrum社区中开始流行，这归功于Mike Cohn的著作Agile Estimating and Planning（《敏捷估算与规划》）。这是制订敏捷计划的技术之一。
2005年，术语“Backlog梳理”（backlog grooming）开始流行。该术语最早的使用记录源自Mike Cohn在“Scrum开发邮件列表”上的观点。几年之后，这个实践才被正式描述。
2005年，Alistair Cockburn和Jim Highsmith领导的小组撰写了项目经理原则的增补版《敏捷项目管理》，向项目经理介绍敏捷开发方法。这本书对于敏捷社区的影响还是很大的，现在被美国项目管理协会（Project Management Institute，PMI）列为官方ACP（敏捷专业人士认证）参考资料之一。
2005年，Jeff Patton在文章“It’s All in How You Slice It”（这完全取决于你如何分割它）中明确表达了“故事地图”（story mapping）的概念，但当时并没有给出这个现在广为流传的名字。
2006年，Esther Derby和Diana Larsen创作的Agile Retrospectives（《敏捷回顾》）填补了敏捷回顾实践的空白。
2007年，敏捷社区发布了看板团队的几份实践报告。这些团队使用了一套称为“看板”（KANBAN）的特别修订方案：没有迭代，没有估算，持续地带着在制品限制的任务板。这些报告包括来自Corbis（David Anderson）和BueTech（Arlo Belshee）的报告。这其实也是对基于迭代的敏捷方法的极大补充，毕竟之前的方法论都是以迭代为主的。KANBAN方式提出这种基于流的工作方式，更加灵活，增量可大可小。对于不好制订计划的敏捷项目，这是一个福音。
2008年，Cem Kaner给出了“探索性测试”（Exploratory Testing）的一个新定义。这反映出这种测试方法在不断完善。
2008年，Agile 2008大会专门设置了一个论坛来讨论“用户体验”（User Experience）的相关实践，例如可用性测试（usability testing）、用户画像（personas）及纸上原型（paper prototyping）。
2008年，Jeff Patton的文章“The New User Story Backlog is a Map”（新的用户故事待办事项是一幅地图）图文并茂地描述了“故事地图”实践。
2008年，虽然最初提到团队开始使用“就绪的定义”（Definition of Ready）的时间是在年初，但第一次正式的说明似乎是从10月开始的，并且该术语很快就被纳入了“官方”的Scrum培训材料。
2009年，我携手许舟平老师，创作了国内第一本小说体敏捷著作《敏捷无敌》。该书以主人公阿捷学习敏捷的艰难历程为主线，展示了一个团队实现敏捷转型的全过程。
持续交付
2009年6月，美国圣何塞，第二届Velocity大会上一次名为“10+ Deploys Per Day: Dev and Ops Cooperation at Flickr”（每天超过10次部署：来自Flick开发和运维人员的协作）的演讲轰动世界，后来几乎所有和DevOps相关的资料都会把这次演讲作为DevOps萌发的标志。这次演讲提出了DevOps的“一个中心，两个基本点”，即以业务敏捷为中心，打造能适应快速发布软件的工具（tools）和文化（culture）。
2009年，持续部署（continuous deployment）实践开始流行，尽管仍有些争议，特别是Timothy Fitz的文章“Continuous Deployment at IMVU”（IMVU的持续部署）。争议是什么不重要，但这篇文章不仅在敏捷领域变得非常重要，在创业圈也很火热，因为IMVU就是写出《精益创业》的Eric的创业项目。
2009年，Don Reinertsen创作的The Principles of Product Development Flow（《产品流式开发的原则》）揭示产品开发流的本质，并提出相匹配的175条原则，讨论了排队论、延迟成本、加权最短作业优先算法等。这本书对于后来很多规模化敏捷方法论都产生了深远影响。
2010年，David J. Anderson创作的KANBAN–Successful Evolutionary Change for Your Technology Business（《看板方法：科技企业渐进变革成功之道》）正式出版。该书的出版代表KANBAN方法作为一个正式敏捷方法论日臻完善。
2010年，《持续交付》的作者Jez Humble参加了第二届DevOpsDays并做了“持续交付”的演讲。从本质上说，《持续交付》中所提到的实践为开发团队如何与运维团队协作提供了最佳实践。如果《持续交付》早两年问世，也许就不会出现DevOps这个术语。然而，随着DevOps理念的传播，DevOps概念的外延越来越广，已经超出了持续交付本身所涵盖的范畴。
2011年，“Backlog梳理”实践升级为Scrum的官方元素，并被纳入The Scrum Guide（《Scrum指南》）。
2011年圣诞节过后的一场大雪，作为当年的初雪，比以往来得要晚一些，几个程序员在麦当劳的豪华包间里做出了一个艰难的决定：mv -f hudson jenkins（将Hudson迁移至Jenkins）。于是，影响整个敏捷界的持续集成工具Jenkins诞生了。这段历史充满了戏剧性，正所谓惹谁千万不要惹怒程序员。Jenkins的前身叫作Hudson，最初是由Sun公司在2004年夏天开发的（就是开发Java的那家公司）。2005年2月，Hudson开源并发布了其第一个版本。当时，Cruise Control在持续集成领域占有率排名第一。但是很快，大约在2007年，Hudson的占有率已经超越Cruise Control。2008年5月，在JavaOne大会上，Hudson获得了开发解决方案类的Duke’s Choice奖项。从此，Hudson成为持续集成的代名词。然而，2009年6月，Oracle公司收购Sun公司后，发生了一件令所有人都惊呆的事情。2010年9月，Oracle公司将Hudson注册为商标。这一行为在2010年11月被Hudson社区的核心开发人员发现，引发了他们的强烈不满。随后，双方进行了不太友好的谈判，不出意料地谈崩了。于是就出现了前面的场景。[6]
[6]摘自CSDN网站的文章《Jenkins简介起源介绍》。
2012年，敏捷大师Gojko Adzi在Impact Mapping（《影响地图》）一书中提出，通过Why→Who→How→What 4个层次的分析法，以结构化的形式显示业务目标（Why）和产品功能（What）之间的联系。这种方法可以帮助团队清晰地看到每个功能对实现业务目标的具体影响路径，确保团队开发的每一个产品功能都是有价值的。
2014年，Jeff Patton创作《用户故事地图》。他在这本书中对用户故事地图实践进行了系统化的阐述，为业界对产品待办事项的梳理方式打开了一扇新的窗口。该方法促进了不同角色之间的协同工作，并有效解决了长期困扰团队“只见树木，不见森林”的问题。
2017年，Janet Gregory和Lisa Crispin重新定义了“敏捷测试”（Agile Testing），这是对该主题首次提出的简洁定义，并且已经被敏捷社区广泛接受和认可。
规模化敏捷
1996年，Scrum of Scrums模式首次在IDX Systems（现为GE Healthcare）项目中实施。当时Jeff Sutherland是该公司的工程部高级副总裁，而Ken Schwaber作为顾问，协助推广Scrum实践。该项目涉及8个业务部门，每个部门都有多个产品线。每条产品线都有自己的Scrum of Scrums。一些产品线甚至有多个层级的Scrum of Scrums。每条产品线都被要求在3个月或更短的时间内推向市场。所有产品线每6个月必须进行一次完全集成、升级和部署，以满足像斯坦福医疗系统等区域性医疗保健供应商的需求。由此可以看出，可以存在多个甚至是并行的Scrum of Scrums，而每日Scrum of Scrums站立会议也可以根据各自的焦点划分为独立的子会议。[7]
[7]摘自CSDN网站的文章《[Scrum模式语言5]Scrum of Scrums》。
2001年，最早提到Scrum of Scrums的出版物是Cutter IT Journal，同时它也出现在2011年的Scrum论文中。
自2005年以来，Craig Larman和Bas Vodde与多个组织合作，将Scrum、精益和敏捷开发扩展到大型产品组。他们将从这项研究中获得的经验和知识转化为一个名为“大规模Scrum”（LeSS）的敏捷框架草案。虽然许多思想领袖已经提出了这样的想法，但Craig和Bas认为，Scrum作为一个框架，具有有效采用敏捷所需的所有要素，而不管规模如何。因此，他们制定了LeSS，力求简洁，没有额外的术语或复杂的描述。
2011年，Dean Leffingwell作为SAFe（Scaled Agile Framework，规模化敏捷框架）的首席方法论专家，正式发布了SAFe的1.0版。在随后的几年内，SAFe融入了敏捷、精益、系统思考、设计思维、精益创业、DevOps等核心理念，形成了四大核心价值观及十大原则，覆盖了团队、项目群、解决方案和投资组合4个层级。特别是敏捷发布火车（Agile Release Train）的概念和项目群增量计划会议（PI Planning）实践，在规模化敏捷方向非常具备代表性。（题外话：其实，Dean与RUP是有非常大的渊源的，因为他创立的RequisitePro公司被Rational公司收购，后来他成为IBM Rational的副总裁。在他推出SAFe时，社区有人戏言“曾经的RUP小子又回来了”，借此批评SAFe过于庞大、不够敏捷，不过这种看法因人而异。）
2012年，还在IBM Rational团队的Scott Ambler与Mark Lines提出了规范敏捷交付（Disciplined Agile Delivery，DAD）过程框架，这也是一个规模化敏捷框架。是的，你没看错，又是出自IBM Rational团队。当时，行业认为采用DAD方法会比传统的RUP方式在企业级软件生产与交付时拥有更高的效率，而且得到了Gartner的特别推荐。
2012年11月，知名敏捷教练Henrik Kniberg发布了一篇博文“Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds”（Spotify的部落、小队、分会和公会式的大规模敏捷）。这篇文章及后面将介绍的Spotify研发过程、工程文化的另外两篇文章一起构成了“Spotify模式三部曲”，一时成为坊间要闻。创造了规模化敏捷的Spotify模式成为很多公司竞相模仿的一种形式。
2015年，Ken Schwaber对外发布Nexus规模化敏捷框架，并认为“规模化的Scrum框架（Nexus）仍然是Scrum”。这句话听起来很熟悉，因为另一个规模化敏捷框架宣称“LeSS也是Scrum”。
2016年，SAFe推出4.0版。该版本从收集到的案例数据中总结出在生产效率、产品上市时间、交付质量、员工满意度等多方面成效显著的方法。
2018年3月，CMMI 2.0明确提出支持敏捷。
2018年，Jeff Sutherland跟Scrum联盟合作，一起创作并发布了Scrum@Scale。它结合了最小可行的管理机构。这是Mozilla和Spotify推广的一种敏捷开发方法。
2019年8月，美国项目管理协会宣布收购DAD，算是在ACP认证之外补全了规模化敏捷。
2019年12月，SAFe推出5.0版，正式提出了业务敏捷的七大能力。其中，双操作系统概念令人眼前一亮，受到众多500强公司的追捧。在国内，SAFe的推广离不开李建昊老师的杰出贡献。他不仅最早创立了中国的SAFe社区，还发起了SAFe四季峰会，并培养了多位SPC（SAFe咨询师）。我也是那会儿成为SPC的。同年，Dean Leffingwell来中国，作为非时空交集的IBM Rational团队的同事，我、许舟平老师、Dean Leffingwell一起合影留念并交换了对敏捷的看法，如图0-4所示。与Dean一起回忆IBM Rational团队的往事和趣闻，我们依然有很多共同的话题。
图0-4 许舟平（左）、Dean Leffingwel（中）、王立杰（右）合影
2020年4月，Jeremiah Lee（Spotify前员工）在自己的博客中发表了一篇颇具争议的文章“Spotify doesn’t Use‘the Spotify Model’and Neither should You”（Spotify自己没有采用Spotify模式，建议大家也不要乱用）。真可谓一石激起千层浪。Lee回忆说，2017年他在斯德哥尔摩总部面试产品管理职位时，招聘人员曾告诫他不要指望Spotify是一个敏捷的“乌托邦”。加入公司后，他亲眼见证了公司的规模在18个月内翻倍至3000人。他认识到，Spotify著名的Squad（小队）模式只是一种理想状态，而且该模式从来没有完整实施过。他还观察到，随着公司领导逐渐转向更传统的管理结构，组织内部出现了混乱。
2021年7月，备受期待的《项目管理知识体系指南》（PMBOK）第七版正式发布。新版本增加了与敏捷相关的内容。据称，在新的PMP考试中，敏捷将会占据一半内容。这可以说得上是一次极大的革新与颠覆，打破了唯项目管理讲项目管理，纳入了许多通用管理学、管理心理学、产品设计理论的知识和理念，例如，新版本中提到了“神奇的数字7”，建议敏捷团队的成员数量最好控制在7±2。
持续敏捷
敏捷的发展简史终于回顾完了。我肯定还遗漏了很多内容。不知道你有没有注意到，许多人为了寻求“敏捷”，一直在坚持不懈地努力，或自己亲身实践，或帮助他人，他们的脚步从未停止。毕竟，“敏捷”只是一个目标，其实，我们所有人都在追求“她”的路上。
Being Agile（持续敏捷）!
现在你明白谁动了你的“敏捷”吗？
其实没有其他人，那个人只能是你自己。
在这个不断变化的世界中，“敏捷”也在不断演变。无数的人正在创造无数种“敏捷”。
或许你不信，接下来我们会给你讲一个叫“敏捷漂流记”的故事，里面有很多有趣的敏捷江湖人物，他们都特别喜欢玩一种叫“漂流瓶”的游戏，每次遇到奇遇，就会用自己的独家心法写出来，放入“漂流瓶”，发布于敏捷江湖，以求扬名立万。
让我们一起去捡起这些漂流瓶吧。
属于你的“敏捷”没准会出现在这些漂流瓶中，也可能在你自己之后的行动中，还可能来自你自己的思考。无论如何，只要你保持开放的心态，享受求知之路的乐趣，一定会找到属于自己的“敏捷”。
王立杰
中国DevOps社区第一届理事会主席