敏捷，DevOps，傻傻不分清楚

            前言             

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

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

我们之前在做敏捷转型，现在又开始DevOps转型，到底啥情况？

总觉得与其去纠缠一个定义，不如踏踏实实做点儿事情。

没必要太纠结，因为两者都在演进，两者也越来越像，否则不会有这些疑问。

原本没想写这个话题，客户问起也只是简单说明。

只是最近不断有人问起，也看到有一些误导性的言论，所以也许还是有必要说说自己的观点。

这个话题注定讨论不清，也注定会有不同的意见；

所有文字仅代表我一家之言，没必要扣什么帽子；

我本人是先做敏捷后做DevOps的，这是我的知识背景；

欢迎讨论，如果初衷是好的话，道理越辩越明；

恕不奉陪，如果是以混淆视听为目的论战。

先说我的观点：

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

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

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

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

• 两者都是试图去解决相同，或相近的问题，只是革命尚未成功，同志还需一起努力。

• 傻傻不分清楚，是不想分太清，没必要分清楚，难得糊涂。

狭义的敏捷与DevOps，也许是你想听到的两者区别。

强调一下，这里说的，注意是狭义而不是狭隘；有狭义就有广义，如果你坚持固守狭义的概念，会不会有点儿狭隘了呢？

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

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

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

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

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

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

DevOps是个筐，什么都可以往里装，敏捷又何尝不是呢？（这里全是褒义）

我是2012年在IBM接触到DevOps的概念的，IBM对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能力成长模型，是Nicole Forsgren博士，Jez Humble以及Gene Kim三位大师，基于多年DevOps现状报告的基础上，汇聚出来的能力模型。（上图是刘征老师基于Accelerate一书，以及多年DevOps现状报告的基础上，二次创新，汇总出来的模型）

从能力模型上来看，所有的连线汇聚点，也就是最终的目的，是组织效能。软件交付和运维效能，是敏捷与DevOps共同的目标。

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

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

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

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

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

DevOps的核心，是精益与敏捷的思想和原则，所以你说到底是敏捷包含了DevOps呢，还是DevOps包含了敏捷呢？我觉得没必要纠缠，两者原本已经无法区分，也无需区分。

敏捷也好，DevOps也罢，能抓住耗子就是好猫。具体应该叫什么，你为什么要那么纠结？

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

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

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

参考资料：

• ”http://www.slideshare.net/JrmeKehrli/devops-explained-72091158“

• “DevOps能力成长模型”

• IBM DevOps资料
  

• 维基百科

姚冬 资深DevOps与精益/敏捷专家，软件工程专家；中国DevOpsDays社区核心组织者之一；Exin DevOps Professional认证讲师；凤凰沙盘认证讲师；SAFe SPC规模化敏捷咨询师；认证Scrum Master, SAFe Agilist；曾任IBM DevOps产品线大中华区技术总监，金融行业Technical Leader；现任华为云软件开发云首席技术布道师。