DevOps VS 敏捷的区别是什么？

当我们面对敏捷和 DevOps 的时候，总会不可避免的思考下面这些问题：

• 敏捷是什么？DevOps 是什么？两者有什么区别？

• 持续集成不是 XP 里面的么，怎么 DevOps 也有持续集成？

• 我们团队之前在做敏捷转型，现在又开始 DevOps 转型，这两者有什么区别？

其实这些问题并没必要太过纠结，因为敏捷和 DevOps 两者都在不断演进，两者也的确越来越像。

这个话题注定讨论不清，也注定会有不同的意见。本文也仅从方法论和实践的角度，为开发者简单论述敏捷与 DevOps。希望每位读者都会从本文中得到自己的理解与启发 ，帮助大家在敏捷与 DevOps 这两条路上走的更远。

先说本文的观点：

▪ 敏捷与 DevOps 初衷、目的是为了解决问题，而不是为了树碑立牌，更不是为了占领地盘。

▪ 两者并非泾渭分明，也没有一条线能够划出来，说哪边是敏捷，哪边是 DevOps。

▪ 讨论敏捷与 DevOps，目的是为了了解两者之间的内在联系，而不是为了划清界限。

▪ 经常被讨论的，是狭义的敏捷与 DevOps 概念，而广义的敏捷与 DevOps，已经趋同。

▪ 两者都是试图去解决相同，或相近的问题，只是还没有能一招解决所有问题的办法出现。

接下来， 让我们从狭义的角度看二者的区别。

传统的敏捷是为了解决业务与开发之间的鸿沟。通过敏捷宣言中强调的个体和互动、可工作的软件、客户合作、响应变化，以及 12 条原则中的尽早的以及连续的高价值交付、自组织团队、小批量交付、团队节奏、可改善可持续的流程、保持沟通等，以及包括 Scrum、Kanban、XP 在内的众多管理和工程实践，来实现开发与业务之间的频繁沟通，快速响应变化。

而 DevOps 的出现，是为了解决开发与运维之间的鸿沟。前端的敏捷的确是快了，却发现因为 Dev 与 Ops 之间的隔阂，无法真正的将价值持续的交付给客户。

开发侧很快，运维侧太稳，这个就是我们常说的开发与运维之间固有的、根因的冲突，即下图中的混乱之墙。开发（尤其是“敏捷”后），求的是快速响应变化；运维，求的是稳定、安全和可靠的服务。更重要的，两者的 KPI 度量指标，绩效考核激励机制不同，决定了如果为达成各自的局部目标，势必存在无法调和的根因冲突。

DevOps 的出现，就是为了打破开发与运维之间的部门墙，从这点上来说，“DevOps 是敏捷在运维侧的延伸”这一说法也不无道理。只是，敏捷与 DevOps，都已经不再是原来的那个敏捷和 DevOps 了；世界变化太快，问题域发生了变化，解决方案域自然也要随之变化。

点击放大

敏捷的好处是，有一个敏捷宣言，宣告其诞生。敏捷的缺点，也许也是因为有敏捷宣言。敏捷宣言并不应该被拿来约束和限制敏捷的范围，敏捷宣言也说拥抱变化，宣言诞生于 2001 年，时至今日，也会与时俱进，只是后来再没有这样的一个标志性的事件来做声明。

DevOps 的不好之处，是没有一个明确的定义。DevOps 的好处，却也正是因为没有一个明确的定义做限制，所以拿来主义，一切好的东西，都可以为我所用。

DevOps 是个筐，什么都可以往里装，敏捷又何尝不是呢？

通常人们对 DevOps 的理解有两方面，即 D2O 和 E2E。D2O，Dev to Ops，即经典、狭义的 DevOps 概念，解决的是 Dev 到 Ops 的鸿沟。E2E，End to End，即端到端、广义的 DevOps，是以精益和敏捷为核心的，解决从业务到开发到运维，进而到客户的完整闭环。DevOps 的 6C 概念，即 Continuous Planning、Continuous Integration、Continuous Testing、Continuous Deploy、Continuous Release、Continuous Feedback，也是端到端广义的 DevOps。

维基百科中总结到，DevOps 的出现，有四个关键驱动力：

• 互联网冲击要求业务的敏捷

• 虚拟化和云计算基础设施日益普遍

• 数据中心自动化技术

• 敏捷开发的普及

从种种概念可以看出，业务敏捷、开发敏捷、运维侧自动化、以及云计算等技术的普及，几乎打穿了从业务到开发到运维（包括测试），所以虽然字面上是 Dev 到 Ops，事实上，已经是 BizDevTestOpsSec 了，即从狭义的 D2O，前后延伸到 E2E，端到端广义的 DevOps 了。

多位 DevOps 大师曾基于多年 DevOps 现状报告，汇聚出来了一个 DevOps 能力成长模型。在 DevOps 能力模型中，DevOps 的最终的目的是组织效能，软件交付和运维效能是敏捷与 DevOps 共同的目标。

持续交付是狭义 DevOps 的核心理念，横跨了架构、开发、测试、运维等角色。持续交付的核心开发实践，也涵盖了架构管理、版本管理、分支策略、测试自动化、部署发布、运维监控、信息安全、团队授权、数据库管理等多个维度，其中不乏我们常说的传统的敏捷相关实践，尤其是下图中 XP 极限编程的很多实践，半数以上在 DevOps 里都能找到。

点击放大

能力成长模型，除了持续交付，还包括精益领导力、精益产品开发、精益管理、组织文化与学习氛围。DevOps 已远远不是 CI/CD 那么简单，CALMS 原则也横跨了文化、管理、精益与技术。

敏捷宣言的十二条原则、SAFe 的九大原则、以及 DevOps 的 CALMS 原则，也是彼此相互融合。SAFe 有借鉴 DevOps 的理念和方法，DevOps 又采纳敏捷的思想和实践，大家又都以精益为思想核心。那么谁包含谁，谁比谁大，彼此的界限在哪里呢？

由此可见，方法也好，实践也好，其价值应该由客户价值来体现。对客户而言，需要解决的问题，是端到端的，是全局而不是局部优化。

所以，是什么，不重要。能解决什么，要解决什么问题，很重要。

DevOps 是集大成者，是各种好的原则和实践的融合，敏捷又何尝不是如此。2001 年的 17 位雪鸟大师，各自在践行着不同的敏捷框架和实践。敏捷宣言和原则，原本就是一次融合。2003 年 Mary Poppendieck 和 Tom Poppendieck 的精益软件开发方法，即便是已经有敏捷宣言的前提下，也一样纳入敏捷开发的范畴。敏捷也是在不断前行，DevOps 与敏捷殊途同归，是同一问题的不同分支，最终汇集到同一个目标。

一个好的方法论，应该是与时俱进，兼容并蓄的；应该是开放的，演进的而不是固化的。

方法论如此，学习和实践方法论的人，更应该如此，以一颗开放的心态，接纳一切合理的存在。

本文参考资料：

• 《DevOps explained》 Jérôme Kehrli

• 《Accelerate》