使用DevOps强化敏捷|一文读懂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合著了这本手册。

这三种方法包括：

二、敏捷和DevOps的历史

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

敏捷的根源可以追溯到20世纪40年代的精益流程，其中包括看板，一种可视化丰田生产系统一部分工作流程的方法。限制理论也是后来发展起来的。然而，敏捷的软件开发方法在20世纪90年代真正起步，当时一群软件开发人员常受到瀑布式开发方法中涉及的高度严格的流程的困扰。这些常导致软件项目花费了数月甚至数年才导致失败。

在20世纪80年代和90年代，诞生了几种软件迭代开发方法作为瀑布方法的替代，包括极限编程（XP）和看板。1995年，引入了敏捷开发的Scrum实践。然后，在2001年Snowbird山度假村的著名会议上，一群思想领袖齐聚一堂，共同编写敏捷宣言。敏捷发展至今，其中许多变化和实践都是从最初的宣言演变而来的，包括现代敏捷。虽然敏捷制定了总体原则，但实践敏捷原则的方法有很多，Scrum和看板是最受欢迎的两种（关于他们的区别，可阅读Kanban VS Scrum：哪个是最好的敏捷项目管理框架）。

DevOps是一套更为新的原则，它源于精益制造中的一些相同概念。“DevOps”一词于2009年首次推出，当时Patrick Debois在比利时举办了“Devopsdays”活动。2013年，Gene Kim（作者），Kevin Behr（作者）和George Spafford（作者）撰写了他们的书《凤凰计划》，其中提出的许多内容构成了DevOps的基础概念。2014年，随着DevOps企业峰会的启动，DevOps不断扩展到企业环境中。今天，DevOps继续与敏捷一起成长和发展。

三、DevOps与敏捷的关键差异

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

如果说存在不同，那么主要在于聚焦点的不同。敏捷教练Martin Corbett表示，“敏捷专注于分解工作，以尽快为客户提供更多价值，而DevOps专注于将代码从构建扩展到部署的项目，例如持续部署。”此外，敏捷专注于构建工作软件以及开发和QA之间的协作，而DevOps则专注于开发、QA和运营之间的协作。

四、DevOps是敏捷的延伸

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

为了实现精益和敏捷最佳实践的核心小批量发布，在DevOps中普及的全栈工程师的概念是这种需求的最佳答案。为了减少交接，工程师必须悉知系统的所有部分，以便团队中的任何成员都能理解操作要求，而无需交付给其他团队。同样，跨职能团队必须成为常态，以便小型，独立的团队可以提供功能齐全的产品，而无需向运营团队进行额外的交接。

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

从另一个角度考虑，如果您有一个只有在开发完成后才能开始的为期两周的QA周期，那么在一两周内就很难将代码推出。同样，诸如变更审批、释放资源、硬件购买和安装等需要耗费时间的事情，都会影响你按时推出代码。更不用说，您可能还有很多的交接工作，或者有一个周期长又繁重的发布过程。如何进行为期两周的迭代并进行为期两个月的发布过程？对此的明显答案是DevOps。

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

五、DevOps与敏捷的好处

精益一直是DevOps的核心，就像敏捷是从精益中生长出来的一样。DevOps也是如此，所以这两者有很大的共同点并不奇怪。DevOps采用Agile中的概念，并将其扩展到代码部署之外。DevOps采用这些概念并将其应用于应用程序和服务的管理。它利用并优化了敏捷的原则，并且沿用了敏捷组织早已意识到的长处。

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

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

小批量交付为推动DevOps实践加速组织提供了另一个绝佳机会。在Scrum或看板等流程中，要将操作任务和操作思想集成到工作中。如果您正在使用Scrum，您也可以考虑使用看板，它更容易适应操作流程。

无论使用哪种方法进行小批量交付，您都可能希望确保使用相同的系统来跟踪整个团队的工作。通过统一跟踪系统，您可以确保不积压工作，并真实反应所有计划内和计划外工作，让您更容易地使工作可见。作为敏捷的一个关键原则，我们还可以扩展使工作可见的概念，以显示运营工作、系统操作和架构支持等工作。组织还可以通过信息辐射体（比如看板）跨团队分享这些信息。

