持续交付与敏捷开发的历史

Posted 2021-04-25 老布谈敏捷

正文共3557字4图，阅读时间：9分钟

编辑 | Dishayen

图片来源 | Twenty20

软件中的“持续交付”不仅仅是一个热门话题。

软件的持续交付是软件开发实践和客户保留的圣杯，这也是DevOps今天是如此热门的概念的原因。要了解持续交付的重要性，你需要了解敏捷的历史以及敏捷方法的来源。

敏捷软件开发的历史并不是从敏捷宣言开始的。

首次出现危机

在20世纪90年代初期，随着PC计算机开始在企业中激增，软件开发面临危机。当时，它被广泛称为“应用程序开发危机”或“应用程序交付滞后”。业内专家估计，经过验证的业务需求和实际生产中的实际应用之间的时间大约为三年。

问题是，即使在25年前，企业的迁移速度也比这更快。

在三年的时间里，需求、系统甚至整个业务都可能发生变化。这意味着许多项目在中途取消，许多已完成的项目并不能满足企业当前的所有需求，即使项目的最初目标已经达到。

在某些行业，滞后时间远远超过三年。在航空航天和国防领域，在一个复杂的系统投入实际使用之前可能需要20年或更长的时间。在一个极端但绝非例外的例子中，1982年开始运营的航天飞机计划使用了20世纪60年代以来的信息和处理技术。高度复杂的硬件和软件系统通常是在数十年的时间范围内设计，开发和部署的。

思想领袖感到沮丧

上世纪90年代，航空航天工程师乔恩科恩因为这些漫长的交付时间以及早期做出的决定而变得越来越沮丧，该项目后来无法改变。“我们正在寻找更加及时和反应迅速的产品，”他指出，越来越多的人认为必须有更好的软件构建方式。

他是17名软件思想领袖之一。

他们开始非正式会面并讨论如何更简单地开发软件，而没有当时瀑布和其他流行软件工程技术的过程和文档开销。

其他行业也在进行转型。设计一款新车需要六年或更长的时间，而在九十年代，这一时间几乎减半。AT＆T已经被打破，所谓的“小贝尔”正在大幅降低手机和服务的成本。

敏捷诞生了

2001年初，在犹他州举行了着名的Snowbird会议，这些看似非生产性的软件开发活动受到志同道合的专业人士的共同欢迎。但这并不是这一群软件领导者第一次见面。他们在2000年春天在俄勒冈州的Rogue River Lodge收集了一年前的资料。

这个团队包括Kern，极限编程先驱Kent Beck和Ward Cunningham，Arie van Bennekum，Alistair Cockburn和其他十二位，今天在敏捷社区都很有名。作为一种实践，敏捷并不是最终的目标。实际上，在那个时代之前，“敏捷”尚未用于正式谈话。在那次会议上，“轻”和“轻”这些术语更为常见，但没有一个参与者对这种描述特别满意。

特别是，这些思想领袖想方设法快速构建工作软件并将其交付给最终用户。这种快速交付方式提供了一些重要的好处。首先，它使用户能够更快地获得新软件的部分商业利益。其次，它使软件团队能够迅速反馈软件的范围和方向。

快速反馈和改变意愿成为敏捷运动的关键特征。

如果软件团队对理解用户需求没有把握，那么它会提供第一个近似值，然后收听反馈。但是在项目开始的时候几乎没有什么可以做的。

对重量级过程的反弹

敏捷决不是批判在20世纪70年代和80年代开发的开发方法，是以回应软件早期经常使用的混乱和无计划的方法。事实上，从1970年到1990年，软件工程的基础理论和实践应运而生。这个想法是将软件工程和物理工程等同起来，并尽可能地从设计和建筑实际中借用。

这种方法表现在已知的瀑布方法中。这种方法明确定义了从需求到部署的应用程序开发生命周期的主要阶段。它被称为“瀑布”，因为团队完成了一步，然后再进入下一步。在继续进行功能设计之前，必须完成要求，在详细设计之前完成功能设计，等等。就像没有上坡的水一样，很少有条件返回到过程的早期阶段。一旦你完成了一个阶段，那个阶段就会被及时冻结。

这种方法给软件开发带来了组织和工程实践的感觉。但是有一个关键的区别。民用或机械工程项目在十年或更长时间内很少发生变化。如果你今天需要设计一座桥梁或一座高层建筑，很可能在一两年内不需要修改细节。

