敏捷软件开发 VS. 传统软件工程　　　　

　　　　自从计算机诞生至今，程序是计算机的灵魂，程序从曾经的小型的计算功能发展到如今的神奇作用，代码行数更是几何倍数的增长。面对软件的开发，人们提出了各种方法以适应不同规模下不同软件的开发。传统方式的软件开发被人们发现越来越多的问题，敏捷开发的概念也在这么多年的编程经历下应运而生。

    　　 敏捷开发在2001年被提出，之后越来越多的从事软件方面工作的人开始接受并认同这种开发方法，与传统的软件开发方法相比，这种开发方法更注重沟通，更便利的团队结构和协作态度。正如敏捷开发的宣言所言，个体和互动高于流程和工具，工作的软件高于详尽的文档，客户合作高于合同谈判，响应变化高于遵循计划。由此可见敏捷开发更加注重的是参与到软件工程中的人员的交流，注重的是编程人员和与业务专家之间的交流沟通，频繁地交付新的软件版本，能够更好的适应需求不断变化的代码编写和团队组织形式，也更加注重了人在软件开发中的作用。

         传统的软件开发的具有连续性的步骤性特征，正如大家所知传统软件开发会有很多步骤如：需求定义，计划，构建，测试和调度。传统软件开发在过去的几十年中促进了软件开发的系统化，对于日益庞大的软件规模，传统软件开发难免会遇到一些相对难以解决的问题。

         这篇博客希望能够通过介绍传统的软件工程和敏捷开发，经过总结对别来体会不同的软件开发方法优劣。

         一、传统软件工程：

         在我们生活的这个星球上有着很多伟大的工程，正如我们所知的胡夫金字塔，它于公元前2560年建成，我们无法相信这样这样一项伟大的工程没有任何的工程管理知识，没有一定的计划性。现代的软件也是一样的，不同于简单的几十行上百行就能实现的小程序，现代软件的规模往往动辄上万行，甚至十万，百万的规模。如果没有一定的计划性，没有一种科学的方法指导我们很难去完成这样庞大的项目。

         1）产生原因：

         20世纪60年代大容量、高速度计算机的出现，使计算机的应用范围扩大，软件开发急剧增长。高级语言开始出现；操作系统的发展引起了计算机应用方式的变化；大量数据处理导致第一代数据库管理系统的诞生。软件系统的规模越来越大，复杂程度越来越高，软件可靠性问题也越来越突出。原来的个人设计、个人使用的方式不再能满足要求，迫切需要改变软件生产方式，提高软件生产率，软件危机开始爆发。虽然在这之前人们已经开始使用甘特图（如图1.1）来制定计划，但是仅仅这样还是无法满足需求。在这段时间里，软件开发的进度越来越难以预测，成本越来越难以控制往往实际成本比预期成本高了不止一个数量级，软件产品的质量越来越难以保证……软件工程在这种环境下出现。传统软件工程包含过程、方法和工具，这些工具使得快速构建高质量的复杂的计算机系统成为可能。软件过程包括了五个框架结构：沟通、策划、建模、构建和部署，这些活动适用于所有的软件项目。软件工程实践遵照一组核心原则，是一个解决问题的活动。

                                                                          　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 图1.1

         2）常见的传统软件工程的过程模型：

         1、瀑布模型（waterfall approach）

         传统的瀑布模型大致可以分为五个阶段：需求（Requirements）、设计（Design）、实现（Implementation）、测试（Test）、维护（Support）。如图1.2所示。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　图1.2

         瀑布式模型的核心思想是按工序将问题化简，将功能实现与设计分开，采用结构化的分析与设计方法将逻辑实现与物理实现分开，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。

