开始介绍第三章内容，第三章主要讲DevOps的几个组件或者叫概念。在本章中，我们想与你讨论与DevOps相关的一些主要概念：敏捷，精益和itope。本小节与Agile相关，与DevOps相关。 Patrick Dubois和Andrew Clayshafer参加了多伦多的Agile 2008大会。在会议上，Andrew提出了一个关于敏捷基础设施的会议。Patrick是唯一到场出席的。他们谈到安德鲁在明年第二次参加Velocity会议上的敏捷基础设施。
然后在2009年晚些时候，Patrick在他的家乡比利时根特开始了一个新的小型开放空间基地会议。他召集了Dev Ops Days会议，有效地创造了DevOps这个术语并开始了DevOps运动。我在2010年1月在奥斯汀的一个名为Ops Camp的活动中听说过John Willis和Damon Edwards，他们正在跑步，每个人都在谈论这个名为DevOps的新事物。由于Dev Ops的历史源于敏捷，所以让我们谈谈它。您可能已经熟悉敏捷了。
敏捷软件开发的宣言是由一群软件开发人员于2001年编写的，他们对当前的软件开发状态不满意。他们认为越来越多的官僚机构和流程正在分层到项目上，希望能取得更有效的结果，但结果往往相反。是的，之前的软件开发方法称为瀑布式，这是因为它将软件从一个阶段移动到另一个阶段。首先，您完全完成所有要求并记录下来，然后将它们扔到墙上（服务器）进行编码，然后对其进行编码。然后他们把它扔到墙上给QA测试它然后他们把它扔到墙上给那些发版工程的人然后如果它是一个服务它被扔到另一个墙上进行操作，听起来很痛苦。在敏捷开发中，这个过程是多次迭代的。对，而不是试图预先完成每个阶段，它强调开发团队和客户之间灵活的协作，围绕工作软件的频繁内部交付。这可以快速生成解决方案，更好地满足客户需求，减少挥之不去的质量问题。
敏捷已经证明了它的好处。第1版的第10个年度敏捷调查报告显示，85％的敏捷团队已经看到了提高的生产力。 80％的受访者表示上市时间更快。敏捷的批评者认为，由于它更快，更具协作性，因此它必须是草率和随意的。是的，但实际上我们看到反过来是正确的。敏捷团队还报告了81％的案例中更好的交付可预测性，并在79％的案例中提高了软件质量。
了解敏捷是一项重大的努力。图书馆有各种各样的书籍，可以帮助您了解更多有关敏捷的知识。如果您已经阅读了敏捷宣言中的原则，那么您将看到缺少的内容：任何提及操作的内容。确切地说，敏捷谈论工作软件，但将系统管理员带入产品团队，但是他们并不习惯。此外，宣言没有提及软件交付管道的最后部分，其中包括构建基础架构，并且在生产中部署和维护了应用程序。
实际上，一开始，敏捷被IT组织中的基础设施方面视为威胁。我必须确信开发经理并不疯狂。而且我非常确信我自己和我的运营团队一起尝试过，而且效果很好。从那时起，我使用Agile运行各种操作和混合DevOps团队，我永远不会回去（瀑布模型）。DevOps与Agile完全一样吗？ 你可以在没有敏捷的情况下练习DevOps，反之亦然，但它可以并且坦率地说可能应该被实现为敏捷的扩展，因为DevOps在敏捷方面有如此强大的根源。
网上自己搜索下敏捷宣言内容。作者的DevOps宣言和敏捷宣言对比，大概就是这样：把敏捷中软件，换成系统。敏捷中主要是开发人员，DevOps需要把运维添加进来。加上结果指导开发DevOps之旅的坚实基础这点。正如我们在下一个节看到的，DevOps不仅仅是敏捷的算法，它归功于精益软件。
