在我们开始之前，先看看这张信息图是如何庆祝六年来软件开发实践从瀑布式到新的 DevOps 和敏捷方法的历史性迁移。
“软件”一词从何而来？
“软件”一词是 1953 年由 19 岁的 Paul Niquette 创造的，他在 UCLA 编写了标准西方自动计算机 (SWAC)，这是全美国仅有的 16 台数字计算机之一。
当我第一次大声说出“软件”时，我周围的人都说，“嗯？” 从一开始我就觉得这个词太不正式了，写起来也很尴尬。 尽管如此，我还是怀着忐忑的笑容偶尔在演讲、讲座和媒体采访中提到“软件”这个词
瀑布模型
随着计算机的普及，Winston Royce 博士的瀑布模型（1956 年）指导公司如何以最短、最有效的方式生产软件。
1976 年，Bell 和 Thayer 在一篇期刊文章中引入了这种逻辑分层系统，随后美国国防部于 1985 年对其 DoD 软件开发提供商进行了标准化。
瀑布模型的六个阶段
初步设计
详细设计
发展
单元测试
一体化
测试
该模型至今仍在使用，最适合可以从其严格的阶段和截止日期中受益的大型项目和组织。
螺旋模型
1986 年，Barry Boehm 将瀑布模型与迭代过程结合在一个他称为螺旋模型的系统中。
模型的四个阶段中的每一个阶段都以设计目标开始，以客户审查结果结束。 每个阶段也有其特定的任务。
螺旋模型最适合大型复杂的不可预测的项目。
Frederick P. Brooks 在他 1975 年出版的《人月神话》一书中指出，从另一个切线来探讨软件开发，“增加更多的人会延长而不是缩短时间表。”
Brooks 紧随其后发表了一篇名为《没有银弹——软件工程中的本质与意外》的文章，认为由于没有任何一个软件是完全没有错误的，我们需要软件开发方法来开发简单可靠的软件。
Scrum 框架
同年，也就是 1986 年，Takeuchi 和 Nonaka 引入了“Scrum”一词，他们说这是一种组织知识创造的方法：
“在当今快节奏、竞争激烈的商业新产品开发世界中，速度和灵活性至关重要。”
Scrum 框架建议软件开发从“橄榄球”方式转变为“接力”方式。 中继软件开发方法使用传统/瀑布方法，一组将过程传递给下一组。
相比之下，橄榄球模型在球队作为一个整体在球场上移动时“传球”。 最后一个速度更快，并且具有更多的自主性和稳定性。
SCRUM 开发流程
三年后，Schwaber 和 Sutherland 在各自的软件开发公司中引入了“Scrum”。 1995 年，Schwaber 和 Shuterland 发表了概述 Scrum 方法的 The SCRUM Development Process。
尽管 Scrum 相对容易理解，但新用户可能会发现 Scrum — 及其价值观、角色、事件和工件 — 很复杂
Rational 统一（软件）过程
一年后，IBM 的 Rational 软件公司创建了 Rational 统一（软件）过程（RUP），将 Scrum 的软件项目生命周期分为四个阶段。
每个阶段都包含所有六个核心开发规程，而某些过程比其他过程受到更多关注。
到目前为止，创新者主要考虑的是大中型公司。 1999 年，肯特·贝克 (Kent Beck) 撰写了他的书《极限编程解释》(Extreme Programming Explained)，专为在模糊和不断变化的软件开发需求中苦苦挣扎的小型企业而写。
该书介绍了软件处理的敏捷革命，据说 Scrum 的协作敏捷性优于瀑布框架的刚性。
敏捷宣言
2001 年，17 名软件开发从业者聚集在犹他州的一个滑雪胜地滑雪放松。 在业余时间，他们编写了敏捷宣言，其中包含四个价值观和 12 条原则，以实现更敏捷的软件开发过程
“通过这项工作，我们开始重视：(1) 个人和互动高于流程和工具； (2) 工作软件优于综合文档； (3) 客户协作优于合同谈判，以及 (4) 响应变化优于遵循计划”
后来，罗伯特“鲍勃大叔”马丁在他于多伦多举行的敏捷 2008 主题演讲中添加了第五个价值，称为：“Craftsmanship over Crap”。
精益软件开发
您想要更好、更快、更便宜的软件开发吗？ Mary 和 Tom Poppendieck 在他们 2003 年出版的《精益软件开发》一书中确定了七个基本的“精益”原则，这些原则可以适用于软件开发领域。
这些原则中的每一个都已经彻底改变了制造、物流和产品开发。 它们可以应用于软件开发价值、流程和程序开发人员。
开发运维
与此同时，沮丧的 Beligan 顾问 Patrick Debois 通过他的演讲开发并推广了 DevOps 一词。
DevOps 只是意味着开发部门（创建代码的部门）和运营部门（使用该代码的部门）之间的跨部门集成。
当然，它远比这复杂，而且它对软件开发和部署的影响是巨大的。 通过统一开发和运营，DevOps 为每个人创造了参与的机会。
看板
最后一个影响是大卫安德森 2010 年出版的书看板。 Less 软件方法论，如来自日本的 Scrum、看板，告诉您如何持续改进您的软件功能、产品或服务。
通过这种方式，它的方法既可以应用于像 Scrum 这样的敏捷模型，也可以应用于像迭代过程这样的传统模型。
那现在把我们留在哪里？
自 Paul Niquette 创造“软件”以来，我们已经走过了漫长的道路。 首先，软件开发生态系统——现在已集成到 DevOps 中——已经获得了一系列工具，从 Dockers 到 Kubernetes、Puppets、Chef 和 Ansible。
至于软件生产的最佳方法，敏捷框架在很大程度上取代了传统模型，这些结构帮助团队按时计划、管理和交付软件。
其中最受欢迎的是规模化敏捷框架 (SAFe)、大规模 Scrum (LeSS)（单团队 Scrum 的规模化版本）和纪律敏捷交付 (DaD)。
期待更多具有变革性未来的发展。
