[敏捷与 DevOps：是敌是友？]

[chengjintian]

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? 编译者：程景天。