事实上，最初设想的瀑布应该适应项目决策的变化和重新考虑。可以回到前一阶段，调整一些决策和期望，这些改变可能会改变目前阶段的各个方面。但在实践中，时间表和预算几乎总是让人觉得不可能，迫使团队坚持早先的决定。

当时，大多数软件开发团队和大学计算机科学部门都把它作为福音，你花更多的时间计划，花在编写代码上的时间就越少，代码就越好。这只会加强一个流程繁重的方法，比交付工作软件更重视规划和文档。

软件项目很少具有与传统工程项目相同的稳定性。业务需求似乎在一夜之间发生变化，并且肯定比以前完成软件应用所需的几个月或几年更快。回想起来，软件显然需要一种不同的工程方法。

当然，问题的另一个部分是软件设计既是一门科学又是一门艺术，其缺陷和相关的人类局限性。

首先，我们根本不知道如何很好地定义软件。用户可以描述他们的业务工作流程，但是他们无法告诉软件设计师哪些功能会自动化以及这些功能应该如何工作。在开始构建产品之前，我们无法精确定义需要什么，将软件工程与大多数其他工程学科分离开来。

其次，从需求到原来的不完美，规范，从规格到实施的翻译都充满了含糊不清。其中一些来自文字的性质; 如果一个声明可能会被误解，那么它几乎肯定会是。但是，由于团队正在设计层面阅读并将其转化为实施层面，所以必然会出现错误和误解。

从业者想要迭代开发

同时，更具体的迭代方法正在开发中。例如，Jeff Sutherland和Ken Schwaber在20世纪90年代初期构思了Scrum过程。这个词来源于橄榄球，并提到了一个朝着共同目标努力的团队。为了在德克萨斯州奥斯汀的面向对象会议上展示它，他们在1995年编写了Scrum。他们以标题为“SCRUM软件开发过程”的论文形式发布了它。

Scrum的基础是这样一个概念，即对于开发新的复杂产品，当小型自组织团队获得目标而不是具体任务时，会产生最佳结果。团队可以自由决定实现这些目标的最佳方式。Scrum还定义了时间盒迭代开发周期，其目标是提供工作软件。今天，大多数宣称采用敏捷方法的团队都表示他们正在使用Scrum。

大约在同一时间，Kent Beck被聘为克莱斯勒实验软件开发项目的顾问。最终，他被任命为项目负责人，为了取得成功，他决定将最佳实践推向极致，并以XP方法论为名。尽管克莱斯勒收购后该项目最终取消，但贝克出版了一本名为“ 极限编程解释 ”的书，并且他的名字成为了领先的替代方法之一的代名词。

也许各种敏捷和迭代技术仍然是少数派，但它不适用于2001年在Snowbird会议上编写的敏捷宣言（Agile Manifesto）。尽管这个小组的目标不明确，但宣言是与当时仍然普遍存在的瀑布模型相反的方法的最明确和最简洁的目的声明。

因此，软件开发社区已经将敏捷宣言及其12项原则锁定为敏捷软件开发运动的明确声明。今天，越来越多的团队自我认定为使用敏捷方法。尽管这些团队中的很多人可能使用包含若干敏捷方法和瀑布元素的混合模型，但他们完全认同敏捷运动的特征，证明了声明的强度和运动的力量。

敏捷、超越

尽管敏捷将我们带到了现实的位置，但并不是故事的结束。有超越敏捷的生活，虽然敏捷是必要的第一步，看看软件开发可能能够冒险的地方。尽快要求我们的头脑可以看到需要软件更改可能是愚蠢的，但尝试加快速度并不愚蠢。敏捷概念能否促进我们软件的持续有效变革？我们是否可以达到软件“发布”及其所有改进的目标不再是计划的事件，而只是像呼吸一样每天，每小时或每分钟发生一次？

但是他所描述的内容毫无疑问。他对软件向生产发布的趋势进行了表述，并讨论了能够每季度，每月，每周发布新版本以及最终每日甚至连续发布新版本的意义。“如果我们不知道该功能是否正确，”他指出，“我们提供了两个版本，让用户决定。” 正如我们今天可以说的，这是持续交付的一个缩影，或DevOps。

敏捷流程是朝这个方向迈出的必要的第一步，但持续交付需要更大的改变。这意味着开发人员根据他们的最佳知识尝试某些东西，但却完全准备根据用户的反应立即删除或更改它。

用户的反应并不是以言语的形式出现，而是以行动的形式出现。

我们监视生产中的应用程序并收集用户行为的数据。实时分析这些数据可以告诉团队接下来要做什么。接下来发生的事情不会超过一两天。

 END