methodology - 什么是瀑布模型的替代方案

Question

您能否给出一种可以减轻瀑布模型缺点的方法？

Answer 1

Waterfall 的问题在于它由单体阶段组成，每个阶段都在前一个阶段。因此，在设计了整个系统之后，代码是在一个块中开发的，而这又是在收集并签署了所有需求之后发生的。

这是一个问题，因为任何更改都必须通过复杂的程序批准并在所有阶段进行。但历史的教训是:变化发生了。当我们开始编码时，需求总是不完整的，或者错误指定的，或者只是过时的。设计和构建过程常常基于假设，当系统进入 UAT 时，这些假设就无效了。这会导致疯狂的返工和滑点。

事实是，没有多少客户擅长设想可工作的软件软件系统所需的那种抽象思维。太多的 IT 专业人员缺乏理解业务逻辑所需的经验。瀑布拒绝接受这些事实。

唯一诚实的需求规范是“我看到就知道了”。因此，尽快将可运行的软件呈现在真实用户面前是至关重要的。任何专注于在短迭代中以增量方式交付工作软件的方法都将“减轻瀑布模型的缺点”。

原来是RAD或 DSDM .然后 XP举起旗帜。现在有Agile和相关的东西，如 Scrum和 Kanban .

那么为什么人们坚持使用瀑布方法呢？

有一种普遍的看法，即敏捷只是牛仔黑客的掩护，他们抛弃所有无聊的流程内容，继续他们最喜欢的事情:编写代码。 “极限编程”的品牌肯定鼓励了这种想法，而且，老实说，这并非毫无根据的指控。也就是说，一些程序员假装敏捷作为不计划、设计或记录的借口。这并不反射(reflect)敏捷的实际实践，敏捷需要与任何其他方法一样严格。

敏捷还要求客户的员工投入更多的时间，这是许多组织不愿意接受的。此外，支付账单的人可能不愿意授权他们的初级员工做出决定。客户和用户之间有一个重要的区别。

在外包方面，瀑布模型提供了一个简单的框架，用于将可交付成果与分阶段付款相匹配。事实上，契约(Contract)方面可能比这更强大:在欧盟，所有值(value) 1 亿欧元或以上的项目都必须使用瀑布。

最后，有些项目的 Waterfall 效果很好。这些项目具有稳定且为客户和开发人员所熟知的知识领域。

最后一句话

尽管失败，瀑布已经成功交付了许多项目。这是因为努力工作、才能和正直比方法论更重要。