DevOps与敏捷异同 - DZone DevOps

敏捷和DevOps可能看起来像是不同的行为，但如果你看看他们的目标，你会发现它们非常相似。看看Agile和DevOps提供的价值。也就是说，看看DevOps的“为什么”；再看看敏捷的“为什么”。当您仔细观察时，您会发现两者的目标是更快地为客户创造价值并更快地改变市场需求。DevOps采用Agile中引入的原则，并将其扩展到代码以外阶段：部署和运营。

既然敏捷和DevOps的目标一致，在围绕它们的实践中发现很多的重叠就不奇怪。在许多方面，DevOps和Agile的交集涉及从该文化中产生的协作文化和现代技术实践和过程。我们在诸如连续测试和Small Batch Sizes等流程中看到了这一点，这有助于确保向客户快速交付工作产品。我们在努力使工作可见，暴露工作流程和系统遥测，以加速价值流向客户。

我们看到Agile和DevOps在重点关注协作方面存在重叠，需要建立小型，有凝聚力的团队，共同负责并更广泛地了解产品交付中涉及的所有部分。

(banq注：有重叠就有竞争，DevOps还是和敏捷有互相替代的关系)

什么是DevOps？什么是敏捷？

在我们开始研究DevOps和Agile之间的关系之前，首先要对这些术语的含义有一个共同的理解是很重要的。虽然有许多定义，但它们可以从根本上理解为一套原则，从中可以推导出工程文化和实践。

敏捷，其存在时间比DevOps长，可以说是更为成熟，其定义于2001年2月的敏捷宣言中。该宣言规定了以下价值：

• 个人和流程与 工具 之间的互动
• 通过综合文档工作软件
• 合同谈判中的客户协作
• 响应遵循计划的变更

多年来，敏捷已经发展到敏捷宣言之外。Modern Agile考虑了90年代后敏捷宣言小型软件团队环境之外的不同方面。在现代，我们经常扩展企业和/或创业公司，我们正在建立实验文化，学习型组织，提高员工保留率，提供客户和业务价值而不仅仅是速度，以及设计心理安全，这是高绩效团队的关键。

虽然DevOps已经尝试过发布宣言，但没有单一的宣言尚未获得敏捷宣言所具有的广泛接受程度。DevOps更重视协作，特别关注开发和运营团队之间的交叉功能以及对这两个方面的责任。

敏捷教练安东尼加德纳说，“我测试，我编码，我部署，我在周末起床并修复错误 - 我让我的代码更好，所以我不必在周末起床。”DevOps可以被认为是一种为客户提供价值的方法，专注于协作和小批量。

DevOps专注于持续集成，自动化一切，持续测试和持续交付。

Gardiner说，“DevOps是一种完全围绕在墙上部署软件过程中移除孤岛的运动或哲学”。这是关于创建一个负责开发，部署和生产代码的跨职能团队。“

虽然没有单一的定义，但Gene Kim，Kevin Behr和George Spafford在他们的开创性小说“凤凰计划 ”中引入了DevOps的“三种方式”的概念。这三种方式是许多DevOps实践的核心。

Kim后来在DevOps手册中对这些进行了扩展，他与Jez Humble和Patrick Debois合著。

这三种方式包括：

• 系统思考：强调整个系统的性能，而不是特定工作或部门孤岛的表现 - 这可以像分工一样大，也可以像个人贡献者一样小。
• 放大反馈循环：创建右到左反馈循环。几乎所有过程改进计划的目标都是缩短和放大反馈回路，以便不断进行必要的修正。
• 持续实验和学习的文化：创造一种培养两种东西的文化：持续的实验，冒险和从失败中学习; 并且理解重复和练习是掌握的先决条件。

值得注意的是，敏捷和DevOps的定义经常令人困惑，因为它们已被选为营销术语并在此过程中被扭曲。这些定义进一步混淆，因为声称正在实施敏捷和DevOps的公司倾向于使用工具和仪式，或者在Scrum的情况下，实施规则而不改变思维模式或组织文化。或者也许没有执行管理层愿意改造。

历史

