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

北航计算机学院 14061157 李奕成

引言

软件开发过程是软件工程中相当重要的一环。一个正确、高效的软件过程能够提高软件工程活动的稳定性、可控性和有组织性。但是，并不存在一种软件过程能够完美的适应所有的软件工程情况。因此，在不同情况下选择合适的软件开发过程显得尤为重要。现代软件工程方法必须是“灵活”的，也就是要求软件工程活动、控制以及工作方法适合于项目团队和要开发的产品。

说到软件工程、敏捷开发，就要提到软件过程的发展历史。20世纪60年代，不存在现代意义上的软件工程，软件规模小，以作坊式开发为主。到了70年代，由于硬件技术的飞速发展，软件需求、软件规模迅速扩大，引发了软件危机。之后出现了软件工程，这种控制软件项目开发的社会学习的过程。但是到了90年代，软件过程控制越发臃肿，软件开发失败的经验促使过程被不断的约束、限制。软件开发过程变得效率低下、对用户需求的响应变慢，渐渐显露出传统软件工程的弊病。新世纪以来，由于互联网技术的发展，需求变化更快，产品迭代也更频繁。轻量级的，以追求高度灵活、效率为主要目标的敏捷软件开发方法被普遍认可，并在一定程度上成为软件工程的思想之一。

本文将主要介绍传统软件工程的两个重要模型，以及敏捷软件开发中最为广泛的极限编程，以及一小部分个人理解。

传统软件工程

传统软件工程的过程模型主要可以分为线性过程流（顺序执行软件工程的沟通、策划、建模、构建、部署这五个步骤），迭代过程流（在执行下一个步骤之前重复执行之前的一个或多个活动），演化过程流（采用循环的方式执行各个步骤），并行过程流（将一个或多个步骤和其他步骤并行执行）。这些过程流对应一些惯用过程模型，即瀑布模型，V模型（加入一定反馈的瀑布模型），增量模型，原型开发模型，螺旋模型，协同模型，形式化方法模型，统一过程模型。

螺旋模型：

图片来自网络

螺旋模型是开发大型系统和软件的理想方法，它结合了迭代的性质以及顺序过程的系统性、可控性。因而具有快速开发越来越完善的软件版本的能力。螺旋模型将软件开发这一完整过程，划分为一系列的开发版本，早期的迭代完成概念上的原型，后期的迭代则将软件开发到用户需要的样子。因为用户能够很早的看到软件的原型，因此减少了需求、功能错误的风险，而且每一次迭代可以说是平均了软件工程的风险。

当然，螺旋模型也有其缺点。因为软件开发涉及到多次的迭代、演化，因此整体的风险需要严谨的评估，也因此难以说服客户演进的方法有效且可控。

形式化方法模型：

这类模型虽然应用不是很广泛，却是非常重要的一类。生活中有很多行业，需要开发逻辑严密，稳定性超高的软件。这些要求注定是普通的传统软件工程模型难以完成的。形式化的方法使用严格的数学符号来确定软件开发任务，定义软件功能、需求，而不是依赖于评审和宽泛的设计。形式化的方法能够有效的提供一定程度内无缺陷的软件。

图片来自网络

这类软件的开发成本较高，需要较高的从业者门槛，也需要客户能够有相应的知识。形式化的方法模型一般被应用于国防、重要基础设施（医疗、商业）等方面，是非常重要的一类开发模型。

在传统软件工程的这些方法中，线性过程模型确实适用于需求定义清楚且稳定的软件开发。演化过程模型，能够快速的产生工作产品，即软件的早期版本，适用于所有的软件工程活动，从早期概念产品开发到最终的长期的软件维护。并发过程模型为软件团队解决重复和并发活动的方法。形式化方法模型强调采用数学进行形式化的软件开发与验证。统一过程模型则强调用户用例驱动，突出软件架构的核心地位，考虑到可能的迭代以及增量。

当软件工程越发庞大、臃肿的时候，人们发现工期往往不够，需求的过度修改导致成本，风险不断上升，传统的方法似乎越来越难以适应信息时代的软件开发。在这样的背景下，敏捷开发方法出现了。

敏捷开发

