传统开发模型vs敏捷开发模型——过程模型的变革

Posted 2020-08-15 lizimeng

一、概念框架

    在了解一个新概念的时候，最好的方法就是把它插入到原有的概念体系中。在不仅有助于对概念的记忆，更利于深刻地认识概念的本质、精髓。下图说明了“敏捷开发”在软件工程理论体系中的位置。

 

    为什么需要软件工程？很简单，为了让我们更好地生产软件。这里的“好”包含多重含义，有成本上的“好”、维护上的“好”等等。但是我们知道，不可能坐着想“我要写好软件”，然后就软件就能写好了。我们需要一套系统化、理论化、工程化的方法，这就是软件工程。我们通过研究以往的经验整理出来一系列活动，包括：沟通、策划、建模、构建、部署等。但是只知道可能需要这些活动还不太够，最好还能提供一些模型，告诉我们设计一个软件先进行什么？接着进行什么？出了问题怎么办？等等。换言之，我们不只需要活动的集合，我们需要一种更精细的结构来指导我们做软件，这就是过程模型。典型的过程模型有：瀑布模型、增量模型、螺旋模型、协同模型等等，当然还包括敏捷开发模型。也就是说，“敏捷开发”是一种软件开发的过程模型。

二、传统过程模型

    什么是传统过程模型？很遗憾，我没有找到一个权威、详细的说法。不过，虽然这个概念的边界可能不是很清晰，但是其核心的部分还是得到一定的公认。这里，我们分析三个典型的传统过程模型：瀑布模型、增量模型和螺旋模型。

瀑布模型

    在20世纪80年代之前，瀑布模型是最早也是应用最广泛的软件过程模型，现在它仍然是软件工程中应用最广泛的过程模型。瀑布模型提供了软件开发的基本框架。其过程是从上一项活动接收该项活动的工作对象作为输入，利用这一输入实施该项活动应完成的内容，给出该项活动的工作成果，并作为输出传给下一项活动。同时评审该项活动的实施，若确认，则继续下一项活动；否则返回前面，甚至更前面的活动。

 

    因为瀑布模型把关键的活动明确的划分，并且以线性的顺序依次完成，所以我们可以让活动之间的联系降低。这是一种优秀的性质，意味着我们在进行一个活动的时候，只需要和上一个活动进行交互，而不需要关注过多的活动。一旦某一个活动出现问题，那么我们只需要去纠正上一个活动的问题即可。同时，这种线性的方式很简单，方便了过程过程管理。

    然而，瀑布模型的线性特征也是它问题的根源。瀑布模型总是试图做好一件事情之后才做下一件事，但是错误是不可避免的。可以看出，在整个开发过程中，只有在最后的部署阶段才能让客户看到这个软件。而通常需求分析阶段是最容易出现错误的阶段，所以很可能最开始的错误会一直流传到最后才会被发现，这意味着我们必须要更改所有的活动以求改正错误，同样的问题还会出现在需求变更时。所以，瀑布模型在实际应用中常常会变为V模型，如下图所示。

 

 

增量模型

 

    增量模型（Incremental Model）是在项目的开发过程中以一系列的增量方式开发系统。在增量模型中，软件被作为一系列的增量构件来设计、实现、集成和测试，每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成。

    增量方式包括增量开发和增量提交。增量开发是指在项目开发周期内，以一定的时间间隔开发部分工作软件；增量提交是指在项目开发周期内，以一定的时间间隔增量方式向用户提交工作软件及相应文档。根据增量的方式和形式的不同，分为渐增模型和原型模型。

    增量模型融合了线性顺序模型的基本成分和原型模型的迭代特征。增量模型采用随着日程时间的进展而交错的线性序列。每一个线性序列产生软件的一个可发布的“增量”。当使用增量模型时，第一个增量往往是核心的产品，也就是说第一个增量实现了基本的需求，但很多补充的特征还没有发布。客户对每一个增量的使用和评估，都作为下一个增量发布的新特征和功能。这个过程在每一个增量发布后不断重复，直到产生了最终的完善产品。增量模型强调每一个增量均发布一个可操作的产品。

    增量模型引进了增量包的概念，无须等到所有需求都出来，只要某个需求的增量包出来即可进行开发。虽然某个增量包可能需要进一步适应客户的需求并且更改，但只要这个增量包足够小，其影响对整个项目来说是可以承受的。

    由于增量模型能够在较短的时间内向用户提交一些有用的工作产品，因此能够解决用户的一些急用功能。同时，交付给用户部分功能后，用户学习、试用过程可以和软件下一个功能的开发并行。但是，增量模型也有如下缺点：

