也许，从运营的角度来看，最可怕的软件开发方法之一可能对小公司再次有意义。

肯施瓦伯——Scrum 的联合创始人和 Scrum.org 的创始人——说瀑布“真的毁了我们的职业”。 “它让人们被视为资源，而不是有价值的参与者。”预先完成了如此多的计划，员工变成了车轮上的一个齿轮。

瀑布式开发模式起源于制造业和建筑业；高度结构化的物理环境意味着设计更改在开发过程中很快就会变得非常昂贵。当首次用于软件开发时，基于知识的创造性工作没有公认的替代方案。

问题

构建软件程序的努力是众所周知的。尽管与其他所有类型的工程相比，软件的发展速度相当快，但没有可以在半秒内编译和处理我们的工作以将结果显示在计算机屏幕上或将其暴露在可交互层上的花哨和快速的机器.必须用程序的所有逻辑对纸板进行打孔。只有这样，机器才能读取一盒穿孔卡片。打字错误通常意味着重新打孔整张卡片。

当然，回想起来这听起来很痛苦，而且确实如此！需要几个专业人员来运行一个简单的编译。有些人只负责在盒子里整理卡片。这不是一项非常专业的工作，但必须有人去做。为了降低这种繁琐操作的成本，Waterfall 发挥了作用。如果事先做好计划，就不需要整天安排大量高度专业化的专业人士坐着打卡。这非常有效。可以避免许多错误，并且开发程序所需的时间更少。

向前走

众所周知，组织在采用新概念方面的缓慢跟不上机器的发展。越来越多的硬件资源变得更容易和更便宜地访问，程序编译不再需要与计算机进行物理交互，网络在全球范围内被发明和实施，使开发人员能够在任何地方分享知识。

在如此快速和协作的环境中，瀑布不再有意义。任何人都可以在您舒适的家中拥有一台机器并编写甚至有时会动摇已知市场实践基础的破坏性程序。投入数月的计划，编写数百页（通常是书籍）的需求文档和图表开始听起来是压迫性管理的不必要步骤。必须做出改变。

旧与新

近年来，许多人都将敏捷作为组织内部软件甚至非软件开发过程的核心和必须遵循的方法论。普遍的心态是，它是所有问题的答案。无论在哪个部门，涉及什么/谁以及性质是什么，都会有一个适合您的敏捷框架。

每个组织都是独一无二的，并面临着各种内部因素（即规模和当前结构）和外部因素（即客户和商业模式）。在按照敏捷宣言创建新框架以满足各种不断出现的问题的需求方面已经做了大量工作。简单性来自这样一个事实，即它是一组遵循并根据您的需求调整的原则。没有万能的解决方案。每个部门都有自己的角色、问题、流程、人员和技能。哪种组合对团队有利将取决于内部和外部因素、需求和目标。

在敏捷环境中，与瀑布式方法相比，团队之间的协作更加频繁，后者编写文档然后传递给下一个。每个被问到的问题都只是用一个简单而懒惰的“阅读文档”来回答。受到对未来愿景的启发，或者只是整理了房间里每个人似乎都很常见的糟糕经历，敏捷宣言变得栩栩如生。对于每一种好的方法，只有一个目标很重要：解决问题。

（旧）新问题

在当时（90 年代、00 年代），谁负责构建一个好的软件产品几乎没有区别。大部分工作在开发人员手中。用户体验本身并不是它自己的东西。显然，它总是存在的，但如果一个产品有很好的接受度，那就有点神秘了。用户界面设计被视为不重要，并呈现出一些可怕的结果。

然而，今天，您可能需要几个具有不同技能的人来构建并保持市场上具有竞争力的产品。 UX/UI 设计师、产品经理（及其变种）、后端开发人员、前端开发人员、移动开发人员、基础设施专业人员等（在这里看到一个模式？）很明显，对更多人员、不同职位的需求正在增加日。

更重要的是，大型科技公司开始变得绝望。没有足够的专业人士来满足他们的需求。在十年（2001-2011 年）中，工资增长高达 35%，最后一个增长高达 47%，具体取决于地区。软件危机时代会再次发生吗？

Waterfall 的主要目标是降低开发阶段（实际代码编写）的成本。薪水如此之高，而且缺乏可用的专业人士，预示着提前计划的卷土重来。小公司不能仅仅与大科技公司的薪水竞争，并让专业人士“更快地犯错”。

你怎么看？在实际执行之前进行计划是否值得？还是每个人都应该使用试错法？也许两者兼而有之？在下面留下您的评论。

这不是方法论之间的比较。我只是指出行业历史的模式、动机以及他们试图解决的运营和技术问题。

谢谢阅读！

一些精彩的评论：

评论1：

瀑布和敏捷有根本的区别。 瀑布基本上是一种适用于软件开发的问题解决方法。 敏捷是围绕以原型设计为导向的方法论编织的一堆愿望（宣言），它已经过度扩展成为现在的时尚。 随着时间的推移，它已经与诸如“计划快速失败”之类的破坏性口号联系在一起。