敏捷软件开发最重要的理念已经被高度概括在了“敏捷软件开发宣言”中，即“个人和这些个人之间的交流胜过于开发过程和工具。可运行的软件胜过于宽泛的文档。客户合作胜过于合同谈判。对变更的良好响应胜过于按部就班地遵循计划”。实际上，敏捷方法的出现是为了克服传统软件工程中认识和实践的缺点。

敏捷开发的出现，主要是为了应对软件开发过程中的不确定性。这也是传统软件工程最难以应对的一点。实际上计算机技术飞速发展，市场环境变幻莫测，用户需求不断更改。不确定意味着变更，变更意味着要付出高昂的代价，不论是时间上，还是经济上。另一方面软件工程师不是机器人，并不是每个人都擅长完成传统软件工程中的各个步骤的方法，尤其是文档作为交流的主要方式就难以让所有人接受。因此敏捷开发强调人的作用，而希望避开死板的计划、结构。正如Ken Schwaber所说“团队应确定他们预期能在迭代内完成多少工作，并承担这些工作。没有什么能比让别人来分派任务更让团队感到沮丧的，也没有什么能让自己负责以履行承诺更让团队倍感欣慰的了。”

图片来自网络

极限编程：

极限编程（eXtreme Programming，XP）是敏捷开发使用最为广泛的一个方法。五个主要的要素是：沟通、简明、反馈、鼓励和尊重。沟通是指XP方法强调工程师之间、工程师与客户之间，进行充分、紧密的口头交流，而避免大量的文档。简明，则是体现在设计上，XP限制开发者进队当前需求进行设计，不考虑长远需求，如果今后需要改进设计，那么支持之后的重构即可。反馈则是某种程度上的测试，软件本身、客户、其他团队成员均可以对团队，对软件开发形成反馈。鼓励和尊重则是强调了极限编程充分体现敏捷开发中“以人为本”的理念。

敏捷开发还有一些独创性的活动方法，比如每日站立会议，敏捷测试，持续集成，结对编程等等，可以说这些方法拜托了传统软件工程，看文档、工作、写文档的循环，能在一定程度上给团队成员一种协作的感觉，让团队更有凝聚力。这种给成员带来的心理上的积极印象也是不容忽视的。

当然，敏捷方法会在另外的方面出现一些缺点。敏捷开发要求项目的利益相关者参与到开发过程中，但是客户和研发团队的工作习惯能否协同是一个问题。而对研发团队来讲，如何从传统的管理模式、研发模式中转换过来，这也是一个问题。管理者可能将传统思维带到敏捷开发中，导致敏捷开发的项目进行了错误迭代和迭代开发产品，敏捷开发是不要试图发送一次完成的功能，而是让它随着时间的推移来完成。更重要的是，如何在敏捷开发中确定一个标准，使敏捷开发有标准可以依照，但同时又不会导致传统方法的缺点出现。

个人理解

软件工程所选用的模型，感觉上也是在寻找平衡，即开发的灵活性和开发的结构性的平衡，既要保证项目在一定程度上足够灵活的应对各种需求的变化、人员的变化等，另一方面，也要保证项目的进展结构足够形式化、规格化。而传统的软件开发模型是侧重后者，就是尽量保证软件工程的结构化，让各个环节稳定推进，最终产出产品。敏捷开发则是侧重前者，用各种方式，提高人员的沟通效率，开发效率，以及需求更改时的重构效率。可以说，传统的软件工程方法，是项目驱动，计划驱动，而敏捷开发则更多的倾向于以团队驱动，以客户驱动。

不论怎样，就像Jim Highsmith所挖苦的：“传统方法学家陷入了误区，乐于生产完美的文档而不是满足业务需要的可运行的系统。轻量级方法或者说敏捷方法学家是一群自己为了不起的黑客，他们妄图将其手中的玩具软件放大到企业级软件而制造出一系列轰动”。我认为这句话正是对软件工程中，所选用的过程模型的一种警戒。如果你发现自己是其中的某一类的话，那么说明你没有正确的使用任何一种开发方法。

参考文献

《软件工程--实践者的研究方法 》

《中国敏捷软件开发成功实践案例集》

http://www.oschina.net/translate/5-agile-development-failure-signs

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