追溯到20世纪90年代，敏捷已存在的时间比DevOps长得多，后者在将近20年后生根。然而，这两套原则都源于精益制造，其历史可以追溯到20世纪40年代。难怪我们今天看到这两者的相似之处。虽然DevOps的流行度持续增长，但Agile已经并且仍然比DevOps更广为人知。谷歌趋势表示“敏捷”一词的搜索量大约是“DevOps”一词的三倍。

敏捷的根源可以追溯到20世纪40年代的精益流程，其中包括Kanban，一种可视化丰田生产系统一部分工作流程的方法。约束理论也是后来发展起来的。然而，敏捷的软件开发方法在20世纪90年代真正起步，当时一群软件开发人员对瀑布式开发方法中涉及的高度严格的流程感到沮丧。这些通常导致软件项目花费了数月甚至数年才导致失败。在20世纪80年代和90年代，创建了几种迭代软件开发方法作为瀑布方法的替代方法，包括极限编程（XP）和看板。1995年，引入了敏捷开发的Scrum实践。然后，在2001年Snowbird Mountain Retreat举行的着名会议上，一群思想领袖齐聚一堂，共同开发敏捷宣言。敏捷在今天持续发展和发展，其中许多不同的变化和实践都是从最初的宣言（包括现代敏捷）发展而来。虽然敏捷制定了整体原则，但有许多常见的方法来实践敏捷原则，Scrum和看板是最受欢迎的两种。

DevOps是一套更新的原则，它源于精益制造中的一些相同概念。“DevOps”一词于2009年首次推出，当时Patrick Debois在比利时Ghen举办了“Devopsdays”活动。这个概念占据了第一年美国Devopsdays的第一年。2013年，领导人Gene Kim（作者），Kevin Behr（作者）和George Spafford（作者）撰写了他们的书“凤凰计划：关于IT，DevOps和帮助您赢得业务的小说”，  其中提出了许多基础概念今天组成DevOps。DevOps继续增长，2014年，我们看到DevOps越来越多地扩展到以DevOps企业峰会为标志的企业环境中。今天，DevOps继续与敏捷一起成长和发展。

合作文化

敏捷与DevOps之间的核心共性之一是强调建立协作文化。这两种方法都在寻找打破孤岛和增加共同责任的方法。通过打破孤岛，DevOps和Agile减少了切换，以提高交付给客户的速度。敏捷主要关注质量保证的包含，而DevOps则采用这种协作概念并将其扩展到运营团队。

在敏捷中，我们将合作文化视为敏捷宣言的核心原则。第一个是“个人和流程与工具之间的互动”，明显表示需要共同合作，而不是为交接创建定义的术语或流程。此外，第三个原则“客户在合同谈判中的合作”强调需要将这种合作扩展到开发团队之外以及客户之外。

敏捷教练Susan McIntosh在她的文章“敏捷心态究竟是什么？”中强调了敏捷的协作思维方式，他说：“敏捷的心态是支持敏捷工作环境的一系列态度。这些包括尊重，协作，改进和学习周期，所有权的自豪感，专注于提供价值，以及适应变化的能力。这种思维方式对于培养高绩效团队是必要的，这些团队反过来为他们的客户带来了惊人的价值。“

在Agile中实现协作有很多实践。对编程，围攻和群集等实践都允许更大的团队一起开发软件。它们脱离了发展的概念，作为一个单独的 程序员 单独完成的任务。此外，Agile致力于将QA无缝集成到流程中，作为负责每次迭代交付工作代码的团队的一个组成部分。

DevOps的许多基础概念也是围绕协作理念构建的。事实上，这个基础可以追溯到对发展，运营和质量保证分离的反应。认识到这些独立的孤岛引起了相互冲突的利益，增加了交接和价值损失，这是DevOps运动的基础之一。

Thoughtworks首席科学家Martin Fowler指出，协作在DevOps中扮演着至关重要的角色，“DevOps文化的主要特征是开发和运营角色之间的协作增加......开发和运营之间应该没有孤岛。切换期和文档不能替代从一开始就在解决方案上合作。调整资源结构有助于操作人员尽早参与团队。让开发人员和运营人员在同一地点将帮助他们一起工作。“

