DevOps和敏捷

一边是Agile，一边是DevOps。

Agile阵营里，Scrum、Kanban、极限编程，LeSS、SAFe......

在另一个阵营，Lean、Continuous integration、Continuous delivery、Infrastructure as Code、以Development和Operations的组合词DevOps！

关于敏捷和DevOps的名词，可以让它们听起来像是非常不同的想法。更加混乱更加复杂的是，这两个概念似乎都无法定义，即使它们有自己的术语和口号。敏捷已经有些年头了，可能不那么模糊，但人们对 DevOps的无数定义感到沮丧，这是很常见的。缺乏定义导致了一些混淆。 

许多人认为敏捷意味着Scrum，DevOps意味着持续交付。这种过度简化在敏捷和DevOps之间造成了不必要的对立，事实上，可能会惊讶地发现它们是一脉相承的！

DevOps和敏捷之间有历史联系。当Patrick DuBois和Andrew Clay Schafer试图在敏捷2008大会上就“敏捷基础设施”进行交流时，与DevOps的联系就诞生了。Patrick后来创造了“DevOps”一词。但是，我们了解Scrum和持续交付的表面现象之后，需要继续深入，考虑敏捷和DevOps之间的实际联系。

敏捷不仅仅是Scrum

在某些团队中，Scrum是持续的、令人沮丧的斗争和富有成效的、有回报的团队合作之间的区别。从另一个角度看，Scrum用客观和专注取代了指令和过度承诺。它也可以像教条一样被接受，然后当业务或工作本身的限制要求不同时，敏捷团队将利用Scrum的基本原则，检查他们的实践，并适应变化，从而更有效。当Scrum用于软件开发环境之外的场景时，这一点也一样重要。

计划外工作

在DevOps社区中，具有敏捷经验的人承认，Scrum对于跟踪计划内的工作很有用。可以计划一些运营中的工作：发布重大系统更改、在数据中心之间迁移或执行系统升级。但大部分运营工作都是计划外的：性能峰值、系统中断和安全性漏洞。这些事件需要立即响应。没有时间在backlog中等待考虑优先顺序或等待下一个Sprint计划会。出于这个原因，许多已经开始接受DevOps思维的团队，将目光从Scrum转向Kanban。这有助于他们跟踪这两种工作，并帮助他们了解它们之间的相互关联。或者，他们采用混合方法，常见的方式是Scrumban或Kanplan。

在许多方面，Scrum被广泛采用，关键在于它没有规定任何技术实践。Scrum的轻量级管理实践通常会对团队产生重大影响。曾经有来自多个源头的任务相互竞争优先顺序，现在用Backlog进行统一优先级规划。曾经有太多工作在同一时间开展，现在有一个计划，任务将在一个可能的时间盒里完成。这些方法结合起来，可以将团队的生产力提升到新的水平。但是，团队可能会发现自己受到缺乏技术实践的限制，例如编码审查、自动化验收测试和持续集成。

极限编程等其它敏捷过程，对技术实践如何支持团队保持可持续发展步伐的能力，以及为管理层和干系人提供透明度和可见性有着强烈的看法和指导。一些Scrum团队只能将技术类任务放在Backlog中，虽然这符合Scrum的指导，但它很快带来了Product Owner对功能的偏见的实际问题，除非Product Owner技术水平很高，否则他可能不具备评估技术实践成本与收益的技能。随着技术任务延伸到运营以支持可靠性、高性能和安全性，这对Product Owner来说变得更加困难。

Product Owner和Service Owner

在Atlassian，为运营的产品设置两个不同的角色。Product Owner善于理解用户需要的功能，但他们不太擅长权衡这些功能与性能、可靠性和安全性等非功能性收益。因此，Atlassian的一些SaaS产品也有一个Service Owner，负责优先处理那些非功能性问题。两位Owner有时可能不得不做一些“精明的交易”，但大多数时候，这些可以由独立的团队来完成。这可能不是“放大运营反馈”的唯一方法，但它确实有助于克服Product Owner对功能的普遍偏见。这种“双Owner”方法并不是DevOps的唯一途径。重要的是将这些非功能性特征理解为“功能”，并能够像任何功能性用户故事一样对它们进行规划和优先排序。

归根结底，这些Scrum的问题都不是Scrum本身固有的。与所有敏捷方法一样，Scrum有一个内置的“流程改进”机制，称为回顾。因此，有理由相信一些Scrum团队会将DevOps作为灵感来源，并使用Scrum 回顾作为调整和迈进DevOps的机会。然而实际上，大多数团队更需要从外部注入想法。在DevOps成为主流之前，DevOps不会是Scrum的必然产物。团队是否聘请敏捷或DevOps教练可能并不重要，只要该人能够在构建、测试和部署软件方面带来自动化经验。

DevOps不仅仅是持续交付

如果做得好， 持续交付 (CD) 原则有助于限制WIP，而部署自动化有助于改善约束。通过这种方式，CD可以帮助软件团队更频繁地交付更高质量的产品，而不必在两者之间进行选择。就像只关注Scrum的团队可能会错过更多样的敏捷方法一样，关注持续交付的团队也会错过更广泛的DevOps领域。

