瀑布式开发方法的两大基本原则是：
（1）采用阶段式开发：这是产品经理最熟悉的用的最多的方法，即软件开发过程被事先分为固定的几个阶段：撰写书面的需求说明文档，设计高层软件架构，设计底层细节，编写代码，测试，部署。
（2）采用阶段式评审：每个阶段结束后，对该阶段提交的成果进行评审，评审通过后才进入下一阶段。
瀑布式开发使用最广，并且经久不衰的原因：
瀑布式开发的流程具有可预测性，所以比较受管理层的欢迎，只要能准确理解需求和技术，而且需求不再改变，开发团队就能为大规模的项目指定精确的开发计划。并且在每个阶段结束时都会提交书面材料，这会让人比较放心，在一定程度上增强人们对项目的信心。
但是使用瀑布式开发也有缺点：
（1）产品验证严重滞后：产品经理必须要等到软件开发的尾声，才能看到可以运行的软件，也就是说，在投入大量人力和资金之前，软件的可用性无法得到验证。
（2）变更计划价格不菲：在瀑布式开发过程中，任何对前期决策的修改都会打乱开发流程，大量工作需要从头来过，严重延误开发进度。然而产品经理负责跟踪客户和用户的需求，如果需求发生变化，修改产品是不可避免的。
（3）无法适应快速的市场变化：瀑布式开发方法严重依赖文档和流程，即使是一点小小的改动都要花费不少的功夫，这就使产品经理压力倍增，即要尽量确保提交的产品设计通过了验证，没有缺陷，另一方面，产品发布后产品经理仍然提心吊胆，随时准备以最快的速度修补产品。
所以，瀑布式开发方法过于理想化，除非是规模很小的项目，否则瀑布式开发方法很难顺利执行。
所以这就不难理解为什么要改用Scrum和极限编程这类敏捷方法了。