瀑布模型、增量模型、迭代模型是项目管理常见的三种模型。每种模型都有其优缺点和适用的项目类型。作为项目经理必须对这几种模型有深入的了解，然后针对不同的项目采用相对应的模型，才能起到事半功倍的作用。
1瀑布模型将软件生命周期分为收集需求、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动。规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。这就是瀑布模型， 如图1-1所示。
简单的说就是先定好需求和相关文档，然后构建框架，然后写代码，然后测试，最后发布产品。一旦文档需求确定，开发人员就按文档开发，直到产品开发完后，才会拿出来给客户。其特征是文档驱动，上一个阶段的所有工作完成且必须有输出产物，结果需要通过审核，才能“流动”到下一个阶段；否则返回前一阶段，甚至更前的阶段活动。
图1-1 瀑布模型流程示意图
瀑布模型的优点：
1）阶段划分明确，每个阶段完成后设置有检查点。前一阶段完成后就只需关注下一阶段。
2）在编码前设置有系统分析和设计的阶段，这个阶段主要考虑系统的逻辑实现，进行系统架构、方案、技术路线等的详细分析和设计，并进行严格的评审后才能进行编码工作，减少了后续编码返工的可能性，且因为前期详尽逻辑分析和设计，后续编码按要求进行即可，经验不是很丰富的工程师也能胜任工作。
3）迫使开发人员采用规范的方法，严格规定了每个阶段需提交的文档，提交的文档必须经过评审审核，降低了沟通成本，有利于早发现问题。每个阶段的开发质量有保障，减少了返工。
瀑布模型的缺点：
1）完全依赖于各阶段产生的文档，没有文档软件几乎不可维护。也很可能导致最终开发出来的产品不是用户所需要的。
2）各阶段完全固定且产生大量的文档，极大的增加了工作量。
3）由于开发模型是线性的，单一流程，不可逆，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。
4）测试是其中一个单独的阶段，编码全部完成后才能进行测试，使开发早期的错误可能要等到测试阶段才能发现，发现问题越晚造成代价越高。
5）要等需求完全确认后才能进行开发，后期一旦需求变更代价较高。不适应需求频繁变化。
6）需要更多的时间进行前期的详细计划。
瀑布模型适用的项目范围：
1）需求很明确且不能隐含不可克服的风险。
2）开发阶段需求不会变化或很少变化。
3）客户除了提出需求以外很少参与开发工作。
4）开发人员对业务领域很熟悉。
5）要求项目预算充足，人员齐备。
瀑布模型开发过程：
图1-2 瀑布模型的开发过程
。
2增量模型一般是指具有底层框架和平台的项目，在该稳定的框架和平台上，来开发和增加具体的业务功能。首先对系统最核心或最清晰的需求进行开发并集成到系统中，再按优先级逐步开发后续的需求，逐步建设成一个完整系统。每个增量之间相对独立，各个增量可以并行开发，增量内部是瀑布模型。增量模型的第一个增量往往是实现基本需求的核心产品。增量模型本质上是迭代的，强调每一个增量都能发布一个可用的产品。
图2-1 增量模型流程示意图
增量模型的优点：
1）能在较短时间内向用户提交可完成部分工作的可适用的产品。
2）有利于进度控制，也能够有计划地管理技术风险，风险分布到几个更小的增量中。
3）整个项目的资金不会被提前消耗，因为首先开发和交付了主要功能和高风险功能。每个增量交付一个可操作的产品，在达到初始需求之前可降低成本。
4）灵活性优于瀑布模型，适用需求的变化。
5）逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品，因为客户可以不断地看到所开发的软件，更加理解后续增量的需求，有利于增加客户对系统的信心，客户也可及时体验并提出问题，从而降低了开发风险，每次增量交付过程中获取的经验，有利于后面的改进，客户也有机会对建立好的模型作出反应，从而提高系统可靠性、稳定性和可维护性。
增量模型的缺点：
1）由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。
2）增量模型的灵活性强，很容易退化为边做边改模型。
3）增量粒度难以选择。
4）确定所有的基本业务需求比较困难。
增量模型适用的项目范围：
1）一般适用于具有底层框架和平台的项目，且用户核心需求或初始需求非常清晰。
2）产品可以分割成不同的阶段分别完成。
3）若软件可拆卸度不高，开发人员全局把握水平不高，用户不同意分阶段提交产品，或者开发人员过剩，都不适宜。
3迭代模型能
是以架构为核心，用例为驱动的，每次只设计和实现这个产品的一部分，每次设计和实现一个阶段叫做一个迭代，每一次迭代都完整地经过所有工作流程的过程（需求分析、设计、测试、实施），再通过客户的反馈来细化需求，并开始新一轮的迭代。真正的迭代必须把每一个迭代周期的成果交给用户，而且每次的成果都是完整可用的。每一次迭代必须以产品的发布结束！
图3-1 迭代模型流程示意图
迭代模型的优点：
1）开发工作可以在需求被完整地确定之前启动，降低了风险，在大规模的投资之前就解决了关键的风险分析。
2）得到早期用户反馈和及时的用户反馈，这样可以快速的调整产品的方向，避免在无用的功能浪费时间和精力，减少风险。。
3）持续的测试和集成。
4）拥抱变更。由于用户的需求并不能在一开始就作出完全的界定，它们通常是在后续阶段中不断细化的。因此，更容易适应需求的变更。
5）提高复用性。
6）由风险驱动，强调可选方案和约束条件从而支持软件的重用，有助于将软件质量作为特殊目标融入产品开发之中。
7）对过程的测量是通过对实现的评定（而不仅仅是文档）来进行的。
迭代模型的缺点：
1）风险管理成本较高，在风险分析，进度管理方面，对项目组成员的要求也非常高。需有一个高素质的项目管理者和一个高技术水平的开发团队。对产品人员的节奏把控能力（定每周目标，需求优先级剖析，以及临时需求的处理）有较高要求，不然容易陷入每周发版日加班加死的节奏。
2）容易跑偏方向，进入无尽的改良却见效甚微。如果产品出发点、方向，迭代的性质和定位不够清晰，那么会陷入无休止的方向调整和补漏当中。
3）盲目快速堆砌功能而忽视框架搭建，导致后续改动往往牵一发而动全身，可能就是小小的动一处而牵动无数功能出现不可预知的BUG。
迭代模型适用的项目范围：
1）高风险项目，且需求不确定，用户能在整个开发过程中不同程度地参与。
2）一个需求大而全的产品，创新型的产品，特别是对产品最终形态还缺乏概念的时候。
迭代模型的项目计划制定方法：
1）以迭代周期的时间线进行计划制定
图3-2 迭代模型的时间轴线计划制定方法
2）以软件工程流程进行计划制定
图3-3 迭代模型的软件工程轴线计划制定方法
4增量模型与迭代模型的关系和区别
共同点：每阶段完成之后，都有一个新版本发布。有利于鼓舞团队的士气，降低项目的风险。 不同点：主要是阶段的划分上不太一样。增量模型从功能量上来划分，每阶段完成一定的功能。迭代模型是从功能的深度或细化的程度来划分，每阶段不断去完善增强功能。
适用性：增量模型适用于需求比较明确，架构比较稳定的软件开发，每次增量不影响已有的架构，在已有的架构下增加新的功能。迭代模型适用于需求不明确、难度比较大的软件开发。 在实际应用中，增量、迭代经常一起使用，如迭代时加入新的功能进行开发。我们在开发自己的软件时，需要根据软件项目的实际情况，进行不同的增量、迭代组合，以充分利用资源，降低项目风险。
5敏捷开发与迭代开发的区别
敏捷开发是以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。迭代开发是软件开发的一种生命周期模型，是一种开发过程；敏捷开发是多种软件开发项目管理方法的集合，是一种开发方法。这是两者最根本的区别。
敏捷开发是一个总体概念，而迭代式开发只是几乎所有敏捷开发所采用的一个主要的基础实践。敏捷开发除迭代式开发外，还包含了其他许多管理与工程技术实践，如演进式架构设计、敏捷建模、重构、自动回归测试等等。总而言之，就是敏捷开发与迭代开发是整体与局部的关系，前者就像大家庭，而后者是大家庭中的一员。
敏捷开发是一个庞大的体系，后面我花时间整理好了给大家详细介绍，先放一个图给大家简单介绍一下敏捷开发的过程。
图5-1 敏捷开发过程示意图
① PO和开发团队对产品业务目标形成共识。
② PO建立和维护产品需求列表并进行优先级排序。
③ PO每轮迭代前，Review需求列表，并筛选高优先级需求进入本轮迭代开发。
④ 开发团队细化本轮迭代需求，并按照需求的优先级，依次在本轮迭代完成。
⑤ 开发团队每日站立会议、特性开发、持续集成，使开发进度真正透明。
⑥ PO对每轮迭代交付的可工作软件进行现场验收和反馈。
⑦ 回到第3步，开始下一轮迭代。
总之，PM在实际的项目工作中，针对不同的项目类型，应该根据不同项目模型的特点选择合适的项目开发模型，这样才能事半功倍，助力项目成功！
