敏捷软件开发 VS 传统软件工程
0.引言
“软件工程”是在1968年召开的一个被称为“软件危机”的会议上首次提出。我们知道计算机最早应用于军事领域，当时的计算机硬件配置性能等也较低，当时的程序的特点就是反应快速、占用空间小等。而随着计算机科学技术的发展，计算机的应用范围越来越广，与此同时，使用者对软件系统的功能要求越来越高，随之而来的就是软件系统自身复杂程度和开发难度在不断加大。那个时代的单个的软件开发技术已经不能扩展而应用到大型的复杂的软件系统中，软件项目有时要延迟几年才能完成，且比预计费用高、不可靠、难以维护等，也就是俗称的“软件危机”。在这背景下，“软件工程”的概念随之产生。而这么多年，软件工程这门工程学科也在不断发展，而根据软件过程分为计划驱动过程和敏捷过程两类，软件工程中也有传统软件工程和敏捷软件工程。
1.传统软件工程
传统软件工程的软件过程为计划驱动过程。计划驱动的过程是提前计划好所有的过程活动，然后按计划去考核程序的执行。也就是说在开始工作之前，必须对所有的过程活动制订计划并给出进度安排。
图 1
传统软件工程最具代表性的软件过程模型就是瀑布模型，如图1，瀑布模型将基本的过程活动如需求分析，系统设计、开发、系统测试等，看成是一些界限分明的独立的过程阶段。每个阶段的结果是一个或多个经过核准的文档。直到上一个阶段完成，下一阶段才能启动。然而在实际过程中，这些阶段经常重叠。在设计阶段，可能发现需求中的问题，在编程阶段，又会发现设计中的问题，以此类推。所以这不是一个简单的线性模型，包括对开发活动的多个反复。每一阶段产生的文档都可能在后续的阶段被修改以反映发生了的变化。
因为生成和确定文档成本很高，所以反复是昂贵的并且十分费时。因此在经过少量反复后要冻结部分开发过程，继续进行后面的开发阶段，剩下的问题留着以后解决或者忽略掉，或者在编程中想办法绕过去。但是这样又会带来新的问题，在最后的生命周期阶段，软件进入使用状态，最初的软件需求中的错误和省略部分这时就会暴露无遗，设计阶段和编程阶段的错误此时也都浮现出来，所以系统必须进化以保持实用，需要对早先的一些过程阶段进行重复。
瀑布模型每一个阶段都需要生成文档，使得过程可见，对于管理者而言使得根据项目计划监控项目过程成为可能。主要问题在于它将项目生硬地分解成这些清晰的阶段，关于需求的责任和义务一定要在过程的早期阶段清晰界定，意味着瀑布模型对用户需求变更的响应较困难。
综合以上这些特性，只有在对需求了解得好，而且在系统开发过程中不太可能发生重大变更的时候，适合采用瀑布模型。而在其他一些情况下，比如全球性快速变化的环境中，采用传统软件工程开发会错失许多机遇，“敏捷软件开发”概念随之产生。
2.敏捷软件开发
在20世纪80年代和90年代初，人们所认为的取得好的软件的最好方法是：需要通过仔细的项目规划和形式化质量保证，采用CASE工具所支持的分析和设计方法，遵循受控的和严格的软件开发过程。这些观点来自软件工程领域中关注大型、长生命期且是由大量单体程序所构成的软件系统的开发的那些人。当这种开发方法应用于小型或者中等规模业务系统时，大部分的时间花在系统应该如何开发而不是花在程序开发和测试上。当系统需求发生了变更，反工就是很严重的问题，描述和设计都需要随着程序改变而改变。基于以上众多不满的软件开发人员在20世纪90年代提出了新的敏捷开发方法。
敏捷开发方法允许开发团队将主要精力集中在软件本身而不是在设计和编制文档上。背后的基本原理体现在敏捷宣言中，宣言如下：
我们在开发过程中发现更好的软件开发方法，并帮助他人这样做。通过这项工作我们的到如下评估:
个体和交互胜过过程和工具；
编写软件胜过书写详尽的文档;
用户合作胜过合同谈判；
响应变更胜过遵循计划；
与就是说，虽然右边的项有价值，但我们更重视左边的项的价值。
敏捷方法普遍依赖于迭代方法来完成软件描述、开发和交付，最适合系统需求在开发过程中快速变化的类型。最有名的敏捷方法为极限编程也称为XP编程。其他敏捷方法包括Scrum,Crystal,适应性软件开发，DSDM和特征驱动开发等。这些方法的基本原则都是相同的，都基于敏捷宣言，原则如表所示：
| 原则 | 描述 |
| 客户参与 | 客户应该在开发过程中始终紧密参与其中。他们的作用是提供新系统的需求、对需求排序并评估系统的迭代。 |
| 增量式交付 | 软件以增量的方式进行开发，客户指定在每个增量中将要包含的需求。 |
| 人非过程 | 开发团队的技术应该得到承认和发扬，团队成员应该保持他们自己的工作风格，不落俗套 |
| 接受变更 | 预料系统需求的变更，并设计系统使之适应这些变更 |
| 保持简单性 | 致力于所开发的软件和开发过程的简单性。只要可能，就积极地去排除系统中的复杂性。 |
接下来介绍一下极限编程，一听其名就觉得非常高大上有木有。它的基础和价值观是交流、朴素、反馈和勇气；即，任何一个软件项目都可以从四个方面入手进行改善：加强交流；从简单做起；寻求反馈；勇于实事求是。XP是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期；通过积极的交流、反馈以及其它一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。
在极限编程中，所有的需求都表示为脚本（称为用户故事情节），它将被直接实现为一系列任务。程序员在写代码之前为每个任务开发测试，在新的代码加入到系统中时，所有的测试都必须成功执行。如图2是一个软件XP过程，它产生了正在开发的系统的一个增量。
图 2
极限编程包含多个实践，如图3所示。在XP过程中，客户亲密投入到系统需求的定义和排序工作中，系统客户是开发团队的一份子，与其他团队成员一起讨论脚本。同时用一个所谓的“脚本卡”封装客户需要。然后开发团队瞄准这个目标在软件的将来版本中实现这个脚本。脚本卡是XP规划过程的主要输入，一旦其被做出，开发团队就把脚本拆分为任务并估计实现时所需的人力与资源。客户然后对脚本进行优先权排序以便实现，选择马上能使用的脚本尽快交付可用的业务支持。极限编程将增量式开发推向极致。新的软件版本一天之中要构造许多次，移交给客户的增量大约是每两周一次。从不拖延发布的截止时间，若有开发问题，将咨询顾客，并将功能从计划发布的版本中删除。
图 3
3.传统软件工程 VS 敏捷软件开发
软件开发的敏捷方法认为设计和实现是软件过程的核心活动而将其他活动如需求的导出和测试合并到设计和实现活动之中。相对而言，传统软件工程的计划驱动方法识别软件过程中的每个阶段及其相关输出。前一个阶段的输出作为规划接下来的过程活动的基础。
随着人类社会的发展，当前的业务都是处于全球性、快速变化的环境中的。机遇稍纵即逝，竞争也无处不在，而当今的各种业务也都和计算机和软件有着千丝万缕的联系，软件几乎是所有业务运行中的一部分，在这样的大环境下，对于软件公司非常重要的一点就是新的软件要迅速地开发出来以抓住新的机遇，应对竞争压力。事实上如今许多业务都宁愿牺牲一些软件质量、降低一些需求来赢得快速软件交付。
而由于业务运行在一个变化的环境中，实际上通常不可能导出一个完全的和稳定的软件需求，只有当系统交付且用户在有了一定系统经验的时候真正的需求才被发现。而在软件过程中，需求的变更也随时可能发生。这种情况下瞄准快速软件开发和交付的开发过程就十分重要，也就是说我们需要采取敏捷软件开发方法。
当然在实际过程中敏捷方法也会遇到诸多问题。首先让客户参与到开发过程中的想法虽然很吸引人，但它的成功依赖于有意愿加入进来且愿意在与开发团队沟通上花时间的人，且此人还要能代表所有信息持有者；其次对变更做出优先级排序是很困难的，尤其有多个信息持有者，每一个信息持有者都会根据自己的利益给出一个优先级排序；还有就是迫于交付时间的压力，团队成员没有时间执行系统简化过程；而最后还有一个非技术问题确实实际过程中十分重要的也就是写合同，软件需求文档总是客户和供应商之间合同的一部分内容，所以，敏捷开发依赖于客户根据系统开发所需要的时间来支付费用，而不是根据需求描述来支付费用的合同，假如合作过程一切顺利还好说，但是问题一旦出现，双方可能会就谁来负责为解决问题花费的额外时间和资源而争执。因此对于许多大型机构的官僚办事程序以及一些政府部门而言可能更加倾向于传统软件工程这样计划驱动的比较好拟定合同的方法。
虽然目前的业务系统中，敏捷开发更为流行，然而在某些领域传统软件工程的计划驱动方法目前是敏捷开发无法替代的，如安全要求极高的控制系统，对其完整的系统分析是十分重要的，而这要求开发者有着非常专业的知识和技能，这种情况下采用计划驱动就是十分恰当的。
实际上，项目被划分为计划驱动的还是敏捷开发的并不重要，最终软件系统的购买者主要关注的是这个可执行软件能否满足他们的要求，是否对个人用户或机构有用。在实践中许多声称使用了敏捷方法的公司接受了某些敏捷实践，并将它们和计划驱动过程集成在一起。最后借用一句话，“黑猫白猫，捉到老鼠的才是好猫”。（PS.当然现在的猫大多数不捉老鼠了）
参考文献 ：【1】软件工程（原书第9版）
【2】软件工程的历史和发展趋势_王芳
