敏捷软件开发与传统软件工程

一、传统软件工程

“软件工程”的概念在1968年召开的一个当年被称作“软件危机”的会议上首次提出。当时，由于软件系统的规模越来越大，复杂程度越来越高，用户需求的不明确，软件开发出现项目延迟、成本难以控制、产品不可靠难以维护等现象，软件危机开始爆发。为解决软件危机，逐渐发展起软件工程。软件工程是借鉴工程化解决方案，来分析、设计和编制软件， 并保证其能按要求运行。

最初的软件开发过程模型起源于更一般的系统工程过程，其典型模型如瀑布模型。在开始工作之前，对所有过程活动制定计划给出进度安排。其主要阶段直接映射基本开发活动：需求分析和定义，系统和软件设计，实现和单元测试，集成和系统测试，运行和维护。其每个阶段的结果是一个或多个文档，直至上一个阶段结束下一个阶段才能开始。如果当前阶段发现问题，则需返回上一阶段进行修改。

瀑布模型：

二、敏捷软件开发

随着 21 世纪的到来，软件产品需求的普遍性日益增加。用户需求的多样性、个性化和不断变化是这一时期软件产品的特点。在这种情况下，传统的软件工程管理理论越来越不适用，人们开始对软件开发过程的定位重新进行思考，试图探索一种新的管理方法。2001年2月在美国犹他州的雪鸟城召开了软件开发大会，会议的结论就是“敏捷宣言”。这份宣言是敏捷管理方法诞生的标志。

敏捷开发的四个核心观点为：（1）人与人的交互：优先于过程和工具。在传统软件工程当中人在软件开发过程中的作用相当于可随时替代的资源，而敏捷开发更强调人本身的作用，没有任何过程方法能代替开发团队中成员本身。在此之上，成员之间的交流直接通过面对面的直接交互则强于通过文档二次交流可能发生的理解偏差。（2）可以工作的软件：优先于求全责备的文档。此观点强调则通过已经完成可以工作的软件可以更好的给客户看到已经完成了什么，文档再完备也无法完全展示出项目的实际效果。直接面对一个可以工作的软件客户可能才知道其真正需要的是什么，才能及时进行需求的描述更改。其最终交付的产品是软件，而不是文档。在一系列阶段活动中文档所起到的作用应是辅助，不能作为真正的衡量标准。（3）客户协作：优先于合同谈判。在软件开发中客户和软件开发人员应成一种互相协作的关系。合同的作用在于使双方可受法律保护，是必须的基础。但在此之上，比合同谈判更重要的是双方的相互合作，仅通过书面的文档，客户可能无法完备准确地描述其需求，开发人员也可能会对客户的实际需求有所偏差，并且在开发过程当中客户也可能会对软件的需求随时做出改变，所以敏捷开发强调业务人员和开发者能在整个项目过程中能始终在一起工作，以快速应变需求的变化及时得到客户反馈。（4）随时应对变化：优先于循规蹈矩。传统软件工程在软件开发之前进行需求分析，希望在开始时尽可能全面的确定需求，之后就只需根据计划循规蹈矩完成。但实际上需求本质上是易变的，变化本质上才是常态，敏捷开发强调拥抱变化，可以随时应对变化，通过频繁迭代开发，不断交付有部分功能的产品给客户获得反馈，不断调整以响应客户的需求变更。

敏捷管理方法有好多种，其中 XP 方法（极限编程）是其中应用最为广泛的方法。它是一个轻量级的、灵巧的软件开发方法；同时它也是一个非常严谨和周密的方法。它的基础和价值观是交流、朴素、反馈和勇气。程序员之间紧密的相互交流,程序员也和客户紧密的交流。设计上保持简单明了。项目一开始,就强调通过对软件的不断测试来获得反馈,程序员尽可能早的把软件交给客户,并实现客户对软件需求提出的变化,有了这些基础,程序员就可以自信的面对需求和软件技术的变化。XP是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期；通过积极的交流、反馈以及其它一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。

三、理解比较

通过查阅资料对这两种开发方式进行比较，敏捷软件开发相较于传统软件工程的其中一个特点在于其所写文档的大量减少，从而减少了工作成本，传统软件工程需要进行大量的文档撰写，以瀑布模型举例，每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务，且前一阶段的输出文档是后一阶段的输入文档。只有前一阶段的输出文档正确,后一阶段才能获得正确的结果。但在开发中一旦本阶段出现问题就需要向上返工，文档也需重新修改编写交付，很多时候客户会不断对需求进行补充更改，甚至可能会到在最后交付时才发现并不是真正需要的，由此导致不仅是软件本身，更多是文档的重新编写，此种情况下文档编写成为一种对工作资源的浪费，故敏捷开发强调软件优于文档。但敏捷开发也不意味着就不需要文档，只是简化掉其中不必要的部分，如果把必须的文档仅以口头的方式进行传递则会增加项目的风险。第二是敏捷开发更强调对需求的适应性，传统软件工程在开始阶段就对一个软件项目定下长期的详细计划，尽可能全面的定下软件的所有需求，之后只需按照已定计划进行开发。然而在软件的实际开发过程当中，很难做到在开发的初始阶段就把所有的需求都定下来，且客户的需求随时会变，一旦发生这些情况，就要进行大量的返工工作，所以传统软件工程更适于一旦需求定下就不再做更改的项目。而敏捷开发，采用迭代式开发，每次向客户提交一个可以工作的具有部分功能满足部分用户需求的软件，在此过程中随时保持与用户的交流，获取到用户的反馈后，再对程序软件进行调整达到要求后再进行下一功能需求的开发，以此可克服开发过程中的频繁需求变更，减少设计的错误，达到更好的适应性。第三在于敏捷开发也更强调人本身的因素。更关注开发团队中成员之间的直接面对面交流，开发人员与客户间的协作。由于客户的参与，开发人员对于需求的要求不是很严格，但通常需要较强的技术支持。而且由于成员之间需要进行频繁的直接交流，故其项目成员较少，人员的流动会导致对项目的影响较大，大型的项目则不太适宜敏捷开发。但在传统软件过程中对于人在其中的作用则是可以被替代的资源，人员的流动则不会对软件开发构成影响。

相较而言，传统软件开发更适合于客户需求基本保持不变，具备固定需求的大型项目；而敏捷开发则适合于需求变化快人员流动小的小型项目。

参考资料：

[1]软件工程 原版：lan 译版：程成，陈霞译，机械工业出版社

[2]敏捷方法与经典软工的较量 莫映

[3]敏捷管理方法在软件开发中的应用 李远

[4]基于敏捷软件开发的软件工程教学研究 管林挺，顾沈明

[5]基于敏捷的软件过程进化 胡君