技术交流会中，让我印象最深的是：大勇学长和丹姐在切磋实际项目中用到的“敏捷开发”，后来由向阳学长对比两人的观点发问“敏捷开发和瀑布模型的优缺点？人员要求？流程？”最终由我们敬爱的米老师做高层次的总结。

    下面，本人根据学长们的建议，并参阅网上资源对“敏捷开发和瀑布模型做对比分析”

软件开发模型的由来

    20实际60年代中期，人们在软件开发过程和维护中所遇到的问题被称作是“软件危机”。

    1968年，在德国召开的NATO（北大西洋公约组织），首次提出“软件工程”的概念，希望能用工程化的原则和方法来克服软件危机。

    在此之后，人们开展了软件模型、软件方法、工具与环境的研究，提出了瀑布模型、演化模型、螺旋模型和喷泉模型等开发模型，出现了面向数据流方法、面向数据结构的方法、面型对象的开发方法，以及一批CASE（计算机辅助的软件工程）工程和环境。

瀑布模型

    1970年WinSTon Royce提出了著名的"瀑布模型"，将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。

      瀑布模型的特点：

1、各阶段划分很明确，便于项目经理对进度的把控，但是缺乏灵活性。

2、适用于需求很明确的项目，因此对于客户需求的变化很难适应。

3、以文档作为驱动，作为每一阶段审核的标准，同时极大地增加了工作量。

4、强调了每个阶段的严格性，只有前一阶段通过审核才能进入下一阶段的设计。开发前期良好需求说明，是最终系统正确性和完整性的保证。

5、由于开发模型是线性的，早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。

6、用户只有等到末期才能见到开发成果。

由瀑布模型引入敏捷开发

    敏捷开发是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。相对于"非敏捷"，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重做为软件开发中人的作用。

什么是敏捷开发？

   一群开发经验丰富和才华横溢的开发人员通过关注其他公司和别的开发团队并且结合自身的项目经验，创建了敏捷开发宣言，让软件开发工作变的更容易更轻松：

1. 个人和交互重于流程和工具
2. 有效的软件重于全面的文档
3. 客户合作重于合同谈判
4. 因时制宜重于按步就班

  敏捷开发的优势？

1、以客户满意度为主。客户会看到产品设计的每一步并在此基础上做出反馈，这时候你需要迅速的做出调整。

2、拥抱变化。客户最关心的是设计出的软件能够满足其需求便阿虎，因此这就需要开发人员从客户那里得到什么，3、就要迅速实现什么。这样软件的每个子项目都会根据需求进行调整，并不会对其它子项目产生不好的影响。

4、频繁交付。从几周到几个月应该交付更新，时间越短越好。及时交付客户维系好的客户关系，并根据客户反馈的信息，并作出相应的调整。

5、面对面的交流。由于领域的区别，客户只是业务了解，而软件开发人员只对软件熟悉，这就可能导致沟通之间出现理解偏差，因为常常在一起工作显得很必然。

瀑布模型和敏捷开发对比分析图：

	瀑布模型	敏捷开发
开发人员水平	普通。编码阶段是没有创意的机械劳动，容易产生抵触情绪。	一群开发经验丰富和才华横溢的开发人员。在有技术问题还没有解决的情况下不适合展开迭代。
与客户的关系	合同谈判	客户参与。以人为本，客户是软件的使用者，是业务理解的专家，没有客户的参与，开发者很难理解客户的真实需求。
项目经理的管理模式	瀑布模型的项目管理是自上而下的命令式管理	敏捷的管理是团队的自我管理和项目经理的服务式管理。
开发人员对项目的了解	各阶段的开发人员只能接触到自己工作范围内的东西，所以对客户需求的理解程度高低不等	注重沟通，所有人员对项目活动的理解应该是一致的。
开发流程	严格的阶段划分：需求分析、软件计划、概要设计、详细设计、编码、测试、维护	28原则，用户的核心功能最先完成。
成本计划	确定。瀑布模型适用于需求确定的项目，因为成本也可以确定。	不确定。因为需求不确定，所以项目的成本计划很难确定。
适用范围	需求明确的大型软件	需求变化
如何应对需求的变化	遵循计划。没有反馈，不适合客户需求不断变化的软件开发。市场的需求变动以及客户对需求描述不清会给瀑布模型带来困难。应。瀑布就意味着没有回头路。	相应变化。适应客户需求的快速变化，激发开发者的热情
对文档的要求	注重文档。前一阶段的输出是文档，只有文档经过严格的审批通过后，才可以进入下一个阶段，且把上一阶段的文档作为下一阶段的输入。否则工作不予以展开。	只写核心文档。强调软件开发的产品是软件，而不是文档。文档是为软件开发服务的，而不是开发的主体。
阶段性产物	面面俱到的文档	具有核心功能的软件
产品交付时间	周期较长。只有到了开发后期，客户才可以看到软件。	周期较短。要求客户有时间对每次迭代的成果进行确认，提出改进意见。

 总结：

     “敏捷”就是快，是一种新的思路。极大地发挥人的创造力，只有快才可以适应社会的节奏。而对于需求明确的大型软件的应用开发，文档的管理与衔接作用是不可替代的。

     至于选择哪一种开发模型，这取决于项目的规模、开发的工期、领导者的素质……。瀑布模型和敏捷开发思想并不是二者只选其一的关系，还可能把敏捷开发的思想融入到“流水线工厂式”的管理中。

      只有认真分析环境因素（外界+人员素质本身）的变化，才能够选择最适宜的开发方式。要知道，最适合的才是最好的。这就是米老师常说的“认识论决定一个人的行为，决定你的未来发展方式，会不会少走弯路”。