瀑布从不严酷或可怕。 它的“缺陷”被夸大了，只是为了让敏捷看起来不错。

正如您所说，重要的是，瀑布是关于将思考放在首位，并为整个过程提供一个正式的结构，以鼓励（重）可用性并插入运行组织的传统方式 - 规划、成本会计、项目管理等。敏捷可能会占有一席之地 ，但是当它很重要时，或者正如你所说的那样，当公司不能继续更快地犯错时，瀑布是解决方案。 瀑布是迭代的，但有一个整体的计划和结构。

评论2：

当然，瀑布项目有一席之地。在一个不复杂（non-complex）但复杂（complicated ）的世界中，结果是可以预测的。我们可以知道，“如果我们这样做，将会发生以下情况。”在我们重复自己的情况下，重复做同样的事情。那么瀑布式方法是一个不错的选择。

在复杂的（complex ）世界中，我们或客户不可能事先知道一切，结果无法预测，我们需要在知道之前学习。然后我们需要另一种方法。一种实验性的方法，我们可以随时做出决定并尽可能晚地做出这些决定。敏捷已成为这些复杂情况的一种解决方案。

当今的数字和网络物理系统通常属于复杂（complex ）类别；我们不可能知道会发生什么，当我们有更多的知识时，我们想做出迟到的决定，并且随着我们的进展获得更多的理解。

我们不会经常两次构建相同的软件。所以我认为任何一种系统的开发通常都不会落入复杂的范畴。但是，为客户安装软件系统可能需要多次完成，虽然很复杂（complicated），但并不复杂（ not complex），我们可能会使用瀑布方法。

说了这么多，我还想强调一下，敏捷并不意味着我们不应该计划。在敏捷宣言中，我们说：“响应改变胜过遵循计划。”关键字结束了。我们仍然需要计划；但是，我们应该计划得恰到好处，并尽可能晚地计划，以应对我们和我们的客户在开发过程中获得的知识所带来的变化。

评论3：

我认为您有一个非常好的观点，即随着开发人员时间成本的增加及其上升趋势，任何可以减少这种情况的方法（规划、使用更便宜或更高效的资源来进行规划等）都在进行得到一个强大的外观。

我不确定瀑布是否是这个问题的答案。我不认为敏捷已被证明是正确的。敏捷肯定有好处，但省钱*不是*其中之一。十多年来，我一直在使用低代码/无代码工具，我确信它们是解决方案的一部分，但不是整个解决方案。

我*知道*花时间写一个技术细节用户故事，上面写着“从这个表中获取数据并使用这些条件连接到那个表，像这样过滤，然后在屏幕上填充列表和他们一起……”（即伪代码）在发现用户故事中的漏洞、帮助了解技术困难等等方面走了很长很长很长的路。我认为伪代码在很大程度上是一门失传的艺术，我在开发过程中看到的许多问题都可以通过预先编写伪代码来避免。

评论4：

瀑布的核心问题：您在计划中忘记了一个项目，这将在开发阶段永远困扰您。

敏捷的核心问题：仅仅因为你在彼此之上添加切片（sprint），你不一定会建造一个埃菲尔铁塔，而是建造比萨斜塔（最终会崩溃）。

您需要更广泛的规划和敏捷实施的健康组合

评论5：

应该定义“瀑布方法”的论文是 Winston Royce 的“管理大型软件系统的开发”。有趣的是，本文没有出现“瀑布”一词。它也没有说你必须一步一步地前进，永不回头。事实上，它说的恰恰相反，并清楚地表明，当发现问题时，您需要回到之前的步骤。那么为什么这么多人认为罗伊斯是在提倡“瀑布式”开发呢？我相信有两个原因。首先，人们只阅读第二张图，它列出了软件开发的步骤，并且确实可以作为瀑布来阅读。其次，这篇论文被敏捷的布道者当作稻草人，他们需要一些东西来打败现有的想法。如果人们真的阅读了这篇论文，他们会发现其中没有与敏捷（或敏捷，如果你愿意的话）不兼容的地方。真的是必读。作为另一篇经典论文，Parnas 和 Clements “一个理性的设计过程，如何以及为什么要伪造它”。

评论6：

瀑布一直占主导地位，并且系统地未能创造价值。 瀑布和敏捷之间的核心区别在于，在前者中，问题解决和解决方案实施由不同的人完成，而在后者中，两者都由团队共同执行，利用跨职能技能。 这就是为什么功能团队不是敏捷，而是具有肤浅敏捷构成的瀑布（冲刺、每日站立，...）。 这就是为什么功能团队不是结果而是输出驱动的原因。

评论7：

我认为这里的答案是更加敏捷。 后端和前端开发人员？ 那是一种反模式。 创建一个团队并给他们解决问题。 为解决方案创建验收标准，让团队与客户交谈。 并为团队提供学习他们缺乏的技能所需的资源。

而且，顺便说一句，瀑布从未起作用，并且在首先讨论瀑布的论文中被描述为一种反模式......

原文：https://medium.com/@marcel_paschoal/agile-is-dead-waterfall-is-coming-b…

本文：https://jiagoushi.pro/node/1997