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》