DevOps vs 敏捷，你的团队把他们弄混了吗？
近年来，DevOps和敏捷的概念愈来愈广为人知，但他们之间的关系又让人困惑。这里有部分原因是由于很多概念吹鼓手为了赶时髦凑热闹而把这两个词当做流行词混用，没有深究其含义，淡化模糊了他们本身的含义。但本质上，是因为DevOps和敏捷都是原则层面的概念，并不针对特定实践，所以也让众人有了太多可以自我理解的空间。
比如一个常见的理解思路：DevOps被定义为文化、流程和工具的交点，专注于打破开发与运维之间的孤岛，并提高软件交付的速度和质量。而敏捷宣言则直接提到了“早期和持续交付有价值的软件”以及“频繁交付工作软件”的目标，从旁观者的角度来看，很容易得出这样一个疑惑：“DevOps和敏捷都关注速度、质量，以及软件开发中的协作，那么他们有什么区别呢？”
答案在于敏捷和DevOps强调的领域。敏捷非常关注客户协作和开发人员/客户反馈循环，而DevOps则强调开发（Dev）与运维（Ops）之间的协作。敏捷旨在将灵活性纳入软件规划和开发中（“响应变化高于遵循计划”），DevOps强调自动化和简化开发流程。
要理解敏捷与DevOps间的差异并各自充分利用它们，就必须了解这两个运动背后的原理，与这些原理相关的普遍实践以及它们意图解决的问题。
敏捷的起源和原则
敏捷宣言的起源在软件开发领域众所周知：2001年2月11日至2月13日，十七名软件专家（称为“敏捷联盟”）在美国犹他州Snowbird滑雪胜地的The Lodge举行了会议。但敏捷并不是在那时那地，像变魔术一样被神奇地创造出来的。这是一场酝酿了多年的运动。
在20世纪90年代末和21世纪初，由于对瀑布等缓慢而繁重的开发方法的缺点感到失望，当时的思想领袖包括ThoughtWorks首席科学家Martin Fowler，极限编程（XP）联合创始人Ron Jefferies和前理论物理学家Mike Beedle试图为软件开发创建一种更轻量级的迭代方法。痛点很简单：传统的软件开发过于僵化，无法使软件团队最大化他们为客户提供的价值。
为了解决该问题，这些思想领袖寻求了另一种替代方法，使快速反馈循环和灵活性成为可能。对瀑布的轻巧替代的渴望导致了里程碑式的时刻，对瀑布的轻量级替代品的渴望导致了里程碑式的时刻，如Jeff Sutherland和Ken Schwaber在1995年“OOPSLA业务对象设计和实现”研讨会的论文中把Scrum方法规范化，以及极限编程的出现。随着这场运动的持续升温，最终赢来了Snowbird的那场聚会。
聚会结束时，“敏捷联盟”拟定了一个宣言作为敏捷软件开发的指南，这个宣言的背后是一个各因素的优先级列表：
客户合作与满意
人优先于流程
频繁的交付
适应变化的能力
面对面交流
简单
反馈闭环
小型自组织团队
按照敏捷创立的宗旨，敏捷会实现以下的功用：
加快客户与软件开发团队之间的反馈循环
赋予软件开发团队快速适应变化的能力
这些原则通常以诸如站立会议，基于用户故事的Sprint以及创建角色（例如产品负责人和Scrum Master）之类的实践形式体现出来。但是，重要的是要了解实践是达到目的的一种手段。他们本身并不敏捷。对于敏捷团队来说，今天的做法现在可能明天就要改良，来确保团队持续的迭代，用以客户为中心，以人为本的方法进行敏捷开发。
DevOps的起源和原则
2007年，正在参与比利时一个大型政府数据中心迁移工作的Patrick DeBois发现：创建软件的敏捷开发团队与部署软件并维护生产服务器的运维团队之间存在着很深的隔阂，他对此感到非常头疼，并开始为此思考对策。
之后，在2008年敏捷会议上，Andrew Shafer和Patrick DeBois开会并成立了敏捷系统管理小组：用来改善开发与运维间的合作。
2009年，来自Flickr的John Allspaw和Paul Hammond以一场名为“10+ Deploys Per Day: Dev and Ops Cooperation at Flickr ”的演讲展示了如何打破开发与运维间的隔阂，使Flickr每天能够部署10次，从而大大提高了这一概念的可信度。而远在比利时的Patrick DeBois无法参加Allspaw和Hammond的演讲，但他受此鼓舞，创建了自己的会议：DevOpsDays。考虑到Twitter上字数限制，#DevOpsDays 的主题标签被缩短为#DevOps。
2009年，John Allspaw和Paul Hammond演讲现场
随着这种方法论对于开发与运维间合作的改善作用被越来越多的案例验证，DevOps愈加受到欢迎，成为当今与软件交付相关的最重要术语之一。
现在我们知道，DevOps创立的目的就是用于解决开发与运维间的隔阂，那什么DevOps呢？或者说，它的底层原则是什么？
一般来说，“三步工作法”是被广为认可的DevOps核心原则（在中也可以看到）：
1.系统思考
DevOps强调将重心放在整个系统上，并制定“共同责任”方法。这意味着开发团队需要开始关注性能，而运维团队也要关注代码的开发和测试方式。整个团队要关注整个系统。
2.反馈闭环
从右（事物的操作方面）到左（事物的开发方面）反馈循环可实现持续改进。
3.学习与实验的文化
鼓励试错和从失败中学习有助于推动改进并产出更具弹性的系统。
“三步工作法”简明扼要地概括了DevOps的基本原理。此外，DevOps还有一些通用的实践，包括：
（几乎）一切的自动化，即持续集成，持续交付，持续部署/交付和持续监控
配置管理
基础设施即代码
采用云原生技术和DevOps工具
通过打破开发人员和运营人员之间的隔阂，DevOps能够帮助团队获得极大的效率提升。成功引入DevOps文化并利用正确工具的团队可以更快地交付代码，缩短反馈闭环并提高整体软件质量。BCG的一项分析表明，DevOps可以将成本降低15％至25％，将调配和部署的时间减少多达90％，并将质量提高50％至70％。
DevOps vs 敏捷
在我们有了一些讨论的背景和共识后，让我们试着回答“DevOps与敏捷开发方法有何不同？”。总体而言，我们可以看到，敏捷是一种软件开发方法，可以优化客户与软件开发团队之间的反馈闭环；而DevOps是一种文化、流程和工具的组合，用来打破开发团队和运维团队之间的隔阂。这是他们在宗旨和目标上的不同，另外，在细节和实践上，他们也是不同的：
敏捷是一种项目管理方法，而DevOps则专注于流程的优化；
敏捷专注于需求和功能开发的灵活性，而DevOps则强调不断测试和部署正在开发的软件；
敏捷通常与Scrum，DaD，LeSS和SAFe等框架相关联，DevOps通常不与任何特定框架相关联，甚至可以通过Waterfall实现；
敏捷强调人员而不是流程，而DevOps则重点关注流程优化和自动化；
敏捷严格专注于软件开发和测试，DevOps则将IT运维包含其中
最后一点可能是最突出的。正如Atlassian的Ian Buchanan指出的那样：“DevOps在应用程序团队之外的敏捷应用。”两种文化都强调速度和质量。两者都具有足够的延展性，可以集成到各种业务模型和行业中。两者都不排斥对方，这引出了一个重要的观点：两种方法可以只选其一，但是最好是两个都有，因为DevOps和敏捷可以很好地互补。
敏捷使团队能够以灵活、快速和高质量的方式向客户交付业务价值；DevOps从技术角度提供了底层的运营文化和基础设施。从这个角度看，互补关系变得直观。如果由于开发环境和生产环境之间的差异而导致底层基础设施崩溃，那么再牛逼的产品负责人和再流畅的sprint也将毫无意义；反之亦然：如果你不专注于为客户带来价值，那么一个维护良好且自动化的流水线就也没有多大用处。
结论：DevOps和敏捷是不同的，但却是互补的
DevOps和敏捷的概念存在一些混乱的原因很简单：许多基本概念重叠——协作，速度，反馈闭环，甚至术语“连续交付”都与两者关联。不过，当你对这两种文化有更深入的了解时，你会了解到它们何为以及为何有所不同。更重要的是，它们在实践中是可以相互补充，获得1+1>2的效果的。
因此，最好的做法是：
点个“在看”表示已看完全文吧~