在日常的工作过程中，项目中主要采用的软件开发模型主要有两种：瀑布模型、敏捷模型。还有一种实践延伸的模型：瀑布+敏捷模型。

瀑布模型

跟名字一样，瀑布模型就像现实中的瀑布一样，倾泻而下，其实与其叫做“瀑布模型”，不如叫做“流水线模型”来得贴切，但业内是这样称呼，那就这样吧。瀑布模型的核心思想就是将软件开发流程的功能设计和实现分开，将软件生命周期分为制定计划、需求分析、软件设计、程序编写、软件测试、运行维护六个节点，通过文档驱动，并且像流水线一样，一个一个节点按顺序流转，最终完成软件的交付。

瀑布模型的优点

• 从管理角度来说，软件拆分节点后，可以很好地按节点制定计划，跟进开发进度，对各个节点进度进行检查，提高了项目的可视化程度。
• 从节点负责人角度来说，上一个节点完成后，只需要关注自己的节点的事情即可，对自己的节点负责，提高了效率。

• 从软件交付角度来说，自需求分析完成后，交付产物会跟需求分析的期望基本一致，整体完整交付。

  瀑布模型的缺点

• 从管理角度来说，节点推进过程中，每个节点都需要产出大量的文档、产物，不仅交付周期变长，每个节点的交付产物检查、交付风险把控也是个大问题。

• 从节点负责人的角度来说，每个节点都要对交付后一个节点负责，只有前一个节点的产物正确，后一个个节点的工作才能获得正确，各个阶段之间由于直接交流少，可能会出现节点流转产生偏差，最终“货不对板”。节点需要产出内容过多也会产生无法准确评估工作量，进而导致节点延期而项目造成整体计划需要调整。

• 从软件交付角度来说，无法根据市场变化动态调整产品，自需求分析节点完成后，软件就像上了高速公路，难以“调头”调整，用户只有在软件交付后才能体验到产品，可能最终产品和用户期望偏差很大。

  敏捷模型

  跟名字一样，敏捷模型的主要特点就是“敏捷”。从百度百科的解释来说，敏捷就是“反应迅速快捷”。其核心思想强调，开发人员和业务人员要更加紧密的“面对面”沟通（而不是书面沟通）、更加频繁交付新的软件版本。换言之，就是把原本软件整体，拆分成多个子软件，每个子软件经过很短的开发周期迭代交付，每一个子软件都可以交付市场或者用户进行需求验证，如果需求有变化，可以在下一个周期进行调整，可以更好地保证最终的交付产品和用户期望是一致的。

  敏捷模型的优点

• 从管理角度来说，流程上更注重节点和节点间的人的交流和协同，每个节点的产物拆分后内容也更少，更利于检查和灵活调整，且降低了总的开发时间。

• 从节点负责人的角度来说，面对面沟通比输出大量文档更高效，减少了文档的交付，每次迭代需要交付的产物也更少，可以更聚焦到整体的一个部分的交付，更好地评估工作量、保证质量以及响应变化。

• 从软件交付角度来说，遇到需求不明确，需求变更较多的项目，敏捷模型能更好地响应变化，以快速的迭代交付，不断进行市场验证和软件调整，最终交付完整且符合用户期望的产品。

  敏捷模型的缺点

• 从管理角度来说，由于减少了文档的产出，各个节点无法追溯各个阶段的中间变化和决定，容易产生疏漏，人员过多时会存在信息同步沟通成本。

• 从节点负责人的角度来说，缺乏文档支持，很多事情都是口头沟通，容易有误解和遗漏，另外遇到人员变动，工作交接也会比较困难。
• 从软件交付角度来说，由于软件开发过程轻视文档的积累，在软件交付后，需要再次迭代、维护的成本会比较大。

  瀑布+敏捷模型

  主要是吸收瀑布模型和敏捷模型的优点，拆分子软件进行瀑布模型迭代，迭代过程中保留必要的文档产出，以减少过程的疏漏，降低交接成本和维护成本。