首先看看敏捷最早应于于哪个领域，即软件开发领域，不仅仅有敏捷软件，扩展开来还包括，敏捷项目、敏捷集团、敏捷企业，好像只有沾上敏捷就能把事情做好。敏捷从0.1到1.0走过了慢长的15年发展。但在回顾这个历史你会发现，敏捷对于企业来讲，仅仅是解决开发端质量与效率的平衡。目前看仅仅是DevOps，真正解决了端到端的价值流全局优化。那么首先回顾一下敏捷诞生与敏捷历史。
1.敏捷宣言诞生
2000年9月，来自芝加哥Object Mentor公司的Bob Martin用一封电子邮件吹响了首次敏捷会议的集合哨。“我想召集一个为期2天的小型会议，时间是2001年1月或2月，地点在芝加哥，目的是让所有轻量级方法论的领袖们汇聚一堂。您们都被邀请了。如果您们觉得还有谁该来，请告诉我。”虽着他的召集，
敏捷首次大会于2001年2月11日到13日召开，17位软件开发领域的领军人物聚集在美国犹他州的滑雪胜地雪鸟（Snowbird）雪场。
经过两天的讨论，“敏捷”（Agile）这个词为全体聚会者所接受，用以概括一套全新的软件开发价值观。这套价值观，通过一份简明扼要的《敏捷宣言》，http://agilemanifesto.org/，中文直译为：敏捷软件开发宣言。
敏捷宣言的诞生，宣告诉了长达15年的敏捷开发运动开始了，参会的大师们带着16种敏捷方法，在全球进行推广，包括来自于极限编程、Scrum、DSDM、自适应软件开发、水晶系列、特征驱动开发、实效编程等方法，他们认为找到了一种管理好软件开发，应对于不同敏捷方向的精神力量，并且强调用于代替文档驱动和重型软件开发过程。
2.敏捷管理发展
敏捷自敏捷宣言的诞生到现在17年过去了，自敏捷1.0应用最广泛的是Scrum方法，就在于他解决了开发管理的问题，但从一个企业视角来看，也是仅仅解决了开发端管理的问题。那么下面简要看一下各方向的概述。
SCRUM：全球应用超过70%，SCRUM是一种迭代的增量化过程，用于产品开发或工作管理。它是一种可以集合各种开发实践的经验化过程框架。SCRUM中发布产品的重要性高于一切。该方法由Ken Schwaber和 Jeff Sutherland 提出，旨在寻求充分发挥面向对象和构件技术的开发方法，是对迭代式面向对象方法的改进。
XP（极限编程）的思想源自 Kent Beck和Ward Cunningham在软件项目中的合作经历。XP注重的核心是沟通、简明、反馈和勇气。因为知道计划永远赶不上变化，XP无需开发人员在软件开始初期做 出很多的文档。XP提倡测试先行，为了将以后出现bug的几率降到最低。
Crystal Methods（水晶方法族）：由Alistair Cockburn在20实际90年代末提出。之所以是个系列，是因为他相信不同类型的项目需要不同的方法。虽然水晶系列不如XP那样的产出效率，但会有更多的人能够接受并遵循它。
FDD （Feature-Driven Development，特性驱动开发）：由Peter Coad、Jeff de Luca 、Eric Lefebvre共同开发，是一套针对中小型软件开发项目的开发模式。此外，FDD是一个模型驱动的快速迭代开发过程，它强调的是简化、实用、 易于被开发团队接受，适用于需求经常变动的项目。
ASD（Adaptive Software Development，自适应软件开发）：由Jim Highsmith在1999年正式提出。ASD强调开发方法的适应性（Adaptive），这一思想来源于复杂系统的混沌理论。ASD不象其他方法那样 有很多具体的实践做法，它更侧重为ASD的重要性提供最根本的基础，并从更高的组织和管理层次来阐述开发方法为什么要具备适应性。
DSDM（动态系统开发方法）：是众多敏捷开发方法中的一种，它倡导以业务为核心，快速而有效地进行系统开发。实践证明DSDM是成功的敏捷开发方法之一。在英国，由于其在各种规模的软件组织中的成功，它已成为应用最为广泛的快速应用开发方法。DSDM不但遵循了敏捷方法的原理，而且也适合那些成熟的传统开发方法有坚实基础的软件组织。
轻量型RUP：其实是个过程的框架，它可以包容许多不同类型的过程， Craig Larman 极力主张以敏捷型方式来使用RUP。他的观点是:目前如此众多的努力以推进敏捷型方法，只不过是在接受能被视为RUP 的主流OO开发方法而已。
敏捷1.0之后从传统观点应该是迎来敏捷2.0，但随着各家流派的兴起，以及敏捷阵营的分家，敏捷应来的是多家敏捷方法之应用。
3.敏捷阵营的分家
SCRUM的创始人之一的 Schwaber 被近离开了 Scrum 联盟（以下简称 SA），而且还是被董事会/理事会赶走的。下图为Schwaber 进行的说明。
My goal of strengthening Scrum and improving the profession was in clear conflict with the community’s goals of maximizing revenues and incomes. This came to a head in August 2009 when the Scrum Alliance board of directors unanimously asked for my resignation. The board members saw my mission as detrimental to their mission of supporting the CST franchise.
Tom Mellor, the new chairman of the board, sent out an email announcing my resignation. After that, the board terminated the programs described above. They cancelled, re-announced, and finally rolled out a basic assessment that failed to provide any meaningful measure of understanding. They terminated the ScrumAlliance’s commitments to our partners, Microsoft and Accentient, in developing courses for Scrum developers. They have since introduced a weak Certified Scrum Developer program that is designed to protect the income of the existing CSTs.
当软件开发圈都在说：“你今天敏捷了吗？”，那么基本敏捷也就走上了敏捷1.0的尽头。
4.基于敏捷百花齐放的管理方法
敏捷宣言过后是否就没有创新与发展了吗？世界还在不断地进行着演进，从传统的软件开发（敏捷方法）发展到开发运营一体化（DevOps）有很多个基于敏捷的方法在推广与使用着。随着业内敏捷百花齐放，各方法都在不断发展，业内可以看到的是两条路径，第一条是敏捷向规模化进行发展，即Spotify、Less、Nexus、SOS、SAFe等方法。第二条即基于DevOps的方法扩展，解决企业全流程全局优化问题。
多数方法都是基于开发的敏捷规模化扩展，未能实现企业级的全局优化（Spotify、SAFe、Scrum Of Scrum、Scaled Professional Scrum - Nexus、Disciplined Agile Delivery、LeSS(Large Scale Scrum）。
DevOps的特点在于企业全局通过引入精益、敏捷、持续交付实现了企业全局的管理优化工作，并且以价值流为驱动，实现了业务价值交付。
DevOps：由Patrick Debois发起，IT咨询师，DevOps的目标就是把Development和Operations整合在一起，提升全局优化效能，因为Dev和Ops中间存在工作墙，需要把开发（Dev）和Ops(运维)整合起来。
不同的阶段patrick debois提出了不同的想法。DevOps1.0的核心是为了解决开发与运维一同玩耍，但到了DevOps2.0,要解决端到端的价值流快速交付 。最新Devops2.0定义为：
DevOps是一个软件工程实践。通过开发、质量、IT运营和信息安全人员的协作，朝着一个共同的目标努力，使技术价值流通过计划工作快速投产用于满足业务和组织的成功，实现每天多次部署、达到世界级的稳定性、可靠性、可用性和安全性。【DevOps Handbook】2017年10月北京老李最新整理
附：https://www.douban.com/note/643251358/ DevOps定义编年史：通过DevOps定义看DevOps发展
5.DevOps全局的优化的体现
全局优化是指从业务到IT开发、IT测试、IT运营再回到最终用户的价值流的全生命周期的全局优化，如下图所示：
DevOps2.0是全局IT管理优化
全局IT管理优化，融合了IT服务管理、敏捷管理、精益管理等核心方法，通过持续交付自动化的方法实现了效率、质量、风险、成本等管理要求的平衡。
网友评论