如何通过DevOps实践来增强敏捷开发
2022-11-02
来源：BuildRun低代码开发平台 作者：Christopher&Sean
如果您曾经对敏捷或DevOps的历史、结构、原则或好处有过疑问，那么您将在这篇文里找到答案，本文被拆分两部分，上半部分主要介绍敏捷和DevOps的历史、差异和好处。
敏捷和DevOps从表面上看可能是不同的，但如果关注他们的目标，会发现它们其实非常相似。两者的目标都是更快地为客户创造价值并更快地改变市场需求。DevOps采用敏捷中介绍的原则，并将其扩展使用到代码以外的部署和运维操作中。
敏捷和DevOps的目标是一致的，因此在实践过程中会发现它们有所重叠。在许多方面，DevOps和敏捷的交叉关系到协作文化以及从这种文化中产生的现代技术实践和过程。连续测试和小批量生产等过程中更容易看到了这一点，在使工作尽量可见化的过程中，公开工作流和系统遥测，有助于确保向客户快速交付工作产品，能加速向客户传递价值。
敏捷和DevOps专注于提供客户价值，这不是为了提供更多功能，而是为了尽可能快速有效地向最终客户提供正确的增值功能。DevOps使用敏捷的概念并对其进行了扩展延伸，因此您可以通过实现DevOps实践来增强敏捷性。
一、什么是DevOps？什么是敏捷？
在开始研究DevOps和敏捷之间的关系之前，首先要对这些术语的含义有一个共同的理解。虽然有许多定义，但它们可以从根本上理解为一套原则，从中可以衍生出工程师文化和实践。
敏捷的存在时间比DevOps长，定义也更为成熟。首次定义于2001年2月的《敏捷宣言》，该宣言包含了以下几条定义：
个人和交互重于流程和工具
工作软件重于公共文档
与客户协作重于合同谈判
响应变化胜过遵循计划
尽管已经有了对DevOps宣言的尝试，但还没有哪一个宣言能够获得敏捷宣言所具有的那种广泛接受度。作为一个一般概念，DevOps重视协作，特别关注开发和运营团队之间的交叉功能以及这两个方面的责任。敏捷教练Anthony Gardiner说，“我测试，我编码，我部署，我在周末起床并修复错误——我让我的代码更好，所以我不必在周末起床。”DevOps可以被认为是一种为客户提供价值的方法，专注于协作和小批量，聚焦持续集成，自动化，持续测试和持续交付。
虽然没有单一的定义，Gene Kim、Kevin Behr和George Spafford在他们的开创性书籍《凤凰计划》中介绍了DevOps的“三种方法”。这三种方法是许多DevOps实践的核心。
Kim后来在《DevOps Handbook》中对这些方法进行了扩展，他与Jez Humble和Patrick Debois合著了这本手册。
这三种方法包括：
二、历史
追溯到20世纪90年代，敏捷已存在的时间比DevOps长得多，后者在将近20年后才出现。然而，这两套原则都源于精益制造，其历史可以追溯到20世纪40年代。虽然DevOps的流行度持续增长，但敏捷仍然比DevOps更广为人知。谷歌趋势表示“敏捷”一词的搜索量大约是“DevOps”一词的三倍。
敏捷的根源可以追溯到20世纪40年代的精益流程，其中包括看板，一种可视化丰田生产系统一部分工作流程的方法。限制理论也是后来发展起来的。然而，敏捷的软件开发方法在20世纪90年代真正起步，当时一群软件开发人员常受到瀑布式开发方法中涉及的高度严格的流程的困扰。这些常导致软件项目花费了数月甚至数年才导致失败。在20世纪80年代和90年代，诞生了几种软件迭代开发方法作为瀑布方法的替代，包括极限编程（XP）和看板。1995年，引入了敏捷开发的Scrum实践。然后，在
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
-
延伸阅读：
-