在DevOps中可以通过多种方式实现此协作，并将其扩展到开发和QA流程之外。构建协作文化的关键方法之一是在所有参与向客户交付价值的团队之间制定共同目标。通过设计开发，运营和质量保证之间共享的目标，您可以使公司明确目标，并将重点放在客户需求和最终交付上。

DevOps鼓励合作的另一种方式是将操作活动集成到sprint中。这可以通过在sprint中包含运营团队成员来实现，或者甚至更好地确保所有sprint团队成员共享运营责任。将操作任务作为积压的一部分包括在内也是有益的。通过这种方式，您可以为与操作应用程序相关的许多任务提供共享焦点，这些任务在以功能为中的团队中经常被忽略。这些操作任务通常被称为“功能”，可能包括可维护性，可伸缩性和安全性等。通过共同构建和运行应用程序和服务，DevOps推动团队之间的协作，以提供更安全和稳定的应用程序。

除了提供功能和“功能”之外，高性能DevOps组织的常见做法是为负责维护这些产品的产品提供团队。一旦系统稳定性得到证实，它就会移交给另一个团队进行维护。其他公司包括开发团队，作为操作问题的寻呼机轮换的一部分。这创造了共同的责任，并加强了共同的目标和责任。

最终，DevOps不是一份工作。它不是一个角色，也不是任何一个人或团队的责任。DevOps的核心是协作，并以这种方式与敏捷宣言中编纂的原则保持一致。

小批量和短周期时间​​​​​​​

小批量和短周期时间是敏捷的关键。通过减少对系统的更改大小，Agile可以更快地为客户创造价值。这种快速部署还允许快速反馈，允许客户或用户快速查看已开发的内容，并允许团队在必要时快速调整课程。这与瀑布式方法形成鲜明对比，客户可能需要等待数月甚至数年才能看到可交付成果，然后才能确定它是否是他们想要或需要的。DevOps采用小批量大小的概念，并通过持续集成和持续部署（CI / CD）进行扩展。CI / CD提供了一个工具链，允许团队加快价值，让客户将周期从几周甚至几小时缩短。

小批量是精益的关键，它起源于20世纪30年代，为敏捷和DevOps提供了一些核心基础。精益专注于消除浪费和减少批量大小来实现这一目标。这减少了正在进行的工作量，因此减少了等待下一个处理阶段的库存量。

这一概念在敏捷的核心原则中得到了回应，该原则指出“经常提供工作软件，从几周到几个月，优先考虑更短的时间尺度。”小批量和缩短周期时间有许多好处。小批量，减少队列，降低交易成本和快速反馈循环可以使可变性成为资产而非负债。根据Don Reinertsen的说法，为了使产品开发增加价值，结果将不可避免地存在不确定性。我们不应该尽量减少失败，而应该接受可变性。我们可以通过有效学习和低效地生成信息来减少不确定性（通过这样做，我们最大化结果的可变性）。虚拟首席技术官Noah Cantor强调了较短反馈循环的影响，称“有” 许多学术研究和行业研究表明，反馈周期越长，人们就越少从中学习。相反的情况也是如此 - 反馈周期越短，人们就越能从中吸取教训。“

有许多方法可以确保您在Agile中拥有较小的批量大小和较短的周期时间。最基本的方法之一是将用户故事分成适合迭代的片段。有许多方法可以减少故事大小，如下图所示。减少故事大小的一个关键方法是将功能拆分为单个用户故事或任务。

切片和拆分用户故事时，确保不创建与组件相关的团队非常重要，而是坚持以功能特征为主的团队。垂直切片用户故事而不是水平切片。也就是说，查看端到端功能而不是应用程序的特定层。

小批量和短周期时间也是DevOps的关键。Gene Kim，Jez Humble和Patrick Debois在“DevOps手册”中花了很多时间。DevOps的第一种方式清楚地说明了这一概念，其重点是从左到右增加产品流量。通过使用精益工具（例如价值流映射），可以识别瓶颈并将其移除以增加对客户的价值流。

此外，这些较短的循环时间是DevOps第二和第三种方式的关键。与敏捷一样，缩短周期时间意味着价值更快地传递给客户，因此团队可以获得更快的反馈。这使实验成为可能，允许团队快速发布客户的功能或变更，并根据反馈快速适应。

