软件开发的常用开发模式

软件开发常用的几种开发模式

● 瀑布开发模式（也叫线性开发模式）

在瀑布开发模式中，所有的开发活动都遵循一定的顺序。在软件开发里，这些活动的通常顺序是：需求的商业价值分析、需求的细化和需求说明书的制定、预研、方案和架构设计、编码实现、测试、后期运维维护。

瀑布模型的特点是所有的开发活动动都是顺序执行的，不能倒退。就像瀑布里的水不能从瀑布底部回到瀑布顶部一样。

瀑布模式是一种项目开发架构。这种架构不仅仅应用在软件开发上，其实在人类活动的各个地方都能见到瀑布模式。比如房屋的建造：前期的地质勘查，建筑的架构蓝图设计，施工和施工中的监测，完工后的检验和后期维护。

瀑布模型的主要优点优点在于每个阶段的职责清晰，便于检查。清晰定义出了各个阶段的输入和输出，隔离了不相邻活动阶段之间的依赖，便于提高阶段活动的效率。

瀑布模型的主要缺点在于系统只有在整个项目的最末期才能见到真正的成品。如果前期的需求、设计有不符合用户的期望或实际情况的，在整个项目的最末端再进行修改会极大增加整个项目的成本。而在软件开发领域，后期的需求改变和设计改变的可能性较大，也可以说是需求和设计的不确定性较高。在这种情况下，这些改变需要的后期改动在软件开发项目的许多时候对项目的按时完成是致命的。在软件研发的历史上这种例子数不胜数，比如微软的Windowns Vista系统的开发就是一个例子

当然，针对瀑布模型的缺点，也有固定的方法可以在一定程度上进行缓解。在项目管理流程中的变更控制流程就是一个很好的例子。在项目团队里有变更控制委员会，对于所有在项目实施过程中发生的变更，都需要走变更控制流程，进行书面的评估、批准、沟通和实施等一系列流程，保证变更的有效

瀑布模型适用于不确定性较低的软件项目。比如使用固定、成熟框架的软件产品，尤其是一些相对小的例行常规项目。但如果是一些需要新技术，或是是新市场的创新性项目，瀑布模型的适用性就会大大折扣

● 迭代式开发模式 （也叫增量式开发模式）

迭代式开发模式是指将整个软件的开发过程划分成多个迭代阶段。在每个迭代阶段中，只完成软件的一小部分功能。但是在这个迭代中，还是会包括开发的大部分活动，比如需求的分析，开发、测试。

迭代开发的最大优点是可以通过尽快的发布可工作的产品，得到市场或用户的反馈，然后进行修改，进而降低整个软件项目在需求、技术和进度上的风险，或者也可以说降低了不确定性。

迭代开发的最大缺点，或者说是最大难点，就是比较不容易做到又能保证每个阶段的持续功能输出，又能做到高的效率和质量。具体表现在要在一个迭代完成所有开发阶段的活动，对外界环境和人员的素质要求都比较高。比如，在现代工业模式里，引以为傲的通过流水线的细化分工达到高产出的效率在迭代模式里就比较困难。因为它要求团队一起做需求分析、一起做开发、一起做测试，一起负责端到端的功能，对不同方面的知识，技巧要求都比较高。

在实际中，迭代开发模式更适用于需要快速变化的领域。比如使用新技术或者开拓新市场的产品。因为快递的反馈比稳定的预测更为重要。

而对于大软件系统的开发，比如超过500人，团队还分布在异地。纯粹的迭代开发模式就不一定比瀑布模式要好。或者说，对于大软件系统开发，除了极少数的顶尖企业，绝大部分的软件公司都做得不怎么样。引用《人月神话》作者的比喻，这些公司都在大系统的焦油坑里挣扎

● 迭代式开发模式的改进

迭代开发模式一个较大的架构。其中演化出了不同的细分、改进模式

● 迭代式开发模式的改进 - Time Boxed 定时开发

定时开发基于迭代开发。特点在于

1. 每次迭代有固定的时间

2. 每次迭代完成后都有一定的可发布的功能输出

● 迭代式开发模式的改进 - Continuous Flow 持续工作流

持续工作流也是居于迭代开发模式。最大的区别在于持续工作流除了要求每个迭代的持续发布，加入了精益（Lean）的思想：通过控制半成品（Work in Progress， WIP）的数量，达到降低在整个开发流程中的浪费（Waste）的目的

不同开发模式的实际使用

在任何领域，永远都不存在一种东西绝对比一种东西好。具体到软件开发领域，没有任何一种开发模式可以绝对地比另外一种好。用软件行业的话来说，就是没有银弹（No Silver Bullet）。

具体的例子就是，在实际的绝大部分软件公司里，并不会单纯地使用上面的一种开发模式，而更多的是使用混合的开发模式。这些混合的模式需要结合不同公司，不同产品的不同情况。这样才可以达到取长补短的效果。毕竟，最为重要的，不是一个组织使用什么样的开发模式，而是在这种模式下是否能更好的实现长期和短期的质量和效率。

主要参考资料

1. Software Development Metrics, David Nicolette, 2015