Waterfall软件开发方法仍然可行吗？

根据我的经验，似乎瀑布模型已被证明过于僵化且对需求变化不敏感，因此在现代软件开发领域中不被视为可行的方法。更加敏捷，迭代的方法的发展和经过证明的往绩似乎表明，没有理由为什么任何人都应该遵循从项目开始到产品交付几乎没有改变的刚性过程。

在时间，成本和质量方面，瀑布式开发方法对于提供软件系统是否仍然可行？

您所引用的瀑布模型从未打算成为实际项目中使用的过程模型。相反，它是一个稻草人。它确定了软件项目中存在的关键阶段和活动以及它们之间的最基本流程。这种过分简化的软件开发方法是有缺陷的，甚至是通过这种方式提出的。

从维基百科文章：

温斯顿·罗伊斯（Winston W. Royce）在1970年的文章中经常引用瀑布模型的第一个正式描述，尽管罗伊斯在本文中并未使用“瀑布”一词。罗伊斯（Royce）将此模型作为有缺陷，无法正常工作的模型的示例进行了介绍。

讨论的论文标题为“ 管理大型软件系统的开发”。在其中，Royce确实在第二页上展示了该模型。但是，紧接图示下方的文字继续显示为：

我相信这个概念，但是上述实施方式存在风险，并且会导致失败。

他在此之后讨论了开发阶段“完成”之后的测试问题，以及此处的故障如何导致重大的重新设计和代码更改，以及这些故障如何导致成本和进度超支。在整篇论文中，他将原始模型改进为在项目上确实可行的模型。最后，他以一个模型进行了介绍，该模型引入了原型设计，客户交互和人工制品的改进-这些思想最终对于1990年代末和2000年代初开始的敏捷运动至关重要。

回答您的问题：您正在询问的Waterfall从来都不是一种可行的方法，可以按时间和预算交付具有合理质量的软件项目。但是，还有其他计划驱动的方法与敏捷相反，它们可以并且确实可以在项目上工作。

人们不使用教科书瀑布模型，而且可能永远不会使用。

这是一种理想的理论构造，其目的是使您思考系统开发中的步骤。主要要点是，您希望尽早进行较大的更改，因为一旦构建了很多代码，您将没有时间或金钱进行较大的更改。

尽管事实上它更多是一种思考方式而不是过程，但实际上，它仍然是许多企业（可能是大多数组织）去构建软件（或房屋，潜艇或其他任何东西……）的方式。

在现实世界中，您在各个阶段之间没有完全严格的界限，有时您会回到小型子项目的先前阶段。方法论告诉您的不是“不允许这些事情”。它告诉您的是“这些事情花费了您的金钱和/或时间”-因此，请避免在将来避免这种情况。

对Agile Snobs（TM）低头看待“老式”开发人员及其古怪，不可行的瀑布方法，这一切都很好，但事实是，敏捷也不是灵丹妙药。有些项目无法使用敏捷来构建，许多团队认为他们是敏捷的，但实际上只是草率而没有组织。

方法论不是重点。关键是要考虑自己在做什么，为什么要那样做 -并在最短的合理时间内为客户带来最大的价值。

人们通常不将神话般的瀑布过程与敏捷过程进行比较，因此不能认为它是死的。真正的瀑布式流程仍然有效，并且在按时交付符合用户期望的预算软件方面表现出色。

询问您正在做什么的一种更好的方法可能是，“何时不那么迭代，而更形式化地更好”？

在某些情况下是这种情况：

• 要求不变时。

• 满足新的要求比达到原始要求的100％重要。

• 当所有技术组件都成熟并得到充分理解时。

从某种意义上说，您可以采取相反的措施，使自己变得敏捷。

很少有技术适用于任何地方。很少有没有用。

是的，它仍然非常活跃，尽管今天使用的是更常见的“ V模型 ”。

在这两种情况下，敏捷都存在的问题是解决方案几乎永无止境，客户可以继续请求更改，而开发将继续迭代解决这些更改。对于基于时间和材料成本的项目，此方法非常有效。对于具有固定成本的项目，没有。

对于这些固定成本的项目，客户几乎总是希望预定义的里程碑可以显示进度，但是，这些更多是正式的书面形式，而不是工作代码。对于这样的客户，书面规格成为项目，而软件开发是次要考虑的项目（因为他们认为，如果您有一个定义明确的项目，则软件应该易于开发）。这些公司也是大量使用廉价的外包开发资源的公司。

因此，如果您有固定的金钱或时间，不要期望需求会改变或不允许改变任何需求，并且期望提供大量的书面文档，那么瀑布模型是唯一的选择合理。

可以在这些项目的中间阶段引入敏捷来进行开发，但是您仍然需要根据需求创建规格的加速阶段，以及现场安装和测试软件的减速阶段。敏捷对这些情况的反应不佳。

给谁？我所处理的大多数经理仍然使用Waterfall Software Dev Process进行调度，并且上级似乎更喜欢它以便进行调度。

实际上，我所知很少的开发人员相信它可以工作甚至是有效的。