敏捷开发和瀑布开发

理解一：

瀑布模型开发：

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

使用里程碑的方式，严格定义了各开发阶段的输入和输出。如果达不到要求的输出，下一阶段的工作就不展开。
强调文档，在开发的后期才会看到软件的模样。在这种情况下，文档的重要性仿佛已经超过了代码的重要性。

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

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

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

既然叫做瀑布，就意味着不应该走回头路。否则如果出现返工，付出的代价会很大。

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

敏捷开发：

核心是迭代。

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

宣言：

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

可以工作的软件 胜过 面面俱到的文档

客户合作 胜过 合同谈判

响应变化 胜过 遵循计划

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

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

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

沟通是非常重要的，所有的开发人员对项目活动的理解应该是一致的。

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

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

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

在有技术问题还没有解决的情况下不适合展开迭代。

理解二：

瀑布模型的特点：

（传统的开发方式）

1、强调文档

前一个阶段的输出就是下一个阶段的输入，文档是个阶段衔接的唯一信息。所以很多开发人员好象是在开发文档，而不是开发软件，因为要到开发的后期才可以看到软件的“模样”。

2、没有迭代与反馈。瀑布模型对反馈没有涉及，所以对变化的客户需求非常不容易适应。瀑布就意味着没有回头路。

3、管理人员喜欢瀑布模型的原因是把文档理解为开发的速度，可以方便地界定不同阶段的里程碑。

敏捷开发

极限编程的思想体现了适应客户需求的快速变化，激发开发者的热情，也是目前敏捷开发思维的重要支持者。

敏捷软件开发是一个开发软件的管理新模式，用来替代以文件驱动开发的瀑布开发模式。

敏捷开发集成了新型开发模式的共同特点，它重点强调：

1.敏捷就是“快”。快才可以适应目前社会的快节奏，要快就要发挥个人的个性思维多一些个性思维的增多。

2.客户参与。以人为本，客户是软件的使用者，是业务理解的专家，没有客户的参与，开发者很难理解客户的真实需求。

3.强调软件开发的产品是软件，而不是文档。文档是为软件开发服务的，而不是开发的主体。

4.设计周密是为了最终软件的质量，但不表明设计比实现更重要。

5.迭代。软件的功能是客户的需求，界面的操作是客户的“感觉”。对迭代的强调是缩短了软件版本的周期。

6.小版本。快速功能的展现，看似简单，但对于复杂的客户需求合理地分割与总体上的统一，要很好地二者兼顾是不容易的。