1） 由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。

2） 在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而使软件过程的控制失去整体性。

3）如果增量包之间存在相交的情况且未很好处理，则必须做全盘系统分析，这种模型将功能细化后分别开发的方法较适应于需求经常改变的软件开发过程。

 

三、敏捷开发模型

    敏捷软件开发又称敏捷开发，是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。虽然在国外已经得到了广泛应用，在中国国内，敏捷开发用的还不算很多。但是随着Agile敏捷开发的流行，越来越多的公司采用敏捷开发用于软件产品和应用的开发。

    敏捷开发是一种以人为核心、迭代、循序渐进的开发方法，相对于传统软件开发方法的“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。

 

四、敏捷开发过程VS传统开发过程

    敏捷开发区别于瀑布式的特征很明显，敏捷开发是以一种迭代的方式推进的，而瀑布模型式是最典型的预见性的方法，严格遵循预先计划的需求分析、设计、编码、集成、测试、维护的步骤顺序进行，步骤成果作为衡量进度的方法，例如需求规格，设计文档，测试计划和代码审阅等等。敏捷开发过程中，软件一直处于可使用状态，它将项目分成若干相互联系、可以独立运行的子项目，因此，每个阶段软件都是可见的，客户可以直观的体验并提出意见。如果按照瀑布式流程，客户可能在签订开发合同3个月后，看到的还只是各种文档（需求文档、设计文档、详细设计文档等等），客户心理或许会不踏实。瀑布式的主要的问题是它的严格分级导致的自由度降低，项目早期即作出承诺导致对后期需求的变化难以调整，代价高昂。瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。在瀑布式开发中，需求修改的时间越靠后，成本越大，所以需求分析人员的压力很大。由于敏捷开发是迭代式的，，并且迭代周期较短，因此很容易相应新需求或是对旧需求的修改。瀑布式开发有很多文档，但敏捷开发不是没有文档，而是轻文档。在敏捷开发过程中，适量的文档还是很有帮助，有助于整理思路，加快沟通和讨论，比如概念设计文档、架构图、SWOT分析文档等等，这些文档在每个产品版本开始之前会有产生，在每个迭代的过程中根据业务人员和市场的反馈也会有一些变更。通过实践证明，这对产品的思路、沟通讨论都非常有帮助。而且这些文档，大多是几页PPT，书写和维护工作都很小。

    相比迭代式的增量开发，相同的是两者都强调在较短的开发周期提交软件。基于Scrum的迭代增量开发一般会在一个比较长的一个迭代周期频率下不断交付，同时迭代中不允许有变化的需求，这样就有一些场景让这种迭代很困难，例如紧急的技术支持、临时增加的非常高的优先级的需求等等，另外项目的估算非常难，导致不容易承诺。相比较，敏捷方法的周期可能更短，并且更加强调队伍中的高度协作。敏捷开发的原则之一是拥抱变化需求时刻在变，人们对于需求的理解也时刻在变，项目环境也在不停的变化，因此你的开发方法必须要能够反映这种现实，敏捷开发方法就是属于适应性的开发方法，而非预设性。另外，敏捷开发更适用于小型团队，在一个办公室工作，属于那种通信基本靠吼的状态，当然团队成员之间的交互会更方便。另外敏捷开发强调用户（或用户代表）要与开发团队在一起工作，便于及时沟通交流。重视交互也应该可以算是最明显的区别之一。这样还有一个好处，就是有利于团队中知识的迅速传播。即使有人离开团队，另外的人也能完成相应的工作。因此，“人与交互”被列为敏捷开发价值观之一，并排在第一位。

 

参考文献：

[1] 普雷斯曼. 软件工程：实践者的研究方法[M]. 北京：机械工业出版社，2011.

[2] 窦万峰. 系统分析与设计方法及实践[M]. 北京：机械工业出版社，2013.

[3] 梁永幸. 浅谈敏捷开发与其他传统开发方式的区别[J]. 电子世界，2012.12.