在DevOps中缩短周期时间和缩小批量周期的关键之一是持续集成（CI）和连续部署（CD）管道。这是CI / CD是DevOps的关键元素的原因之一。通过持续集成，不断对变更进行合并和验证，从而使整个产品始终具有可交付性。持续部署可确保产品始终处于可部署状态，从而可随时将价值交付给客户。这两种实践采用了最初在Scrum和两周发布周期等敏捷方法中引入的快速开发和交付，并将其进一步降低到每天甚至每小时。在2009年的Velocity，John Alspaw和Paul Hammond发表了他们的演讲，“每天10+部署：Flickr的开发和运营合作” 这启动了现在嵌入在DevOps中的许多CI / CD概念。如今，Netflix，谷歌，亚马逊等公司每天都要部署数千次。

使工作可见

可见性是DevOps和Agile中的另一个关键因素。对于Scrum和Kanban等敏捷实践，这通常采用董事会的形式来共享信息。DevOps利用这些实践，但也扩展它们以共享有关系统在任何给定时间的执行情况的信息。这可以采用信息散热器，大型可见仪表板和共享仪表板的形式。

虽然敏捷宣言没有规定让工作可见的必要性，但这些概念的基础是这些概念的基础。“宣言”强调“个人与互动”和“客户合作而不是合同谈判”和“响应变革而不是遵循计划”，所有这三项都通过使工作可见而得到加强。

敏捷开发了“信息散热器”的概念，这是位于敏捷开发团队附近的大型图表，显示了整个开发周期的工作进度。Alistair Cockburn在2000年创造了“信息散热器”一词，并在他2001年出版的“ 敏捷软件开发”一书中介绍了它。

多米尼加·德格兰迪斯在她的着作“ 让工作可见：揭露时间盗窃以优化工作和流动”中谈到了这一点  。她清楚地说明了如何通过使工作可见，我们可以轻松识别瓶颈并改善整个系统的工作流程。

Scrum和Kanban的做法利用了公共板来显示工作进度，这些进度流经一系列步骤，这些步骤被定义为公共板顶部的列。通过为团队提供可视化工作的方法，他们使团队能够一起工作。这些板还有助于快速识别瓶颈。

这个概念明确地符合Gene Kim的第一个DevOps原则，即启用流程。DevOps团队经常使用Scrum和Kanban板来使他们的工作可见。协同工作，开发和操作可以使用这些来确保跟踪所有工作。此外，通过在敏捷团队中集成操作和安全实践，他们可以确保将工作票包含在非功能性工作中。这种非功能性工作可能包括使系统更易于维护，安全或稳定的工作，这些要求经常被功能集中的团队忽视。

DevOps专注于放大反馈回路和广播运营信息的第二种方式是一种很好的方法。这可以包括Scrum板，但它还可以包括有关系统性能，用户体验以及性能基础的代码和基础架构性能的实时数据。这些散热器可以包括在整个建筑物的战略位置张贴的大型监视器。

DevOps手册专门用于遥测的主题。在他们的章节“创建遥测以实现查看和解决问题”中，他们写道：“我们的目标是将这些信息传播给组织的其他人，确保任何想要了解我们正在运行的任何服务的信息的人都能得到它......通过快速，易于获取和充分集中化遥测，价值流中的每个人都可以分享现实的共同观点。“

Pearson Education是一家专注于在线教育的出版公司，实施了一项名为“Monitors Everywhere”的计划。在该计划中，每个团队都有一个共享监视器，他们的任务是显示与团队相关的关键数据。这些数据的范围从代码提交频率到数据库锁，以及根据团队对客户服务台的调用次数。

Etsy是一家以其DevOps思想领导力而闻名的工艺电子商务公司，在工作可见的空间中也做了大量工作。在他着名的博客文章“衡量一切，衡量一切”伊恩马尔帕斯写道，“如果Etsy的工程学有宗教信仰，那就是图形教会。如果它移动，我们会跟踪它。“事实上，当Etsy搬进他们新的环保办公室时，他们甚至有一个传感器并报告了建筑物屋顶雨水蓄水池的水位。这产生了许多好处，并有助于实现Etsy所倡导的持续部署方法。Patrick McDonnell谈到了在DevOps手册中监控部署数据的好处说，“通过这样做，我们可以更快地看到任何意外的部署副作用。我们甚至开始在办公室周围放置电视屏幕，这样每个人都可以看到我们的服务表现如何。“

