DevOps是敏捷在软件开发团队的另一应用。那么相比之下，哪个更胜一筹？
一边，有业界认可的scrum master，它的朋友极限编程者，以及由其衍生的 LeSS、SAFe、DAD等，是敏捷。
另一边，有精益文化机器，用代码持续交付其基础架构，它的名字左边是开发，右边是运维，合起来就是DevOps。
虽然我已尽我所能在普及这两个概念，但人们关于敏捷和DevOps的争论依然让它们听起来完全不同。更糟糕的是，尽管他们都已经有了各自的行业术语和口号，但两者的概念还是没办法准确定义。鉴于敏捷诞生早于DevOps ，所以它的定义也相对清晰一些，但DevOps五花八门的定义仍然让很多人都很困惑。而正是因为二者都缺乏准确的定义，所以导致人们经常会有一些误解。
很多人认为敏捷等于scrum，DevOps等于持续交付。过度简化的理解让敏捷和DevOps之间形成了不必要的对峙，但最终你会惊讶地发现二者其实是非常好的朋友！
毫无疑问DevOps和敏捷之间的联系由来已久。在2008敏捷大会上，Patrick DuBois和Andrew Clay Schafer尝试建立二者之间的关系并提出“敏捷架构”这一概念，这时，敏捷与DevOps之间的关系就已初现端倪。尽管Patrick后来提出了“DevOps”一词，但敏捷大会依然被追溯为DevOps的起点。所以我们不妨透过Scrum和持续交付的表面，深入了解二者的历史，来思考一下敏捷和DevOps之间还存在哪些关联。
一、敏捷绝不仅仅是Scrum
某些团队中，scrum让团队工作介于一成不变、苦苦挣扎和量产、高回报之间。还有一些团队，scrum用客观和聚焦代替主观和过度承诺。我们也可以把它视为一种教条。当业务收到限制或工作本身需要做出改变的时候，敏捷团队将利用scrum的基本原则，审视自身的工作并做出更有效的调整。尤其是当scrum应用于软件开发环境之外的业务时，这点尤为重要。
提前规划计划外的工作
在DevOps社区，有敏捷经验的人都觉得scrum能够有效追踪计划中的工作。一些正在运行中的工作可以被计划：如发布一个重大系统变更、切换数据中心或系统升级等。但在运行中大多数事情是没办法计划的：如性能到达峰值、系统中断或安全问题等。这些突发事件都需要快速做出反应。没时间等到把这些事项在backlog中确定优先级后再做或放到下个sprint规划会议中处理。正因如此，很多团队开始慢慢接受DevOps思想，Scrum之外再引入Kanban。这样使得团队可以同时追踪两种类型的工作，帮助他们理解两者之间的联系。或者，他们采取了一种综合方法，叫做Scrumban 或 Kanplan （也就是有backlog的看板）。
在很大程度上，scrum得以广泛应用的关键可能在于它不对技术方法设限。Scrum作为轻量级管理方法，往往能为团队带来巨大变化。之前，可能会有来自多个master的优先事项互相竞争，但在scrum中，backlog中只会存在一组优先事项。之前，团队中可能会存在同时推进很多工作的情况，而现在取而代之的是一个在限定时间内可以完成的工作计划。综合来看，这些都可以将团队的生产率带到一个新的水平。然而，团队可能会因技术实践的缺乏而受到限制，如代码审查、自动化验收测试、持续集成。
其他敏捷方法如极限编程，也对技术如何使团队保持可持续交付节奏并向管理层和利益相关者提供透明度和可见性提出了明确要求。一些Scrum团队倾向于将研发任务放在backlog中。虽然这在scrum的指导下适应得很好，但很快就会遇到Product Owner对产品功能的偏向性问题。除非Product Owner的技术能力很强，否则TA可能无法评估技术的成本或收益。尤其是当技术任务延伸到运维、可靠性支持、性能、安全性等方面时，对Product Owner来说更加困难。
Product Owner 和Service Owner
在Worktile，我们认识到，为我们运营的产品设置两个不同角色很有必要。Product Owner善于理解用户的功能性需求，但可能并不擅长权衡产品功能与性能、可靠性和安全性等非功能性功能之间的优先级。因此，一些SaaS产品也配备了Service Owner角色，负责确定前述非功能性功能的优先级。尽管两个角色经常需要讨价还价，但大部分情况下，独立的团队都可以自行完成这两个角色的任务。虽然这并不是“强化反馈”的唯一方法，但确实能够克服Product Owner对产品功能中比较常见的偏见问题。但设置‘两个Owner’并非实现DevOps的唯一途径。重要的是将非功能性特征理解为“功能”，并将它们像功能性的用户故事一样，进行规划和优先级排序。
在DevOps成为主流前，不能确定scrum自然发展的结果一定是DevOps。
敏捷方法中，Scrum有一个内在的“过程改进”机制，叫做回顾会议。因此，我们有理由相信一些scrum团队会想用DevOps作为灵感来源，用scrum回顾会议作为向DevOps方向调整的契机。然而，事实让我们意识到大多数团队需要注入外部思想。在DevOps成为主流前（哪怕成为学校必学内容），我们不能确定scrum自然发展的结果一定是DevOps。团队到底是有敏捷教练还是DevOps教练参与并不重要，只要他能给团队带来在构建、测试、部署等方面的自动化经验即可。
二、DevOps也不仅限于持续交付
如果应用得当，持续交付的规则可以有效限制在制品数量，而部署的自动化有助于打破工作局限。通过这样的方式，持续交付让软件开发团队频繁交付更高质量的产品，而不必在二者之间抉择。然而，正如仅专注于scrum的团队可能会忽视更广泛的敏捷环境那样，仅专注于持续交付的团队也会错过更广泛的DevOps环境。
持续交付实践并不能直接解决业务部门和开发团队之间的沟通问题。如果业务部门设定了一个为期一年的预算驱动计划，那么产品交付团队每次交付产品后都需要等待数月才能得到业务部门给的反馈。而这些反馈通常都是一些影响后续工作的步骤性功能，像取消项目或者更糟糕的是需要扩充项目团队（因为大量涌入新人会影响团队已有的稳定性）。
敏捷流畅度模型将“价值聚焦”视为流畅度的第一层级，即团队需要注重透明度和一致性。如果价值不聚焦，持续交付很容易陷入技术改进的无限死循环而无法向业务交付可观的价值。团队可能擅长快速高质量的交付，但就产品本身而言，可能对终端用户或者企业来说几乎没有价值。即使很多用户给出了较好的评价，但从较大的业务组合层面来看可能就会评估为低价值。因此，没有价值聚焦这一重要流畅度，团队很难在技术和功能之间权衡取舍。
这点对于有遗留代码库的团队来说尤为重要，因为遗留代码库可能没有自动化测试或适合频繁部署的设计。在一个遗留环境中，持续交付转换可能需要数年的时间。因此，证明产品的商业价值就显得尤为重要。
三种方法
DevOps不仅仅是自动化部署流水线。换句话说，DevOps方法要求“运维人员（Ops）能够像开发人员（Devs）那样思考，而开发人员（Devs）也要像运维人员（Ops）那样思考。” 以下是这一观点的进一步阐述以及可作为DevOps原则的三种方法：
第一种：系统思维
强调整个系统的性能，而不是特定的工作孤岛或部门的性能——这个系统可以大到涵盖整个业务部门，小到仅包括单个工作项。
第二种：扩大反馈循环
创建全流程的反馈循环。几乎所有过程改进计划的目的都是为了缩短并强化反馈循环，以确保可以不断进行必要的修正。
第三种：不断实践和学习的文化
塑造一种聚焦在这两件事上的文化：不断实践、勇于冒险并从失败中学习经验；要明白重复和实践是熟练掌握的先决条件。
持续交付侧重于第一种方法： 即实现从开发到运维的自动化流程。自动化在加快系统部署上的作用非常明显，但系统思维绝不止于自动化。
第二种方法的突出特点是实践， 即“开发人员也要随身携带传呼机”。虽然开发人员不一定真的要随身携带传呼机做到随叫随到，但他们也需要积极参与到运维工作中。这样能让开发人员了解到他们开发过程中所做选择带来的后续影响。例如，这样做能让开发人员将自己的日志消息存放到更好的位置让它们发挥更大的作用。开发人员不仅仅要了解运维工作，还要结合自己对系统的理解做一些故障排除的工作，这样可以更快地找到并实施解决方案。
第三种方法强调在整个系统中进行增量实验，而不仅仅是应用程序在流水线中移动的变化。 换句话说，看出自动化所需的时间并用日益强大的基础设施来不断改进它相对来说是比较容易的。而要清楚的知道角色或企业之间的交接如何导致延期是比较困难的。这意味着团队要“检查和调整”整个交付工作流，寻找可以提升人员协作效率的点。对于这个问题，持续交付要求团队养成不断适应和改进的习惯。如果团队从来不去思考如何变得更高效，并付诸行动去调整和改善，那么持续交付也无法持续发展和完善。团队要相信自己有能力解决自己的问题。
在scrum中，每次回顾会议都是一次改进实践和工具的机会。但如果团队没有抓住这些机会解决短期和长期的技术问题，他们就无异于坐等Product Owner将持续交付任务放到他们的backlog中，而事实上，Product Owner永远不会这么做。
DevOps是敏捷在软件开发团队之外的应用
Scrum主要遵循“欣然面对需求变化，哪怕变更出现在开发后期。敏捷过程正是利用变化来帮助客户取得竞争优势”这一敏捷原则。
而持续交付遵循的敏捷原则是：“我们的首要任务是通过尽早、持续地交付有价值的软件，来满足客户的需求”。
这意味着敏捷更强调输入和输出的变化，而不是每日站会和sprint规划会等仪式。事实上，《敏捷宣言》中还有另外10条原则。我们应该将它们视为一个整体，而不是从中选择某些原则。因为这些原则合起来代表的是敏捷和DevOps对变更的态度。
DevOps旨在将敏捷关于变更的态度应用到新的领域：IT运维。
这些人一直在运行对于企业来说非常重要但同时又非常脆弱的系统。也正是因为它的重要性，所以也最迫切需要得以改进。因此，这里敏捷强调的变化并不是“为了改变而改变”。是为了让开发对其变更质量负责，同时提高整体交付商业价值。而这种对商业价值的关注是敏捷和DevOps的另一个共通点。
最后，敏捷和DevOps本身并不是业务指标。它们都是可以激励组织用更好的方法实现目标的企业文化。将敏捷和DevOps结合起来使用能取得更好的效果。而避免这两种文化发生冲突的诀窍就是要理解构成它们的更深层次的价值观和原则。武断而狭隘的定义会禁锢思维。相信看完本文，你已经知道敏捷不仅限于scrum，而DevOps也不仅限于持续交付。那么接下来，你就可以尝试强大的Agile + DevOps组合了。
Worktile 官网：worktile.com
作者：IAN BUCHANAN
内容整理：Worktile
文章首发于「Worktile官方博客」，转载请注明出处。