　　　瀑布模型是最早出发的软件开发模型，在被广泛使用的几十年里它提供了软件开发的基本框架。对于瀑布模型优点很明显，为项目提供了按阶段划分的检查点，每次完成该任务时只有确保正确才会开展下一步阶段，因此使用瀑布模型使软件开发人员在软件开发的时候只需考虑当前阶段的编程任务。但是正是这种优点也带给了这种模型很大的局限性，因为瀑布模型有很强的阶段性，造成了这种编程方法面对当下复杂多变的程序设计时会很局限：1）当客户提出新的需求时因为不可逆性，逆转工作有可能会做到但是成本很大。2）使用这种开发如果在前面阶段出现问题会出现累积现象，错误会传递发挥扩大，导致成本和质量的失控。3）开发模型是线性的，用户只有等到阶段末期才能看到开发成果，加大了开发的风险。

         经过这段时间对于这些方面论文或是文章的阅读，感觉瀑布开发给人感觉是一种很奇怪的模式，也许是因为学生时期代码量的不足，以及见到的问题过少，感觉在一个项目的初期就能够构建的很完善这对制定计划，设计的人是一个很大的挑战。因此采用这种方式开发就对开发人员准确的了解每个模块实现了哪些问题，如何完成一个项目不同要求的处理顺序，怎么确定实现不同任务时需要的工程量有了很高的要求。虽然有了一个框架更容易在一个规定的时间内完成一项任务，但是很多在开发过程中产生的想法和用户在不同阶段的需求无法在这种开发模型中得到很好的实现。

         2.演化过程模型

         相对于上面的瀑布开发模型，演化过程模型开始于沟通，软件开发人员与客户先进性沟通，定义软件的整体目标，明确已知的需求，在大致了解目标之后快速的设计出一个模型，这个模型的设计主要集中在用户能够看得到的方面。然后由利益相关者进行评价，经过利益相关者的反馈信息，进一步细化软件的需求。这种开发方法的大致架构如图1.2.1所示。                                                

    图1.2.1

         优劣性：这种开发方法一方面增加了与利益相关者的交互，能够更好适应复杂多变的需求，让用户在看到一个大致框架的基础上能够在原本的想法上提出新的需求更加方便。但是这种开发方法的缺点正是因为利益相关者不一定是了解开发的人员，因为是各种各样需求堆积出的程序，就会造成很多意向不到的bug，过多的需求会让开发人员难以保证整体软件质量，会造成软件的可维护性降低。作为一个开发人员在完成当下的一个目标时可能只是想赶快实现，不会过多的考虑算法问题，随着规模的累积可能会造成了系统的冗余，软件运行速度不够理想。

         这种开发方法正像是我们学生在写大作业时候采用的方法，在大二下学期的面向对象课程中，一次作业是出租车的调度系统。这个主题连续出了3、4次问题，从开始简单的抢单，接送乘客需求，增长到了考虑道路交叉路口的红绿灯以及道路双向、立交桥问题。因为每次写作业时下次作业的需求时未知的，而作业的规定完成时间又很短，自己注重更多的是如何完成这个问题。第一次作业在寻路算法的选择上选到了相对简单但是效率不高的Dijkstra算法，而且没有进行优化，这就导致了之后的几次作业处理十分麻烦，想要去修改之前的问题却发现规模太大，或是太懒就没有进行修改。这造成了之后的作业代码效率极低，计算时耗时过长。

二、敏捷软件开发

         敏捷开发所推崇的是通过减少繁杂的计划，构造出多样的环境来简化事物，这种观念下有大量不同的方法，技术和实践。敏捷软件工程是哲学理念和一系列开发指南的综合。这种哲学理念在文章开头有所介绍，这种哲学理念推崇让客户满意的软件早期的增量发布，小而高度自主的项目团队，非正式化的方法，最小化软件工程工作产品以及整体精简开发。开发的指导方针强调超越分析和设计的发布，以及开发人员和客户主动和持续的沟通。

         在敏捷开发中开发团队是由软件工程师和利益相关者共同组成的，这个团队掌握着自己的命运，这就要求团队的成员要相互交流，相互合作。敏捷虽然能够带来很多好处，但是从本质上讲敏捷开发只是为了克服传统软件开发的弱点形成的。敏捷开发不是完全独立于传统软件工程之外。

         正如Best Practices for Large Software Development Projects这本书中所讲述的，早在软件工程的改变之前，传统工业就有一场革命。丰田汽车提出了持续改进的观念，使得丰田汽车公司飞速发展，这种观念的特征很像是从课本上了解到的敏捷开发。它注重的的是小的增幅，涉及到每个人，集体主义，团队奋斗，系统方法，强调小的投资但是非常努力维持，向人员倾斜，争取更好结果的过程。今井正明是这么描述持续改进方面：1）每天逐步的把小事情做好。2）设置和实现更高的标准。3）对待每个人都像是对待顾客。4）全面的逐步提高。

         正是这种精益生产推动了传统工业的发展，敏捷开发与这场传统工业革命有着相似之处，都是注重了人的交流，强调了和小的方面的进步。常见的敏捷开发有极限编程（XP），Scrum，动态系统开发方法，特征驱动开发。因为从未接触到这方面的开发工作，知识的获得仅仅只能通过课本。以极限编程过程为例，包含了策划、设计、编码和测试4个框架活动的规则和实践。如图2.1所示：