持续学习

敏捷和DevOps都在其核心原则中有持续学习，在敏捷中，这个概念是敏捷宣言的一部分，并且在诸如回顾之类的关键实践中很明显。在DevOps中，它是在诸如无可指责的事件事后死亡之类的实践中实施的第三种DevOps方式的一部分。

敏捷宣言强调“响应改变而不是遵循计划”，因此，建立了一个强调适应需要的宗旨。在这种适应中，假设团队正在反思和改进。随着敏捷持续的短周期，团队能够审查事情的进展情况，并对他们提供的产品及其用于交付产品的流程进行快速调整。此外，“客户协作超过合同谈判”的宣言原则意味着紧密的反馈循环，倾听和从客户反馈中学习。在Agile中，产品团队可以快速向客户提供功能，并快速学习现实反馈和这些功能的使用，以便他们快速调整课程。

DevOps还强调持续学习。DevOps的第三种方式侧重于持续学习。在IT革命网站上，Kim写道，“第三种方式是创造一种培养两种东西的文化：持续的实验，冒险和从失败中学习; 并且理解重复和练习是掌握的先决条件。“

敏捷和DevOps都有实践，这些实践编纂了持续学习和不断实验的精神。在Scrum中，回顾过程被纳入流程中，以确保团队花时间反思每一次迭代，从错误中吸取教训并庆祝成功。回顾会是团队反思上一次迭代并寻找改进领域的会议。小组讨论什么进展顺利，哪些进展不顺利，并列举需要改进的领域。通过这种方式，回顾性实践建立了持续学习和持续改进敏捷。

Sprint演示是敏捷过程中持续学习的另一个很好的例子。许多敏捷团队在每次迭代结束时都会对sprint交付项进行演示。这些允许团队成员相互学习，更好地了解产品的所有部分。Sprint演示还可以加入参与sprint演示的项目利益相关者的快速反馈。这种做法使团队有机会反思成功，相互学习，并提供建设性的反馈，以继续发展和学习。

在DevOps中，通过诸如事故后事件等实践强调了持续实验和持续学习的原则。John Allspaw帮助启动了无可指责的事后概念，这是DevOps实践的一个共同组成部分。在他撰写的Etsy博客，Code as Craft的博客文章中，他写道，“通过以一种关注失败机制的情境方面和接近失败的个人决策过程的方式调查错误，组织可以来如果它只是简单地惩罚所涉及的行为者作为补救措施，那么通常会更安全。“Allspaw强调，验尸后最重要的事情不是可以采取的一系列行动，而是组织学习。

在Etsy他们不仅没有责备事件，他们实际上是在庆祝失败。庆祝失败的原因之一是犯错误的人实际上是最好的工程师。这些人正在为业务做出最大的改变并推动创新。因此，重要的是不仅要限制责备，而且实际上要将庆祝失败的文化习惯灌输为学习的机会。Etsy凭借他们的三个武装毛衣奖来做到这一点。由CTO颁发的Etsy alum颁发的着名奖项旨在庆祝今年最大的失败。通过灌输诸如无可指责的故事和失败的庆祝等习惯，DevOps可以鼓励一种对讨论失败并不断学习和成长的文化。

嵌入式运维的专业化与“全栈”工程师的兴起

在许多方面，将QA嵌入到Agile方法的产品团队中，与在DevOps中的开发团队中嵌入运维的需求相似。

在瀑布式中，许多组织分为不同的开发和QA团队。质量保证和开发团队也经常受到竞争目标的驱动，质量保证团队专注于软件质量，开发团队专注于功能交付的速度。这种划分与开发和运营的组织划分没有什么不同。在这些组织中，开发和运营也是由单独的目标驱动的，运营侧重于稳定性，而开发侧重于特征速度。随着敏捷的发展和成熟，越来越明显的是QA必须在整个开发过程中参与其中。除此之外，质量需要成为每个人工作的一部分。为了避免冗长的交接和单独的QA周期，Agile将QA集成到团队中。同样，我们现在看到DevOps中的一个动作，即在整个开发生命周期中参与运营团队或运营思维。