当您着眼于构建更具协作性的文化时，要把每一次失败都当作组织学习的机会。在这个文化中建立一些仪式，比如无可指责的事后反思、黑客马拉松和失败奖励等。

对于本文中讨论的重叠，存在组织上的含义。在敏捷和DevOps中包含QA意味着我们必须开始构建跨职能团队，并培养具有广泛知识技能的人员。这种重叠是随着“全堆栈工程师”的概念而发展起来的。虽然每个人都知道一切可能不现实，但我们当然可以努力确保团队中的每个人都有共同的责任和目标，包括质量和运营，如果他们乐于负责和学习的话。

有许多方式可以采用敏捷原则并使用DevOps强化它们，但最重要的是组织文化的一致性。如果团队在目标上没有保持一致，那么敏捷中规定的团队方法将不能扩展到部署以外的操作中使用。如果所有技术交付团队都遵循相同的目标，即可立即开始打破这些组织之间的孤岛。如果我们可以通过敏捷开始打破组织孤岛并通过DevOps强化这项工作，我们将拥有真正的高性能组织。

六、敏捷和DevOps的共性

6.1 协作文化

敏捷和DevOps之间的核心共性之一是他们都强调打造协作文化。这两种方法都着眼于打破壁垒，增加成员共同责任感。通过打破隔离，DevOps和Agile减少了交接，提高了向客户交付的速度。DevOps将这种协作概念扩展到了运维团队中，而敏捷关注QA是否包含在内。

在敏捷中，我们看到协作文化直接融入到了敏捷宣言的核心原则中。第一个定义“个人和交互重于流程和工具”明显地表达了合作的需要。此外，第三个原则，“客户协作重于合同谈判”，强调需要将这种协作扩展到开发团队之外，也扩展到客户当中。

敏捷教练Susan McIntosh在她的文章《敏捷心态到底是什么》中提到，“敏捷心态是一种支持敏捷工作环境的态度。其中包括尊重、协作、改进和学习反馈、对归属的自豪感、专注于提供价值以及适应变化的能力。这种心态对于培养高绩效团队是必要的，而这些团队反过来又为客户带来了惊人的价值。”

在敏捷中有许多协作的例子，诸如结对编程、Mob编程和Swarming等实践都允许更大的团队合作开发软件，虽然这与开发的原概念相悖（开发原本是指由一个单独的程序员单独完成的任务）。此外，敏捷工作还将QA无缝链接到流程中，作为团队任务的一部分。

RonLichty表示：“我将通过Scrum中的产品所有者角色将产品管理集成到团队中。PdMs向开发人员“越过墙”抛出需求的历史由来已久，这与开发人员向测试人员“越过墙”抛出代码的历史没有太大不同！”RonJeffries写了他在极限编程中处理故事的方法。Atlassian建议通过使用单页仪表板缩小PRD（产品需求文档）来保持需求的精简。

DevOps的许多基本概念也是围绕协作的概念构建的。事实上，这个可以追溯到早先反对将开发、运维和QA分割之时。DevOps运动的基础之一，正是人们认识到开发、运维和QA彼此独立会导致利益冲突、增加交接成本。

Thoughtworks的首席科学家Martin Fowler指出协作在DevOps中扮演重要角色，他认为，“DevOps文化的主要特征是增加了开发和运维角色之间的协作……开发和运维之间不应该存在壁垒。”和从一开始就一起工作解决问题相比，切换周期和文档是一个糟糕的替代品。调整资源结构，使运维人员能够尽早参与到团队中来是很有帮助的。

另外，建立协作文化的一个关键方法是在所有参与交付的团队之间制定共同的目标。使开发、运维和QA之间在明确的目标上保持一致，并将重点放在客户需求和最终交付上。

DevOps鼓励协作的另一种方式是将运维活动集成到Sprint中。这可以通过在Sprint中加入运维团队成员来实现，甚至更好的方法是，将运维职责分给所有Sprint团队成员。

