项目管理者面临的一个大BUG是：程序员开发的是客户业务的软件项目，但客户不了解软件，开发者不了解业务，如何有效沟通是软件质量的重大障碍。把开发者变成客户业务的专家是个没有办法的办法，让软件企业付出的代价也是昂贵的。
瀑布式开发，也就是从需求到设计，从设计到编码，从编码到测试，从测试到提交大概这样的流程，要求每一个开发阶段都要做到最好。 特别是前期阶段，设计的越完美，提交后的成本损失就越少。
迭代式开发，不要求每一个阶段的任务做的都是最完美的，而是明明知道还有很多不足的地方，却偏偏不去完善它，而是把主要功能先搭建起来为目的，以最短的时间， 最少的损失先完成一个“不完美的成果物”直至提交。然后再通过客户或用户的反馈信息，在这个“不完美的成果物”上逐步进行完善。
螺旋开发，很大程度上是一种风险驱动的方法体系，因为在每个阶段之前及经常发生的循环之前，都必须首先进行风险评估。
敏捷开发，相比迭代式开发两者都强调在较短的开发周期提交软件，但是，敏捷开发的周期可能更短，并且更加强调队伍中的高度协作。 敏捷方法有时候被误认为是无计划性和纪律性的方法，实际上更确切的说法是敏捷方法强调适应性而非预见性。 适应性的方法集中在快速适应现实的变化。当项目的需求起了变化，团队应该迅速适应。这个团队可能很难确切描述未来将会如何变化。
简单的说，敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。
敏捷开发主要包括几个步骤： 需求制定——》需求分析——》设计编码——》测试、功能验证——》发布版本——》下一个周期
在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。
开发的阶段性成果会在开发过程中尽早的进行审查，项目的风险会降低；
适用于需求不明确情况，因为需求不明确，所以需要在不断迭代的过程中来逐步理清需求。
灵活性较高，几乎可以在任何时间进行需求变更；
敏捷鼓励开发人员与业务用户之间进行多频次的沟通，业务用户的不合理需求以及开发人员的错误理解都会在这些频繁的沟通中进行不断审查和更新，
敏捷的协作通常要高得多，通常能开发出更高质量的产品；
适用于快速变化的项目，特别是面向前端业务人员的CRM项目更容易根据业务的变化而变化。
敏捷的概念接受度还不算太高，初次尝试可能不会非常成功；
最终交付的内容无法预测，预期和实际完成的内容经常会有很大差异；
敏捷需要高水平的协作以及开发人员和用户之间的定期沟通。 业务和IT人员在沟通前需要做大量的准备工作，但很多情况下业务的沟通时间无法保证；
当存在乙方供应商的情况，敏捷会面临更大的挑战性。 客户通常希望尽早了解他们的项目投入。 预估项目时间和成本难度较高；
在敏捷项目中，最大的问题可能是业务部门永远不希望有最终的截止时间。
简单说：像工厂流水线一样把软件开发过程分成各种工序，并且每个工序可以根据软件产品的规模、参与人员的多少进一步细分成更细的工序。既然叫做瀑布，就意味着不应该走回头路。否则如果出现返工，付出的代价会很大。 特点： 最典型的预见性的方法，严格遵循预先计划的需求分析、设计、编码、集成、测试、维护的步骤顺序进行。
步骤清晰明确；
文档完整，开发过程中可以作为参考；
瀑布开发是从工业发展过来的，不适合计算机软件的开发；
开发周期长，花大量时间去编写文档，耗费时间、人力；
客户只有在整个项目完成时才可以看到成果，会导致信任问题；
风险大，在开发过程中并不能明白最后的结果，同时不能适应变化；
