严格把软件项目的开发分隔成各个开发阶段：需求分析，要件定义，基本设计，详细设计，编码，单体测试，结合测试，系统测试等。编程
瀑布模型把开发人员定义为流水线上的工人。因为各阶段的开发人员只能接触到本身工做范围内的东西，因此对客户需求的理解程度高低不等。对于客户需求变动，编码人员会比设计人员更容易产生很强的抵触情绪。工具
在每一个开发阶段都会有一些信息刻意的不让其余开发阶段的人员知道（本意是为了提到效率，但实际上有时候产生的是互相的理解误差）。测试
瀑布模型产生的管理文档(计划书，进度表)等，能让不太了解该项目的人也能看懂项目的进度状况（只有能看懂百分比就行），很适合向领导汇报用。因此管理人员比较喜欢瀑布模型，可是开发人员不喜欢，由于它束缚了开发人员的创造性。编码
既然叫作瀑布，就意味着不该该走回头路。不然若是出现返工，付出的代价会很大。spa
软件生命周期前期形成的Bug的影响比后期的大的多。设计
核心是迭代。生命周期
由于最终目标是让客户满意，因此可以主动接受需求变动，这就使设计出来的软件有灵活性，可扩展性。项目管理
宣言：开发
个体和交互 赛过 过程和工具文档
能够工做的软件 赛过 面面俱到的文档
客户合做 赛过 合同谈判
响应变化 赛过 遵循计划
简单设计，重复迭代。减小没必要要的文档。
客户最关心的功能最早完成。
要求客户有时间对每次迭代的成果进行确认，提出改进意见。
沟通是很是重要的，全部的开发人员对项目活动的理解应该是一致的。
开发团队有两个队伍，业务团队和技术团队。若是任何一方控制了沟通，那么项目注定会失败。若是业务一方控制，项目会议上就会不断的要求功能和交付日，而不太担忧开发人员是否可以所有完成或开发人员是否明白他们的真正要求；若是开发人员控制了沟通，那么项目会议上技术术语会代替面向客户的业务语言，开发人员也失去了经过倾听来了解客户真正需求的机会。
PMBOK的项目管理是自上而下的命令式管理，而敏捷的管理是团队的自我管理和项目经理的服务式管理。
敏捷开发不能在一开始就给出项目的成本计划。
在有技术问题尚未解决的状况下不适合展开迭代。
理解二：
瀑布模型的特色：
（传统的开发方式）
1、强调文档
前一个阶段的输出就是下一个阶段的输入，文档是个阶段衔接的惟一信息。因此不少开发人员好象是在开发文档，而不是开发软件，由于要到开发的后期才能够看到软件的“模样”。
2、没有迭代与反馈。瀑布模型对反馈没有涉及，因此对变化的客户需求很是不容易适应。瀑布就意味着没有回头路。
三、管理人员喜欢瀑布模型的缘由是把文档理解为开发的速度，能够方便地界定不一样阶段的里程碑。
敏捷开发
极限编程的思想体现了适应客户需求的快速变化，激发开发者的热情，也是目前敏捷开发思惟的重要支持者。 敏捷软件开发是一个开发软件的管理新模式，用来替代以文件驱动开发的瀑布开发模式。 敏捷开发集成了新型开发模式的共同特色，它重点强调： 1.敏捷就是“快”。快才能够适应目前社会的快节奏，要快就要发挥我的的个性思惟多一些个性思惟的增多。 2.客户参与。以人为本，客户是软件的使用者，是业务理解的专家，没有客户的参与，开发者很难理解客户的真实需求。 3.强调软件开发的产品是软件，而不是文档。文档是为软件开发服务的，而不是开发的主体。 4.设计周密是为了最终软件的质量，但不代表设计比实现更重要。 5.迭代。软件的功能是客户的需求，界面的操做是客户的“感受”。对迭代的强调是缩短了软件版本的周期。 6.小版本。快速功能的展示，看似简单，但对于复杂的客户需求合理地分割与整体上的统一，要很好地两者兼顾是不容易的。