DevOps DNA 分析

瀑布模型、敏捷以及其他开发框架是如何塑造 DevOps 的演进的？以下是我们发现的内容。

cubes coming together to create a larger cube

图片来源：

Opensource.com

如果要分析 DevOps 的 DNA，您会在其血统报告中发现什么？

本文并非方法论评比，因此如果您正在寻找关于软件工程最佳方法的建议或辩论，您可以就此停止阅读。相反，我们将探索使 DevOps 走向当今数字化转型前沿的基因序列。

DevOps 的大部分演变都经历了试错过程，因为公司都在努力响应客户的需求，同时提高质量并在竞争日益激烈的市场中脱颖而出。更具挑战性的是，全球经济正在从产品驱动型经济向服务驱动型经济转型，以新的方式将人们联系起来。软件开发生命周期正变得越来越复杂，服务和微服务相互连接并进行检测。随着 DevOps 比以往任何时候都更快地向前推进，变革的速度正在淘汰较慢的传统方法，如瀑布模型。

我们并非抨击瀑布模型方法——许多组织有充分的理由继续使用它。然而，成熟的组织应力求摆脱浪费的流程。事实上，许多初创公司相对于在日常运营中使用更传统方法的公司而言，具有竞争优势。

具有讽刺意味的是，精益、看板、持续和敏捷原则和流程可以追溯到 20 世纪 40 年代早期，因此 DevOps 不能声称是一个全新的想法。

让我们首先回顾几年，看看瀑布模型、精益和敏捷软件开发方法。下图显示了软件开发生命周期的“单倍群”。（请记住，我们不是在寻找最佳方法，而是试图了解哪种方法对我们 67 年的软件工程经验以及 DevOps 思维模式的演变产生了积极影响。）

图片来源：

单倍群——SDLC 的父系谱系

“愚者手持利器，仍是愚者。” -Mathew Mathai

传统瀑布模型方法

在我们看来，最古老的遗传物质来自瀑布模型，该模型由 Winston W. Royce 博士在 1970 年代发表的一篇论文中首次提出。

与瀑布一样，这种方法强调在单个过程中逻辑且顺序地进行需求、分析、编码、测试和运营。您必须完成每个序列，满足标准并获得批准，然后才能开始下一个序列。瀑布模型方法有利于需要严格的序列、具有详细且可预测的范围以及基于里程碑的开发的项目。与流行的看法相反，它还允许团队在需求、分析和设计阶段进行实验并进行早期设计更改。

精益思想

尽管精益思想可以追溯到 1450 年代的威尼斯军械库，但我们将时钟拨回到丰田创建丰田生产系统的时候，该系统由日本工程师在 1948 年至 1972 年间开发。丰田于 1992 年发布了该系统的官方描述。

精益思想基于五项原则：价值、价值流、流动、拉动和完美。这种方法的核心是理解和支持有效的价值流，消除浪费，并为用户交付持续的价值。它旨在让您的用户在不受干扰的情况下感到满意。

改善

改善基于渐进式改进；计划->执行->检查->行动 生命周期促使公司转向持续改进的思维模式。改善最初是为了改进装配线的流程和过程而开发的，改善概念还在整个供应链中增加了价值。丰田生产系统是改善和持续改进的早期实施者之一。改善和 DevOps 在工作流程从设计到生产的环境中协同工作良好。改善侧重于两个领域

流动
流程

持续交付

改善启发了流程和工具的开发，以实现生产自动化。公司能够通过消除浪费（包括文化和思维模式）并尽可能多地使用机器、软件和机器人技术进行自动化，从而加快生产速度并提高质量、设计、构建、测试和交付阶段。改善哲学的许多方面也适用于精益业务和软件实践以及 DevOps 原则和目标的持续交付部署。

敏捷

敏捷软件开发宣言出现在 2001 年，由 Alistair Cockburn、Bob Martin、Jeff Sutherland、Jim Highsmith、Ken Schwaber、Kent Beck、Ward Cunningham 等人撰写。

敏捷并非不顾一切、抛弃设计或在狂野西部构建软件。它关乎能够创造和响应变化。敏捷开发基于十二项原则和一份宣言，该宣言重视个人和协作、可工作的软件、客户协作以及响应变化。

规范化敏捷

由于《敏捷宣言》已保持静态 20 年，许多敏捷实践者一直在寻找向该方法添加选择和主观性的方法。此外，《敏捷宣言》主要侧重于开发，因此在当今快节奏的开发环境中，尤其需要将重点转向解决方案而不是代码或软件。Scott Ambler 和 Mark Lines 合著了《规范化敏捷交付》和《规范化敏捷框架》，这些书是基于他们在 Rational、IBM 以及团队需要更多选择或不够成熟来实施精益实践，或者上下文与生命周期不符的组织中的经验。

DAD 和 DA 的意义在于，它是一个流程决策框架，可以简化围绕增量和迭代解决方案交付的流程决策。DAD 建立在敏捷软件开发的许多实践之上，包括 scrum、敏捷建模、精益软件开发等。广泛使用敏捷建模和重构，包括通过测试驱动开发 (TDD) 鼓励自动化，精益思想（如看板）、XP、scrum 和 RUP，通过选择五种敏捷生命周期，以及架构师所有者的引入，为敏捷实践者提供了额外的思维模式、流程和工具，以成功实施 DevOps。

DevOps

据我们所知，DevOps 出现在 2009 年在比利时举办的一系列 DevOpsDays 活动期间，并成为众多数字化转型的基础。Microsoft 首席 DevOps 经理 Donovan Brown 将 DevOps 定义为“人员、流程和产品的结合，以实现为最终用户持续交付价值”。

让我们回到最初的问题：如果您分析 DevOps 的 DNA，您会在其血统报告中发现什么？

我们正在审视 80 年、48 年、26 年和 17 年前的历史——在当今快节奏且常常动荡的环境中，这简直是永恒。从本质上讲，我们人类不断试验、学习和适应，从我们的基因链中继承优势并解决弱点。

在显微镜下，我们将发现瀑布模型、精益思想、敏捷、scrum、看板和其他遗传物质的痕迹。例如，对于详细且可预测的范围，有瀑布模型的痕迹；对于减少浪费，有精益的痕迹；对于促进可交付代码的增量，有敏捷的痕迹。定义何时以及如何交付代码的基因链是 DevOps 在我们的 DNA 探索中发光的地方。

您可以使用从观察生产中的解决方案收集的遥测数据来驱动实验、验证假设并确定产品积压事项的优先级。换句话说，DevOps 继承了各种经过验证且不断发展的框架，使您能够转变文化、将产品用作推动者，最重要的是，让您的客户满意。

如果您对精益思想和敏捷感到满意，您将享受到 DevOps 的全部好处。如果您来自瀑布模型环境，您将从 DevOps 思维模式中获得帮助，但您的精益和敏捷同行将胜过您。

eDevOps

2016 年，Brent Reed 创造了术语 eDevOps（迄今为止，Google 或 Wikipedia 上没有相关参考资料），将其定义为“一种工作方式 (WoW)，通过人员、流程和工具，在整个企业中无缝地实现持续改进”。

Brent 发现敏捷在 IT 领域失败了：采用精益思想的企业未能从他们信任的 IT 专家那里获得他们期望的价值、重点和速度。当他看到一座“象牙塔”时感到沮丧，其中孤立的 IT 服务与架构、开发、运营和帮助台支持团队脱节，他应用了他规范化敏捷交付的实践知识，并在 DAD 工具集中添加了一些目标和实际应用，包括