CD的实践并不能直接解决业务团队和软件团队之间的沟通问题。如果企业有一个以年为周期的预算驱动的计划，那么将每个提交交付到生产中的团队可能仍需要等待数月才能做出反应。这些反应常常以阶梯式的形式出现，比如取消项目，或者更糟糕的是，项目团队增加一倍（因为大量新人的涌入会造成破坏）。

敏捷流畅度模型将第一级流畅度表示为“专注于价值”，团队专注于透明度和一致性。如果没有这种流畅性，CD很容易陷入无休止的技术改进循环，对业务没有明显的价值。一个团队可能擅长快速交付高质量的产品，但对于最终用户或业务而言价值较低的产品。即使有很多用户的好评，这种对低价值的评估也可能只有在更大的业务组合层面才有可能实际意义。如果没有这种重要的流畅性，就很难权衡技术实践与功能。这对于拥有遗留代码库、可能没有自动化测试或适合频繁部署的设计的团队来说尤其重要。在传统环境中，CD转型可能需要数年时间。因此，更重要的是能够展示商业利益。

三种方式

DevOps不仅仅是自动化部署管道。用John Allspaw的话来说，DevOps是关于“像开发人员一样思考的运营人员。像运营人员一样思考的开发人员”。Gene Kim详细阐述了这一想法，将三种方式解释为DevOps 的原则：

持续交付（CD）专注于第一种方式： 自动化从开发到运维的流程。自动化在帮助加速部署系统方面发挥着明显的作用。但系统思考不仅仅是自动化。

第二种方式的特点是“开发人员到第一线”：尽管可能不需要真正到第一线，但这意味着将开发人员拉入运营问题。这有助于开发人员了解他们的开发选择的后果。例如，这可以激发开发人员将日志消息放在更好的位置，并使这些消息更有意义。这不仅仅是意识。开发人员还将他们对系统的内部理解用于故障排除工作，因此可以更快地找到并实施解决方案。

第三种方式是：在整个系统中进行增量实验，这不仅仅是对应用程序的范围内。比如，很容易看出自动化需要多长时间，并使用越来越强大的基础设施来不断改进它。很难理解角色或组织之间的交接是如何导致延迟的。这意味着团队在整个交付工作流程中“检查和调整”，寻找改善人员协作的机会。就此而言，CD需要一种适应和改进的习惯。如果团队不思考如何变得更有效率，然后在其它事情或行为上进行调整，那么CD也不会发展壮大。团队需要感到有能力解决自己的问题。

在Scrum中，每次回顾都是改进实践和工具的机会。但如果团队不利用这些机会解决短期和长期的技术问题，那么他们只会等待Product Owner将CD相关任务留在backlog，改进永远不会发生。

DevOps和敏捷应用于软件团队之外

Scrum主要的敏捷原则，“拥抱变化，即使是在开发的后期。敏捷过程利用变化来获得客户的竞争优势。”

持续交付主要的敏捷原则，“首要任务是通过早期和持续交付有价值的软件来满足客户”。

这意味着敏捷的价值在于拥抱内部和外部的变化，而价值不在于像站会和Sprint计划会这样的仪式。事实上，敏捷宣言中还有多条其它原则。与其试图在这些原则中进行选择，不如将它们作为一个整体来考虑。这些原则共同代表了敏捷和DevOps共同的变革态度。

DevOps旨在将这种敏捷的变革态度带给新的非开发团队：IT运营。

这些人一直被困在试图运行对业务来说也是最重要的脆弱系统。因为它们对业务最重要，所以它们也是最迫切需要改变的地方。因此，这种拥抱变化的敏捷理念并不是“为变化而变化”。这是关于让开发人员对其变更的质量负责，同时提高交付业务价值的整体能力。这种对业务价值的关注是敏捷和DevOps共有的另一个方面。

最后，敏捷和DevOps本身都不是业务目标。两者都是文化运动，可以激发组织以更好的方式实现目标。敏捷和DevOps结合起来可以更好地工作。避免这两种思想冲突的诀窍是理解形成它们的更深层次的价值观和原则。快速但狭隘的定义会导致孤立的思维。既然知道了敏捷比Scrum更重要，DevOps比CD更重要，那么就可以尝试强大的敏捷+DevOps组合。

将工具与自动化连接起来

跨多种工具工作的最大挑战可能是场景的不断变化和带来的中断。如果被非代码任务打断，可能需要数小时才能恢复正常。出于这个原因，越来越多的人正在通过他们的git提供程序和工作管理工具实现自动化。以下是三个最常见的自动化规则

1. 当创建提交且状态为“待办”时，将此问题转换为“处理中”。
2. 完成合并请求时转换为“完成”。 
3. 如果构建失败，在任务中添加评论，并发送通知。

提示，目前可以在Jira自动化模板库中查看到100多个自动化规则，这是现成的可参考的敏捷+DevOps实践。