本文作者：何文强 — CODING 高级解决方案架构师 具有一线互联网、物联网独角兽、全国股份制银行、新型智慧交通等跨行业从业经历，历任 Java 开发高级工程师、DevOps 技术专家、高级研发经理等职，对微服务、敏捷、DevOps、容器技术有深刻的理解和丰富的实践。
敏捷软件开发背景
新旧生产力与生产关系
主流软件开发方法：瀑布软件开发（旧生产关系）
瀑布式开发的另一个主要问题是每个阶段都是串行的，当前阶段正在进行软件活动时，向下的阶段全部处于等待和阻塞状态，严重浪费团队资源，降低团队效率。
市场商业：互联网时代 Web1.0（生产力方向）
1990s，WWW 开启商业化浪潮，互联网真正进入大众视野，以浏览器为核心的 web 应用开始大规模增长，技术与商业、社会和政治更大范围的联动，互联网应用的边界在不断的扩大，面对急剧增长的 web 应用，当前软件工程和软件开发模式受到了巨大的冲击，需要新的软件开发方法（生产关系）来满足新的生产力要求。
超大规模集成电路走向成熟（生产力）
1985s 后，超大规模集成电路得到迅猛发展，算力得到了极大的发展，为应用规模化发展提供了有力的技术支持。
新软件开发方法：敏捷软件开发（新生产关系）
生产力得到快速发展，生产力方向发生改变，旧的生产关系无法与生产力和生产力方向的矛盾日益突出，且不可调和。需要新的生产关系来匹配生产力和生产力方向。敏捷软件开发就是新的生产关系。
乌卡（VUCA）时代
- 易变性：当今世界的变化越来越多，越来越快，越来越不可预测。
- 不确定性：历史上的任何一个时代所带来的经验已经无法为当今世界的所有变化提供参照。
- 复杂性：事物间的交融越来越密切，各种问题的产生原因，其带来的影响和反应会受到更多不同因素的相互牵制。
- 模糊性：清晰地为定义或划定边界都变得困难。非黑即白的判断标准也似乎越来越不适用。
瀑布软件开发问题
- 软件开发周期长，交付速度慢，无法及时响应外部变化；
- 阶段串行化，存在大量依赖等待，资源利用率低；
- 需求变更困难，流程固化严重；
- 沟通协作成本高，因分工产生的部门墙严重阻碍大大增加了沟通协作成本。
敏捷软件开发发展历程
萌芽期（20 世纪 90 年代）
20 世纪 90 年代，随着互联网的兴起，瀑布及其延伸的其他模型（迭代、增量、螺旋、V模型等）不能够满足软件开发和交付的需要，一些优秀的开发理念和管理实践被倡导和推崇。
在 1990~1994 期间，时间盒、重构、站立会议、持续集成、Scrum（1993 年定义，1996 形成框架）、每日站会被相继提出并得到采纳和应用；随着 web1.0 的快速发展，更多的优秀的方法实践被提出完善，例如在 1995~1999 期间，Sprint、结对编程、Scrum、FDD（函数驱动开发）、冒烟测试、Junit、增量、XP（极限编程）等方法实践；随着 2001 年《敏捷宣言》的诞生，对 90 年代的众多优秀的理论实践进行了理论和原则上的大一统，使得敏捷成为一种完全不同于瀑布的新的软件开发方法。敏捷软件开发开始快速发展，越来越多的优秀软件实践及框架被提出并纳入敏捷软件开发范畴。
引入期（2000~2004）
在 2000~2004 期间，燃尽图、精益编程（这是从精益制造借鉴而来的，主要目的是消除浪费，目前已演进为精益产品开发，后续有详细介绍）、SAFe（规模化敏捷开发框架）、Done 的定义、累积流图 、TDD（测试驱动开发）、看板（从精益制造中借鉴而来）、DDD（领域驱动设计）、用户故事等被相继提出和推广。
成长期（2005~2009）
在 2005~2009 期间，LeSS（大型 Scrum）、故事地图、BDD（行为驱动开发）、持续部署、探索性测试、backlog、WIP（限制在制品）也被提出和发展。这些优秀的理念和实践主要以敏捷框架的形式进行系统的管理和发展，例如 Scrum 框架、XP 框架；LeSS 框架、SAFe 框架等。
成熟期（2010~）
随着移动互联网的出现、发展和普及，新一轮信息产业周期的调整与发展，IT 交付方式由企业内部资源交付转变为外部用户价值交付；软件交付周期有每年/每季度交付转变为每月/每周甚至每天交付；软件开发团队由几个人变成数十人甚至数百人。面对价值交付方式由内转外、交付周期缩短、研发团队规模膨胀等困难与挑战，敏捷软件开发方法的特点和优势得到彰显和放大，迅速成为互联网企业首选的软件开发方法。
敏捷宣言
敏捷宣言的由来：2001 年 2 月 11 日至 13 日，在犹他州瓦萨奇山雪鸟滑雪胜地的小屋里，17 个人聚在一起聊天、滑雪、放松，并试图找到共同点——当然还有吃饭。出现的是敏捷“软件开发”宣言。来自极限编程、Scrum、DSDM（动态系统开发方法）、自适应软件开发、Crystal（水晶方法）、功能驱动开发、实用编程等的代表对文档驱动的重量级软件开发流程的替代方案的需求表示同情。
敏捷软件开发宣言定义了 4 个价值观和 12 个原则。
价值观
敏捷实践者一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此建立如下价值观：
敏捷价值观强调：尽管右项有其价值，但是我们更重视左项价值。
#1 个体和互动高于流程和工具
尽管在项目中流程和工具很重要，但是我们更应该将重点放在个体和交互上。这是因为项目是由人来执行，而不是工具。人是获得成功的关键因素，敏捷团队特点强调团队成员的能力，鼓励发挥和积极调动人的主观能动性。
在敏捷软件开发中，如果团队中没有优秀的成员，那么再好流程和工具也无法让项目成功，但是糟糕的流程和工具却可以让优秀人才流失和项目失败；优秀的团队成员如果没有良好的沟通与协作，再优秀的成员的也无法阻止项目失败。因此，我们仍然需要适当的流程和工具，但是我们更强调人的能力以及人的沟通与协作。
#2 可工作的软件高于详尽的文档
尽管在项目中，文档作为一种重要软件开发过程资产，但是文档不是项目成功的关键，最终交付的可工作的软件才是。过分强调文档的重要性和详尽性不仅会花费团队大量的时间和经历，而且也不能保障和促进项目的成功。
敏捷软件开发更加强调价值交付和结果导向，可工作的软件相比于详尽的文档，更能代表项目真实价值和最终成果的量化，也更能体现软件团队的工作价值。
#3 客户合作高于合同谈判
尽管合同谈判在大型软件分包和协同中具有重要作用，但是这种甲乙式和雇佣式的合同谈判无法帮助开发人员理解客户需求，只有通过和客户更多的交流合作才能帮助开发人员或者产品经理理解客户的需求，开发出满足客户真实需求的软件。
#4 响应变化高于遵循计划
尽管在项目中遵循既定的计划很重要，但是在实际的软件开发中，不确定性客观的存在，导致计划经常变化，项目很难按既定的方案执行。因此，拥抱和响应变化能够让团队更加灵活弹性的完成软件交付，减少应不确定带来的软件风险，降低项目失败率。
十二原则
#1 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意
客户满意和有价值的软件是项目成功的主要表现。要确保我们开发的软件产品能够给客户带来真正的价值，需要以客户为中心，以价值为导向，并尽早的连续小批量交付让客户能够及时感知和反馈，让客户宾至如归。
#2 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化
变化是真实客观存在的，无论在开发的哪个阶段，我们都需要正确的看待和接受变化。对于变化，我们不仅需要欣然接受和面对，还需要能够掌控变化，让客户在变化的市场或商业中获得持续的竞争力。
#3 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期
对于软件交付，我们更强调软件的可工作性，只有可工作的软件才是有价值的，并且更加强调交付的周期尽可能的短，越短的交付周期越有利于对快速变化的市场商业需求做出及时准确的响应，越短的交付周期越有利于提升企业在不确定中环境中的适应性和韧性。
#4 业务人员和开发人员必须相互合作，项目中的每一天都不例外
想要高效的交付客户满意的软件，业务和开发必须进行频繁亲密的合作。业务和开发的真诚合作不仅有利于开发出正确的产品和服务，进而提升客户的满意度；而且持续频繁真诚的沟通与协作有利于提升团队的协作效率，减少因沟通不充分、理解不一致带来的浪费。
#5 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标
软件开发属于知识类工作，需要知识工作者来完成。知识工作者具有巨大的个人潜力和创造力，充分调动知识工作者的主观能动性和创造力。围绕知识工作者创建项目，并给予他们最大的帮助、信任与自由，有助于目标的快速达成和项目的最大成功。
#6 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈
在软件开发协作中，面对面沟通可以有效降低信息传递的失真率，提升沟通的有效性，保障信息的一致性。相对于邮件、电话等沟通方式，面对面沟通是效率最高效果最好的沟通方式，如果条件允许，我们应该尽可能的采用面对面沟通的方式进行沟通协作以最大化效率和效果。
#7 可工作的软件是进度的首要度量标准
在敏捷软件开发中，我们更加强调价值交付和结果导向，可工作的软件是软件交付最重要的价值。因此，需要将最大价值的事情（可工作的软件）作为进度度量的首要标准。
#8 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续
可持续开发可以消除高负荷工作并保持可持续的速度工作，以稳定的节奏和固定的周期进行产品开发和交付，所有团队成员保持步调一致。
#9 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强
随着软件开发的持续进行，技术债也随之积累，技术债会使软件开发速度变慢，系统可靠性降低。在敏捷开发中对架构设计和技术有着执着的追求和设计，并持续不断的进行技术重构和债务解决，增强团队的技术敏捷力。
#10 以简洁为本，它是极力减少不必要工作量的艺术
在软件开发中，在满足基本流程的基础上，尽可能的减少流程、工具的复杂度；在软件功能开发中，也需要尽可能的减少一些不需要的功能特性的开发。尽可能消除开发过程和软件需求上的一些不必要的浪费。
#11 最好的架构、需求和设计出自自组织团队
架构、需求和设计会随着团队一起工作而慢慢浮现，团队亲历其中，对架构、需求、设计理解最充分、真实、深刻（听到炮火的士兵更加了解前方战线的真实情况）。赋予团队能力和权限，让团队能够自行的组织和管理，并由他们自行设计架构、需求和设计，这些架构、需求和设计通常是最好的。
#12 团队定期地反思如何能提高成效，并依此调整自身的举止表现
花时间反思和从经验中学习能够减少重复犯错的概率，对经验能力进行更好的积累和沉淀，有助于持续提升团队能力和构建卓越的工程师文化。
敏捷软件开发主流框架
敏捷软件开发方法是一种方法和思想，不是具体框架，凡是符合敏捷宣言价值观和敏捷宣言原则的框架均可成为敏捷软件框架。目前主流的敏捷框架包括Scrum、XP（极限编程）、SAFe（规模化敏捷框架）、LeSS（大规模 Scrum）、DSDM（动态系统开发方法）、Crystal（水晶方法）等。“敏捷软件开发方法”与“敏捷开发框架”的关系可以简单理解为 JAVA 中“接口”和“类”的关系。笔者将对 Scrum、XP、SAFe 框架做逐一介绍。