除了交付特性和“功能”之外，在高性能的DevOps组织中，通常还向交付产品的团队提供维护这些产品的职责。一旦系统的稳定性得到证明，它就会移交给另一个团队进行维护。其他公司包括开发团队，作为操作问题的寻呼机轮换的一部分。这就产生了共同的责任，并加强了共同的目标和责任。当然，DevOps不是一份工作，它不是一个角色，也不是任何一个人或团队的责任。DevOps的核心是协作，这与敏捷宣言中的原则保持一致。

6.2 小批量、短周期

小批量和短周期是敏捷化的关键。通过减少对系统的更改，敏捷可以更快地为客户带来价值。这种快速部署能带来快速反馈，客户或用户可以快速查看已开发的内容，团队能在必要时快速调整路线。

这与瀑布式方法形成了鲜明的对比，在瀑布式方法中，客户可能要等上几个月甚至几年才能看到交付成果，只有到那时才能确定产品是他们所想的还是所要的。DevOps采用小批量的概念，并通过持续集成和持续部署（CI/CD）对其进行扩展。CI/CD提供的工具链加速团队对客户的价值，将周期从几周缩短到几天甚至几小时。

小批量是精益的关键。起源于20世纪30年代的精益为敏捷和开发人员提供了一些核心基础，它专注于消除浪费和减少批量，减少正在处理的工作量，从而减少等待下一个阶段处理的库存量。

这一概念与敏捷的核心原则相呼应，敏捷的核心原则规定“经常交付产品，从几周到几个月，优先选择较短的时间段。”小批量和较短的周期时间有很多好处。根据DonReinersen的说法，为了让产品开发增加价值，结果必然会有不确定性。我们不应该试图最小化失败，而应该接受可变性。我们可以通过有效地学习和高效地生成信息来减少不确定性。

VirtualCTO官诺亚•坎特（Noah Cantor）强调了短反馈循环的影响，“有很多学术研究和行业研究表明，反馈周期越长，人们从中学习的知识就越少。反之亦然——反馈周期越短，人们可以从中学习的越多。”

有很多方法可以确保你在敏捷中拥有小批量和较短的周期时间。最基本的方法之一是将用户故事分割成适合迭代的片段。减少故事的规模很多，比如将功能拆分为单个用户故事或任务等。

当划分和拆分用户故事时，重要的是确保您不创建合成型团队，而是坚持使用功能团队。垂直而不是水平地拆分用户故事。也就是说，观察端到端的特性，而不是应用程序的特定层。

小批量和短周期也是DevOps的关键。DevOps的重点是从左到右增加产品流。通过使用精益的工具（如价值流图），可以识别瓶颈并消除它们，从而增加对客户的价值流。

此外，较短的循环时间是DevOps第二和第三种方法的关键。与敏捷一样，更短的周期意味着价值能更快地传递给客户，因此团队可以更快地获得反馈，以便能快速向客户发布特性或更改，并根据反馈快速调整。

DevOps中缩短循环时间和I迭代周期的关键之一是持续集成（CI）和持续部署（CD）。通过持续的集成，一些更改会不断地被合并和验证，从而使整个产品始终具有潜在的可交付性。而持续部署会确保产品始终处于可部署状态，允许随时向客户交付价值。这两个实践采用了敏捷方法中最初引入的快速开发和交付，并将其周期进一步减少到每天甚至每小时。

6.3 工作可视化

可视化是DevOps和敏捷中的另一个关键元素。对于像Scrum和看板这样的敏捷实践，通常采用板的形式来共享信息。DevOps利用并进一步扩展了这些方法，来共享系统在某一特定时间内的执行情况，这可以通过大型可视仪表盘和共享仪表盘的形式等展现。

虽然敏捷宣言并没有规定工作可视化的必要性，但是概念是实践的基础。宣言强调“个人和交互重于流程和工具”和“客户协作重于合同谈判”以及“响应变化重于遵循计划”，这三个方面都能通过工作可视化而得到加强。

