瀑布模型开发
严格把软件项目的开发分隔成各个开发阶段：需求分析，要件定义，基本设计，详细设计，编码，单体测试，结合测试，系统测试等。
使用里程碑的方式，严格定义了各开发阶段的输入和输出。如果达不到要求的输出，下一阶段的工作就不展开。
强调文档，在开发的后期才会看到软件的模样。在这种情况下，文档的重要性仿佛已经超过了代码的重要性。
瀑布模型把开发人员定义为流水线上的工人，由于各阶段的开发人员只能接触到自己工作范围内的东西，所以对客户需求的理解程度高低不等。对于客户需求变更，编码人员会比设计人员更容易产生很强的抵触情绪。
在每个开发阶段都会有一些信息刻意不让其他开发阶段的人员知道（本意是为了提高效率，但实际上有时候产生的是互相的理解偏差）。
瀑布模型产生的管理文档（计划书，进度表）等，能让不太了解该项目的人也能看懂项目的进度情况（只有能看懂百分比就行），很适合向领导汇报用。所以管理人员比较喜欢瀑布模型，但是开发人员不喜欢，因为它束缚了开发人员的创造性。
既然叫做瀑布模型，就意味着不应该走回头路。否则如果出现返工，付出的代价会很大。
软件生命周期前期造成的Bug的影响比后期的大得多。
敏捷开发
核心是迭代。迭代是重复反馈过程的活动，其目的通常是为了逼近所需目标或结果。
因为最终目标是让客户满意，所以能够主动接受需求变更，这就使设计出来的软件有灵活性，可扩展性。
宣言：
个体和交互 胜过 过程和工具
可以工作的软件 胜过 面面俱到的文档
客户合作 胜过 合同谈判
响应变化 胜过 遵循计划
简单设计，重复迭代。减少不必要的文档。
客户最关心的功能最先完成。
要求客户有时间对每次迭代的成功进行确认，提出改进意见。
沟通是非常重要的，所有的开发人员对项目活动的理解应该是一致的。
开发团队有两个队伍，业务团队和技术团队。如何任何一方控制了沟通，那么项目注定会失败。如果业务一方控制，项目会议上就会不断的要求功能和交付日，而不太担心开发人员是否能够全部完成或开发人员是否明白他们的真正要求；如果开发人员控制了沟通，那么项目会议上技术术语会代替面向客户的业务语言，开发人员也失去了通过倾听来了解客户真正需求的机会。
敏捷开发不能在一开始就给出项目的成本计划。
在有技术问题还没有解决的情况下不适合展开迭代。