敏捷软件开发与传统软件工程的比较

            软件工程的开发过程中有两种不同的管理和开发体系，一种是基于“瀑布模型”的预设性传统软件工程，另一种是轻量级的适应性敏捷软件开发。本文简单阐述传统软件工程的开发方法与敏捷软件开发的区别，并通过“瀑布模型”和SCRUM方法的比较来探析传统软件工程与敏捷软件开发的异同。最后得出，把传统软件工程和敏捷软件开发相结合，将架构“颗粒化”，在简单可快速交付的敏捷软件开发中嵌套系统的传统软件开发方法，实现预见性和适应性折中。

        随着计算机的发展，对软件的需求越来越大，软件的规模也变得越来越大，结构越来越复杂，软件开发管理困难而复杂，在这个“软件危机”背景下产生的传统软件工程，用工程化的方法构建和维护有效和高质量的软件。暂时解决了软件的兵荒马乱时代，但随着社会和科技的发展，对软件的需求变化越来越快，传统的软件工程很难再适应瞬息万变的客户需求，敏捷软件开发应运而生，其轻量级、简单、可快速交付、适应性强收到开发团队的青睐，与传统软件工程并肩，形成软件工程中的两大开发体系。

（1）传统软件工程

       基于“瀑布模型”的传统软件开发方法中，以软件架构为核心，采用结构化的设计和分析方法将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动。并规定他们自上而下，相互衔接的顺序，如同瀑布的流水一般，各个阶段的通过文档相互流通。前期就要设计好整个软件大厦的框架来指导和支撑后面各个方面的开发和维护工作，后面在根据前期设计的蓝图来逐步实现。由架构师完成软件架构设计，开发人员再根据软件大厦的蓝图进行软件开发。这种开发方法的优点是，超前的预见性和每一阶段都要通过严格的审查才能进行下一个阶段，保证了软件的质量。缺点是，软件的框架一旦确定下来就很难改变，甚至会牵一发而动全身，难以适应变换莫测的客户需求。由于各个阶段要自上而下相互衔接，各个阶段的沟通要通过大量臃肿、复杂的文档来传递信息。

       瀑布模型是Winston Royce在1970年提出的一种软件开发模型，瀑布式开发是一种传统的计算机软件开发，是最经典的预见性软件开发方法，严格遵守计划、分析、编码、测试、维护的步骤。阶段之间通过文档流通，每个阶段结束时要进行严格的审查，检查功能设计和实现是否符合上阶段流下了的文档的要求，如果不符合就逆流到上个阶段检查并修正，以此往复，直到流到最后阶段产品通过测试后进行发布及运行期间的维护。

       三个阶段：定义阶段、开发阶段和维护阶段。开发阶段架构师要有预见性地分析客户现在的需求以及以后可能变动的需求，设计规划好大量的功能需求和非功能需求，尽可能多地满足客户后面需求的变动，避免日后重构软件框架带来的成本亏损。设计包括UML图，API接口，数据库表等。开发阶段开发人员根据架构师的对客户需求分析以后设计的蓝图进行软件的开发和测试，实现用户的需求。运维阶段开发团队根据用户使用软件的体验、反馈、软件存在的bug和新增功能需求对软件进行维护，保证软件在保证鲁棒性的前提下尽可能地满足客户的需求。

六个流程：制定计划、需求分析、软件设计、程序编写、软件测试和运行维护。

       瀑布模型的特点：强调文档：瀑布模型每个阶段之间的沟通和交流就是文档，上一个阶段的输出就是下一个阶段的输入，文档就是前后阶段衔接的介质。缺少开发人员之间面对面的沟通和交流，造成文档臃肿现象。结构明显：按需求分析将整个工程划分为完整的阶段集合，每个阶段都有明确的检查点，当出现问题可以使用顺藤摸瓜式往上检查。当一个阶段结束后通过严格审查，就可以只关注下一个阶段，出现问题再逆流检查。

（2）敏捷软件开发

       2001年由17位业界专家构成的敏捷开发联盟成立，联盟起草了敏捷宣言：个体与交互胜过过程与工具；可用的软件高于复杂的文档；客户的合作胜过合同的谈判；响应变化胜过遵循计划。敏捷软件开发是一组重视人的主观能动性和开发人员、管理层和产品负责人的沟通，通过迭代式和增量式软件，追求便捷，可快速交付，及时响应客户需求变动的软件开发管理方法。

       敏捷软件开发方法体系主要包括：SCRUM、XP（极限编程）、CRYSTAL（水晶编程）、PPD（特性驱动开发）等。敏捷软件开发的一个精髓就是“刚刚够”思想。用逐步实现的思想替代完整架构，每一步的需求和人员及其沟通、开发成本都刚刚好，通过不断地迭代，在迭代过程中响应客户需求的变化，实现最紧致成本，体现“刚刚好”思想。同时对每次迭代的反馈进行讨论和思考，总结经验和吸取教训。

SCRUM方法：

       在敏捷软件开发中，软件项目被切分成很多个子项目，通过选取优先级较高的一组子项目作为敏捷迭代的球心进行迭代，每次迭代都有明确的需求、目标、人员、并且每次迭代之后都要有可交付的产品。就好比从山顶滚雪球，选取优先级较高的需求作为首次迭代的球心，经过增量式迭代，每次迭代加带一定的需求滚下山，下山就可以形成可交付的产品。

三个角色：管理层（Scrum Master）、产品负责人（Product Owner）和开发团队（Team）。

       三种工件：产品列表（Product Backlog）、迭代列表（Sprint Backlog）和燃尽图（Burn Down Chart）。

       四个会议：Sprint Plan Meeting（Sprint计划会议、需求评审会议）、Daily Scrum Meeting（每日站立会议）、Sprint Review Meeting（验收会议）和Sprint Retrospective Meeting（Sprint回顾会议）。

五个步骤：

（1）Product Owner根据需求的优先级确定一个排序好的Product Backlog;

（2）Scrum Team通过Sprint Plan Meeting根据Product Backlog按优先级选出一组需求作为迭代的目标，即Sprint Backlog。这个阶段一般的时间是4周。

（3）Scrum Team完成Sprint Backlog过程中需要每天都要进行Daily Scrum Meeting,每个人都要汇报所完成的进度和遇到的问题，总结经验，通过Burn Down Chart记录工作的整个过程。

（4）当本次Sprint把Sprint Backlog都实现完之后进行Sprint Review Meeting,这个会议总管理层和产品负责人以及开发团队都要参加，讨论本次Sprint交付的产品，以及根据产品负责人的需求变动及时调整。

（5）最后进行Sprint Retrospective Meeting，回顾本次迭代整个过程中遇到的问题，以及解决方案，为下一轮Sprint做准备。

      总结：

（1）敏捷开发与传统软件开发的比较

敏捷开发的优点是轻量级、简单、可快速交付、最大的特点是高度透明、检验和适应，注重开发团队之间以及开发团队与客户的及时沟通，主张响应需求变化，但是不够系统。

传统软件架构的优点在于预见性和系统性，能在正式开发前预见软件的功能需求和非功能需求，最大的特点是重视文档和结构明显，主张固定的流水开发，很难响应客户需求的变化，难以保证开发的灵活性。

（2）敏捷开发与传统软件工程的融合

将具有系统性和预见性的传统软件工程架构嵌套到敏捷开发的每次轻量级的迭代中，将软件架构颗粒化，嵌套到整个敏捷开发，使软件工程兼具软件架构的预见性和敏捷开发的适应性，根据项目的大小来调整嵌套的程度，根据每次迭代项目的大小来选择不同的架构，实现敏捷开发与软件架构融合的双赢。