从瀑布模型到敏捷开发——认识论决定行为

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

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

软件开发模型的由来

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

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

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

瀑布模型

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

      瀑布模型的特点：

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

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

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

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

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

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

由瀑布模型引入敏捷开发

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

什么是敏捷开发？

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

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

  敏捷开发的优势？

1、以客户惬意度为主。

客户会看到产品设计的每一步并在此基础上做出反馈。这时候你须要迅速的做出调整。

2、拥抱变化。客户最关心的是设计出的软件可以满足其需求便阿虎，因此这就须要开发者从客户那里得到什么，3、就要迅速实现什么。

这样软件的每一个子项目都会依据需求进行调整，并不会对其他子项目产生不好的影响。

4、频繁交付。从几周到几个月应该交付更新，时间越短越好。

及时交付客户维系好的客户关系，并依据客户反馈的信息，并作出对应的调整。

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

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

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

 总结：

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

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

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