瀑布式开发和敏捷开发的对比

瀑布模型开发：

严格把软件项目的开发分隔成各个开发阶段：需求分析，要件定义，基本设计，详细设计，编码，单体测试，结合测试，系统测试等。

使用里程碑的方式，严格定义了各开发阶段的输入和输出。若是达不到要求的输出，下一阶段的工做就不展开。

 

强调文档，在开发的后期才会看到软件的模样。在这种状况下，文档的重要性仿佛已经超过了代码的重要性。

 

瀑布模型把开发人员定义为流水线上的工人。因为各阶段的开发人员只能接触到本身工做范围内的东西，因此对客户需求的理解程度高低不等。对于客户需求变动，编码人员会比设计人员更容易产生很强的抵触情绪。

在每一个开发阶段都会有一些信息刻意的不让其余开发阶段的人员知道（本意是为了提到效率，但实际上有时候产生的是互相的理解误差）。

 

瀑布模型产生的管理文档(计划书，进度表)等，能让不太了解该项目的人也能看懂项目的进度状况（只有能看懂百分比就行），很适合向领导汇报用。因此管理人员比较喜欢瀑布模型，可是开发人员不喜欢，由于它束缚了开发人员的创造性。

 

既然叫作瀑布，就意味着不该该走回头路。不然若是出现返工，付出的代价会很大。

软件生命周期前期形成的Bug的影响比后期的大的多。

 

 

敏捷开发：

核心是迭代。

由于最终目标是让客户满意，因此可以主动接受需求变动，这就使设计出来的软件有灵活性，可扩展性。

 

宣言：

个体和交互 赛过 过程和工具

能够工做的软件 赛过 面面俱到的文档

客户合做 赛过 合同谈判

响应变化 赛过 遵循计划

 

简单设计，重复迭代。减小没必要要的文档。

客户最关心的功能最早完成。

要求客户有时间对每次迭代的成果进行确认，提出改进意见。

 

沟通是很是重要的，全部的开发人员对项目活动的理解应该是一致的。

 

开发团队有两个队伍，业务团队和技术团队。若是任何一方控制了沟通，那么项目注定会失败。若是业务一方控制，项目会议上就会不断的要求功能和交付日，而不太担忧开发人员是否可以所有完成或开发人员是否明白他们的真正要求；若是开发人员控制了沟通，那么项目会议上技术术语会代替面向客户的业务语言，开发人员也失去了经过倾听来了解客户真正需求的机会。

 

PMBOK的项目管理是自上而下的命令式管理，而敏捷的管理是团队的自我管理和项目经理的服务式管理。

 

敏捷开发不能在一开始就给出项目的成本计划。

 

在有技术问题尚未解决的状况下不适合展开迭代。