有许多不同的组织结构用于构建跨职能团队。有些组织不再拥有单独的QA团队，而是将QA嵌入到每个团队的职责范围内。其他公司在每个团队中都有专门的QA人员。其他公司拥有一个专门的质量保证团队，作为标准持票人，确保质量保证实践和工具在整个组织内保持一致。然而，它是有组织的，需要明确划分职责，以便将质量保证真正纳入每个团队的交付周期的一部分。

同样，我们看到运营中的专业化和整个堆栈工程师的崛起正在受到侵蚀。自2012年以来，对全栈工程师的需求一直在稳步增长，这体现在对全栈工程职位的要求越来越高。就像敏捷团队认识到需要将QA整合到每个人的工作中一样，我们现在看到越来越需要整合运营。对于小型的敏捷团队，通常不可能拥有专门的网络工程师，数据库工程师和存储工程师，因此解决方案是找到对所有这些组件和应用程序有深入了解的人。

将质量保证整合到开发团队和整合运营之间的相似之处使我们能够从组织开发和QA团队中汲取经验教训，以实现敏捷交付。最终，目标是通过消除专家团队并将角色和职责纳入主要团队来减少交接。这导致了“你构建它，你运行它的心态”，你必须将质量和可维护性嵌入到软件开发和工程中。

关键差异

虽然敏捷和DevOps具有重要的一致性，但重要的是要注意它们的重点不同。Agile主要关注应用程序的构建，而DevOps则将这一重点扩展到包括构建和运营应用程序。DevOps采用了敏捷的许多概念，并将这些概念扩展到构建过程之外并进入生产。正是这个扩展定义了真正的差异。

因此，如果存在差异，则主要是关注焦点。Agile Coach的Martin Corbett表示，“敏捷专注于打破工作，以尽快为客户提供更多价值，而DevOps专注于将代码从构建到部署等项目，例如持续部署。”此外， Agile专注于构建工作软件以及开发和QA之间的协作，而DevOps则专注于开发，QA和运营之间的协作。

虽然许多人都在寻找敏捷与DevOps之间的差异，但实际情况是，这两种方法具有非常相似的目标和类似的基础原则，并且最终具有比差异更多的相似性。

DevOps作为敏捷的延伸​​​​​​​

在许多方面，DevOps可以被视为敏捷的延伸，甚至是敏捷的自然演变。在瀑布中，有一个明确的交接（它由流程强制执行）。敏捷作为一个持续的过程，需要一种新的方法，DevOps有助于实现这种方法。

为了实现精益和敏捷最佳实践的核心小批量发布，您需要找到一种方法来减少切换并使发布到生产中变得简单无缝。出于这种必要性，自然会出现许多DevOps实践。在DevOps中普及的全栈工程师的概念是这种需求的自然答案。为了减少切换，工程师必须意识到系统的所有部分，以便团队中的任何成员都能理解和集成QA，安全性和操作要求，而无需交付给其他团队。同样，跨职能团队必须成为常态，以便小型，独立的团队可以提供功能齐全的产品，而无需向运营团队进行额外的交接。

此外，Agile的持续流程需要一定程度的构建和部署自动化。其中大部分都是在DevOps的CI / CD实践和工具中提供的。CI / CD需要允许快速部署经过全面测试和功能齐全的代码给客户。因此，再次很容易看出CI / CD是敏捷实践所必需的自然演化。这些实践继续发展，使发布周期时间进一步缩短，从数周到数天甚至数小时。

从另一个角度考虑这个问题，如果你有一个两周的QA周期，只有在开发完成后才能开始，那么在一周或两周内完成代码是非常困难的。同样，如果您需要等待一周的时间来获取变更批准和发布资源，或者在更糟糕的情况下等待数月的硬件购买和安装，则很难在一两周内将代码排除在门外。如果你有很多切换，那么很难成为敏捷。如果你有一个漫长而繁琐的变更管理流程，那么很难成为敏捷。如果你有一个漫长的繁琐的释放过程，那么很难成为敏捷。你怎么能做两周的迭代并有两个月的发布过程？对此的明显答案是DevOps。

