敏捷与 DevOps：是敌是友？

DevOps 是敏捷应用于软件团队的成果。但真正的问题是，在一场比赛中，哪一方会获胜？

在角斗场的一头，咱们有通过认证的敏捷教练，他的朋友们都知道他是一个极限程序员，而在他的孩子们眼里则是不那么安全的父亲。他就是＂敏捷＂！

而在另外一头，咱们有一个精益文化机器，他不断地将他的架构以代码形式传递出来，他的左臂就是开发，他的右臂是就运维。他就是＂DevOps＂ !

尽管我已经把双方都视为已经被炒做得天花乱坠的概念，但关于敏捷和 DevOps 的声音让它们听起来像是很是不一样的想法。更复杂的是，即便两个概念有本身的行话和口号，但它们的定义依然含糊不清。做为历史更悠久的一方，敏捷可能不那么模糊，但人们对 DevOps 的众多定义感到迷茫无助是很常见的。缺少精准的定义致使了他们之间产生一些共同关联点。

许多人认为敏捷意味着 Scrum，DevOps 意味着持续交付。这种过分简化在敏捷和 DevOps 之间形成了没必要要的紧张局势，因此当你发现他们是最佳拍档时，你会感到惊讶无比！

不能否认，DevOps 与敏捷之间的历史是有千丝万缕的联系。当 Patrick DuBois 和 Andrew Clay Schafer 试图在 Agile 2008 大会上讨论“敏捷架构”时，与 DevOps 的联系就诞生了。尽管 Patrick 后来才创造了“DevOps”这个词，但在 DevOps 的发展历程中仍然用敏捷大会来记念这一块儿点。当咱们深刻到 Scrum 和持续交付的表面之下时，咱们深刻研究一下历史，就会发现敏捷和 DevOps 之间的实际联系。

「CODING 企业版」做为企业级软件研发管理系统，助力团队敏捷开发转型升级。

敏捷不只仅是 Scrum

在一些团队中，Scrum 是两种协做之间的区别，一种是持续使人沮丧的斗争，另外一种富有成效、回报颇丰。在另外一些状况下，Scrum 以客观和专一取代了办公室政治和过分承诺，它也能够视为信条教理。当因为业务或工做自己的约束要寻求变化或者作出改变时，敏捷团队将祭出 Scrum 基本原则的利剑，检查他们的实践行为，以逐渐变得更加高效。当 Scrum 应用于软件开发的环境以外时，这一点尤其重要。

预先对计划之外的工做作规划

在 DevOps 社区中，那些有敏捷经验的人赞成 Scrum 对于跟踪计划中的工做是有用的。一些运维中的工做能够被计划：好比发布一个大的系统变动，在数据中心之间迁移，或者执行系统升级。可是大部分的运维工做都是没法计划的：性能达到峰值上线、系统中断和安全问题。这些事件须要当即作出反应，没有时间等待其加入待办事项列表再按优先级排列，也不可能在下一个冲刺周期中再列入计划。出于这个缘由，许多已经开始拥抱 DevOps 思想的团队，从 Scrum 跳跃到了“看板”。这有助于他们跟踪这两种工做，并帮助他们理解之间的相互做用。另外一种方法是采用一种混合方法，一般称为 Scrumban 或 Kanplan（带有计划的看板）。

在许多方面，Scrum 被普遍采用的关键点多是它没有预先设定任何技术实践。Scrum 的轻量级管理实践经常对团队产生很大的影响。在过去，多个管理者会提出不一样高优先级的事项，在如今，只有一组定好了优先级的待办事项。过去有太多的工做同时在进行中，如今都按一个被时间约束、被讨论验证过的计划来执行。综合起来，这可让一个团队达到新的生产力水平。然而，团队可能会发现本身受到缺少技术实践的限制，好比代码评审、自动验收测试和持续集成。

