常见开发模型-敏捷开发与瀑布开发模型详解
引言
在学习软件工程的时候接触过一些软件工程开发模型的相关概念，其中，印象比较深刻的就是瀑布模型和敏捷开发模型。这两种模型在日常的软件开发中都是非常常用的，但是它们也有比较大的区别，所以在实际的应用场景也不同。
瀑布模型式是最典型的预见性的方法，严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行。敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。
敏捷开发模型
敏捷软件开发是基于敏捷宣言定义的价值观和原则的一系列方法和实践的总称。自组织、跨职能团队运用适合他们自身环境的实践进行演进得出解决方案。
敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。
敏捷开发的特点
敏捷开发的特点就是下面4句话：
「个体与交互」胜过「过程与工具」
「可以工作的软件」胜过「面面俱到的文挡」
「客户协作」胜过「合同谈判」
「响应变化」胜过「遵循计划」
在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
敏捷开发借助互联网浪潮开始流行起来，相比瀑布模式，敏捷无疑更加贴近互联网时代背景下快速发展变化的市场环境以及业务需求。
敏捷开发的三大角色
产品负责人（Product Owner）
主要负责和客户沟通确定产品的功能和达到要求的标准，并指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果，一般是由产品经理担任。
流程管理员（Scrum Master）
问题清道夫！主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。
开发团队（Scrum Team）
开发主力！主要负责软件产品在Scrum规定流程下进行开发工作。人数控制在5~10人左右，每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，同时具有一定的表达能力；不论过程只问结果！只要能达到目标，不论任何工作时间、方式。
敏捷开发的生命周期
软件开发生命周期(SDLC)是设计，开发和测试高质量软件的一种现象。
在敏捷的SDLC开发过程中，客户能够看到结果并了解他/她是否满意。这是敏捷SDLC模型的优势之一。
敏捷SDLC的每次迭代都包含跨不同阶段的跨职能团队：
- 需求收集和分析
- 设计要求
- 构造/迭代
- 部署
- 测试
- 反馈
敏捷开发主要包含三种模式：
迭代式开发生命周期
听说过敏捷的同学一定都听说过迭代这个东西。有的人说我们要迭代一个版本，有的人说我们要在这个迭代周期内完成什么，不管它指的是具体的软件版本，还是一段时间，这两字的含义其实都是一样的，那就是在整个项目开发过程中，切分出来的一个一个的小时间段。这一个时间段就是一次迭代。通过一次次的迭代，让整个项目更加清晰。最出名的针对迭代的概念的图示就是这个图。
从这个图中我们能看出什么呢？迭代就是不断丰富细节的过程。每一次的迭代，我们都应该让这个项目更加的清晰明了，细节也一步步地完善。
增量式开发生命周期
说完迭代式开发过程，我们再来说说增量，迭代和增量是所有敏捷教程都会说的东西，因为这两个东西很多人容易搞混。增量实际上是不断的添加待开始项目的产品的模块功能。就像搭积木一样地将不同的模板拼成一个完整的产品。同样地，也有一张图是专门针对增量这个概念的。
看出来增量和迭代的不同了吗？迭代的时候，有轮廓，不断完善细节。而增量，没有整体轮廓，上来就是细节完整的一个部分，不断地一部分一部分地完成，最终形成一个完整的产品。
补充：迭代和增量这两种图，同时对应 Web 应用中图片的两种展示形式，不知道大家有没有印象，在网速不好的时候，有些网站打开大图是一块一块出来的，而有些网站打开大图是先模糊然后一步一步清晰的。有兴趣的同学可以搜索查找一下 PhotoShop 中导出 WEB 格式时选择连续功能的作用。
混合式开发生命周期
将上面的迭代和增量合起来，也就是在一次迭代中同时包含着增量，这样的形式就是混合式的生命周期 。这种情况下可以很好地运用这两种开发形式的优点。其实，我们目前大部分公司中的迭代冲刺都是这种混合式的生命周期的开发形式。在每次迭代中，我们添加的新功能模块其实就是在整个项目的轮廓中不断添加完善细节。
但是，需要注意的，不管是考试还是面试，你还是要能清晰地说明白迭代和增量的区别的。此外，在混合的时候，每次迭代也可以看做是一次传统的开发过程，总之，混合就是各种混合，吸收各家优势。
敏捷开发的优点
- 更快交付价值
- 更低的风险
- 拥抱变化
- 更好的质量
- 持续改进
- 更高的客户满意度
- 更高的团队满意度
敏捷开发的缺点
- 很难进行准确的资源规划
- 很难准确的定义“轻量的“或必要的文档
- 很难把握整体产品的一致性
- 很难预测有限的终点
- 很难有效地进行度量
瀑布开发模型
瀑布模型（Waterfall Model）是最早出现的软件开发模型，是传统软件开发方法的代表。在软件工程中占有重要的地位，它提供了软件开发的基本框架。1970 年温斯顿·罗伊斯（Winston Royce）提出了著名的“瀑布模型”，直到 80 年代早期，它一直是唯一被广泛采用的软件开发模型。
瀑布模型式是最典型的预见性的方法，严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行。步骤成果作为衡量进度的方法，例如需求规格，设计文档，测试计划和代码审阅等等。
瀑布式的主要的问题是它的严格分级导致的自由度降低，项目早期即作出承诺导致对后期需求的变化难以调整，代价高昂。瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。
有论文统计，它是造成70%软件开发失败的原因。
瀑布模型的生命周期
瀑布模型将软件生命周期划分为 制定计划、需求分析、软件设计、程序编写、软件测试和运行维护 等六个基本活动，并且规定了它们 自上而下、相互衔接的固定次序 ，如同瀑布流水，逐级下落。其严格强调文档，前一个阶段的输出就是下一个阶段的输入，文档是个阶段衔接的唯一信息。所以很多开发人员好象是在开发文档，而不是开发软件，因为要到开发的后期，才可以看到软件的“模样”。
瀑布模型的优点
瀑布模型作为最典型的预见性方法，其优点主要在于：
- 阶段清晰：从计划到开发最后到上线运行，三个阶段非常清晰。
- 时间顺序：每个阶段顺序必须是从上到下，严格按照时间先后进行。
- 环环相扣：在每一个阶段都必须有产出物然后才能进入到下一个阶段进行。
- 黑盒模式：每个阶段都有各自的角色和分工，各自只关心自己的任务。比如需求阶段开发人员无需关注。
瀑布模型的缺点
而其缺点也突出：
- 需求隔离：由于各阶段的人员只能接触到自己工作范围内的东西，所以对客户需求的理解程度高低不等，开发人员更像是定义为流水线上的工人。
- 变更代价大：既然叫做瀑布，就意味着不应该走回头路。否则如果出现返工，付出的代价会很大。需求变更，编码人员会很强的抵触情绪。
- 束缚创造性：由于强调文档管理，所以管理人员会比较喜欢，但是他束缚了开发人员的创造性。
- 周期漫长：整个开发持续的生命周期很长，需求和设计的时间会耗费特别多，有时候会占用三分之一甚至更多时间，这样整个周期就会变长，大都在半年到一年左右的时间，所以更适合需求相对稳定的大项目。