这并不是说没有DevOps就无法实现敏捷。敏捷在DevOps之前很久就存在，并且肯定有敏捷团队不遵循许多DevOps实践。正如Noah Cantor所说，“你可以互相做敏捷实践和DevOps实践。你不能做的是采用敏捷原则或DevOps原则，因为它们太相似而不能分开。“并不是说它们是不可分割的，只是敏捷是一个自然的前身并激发对DevOps的影响。

结论

精益一直是DevOps的核心，就像敏捷从精益生长出来一样，DevOps也是如此，所以这两者有很大的共同点并不奇怪。在2015年的DevOps状态中，作者表示，“当您将精益管理实践应用于技术时 - 限制在制品（WIP）; 引入视觉显示以监控质量，生产力和WIP; 并使用监控数据来帮助决策 - 您可以获得结果。文化变得更具生成性和绩效导向; 人们在工作场所的压力减轻; 并且IT性能得到改善。“

DevOps采用Agile中建立的概念，并将其扩展到代码部署之外。DevOps采用这些概念并将其应用于应用程序和服务的管理。通过利用敏捷原则，DevOps可以扩大它们，增加使用Agile的组织已经认识到的好处。

并不是说为DevOps做DevOps，或者因为你正在做敏捷而做DevOps。已经证明DevOps实现可以产生结果。2017年DevOps状态报告显示，高性能DevOps团队的部署速度提高了46倍，交付时间缩短了44倍，更改失败率降低了5倍，平均恢复时间缩短了96倍（MTTR）。在具有成熟DevOps实践的组织中，这些数字被低估了。

当我们查看Agile和DevOps重叠的每个区域时，DevOps放大了敏捷实践，我们希望您可以采取一些具体步骤来推动您的组织发展。构建协作的最关键步骤之一是共同目标的制定。通过共享目标，您可以确保开发，运营，质量保证都一致并朝着同一目标努力。

小批量规模为推动DevOps实践加速组织提供了另一个绝佳机会。在Scrum或Kanban等流程中，我们希望将操作任务和操作思想集成到您的工作中。如果您正在使用Scrum，您可能还希望转移到Kanban，这可以更容易地适应操作流程。

无论您使用哪种方法进行小批量交付，您都可能希望确保使用相同的系统来跟踪整个团队的工作。通过统一跟踪系统，您可以确保不创建积压工作，并且确实反映了所有计划内和计划外工作。这还可以让您更轻松地使您的工作可见。作为敏捷的一个关键原则，我们可以扩展使工作可见的概念，以显示操作工作以及系统操作和支持结构的工作。通过实施信息散热器以跨团队分享这些信息，组织可以大踏步前进。

当您着眼于构建更具协作性的文化时，您还可以确保在不断学习和实验的过程中灌输最佳实践。有一些优秀的开源工具，如Chaos Monkey，可以帮助您插入错误，以便您可以强制失败，从中学习，并构建更具弹性的系统。作为其中的一部分，您还必须确保建立一种文化，将每一次失败都视为组织学习的机会。在你的文化中建立仪式，例如无可指责的事后训练，黑客马拉松和失败奖励，可以成为灌输学习和实验文化的好方法。

我们在本文中讨论的重叠有组织含义。在DevOps中将敏捷和操作中包含QA意味着我们必须开始构建跨职能团队并培养具有广泛知识的人员。这种重叠随着“全栈工程师”的概念而发展。虽然每个人都知道一切的想法可能不太现实，但我们当然可以努力确保团队中的每个人都分担了涉及质量和操作的责任和目标，如果他们对这些事情负责，也在学习。

有许多方法可以采用敏捷原则并使用DevOps扩展它们，但最重要的一个方法是组织文化的一致性。如果团队从根本上不符合目标，那么在Agile中编写的团队方法将无法扩展到部署到运营之外。实现这一目标的最佳方法之一是确保目标和目标的一致性。如果所有技术交付团队都遵循相同的愿景，目标和目标，您将立即开始打破这些组织之间的孤岛。如果我们可以通过敏捷开始打破组织孤岛并通过DevOps扩展这项工作，我们将采取措施确保我们拥有真正高绩效的组织。