您能否提供一种可以减轻瀑布模型缺点的方法？
最佳答案
Waterfall的问题在于它由整体阶段组成，每个阶段都位于前一个阶段。因此，在设计完整个系统之后，将代码分块进行开发，而这又是在收集并签署了所有需求之后发生的。
这是一个问题，因为任何更改都必须通过复杂的过程来批准，并贯穿所有阶段。但是历史的教训是:变化在发生。在我们开始编码时，需求始终是不完整的，或者是错误指定的，或者只是过时的。太多的设计和建造都是基于假设进行的，当系统进入UAT时，这些假设将无效。这导致疯狂的返工和延误。
事实是，没有多少客户擅长于构想工作软件系统所需的抽象思维。太多的IT专业人员缺乏理解业务逻辑所必需的经验。瀑布拒绝接受这些真理。
唯一诚实的要求规范是“看到后就会知道”。因此，至关重要的是尽快使实际用户面前的工作软件。任何侧重于在短迭代中逐步交付工作软件的方法都将“减轻瀑布模型的缺点”。
最初是RAD或DSDM。然后XP举起横幅。现在有Agile和相关的东西，例如Scrum和Kanban。
那么，为什么人们坚持使用Waterfall方法？
人们普遍认为，敏捷只是牛仔黑客的掩饰，可以抛弃所有无聊的过程内容，并继续他们最喜欢的东西:编写代码。 “极限编程”的烙印无疑鼓励了这种想法，老实说，这并不是毫无根据的指控。就是说，有些编码员伪装成敏捷的借口，没有计划，设计或记录文档。这并不能反射(reflect)敏捷的实际实践，而实践需要与其他任何方法一样严格。
此外，敏捷还需要客户的员工投入更多的时间，许多组织都不愿接受这些时间。同样，付账的人可能不愿授权其下级员工做出决定。客户和用户之间有重要区别。
当涉及外包时，瀑布模型为将可交付成果与分期付款匹配提供了一个简单的框架。的确，契约(Contract)方面可能比这更强大:在欧盟，要求瀑布对所有值(value)1亿欧元或以上的项目都强制执行。
最后，有些项目瀑布效果很好。这些项目具有稳定的知识 Realm ，客户和开发人员都对此 Realm 很了解。
最后一个单词
尽管失败，但Waterfall还是成功交付了许多项目。这是因为努力，才干和诚信比方法更重要。