敏捷促成了“信息辐射源”概念的发展，这是一种位于敏捷开发团队附近的大型图表，能显示整个开发周期的工作进展。Alistair Cockburn在2000年创造了“信息辐射源”这个术语，并在他2001年出版的《敏捷软件开发》一书中做了介绍。

工作可视化能直接暴露出时间的缺漏，以优化工作和流程。通过为团队提供可视化工作的方法，使团队能够一起工作更加方便，这些板还帮助快速识别瓶颈。

DevOps的第二种方法集中于增强反馈和共享操作信息，这是一种很好的方法。这可以包括Scrum板，也可以包括关于系统性能、用户体验以及代码和基础结构性能的实时数据。这些信息图表就像在整个建筑的战略位置张贴的大型监视器。

在DevOps手册，作者还用了整整一章的篇幅来讨论遥测的问题。他们在他们的“创建遥测技术以发现和解决问题”一章中写道，“我们的目标是将这些信息辐射到组织的其他部门，确保任何想要我们正在运行的任何服务的信息的人都能获得这些信息……使价值流中的每个人都可以实时共享信息和提出观点。”

Etsy是一家以DevOps思想领导能力闻名的工艺电子商务公司，在工作可视化的领域也做了很多工作。“如果Etsy的工程有宗教信仰，那就是图形教会。”Patrick McDonnell在DevOps手册中谈到了监控部署数据的好处，他说：“通过这样做，我们可以更快地看到任何意外的部署副作用。我们甚至开始在办公室周围安装电视屏幕，以便每个人都能看到我们的服务表现。”

6.4 持续学习

敏捷和开发人员的核心原则中都有持续学习。在敏捷中，这个概念是敏捷宣言的一部分，在DevOps中，它是DevOps的第三种方法的一部分。

敏捷宣言强调“响应变化而不是遵循计划”，因此，它构建了一个强调适应需求的原则。在这种适应性中，假设团队不断的反思和改进，在持续的敏捷短周期中，团队便能够审查事情的进展情况，并对他们交付的产品和交付过程进行快速调整。此外，“客户协作重于合同谈判”的宣言宗旨意味着严格的反馈循环、倾听和从客户反馈中学习。在敏捷中，产品团队可以快速地向客户交付功能，并快速地从实际反馈中学习和快速调整。

DevOps也强调持续学习，其第三种方法便聚焦于此。在IT革命网站上，Kim写道：“DevOps第三种方法是创造一种能促进两件事的文化：一是持续实践、冒险和从失败中学习；二是理解重复和实践是精通某件事的先决条件。”

同时，敏捷和DevOps都把不断学习和不断实验的精神付诸实践。在Scrum中，有被置于流程中的回顾会，用以确保团队花时间对每一次迭代进行反思、从错误中学习并总结成功的经验。回顾会是团队对前一次迭代进行反思并寻找改进的会议，小组成员会讨论哪些进展顺利，哪些进展不顺利，并列举需要改进的方面。

Sprint演示是敏捷流程中持续学习的另一个很好的例子。许多敏捷团队会在每次迭代结束时对Sprint可交付成果进行演示，这样可以让团队成员互相学习，更好地理解产品的所有部分。Sprint演示中还能加入项目涉众的快速反馈，为团队提供了一个互提意见和互相学习的机会，帮助大家继续成长。

在DevOps中，不断学习和不断实验的精神通过事故事后分析等行为得到了强调。JohnAllspaw帮助推出了事后无指责概念，之后这成为了现在DevOps实践的一个共识。他在博客中写道：“事后总结最重要的事情不是一系列可以采取的行动，而是组织学习。”

在Etsy，员工不仅毫无责备地看待事件，甚至还庆祝失败。庆祝失败的原因之一是犯错误的人实际上是最好的工程师，这些人是那些为企业做出最大改变和推动创新的人。因此，重要的不仅仅是限制责备，实际上还灌输了一种文化习惯，这种习惯将庆祝失败视为学习的机会。Etsy的CTO每年会颁发一个很有声望的奖项，以庆祝今年最大的失败。DevOps通过灌输诸如无指责事后分析和失败庆祝等习惯来鼓励一种开放讨论失败并不断学习和成长的文化。