其余像极限编程（Extreme Programming）这样的敏捷过程，对于技术实践如何支持团队保持速度、并为管理人员和利益相关者提供透明度和可见性，有颇有力的观点。一些 Scrum 团队将技术任务放在待办事项列表中，虽然这很符合 Scrum 的指导原则，但它很快就遇到了实际问题——产品负责人对功能特性的偏见。除非产品负责人很是懂技术，不然她或他可能没有能力评估技术实践的性价比(成本/效益)。当技术任务延伸到运维工做以支持可靠性、性能和安全性时，对于产品负责人来讲，这就变得更加困难了。

「CODING 企业版」做为企业级软件研发管理系统，任务看板功能实现了 Epic \ user stories \ Sprint 等敏捷概念落地。

产品负责人和服务负责人

在 Atlassian，咱们已经认识到在产品中有两个不一样的角色是有帮助的。咱们的产品负责人很擅长理解用户须要的特性，可是他们不太擅长将这些特性与性能、可靠性和安全性等非业务性功能进行权衡。所以，Atlassian 的一些 SaaS 产品也有相应的服务负责人，负责对这些非业务性功能进行优先级排序。从时间上看，这两个负责人可能不得不进行一些“激烈的讨价还价”，但大多数状况下，这些均可以由独立的团队来完成。这可能不是从运维工做中“放大反馈”的惟一方法，但它确实有助于克服产品负责人对功能特性的广泛偏见。这种“两个负责人”的方法并非惟一的 DevOps 方法，重要的是要理解这些做为“特性”的非业务性功能，而且可以像任何其余功能同样对它们进行计划和排序。

在 DevOps 成为主流以前，它不会是 Scrum 的天然结果。

最终，这些对 Scrum 的批评都不是 Scrum 自己固有的。与全部敏捷方法同样，Scrum 有一个内置的“过程改进”机制，称为回顾。所以咱们有理由相信，一些 Scrum 团队将利用 DevOps 做为灵感的来源，并将 Scrum 回顾对 DevOps 进行调整。然而，要意识到大多数团队须要外部力量来推动，这是很实际的。直到 DevOps 成为主流（甚至在学校里开始教过）以前，DevOps 也不会是 Scrum 的天然结果。不管团队引入的是敏捷教练仍是 DevOps 教练，这均可能是可有可无的，只要这我的可以在构建、测试和部署软件的过程当中带来自动化的经验。

DevOps 不只仅是持续交付

若是执行得好，持续交付（CD）的规程有助于规范正在进行中的工做，而部署的自动化有助于提升约束。经过这种方式，持续交付能够帮助软件团队更频繁地交付，并保证更高的质量，而不是在二者之间作出妥协。然而，就像团队只关注 Scrum 同样，可能会错过敏捷更普遍的环境，因此专一于持续交付的团队也会错过 DevOps 更普遍的背景。

持续交付的实践并不能直接解决业务和软件团队之间的沟通问题。若是业务团队有一年时间的计划周期，那么软件团队将每一个代码提交上线可能还须要等待几个月才能获得反馈。一般这些反馈都是做为下一步的指示，好比取消项目，或者困扰项目团队的其余麻烦（一般大量新用户的涌入对性能是破坏性的）。

敏捷流畅度模型代表，第一级的流畅性是“专一于价值”，而团队关注的是透明度和一致性。若是没有这种流畅性，持续交付可能很容易地发展成一个无穷无尽的技术改进循环，对业务没有任何价值。一个团队可能擅长于以高质量的速度交付，可是对于最终用户或业务来讲这多是一个价值较低的产品。即便有许多用户说了这是好东西，但在更大的业务组合级别上，可能对这个产品的评估是低价值的。若是没有这种重要的流畅性，就很难衡量技术实践与功能特性的关系。对于具备遗留代码库的团队来讲，这一点尤为重要，由于它可能没有自动化测试或适合频繁部署的设计。在遗留的环境中，持续交付转换可能须要数年时间。所以，可以证实商业利益是很是重要的。

三种方法

DevOps 不只仅是自动化部署流水线。用 John Allspaw 的话说，DevOps 关乎“像开发者同样思考的运维，像运维同样思考的开发者”。在详细阐述这一思想时，Gene Kim 介绍了做为 DevOps 原则的三种方法：

