我已经阅读了很多关于敏捷和瀑布的信息，我想不出今天有人应该做瀑布的任何理由。我特别关心测试过程。我是否错过了什么，是否有一些我忽略的明显优势？
在某些情况下，瀑布是合适的。 典型示例包括军事、太空、医疗和安全关键系统，例如飞行控制软件，您绝对需要首先精确详细地确定规格，开发它，然后彻底测试整个产品。
敏捷适用于大多数业务和产品软件（即大多数构建的软件），因为它允许用户从一个粗略的想法开始，并随着他们的发展而完善它。 如果他们的网站或内部业务线应用程序在几次迭代中不太正确（或有错误），那么它通常会被从工作位快速交付的业务价值所抵消。 您不会想从核电站控制器系统的粗略想法开始，并在此过程中对其进行完善。
使用纯瀑布的代价是，在这些场景中开发软件的成本要高出几个数量级。 然而，成本效益仍然是有利的，因为你无法承受（比如）你的航天器在进入轨道的中途击中一个零指针异常。
当然，两者之间有灰色阴影。 可以在瀑布框架中使用敏捷技术（参见RUP），并且可以在纯瀑布和纯敏捷之间放大和缩小平衡。
瀑布式开发模型的主要优点之一是它已经使用了多年来开发。 它有效。 尽管敏捷有很大的转变和关注，但瀑布是一个非常清晰的过程，每个开发部分都有起点和终点。
随着敏捷编程的引入，很容易看到瀑布的下降以及它如何不适应当今的编程需求。
只要你小心谨慎，提前计划并充分测试，我会说敏捷测试可以和瀑布一样有效，甚至更有效 - 当测试抛出一些可能导致设计更改的错误时，使用敏捷当然更容易。
要考虑的另一件事是使用测试驱动开发进行开发。 http://en.wikipedia.org/wiki/Test-driven_development
外包
我看到许多公司坚持使用瀑布式的外包项目。 大多数供应商在报价方面会非常具体。 瀑布非常适合这种模型 - 你交出你想要的东西，他们生产它。 我不喜欢这个，但我可以理解以这种方式执行的原因。 我认为大多数外包公司最终会找到一种方法，使其变得更加敏捷，因为它越来越符合行业标准。
问题的答案取决于您为项目使用哪种开发方法。是敏捷的/是瀑布吗/等等。在过去的三到四年里，我一直参与只涉及敏捷或瀑布的项目，所以将他们作为我的参考点。如果项目的需求不断变化，我们永远不应该进行瀑布式设计，因为瀑布式方法假设设计/分析/等已经完成，而如果我们追求敏捷，它基于增量方法，我们将项目划分为增量故事和构建/测试， 因此，如果需求发生变化，开发人员和测试人员的返工并不多。例如，假设我们必须创建四个新网页作为我们项目的一部分，然后瀑布假设他们的设计等已经完成，一旦所有四个页面都开发完毕，测试就会开始，而如果敏捷发生，我们首先开发一个页面并将其交给 QA 进行测试 [手动/自动化]， 等等。因此，我们可以看到敏捷为我们的项目增加了价值，除了在开发时发现功能缺陷/错误之外，它不会使其容易受到需求变化的影响。