瀑布，敏捷和其它开发框架怎样塑造DevOps的演变？
图片来源：opensource.com
如果分析DevOps的DNA，在其祖先报告中会找到什么？
本文不是方法论，没有关于软件工程的最佳方法的建议或辩论。相反，我们将探索把DevOps带到当今数字化变革前沿的基因序列。
大多数DevOps都是通过反复试验而发展起来的，因为公司一直在努力响应客户的需求，同时提高质量并在竞争日益激烈的市场中脱颖而出。更严峻的挑战是，从产品驱动向以服务驱动的全球经济过渡，以新方式将人们联系起来。软件开发生命周期正成为一个日益复杂的服务和微服务系统，包括互连和检测系统。随着DevOps走得更快更远，更新速度正在抹杀瀑布等较慢的传统方法。
我们不是抨击瀑布式方法——许多组织都有充分的理由继续使用它。然而，成熟的组织应该致力于摆脱浪费的流程，事实上，许多初创公司比在日常运营中使用更传统方法的公司更具有竞争优势。
具讽刺意味的是, 精益、看板、连续和敏捷的原则和流程可以追溯到 20世纪40年代初, 因此 DevOps不是一个全新的概念。
让我们回顾一下几年前，看看瀑布、精益和敏捷软件开发方法。下图显示了软件开发生命周期的“haplogroup”。（请记住，我们并不是在寻找最佳方法，而是试图了解哪种方法对我们67年的软件工程和DevOps思维方式的演变有积极的影响。）
Haplogroup——SDLC父系
“拿着工具的傻瓜还是个傻瓜。”——Mathew Mathai
1.传统瀑布方法
从我们的角度看，最古老的遗传物质来自瀑布模型，由Winston W. Royce博士在上世纪70年代发表的一篇论文中首次提出。
像瀑布一样，这种方法强调依次通过：需求，分析，编码，测试和应用，这几个步骤和顺序来进行。必须在每个序列完成后，满足条件并获得签收，然后才能开始下一个序列。瀑布式方法适用于需要严格序列、具有详细且可预测的范围和基于里程碑的开发的项目。与流行的观点相反，它还允许团队在需求，分析和设计阶段进行实验并进行早期设计更改。
瀑布
2.精益思想
虽然精益思想可以追溯到15世纪50年代的威尼斯阿森纳, 但据丰田于1992年公布的丰田生产系统官方描述，日本工程师在1948年至1972年间开发丰田生产系统时, 就开始使用了精益思想。
精益思想是基于五个原则：价值、价值流、流动、拉动和尽善尽美。这种方法的核心是理解和支持有效的价值流，消除浪费，并为用户提供持续的价值。不间断地愉悦用户。
精益思想
3.持续改善
持续改善基于渐进式改进；计划->执行->检查->行动生命周期使公司走向持续改进的思维模式。持续改善的概念最初是为改善装配线的流程而开发的，它还在整个供应链中增加了价值。丰田生产系统是持续改善和持续改进的早期实施者之一。持续改善和DevOps在工作流从设计到生产的环境中可以很好地协同工作。持续改善集中在两个方面：
• 流
• 过程
4.持续交付
持续改善激发了自动化生产的流程和工具的开发。通过尽可能地消除浪费（包括文化和思维模式）和尽可能地使用机器，软件和机器人技术实现自动化，公司能够加快生产并提高：质量，设计，构建，测试和交付过程。持续改善的许多理念也适用于精益业务和软件实践以及DevOps原则和目标的持续交付部署。
5.敏捷
《敏捷软件开发宣言 》于2001年发表，由 alistair cockburn、bob martin、jeff sutherland、jim highsmith、ken schwaber、kent beck、ward cunningham等撰写。
敏捷 不是抛弃谨慎，放弃设计，或者放任自流地构建软件。是关于能够创造和应对变化。敏捷开发基于十二项原则 和一个宣言，它重视个人和协作，工作软件，客户协作以及对变化的响应。
敏捷
6.规范敏捷
由于敏捷宣言已有20年不变，许多敏捷实践者一直在寻找方法来给它增加选择和主观性。此外，敏捷宣言主要关注开发，因此在当今快节奏的开发环境中尤其需要对解决方案而不是代码或软件进行调整。Scott Ambler和Mark Lines基于他们在Rational，IBM和一些组织的经验，共同撰写了规范敏捷交付 和规范敏捷框架 。这些组织中，团队需要更多选择或者不够成熟到实施精益实践，或者项目环境不适合生命周期。
DAD和DA的意义在于，它是一个过程 决策框架 ，能够围绕增量和迭代解决方案交付来简化过程决策。DAD基于敏捷软件开发的诸多实践，包括scrum、敏捷建模、精益软件开发等等。敏捷建模和重构的广泛使用，包括通过测试驱动开发（TDD）来鼓励自动化，通过选择五个敏捷生命周期使用精益思想（如看板、XP 、scrum 和RUP ）以及架构师所有者的介绍，为敏捷实践者增加了思维模式，流程和工具，来成功实施DevOps。
7.DevOps
据我们所知，DevOps于2009在比利时的一系列DevOps会议中出现，进而成为众多数字变革的基础。微软主要DevOps经理Donovan Brown 将DevOps定义为“人员、过程和产品的联合，以便为最终用户持续地交付价值。”
让我们回到最初的问题：如果分析它的DNA，您会在DevOps的祖先报告中找到什么？
DevOps
我们的研究追溯到80，48，26，和17年前的历史——在当今快节奏和变幻莫测的环境中，那是相对不变和静止的时代。本质上，我们人类不断地实验、学习和适应，继承优势并解决遗传链中的弱点。
显微镜下，我们将找到瀑布，精益思想，敏捷，Scrum，看板，和其它遗传痕迹。例如，有详细和可预测范围的瀑布痕迹，用于减少浪费的精益痕迹，以及用于促进可交付代码增量的敏捷痕迹。定义何时及如何交付代码的基因链是我们DevOps探索中的发光点。
您可以用从生产中观察解决方案而收集到的遥测数据来驱动实验、确认假设以及设定产品待办事项的优先顺序。换句话说，DevOps继承了各种成熟的和不断发展的框架，使您能够转变您的文化，用产品来驱动，最重要的是，让您的客户满意。
如果您对精益思想和敏捷感到满意，您将享受DevOps的全部优势。如果您来自瀑布环境，您将从DevOps思想中获得帮助，但您的精益和敏捷的同行们将会超越您。
8.eDevOps
eDevOps
在2016年，Brent Reed创造了eDevOps概念（至今没被谷歌或*引用），将其定义为“一种通过人、过程和工具无缝地给整个企业带来持续改进的工作方式（WOW）。“
Brent发现敏捷在IT上失败了：采用精益思想的企业并没有实现IT专家预期的价值，重点和速度。沮丧地看到一个“象牙塔”，其中孤立的IT服务与架构，开发，运营和服务台支持团队脱节。他运用规范敏捷交付的实用知识，并给DAD工具集添加了一些目标和实际应用，包括：
• 通过持续改进（持续改善）思想来关注和推动文化，即使人们隔着小隔间也能将他们聚在一起。
• 通过自动化（TDD+重构所有可能的东西），消除浪费，并采用TOGAF 、JBGE（勉强够用）的文档编制方法。
• 通过建模（架构建模）和向左移动来实现价值，通过暴露反模式，同时通过更多功能和战略性的现代数字存储库中的协作模式进行共享
凭借在IBM的AI经验，Brent为eDevOps设计了一个成熟度模型，可以逐步自动化仪表盘，用来进行测量和决策，以便通过持续部署（从开发到生产的自动化）实现持续改进，对任何组织都有切实的可行性。eDevOps在一个基于严格DevOps的有效转型计划中，可实现：
• DevOps的业务（BizDevOps）
• DevOps的安全性 (SecDevOps)
• DevOps的信息 (DataDevOps)
• 松散耦合的技术服务，同时聚集和提升所有利益相关者
• 每两周或更快地构建潜在的消耗品解决方案
• 通过从概念到实时生产使用的DevOps过程，收集、测量、分析、展示和自动化可操作的洞察力。
• 跟随持续改善和规范敏捷方法之后持续改进
9.DevOps发展的下一阶段
DevOps最终是否会被认为是炒作（一个多种技术组合的集合），并被加到本已冗长的流行语名单里？当然，时间将告诉我们DevOps将如何发展。然而，DevOps的DNA必定继续成熟和改进，开发者们必须明白，它既不是灵丹妙药，也不是治愈所有疾病和解决所有问题的补救措施。
DevOps!=敏捷!=精益思想!=瀑布
DevOps!=工具!=技术
DevOps⊂敏捷⊂精益思想⊂瀑布
原文链接：
https://opensource.com/article/18/11/analyzing-devops