共计 2694 个字符，预计需要花费 7 分钟才能阅读完成。
原文链接：https://support.huaweicloud.com/reference-devcloud/devcloud_r…
当咱们面对麻利和 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》
本文更新于 2022 年，如有谬误欢送斧正