图2-1

         对于不同的活动：1）策划，策划开始于倾听，建立一系列用户需求的“故事”，每个故事都有自己的权值，权值是客户根据价值标注出来的，开发人员预估成本，当成本超过了3个开发周，故事将进一步细化，新的故事可以在任意时刻书写。2）设计，严格遵循KIS原则，即使用简单的表述。设计为故事提供了不多也不少的实现原则。3）编码，在故事开发和初步设计完成后，团队应当开发一系列用于检测本次发布的所有故事的单元测试，这样开发者就能集中精力于实现内容。在编码中注重的是结对编程，结对的两个人互相分工。4）测试，在编码开始之前建立单元测试是XP方法的关键因素，这种方式支持代码修改以后及时的回归测试。一旦将个人的单元测试组织到一个“通用测试集”，每天都可以进行系统的集成和确认测试。XP的验收测试着眼于客户可见的，可评审的系统级特征和功能。

         过于教条化的内容也许不是自己在这一周两周的阅读中所能体会到，但是通过阅读和自己的理解，敏捷开发注重开发中人的作用，强调了程序员团队和利益相关者之间的紧密协作，面对面沟通，频繁的交付新的软件版本。这种方法相较于传统的软件开发队伍中的人员高度协作，适用于需求不断变化的产品。 瀑布模型严格遵守了顺序执行，用户可能在开发的前期只能看到一个个文档，无法看到自己需要的产品是否是开发团队正在做的。而敏捷开发擅长于及时和客户交流，是一种周期短的迭代式开发，虽然不重视文档但是还是有适量的文档，这些文档在开始时产生的在不断的开发中也会随之变化，指导软件的开发。更多的是需要团队成员的交流。

         敏捷开发在我理解里和传统制造业中的丰田很相似，明白实现目标的优先级，当产品经理或者客户提出需求时开发人员可以互相沟通，能够明确开发的目标和每个人的任务。面对打的任务要求细化任务，每个人负责一部分，Do little things gradually better every day.开发的时候开发人员因为需求比较细更容易吃透需求，理清逻辑，有问题时能够及时和同事或者产品的需求人员交流。在开发的过程中负责人员能够根据任务需要进行人力资源的分配。测试要求了开发一个功能就跟进一个功能的测试，这样一方面有效的解决了问题累积的可能性，另一方面减轻了最后统一测试的压力。

       但是敏捷开发对于整个团队的需求会更高，传统的软件开发对于制定计划的人要求比较高，在面对手下的人员良莠不齐的情况下提前制定好了计划，就不是很需要成员相互交流，这样水平低的开发人员在开发中只需要做好自己分内的事情就可以了，全部的目标就是完成自己的代码。如果对于这样的团队要求敏捷开发就会出现大牛和水平低的人聊不到一块，大家注意到的内容不一样，最后可能无法形成良性的循环。对于团队规模来说一个很庞大的团队在执行敏捷开发时的难度要高于传统软件工程的，如何协调大团队之间交流成本比大家埋头苦干自己分内的事情要大的多。

三、总结

         敏捷开发虽然在外表上和传统软件工程差别很大，但是敏捷不是万能的，敏捷开发中也脱离不了传统软件工程的精华，相较于传统软件工程敏捷开发像是一个走迷宫的小老鼠，每一次在尝试，都在改变，面对复杂多变的变化能够不断修正自己的方向，一步步走出迷宫。传统软件工程注重了过程的统一性，要求了阶段性，虽然面对变化反应迟缓，开发周期很长，但是对于成员的要求要比敏捷开发低，在固定了开发目标的前提下出错率更好保证。面对需求越来越多变的当下敏捷开发能够更好的适应，但是敏捷开发使用的团队整体素质需求相对高，而且要求差距不能过于明显。无论是敏捷开发还是传统开发都各有优劣，选择团队最合适的开发方法才能更好的完成任务。

四、参考文献

[1].Roger S Pressman,软件工程——实践者的研究方法（第七版）,机械工业出版社

[2].Thomas Stober;Uwe Hansmann,     Best Practices for Large Software Development Projects ,  Springer Publishing Company, Incorporated, 2010

[3].David Cohen, Mikael Lindvall, and Patricia Costa,Fraunhofer Center Maryland,    Agile Software Development( DACS State-of-the-Art/Practice Report)

[4].浅谈敏捷开发与其他传统开发方式的区别  作者：梁永幸 

[5].敏捷开发之Scrum扫盲篇 作者：Taven.李锡远 出处：http://taven.cnblogs.com/

敏捷软件开发 VS. 传统软件工程