第一种方法：系统性思惟 —— 强调整个系统的性能，而不是一个特定的工做或部门的性能。这个系统它能够像一个部门同样大，也能够像单个贡献者同样小。 第二种方法：反馈放大回路 —— 建立从右往左的反馈循环。几乎任何过程改进计划的目标都是缩短和放大反馈循环，这样就能够不断地进行必要的修正。 第三种方法：持续试验和学习的文化 —— 创造培养两种东西的文化：不断地试验、冒险以及从失败中学习；理解重复和练习是掌握的先决条件。

持续交付（CD）关注的是第一个方法：将从开发到运维的流程自动化。自动化在帮助加速部署系统方面起着明显的做用。可是，系统思考不只仅是自动化。 第二种方法的特色是，开发者也要戴着寻呼机。 尽管使用寻呼机这样的描述多是没必要要的，但这意味着将开发人员拖入运维工做。这有助于开发人员了解他们的开发选择的后果。例如，这能够激励开发人员把日志信息放在更好的地方，并使这些消息更有意义。这不只仅是关于意识的问题。开发人员还将他们对系统的内部理解引入故障排除工做，所以能够更快地找到问题并提出解决方案。 第三种方法是在整个系统中进行增量式的试验，而不只仅是应用程序在流水线中移动的变化。 换句话说，自动化相对容易看出须要多长时间，并使用日益强大的基础设施来不断改进它。比较难理解的是角色或组织之间的交接是如何致使延迟的。这意味着团队在整个交付工做流程中进行“检查和适应”，寻找改善人与人之间协做的机会。就此而言，持续集成须要保持适应和改进的习惯。若是团队没有思考如何变得更有效率，并在任何事情上积极适应和调整它的行为，那么持续集成也不会成长和繁荣。团队须要有能力解决本身的问题。

在 Scrum 中，每一个回顾都是一个改进实践和工具的机会。可是，若是团队没有利用这些机会来解决短时间和长期的技术问题，那么他们就会等待产品负责人把持续集成任务放到待办事项列表中，这是永远不会发生的。

「CODING 企业版」做为企业级软件研发管理系统，助力团队敏捷开发转型升级。

DevOps 是敏捷应用于软件团队以外的成果

Scrum 主要映射到的敏捷原则是，“欢迎不断变化的需求，甚至于在开发后期。敏捷过程利用变化来保证对于客户的竞争优点。”

持续交付主要映射到的敏捷原则是，“咱们的首要任务是经过早期和持续交付有价值的软件来知足客户。”

这意味着敏捷更多的是拥抱即将到来的以及外部的变化，而不是像在会议站着或冲刺周期计划这样的仪式。实际上，敏捷宣言中还有其余 10 个原则。与其试图在这些原则中作出选择，不如把它们视为一个总体。这些原则共同表明了一种对敏捷和 DevOps 的态度：改变是很常见的。

DevOps 试图将它做为敏捷的态度传递给新的受众：IT 运维。

这些人一直在试图保脆弱系统的运行，而这些系统对企业来讲也是最重要的。由于它们对企业来讲是最重要的，因此它们也是最迫切须要改变的地方。所以，这种拥抱变化的敏捷理念并非“为了改变而改变”。它关乎让开发对其变动的质量负责，同时提升交付业务价值的总体能力。这种对业务价值的关注是敏捷和 DevOps 相通的另外一个方面。

最后，不管是敏捷仍是 DevOps 都不是他们本身的商业目标。二者都是文化运动，都是用更好的方式来激励你的组织，以实现你的目标。敏捷和 DevOps 在组合中比对手更有效。避免这两种想法之间的冲突的诀窍是理解它们所造成的更深层次的价值观和原则。快速但狭隘的定义致使了“竖井式思惟”。如今你已经知道，敏捷比 Scrum 更重要，并且 DevOps 比持续集成更重要，你已经准备好尝试强大的敏捷+ DevOps 组合了！

「CODING 企业版」做为企业级软件研发管理系统，助力团队敏捷开发转型升级。

本文中文翻译自原文：Agile and DevOps: Friends or Foes? 编译者：程景天。