本篇博客分别基于软件开发生命周期和范围管理这两个不同的方面对传统软件开发方法和敏捷软件开发方法进行分析比较，希望与读者分享交流。
传统方法：
从本质来讲，传统软件开发方法是一个软件开发架构，其开发过程是通过一系列阶段顺序展开的。通常，这一方法不能很好地表达和描述用户的需求，而且在项目整个开发周期的所有阶段都有需要不断完善的文档。
敏捷方法：
软件行业飞快发展，软件技术不断创新，客户期望迅速变化，考虑到需要克服传统开发方法的缺点，敏捷开发在近十年来兴起，以其灵活性，易操作性得到软件行业的广泛关注。敏捷方法通过使用迭代、早期测试和客户协作来处理不稳定的需求，在项目的整个开发周期中不断改进，从而使得敏捷开发方法能够尽快提供业务价值。也因此，在过去几年中，敏捷软件开发已经成为一种极具前景的复杂性方法，并提出了各种敏捷方法，其中包括被广泛应用的极限编程（XP）。
一、传统方法与敏捷方法基于软件开发生命周期法的比较
软件开发生命周期（SDLC：software development life cycle）是指软件开发的全部过程、活动和任务的结构框架，其一般步骤包括：确定问题、可行性分析与开发计划、收集需求、分析与设计、编码开发、测试、安装、维护。
软件开发生命周期法也称为结构化系统开发方法，将这一概念进行工具化，就得到了软件开发生命周期模式。通过软件开发生命周期模式，能清晰、直观地看到软件开发的全过程。
1、传统软件开发生命周期模式
传统模式阶段划分分明，项目需求的细节要求在开发之前给定，并且要求用户需求明确，只有在正确的需求下才能得到正确的下一步结果。与此相对应的，每一阶段没有得到相应的文档，是无法进行下一阶段工作的。开发过程中客户不会参与。这也往往会导致最终开发软件与顾客理想软件有差距。瀑布模式是传统方法最典型的代表，其生命周期图如图1所示。
在实际的软件开发过程中，软件的需求往往是变化的，而瀑布开发模型很难适应这种变化。针对瀑布模型的这一不足，又出现了螺旋模型和统一过程开发模型，但仍然无法很好地适应需求的快速变化。
2、敏捷开发生命周期模式
不同于传统模式，敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。所有的迭代（不论长度）都有相同的模式，这也是敏捷开发规律的一部分。在敏捷开发中，软件项目在构建初期被切分成多个子项目（得到大概的需求和架构模型），各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。由此，敏捷开发的生命周期由多个迭代过程完成，在迭代的每次过程中都要重复分析、设计、编码等，如图2所示。
敏捷方法允许变化可以随时随地发生。极限编程（XP）是较为典型、最为完善的敏捷开发方法。XP作为一种近螺旋式的敏捷开发方法，将复杂的开发过程分解为一个个相对比较简单的小周期，通过与客户积极的沟通、反馈以及其它一系列的技术方法，这一过程使得开发人员和客户都可以非常清楚开发的进度、变化、待解决的问题和潜在的阻力等，并根据实际情况及时调整开发过程。XP的生命周期如图3所示，它首先创造一个候选架构，然后通过一个关于整个系统运作方式的简单描述来指导全部开发过程，而不需要提前进行详细架构设计。
3、比较讨论
传统方法在开发初期和客户沟通，获取尽可能明确详尽的需求，其开发软件的过程往往是客户与开发团队的利益博弈的过程，所以在开发过程中顾客的参与度不高，主要强调计划、过程和文档等。而敏捷方法对于需求不明确的复杂项目，要求客户和开发团队一起开发能够在较短时间和较低预算内成功完成，主要强调团队、客户合作和拥抱变化等。
综上，我们可以认为敏捷方法是综合多种传统方法优点整理出来的一种开发方法，是一个新的思路，但这并不意味着不一定是所有软件开发的最优选择。当然，敏捷方法也存在一些问题，如敏捷方法中通常使用代码替代文档，在很多实际情况下大大降低了系统的可读性。这就需要我们能够随机应变，采用更务实的思想和方法。
二、传统方法和敏捷方法基于范围管理的比较
范围用以限制和控制项目中包含的工作。良好定义和良好管理的范围对于项目成本效益和软件开发时间表非常重要。项目范围主要涉及到两方面内容：
①产品范围界定：产品范围的特征和功能包含在产品或服务中。
②工作范围界定：项目工作的完成为的是能交付一个有特殊的特征和功能的产品。
项目范围管理包括的程序，要求能确保该项目所覆盖的整体工作要求和单项工作要求，从而促使项目工作成功地完成。针对软件开发过程中不明确的需求、不可用的资源，不断变化的环境和不灵活性等众多可能问题，项目中需要进行范围管理，如果不仔细管理，可能导致项目失败。范围管理主要包括以下五个过程：
①启动阶段：督促项目管理组织开始着手项目下一阶段的工作。
②范围规划报告：写出一份书面报告，作为未来项目决策基础。
③范围界定：把主要的项目工作细目分解成更小、更易管理操作的单元。
④范围核实：正式认可这个项目范围。
⑤范围变化控制：对项目范围的变化进行控制。
1、传统方法的范围管理
在传统软件开发方法中，范围被定义为软件项目的完整需求规范。它包含项目开始时的详细需求，在开发过程的后期阶段需要分析使用这些需求。然而，耗费开发人员很多时间和精力完成的相关文档并不支持在开发过程的后期阶段可能发生的变化。这些不可控的变化往往会导致范围蠕变（在产品或项目开发期间，需求驱动发生变化，带来一些开始没有计划的产品特点，对产品质量或软件开发时间表产生影响），而处理范围蠕变需要使用不同的工具和技术，这可能使得项目逾期并且超出预算。
传统方法创建工作分解结构（WBS），用以把项目可交付成果和项目工作分解成较小的、更易于管理的组成部分的过程。当范围发生变化时，传统方法需要审查整个工作分解结构，很难基于特定变化做出良好快速的适应，这将不可避免地影响项目的成本、资源、质量和时间表。因此，为避免项目失败，传统方法需要非常仔细地定义和管理其范围。
2、敏捷方法的范围管理
敏捷方法拥抱软件开发过程的后期阶段的变化，即接受项目范围的波动。因此，敏捷方法的项目范围常常需要满足高级别的要求。敏捷方法的范围采用迭代并接受渐进的变化，由负责接受或拒绝在每个迭代期间完成的功能的客户来验证和控制。
管理范围蠕变是敏捷方法范围管理的一个非常重要的方面。在软件开发过程中会不断地产生一些变化，其中可能存在着影响整个项目的变化，敏捷方法中的范围管理技术会管理这些不可控的改变，这在一定程度上保证了软件项目在开发过程中的稳定性。与传统方法不同，在敏捷方法中没有创建WBS。
3、比较总结
范围定义了软件开发过程的边界。范围管理是关乎敏捷方法和传统方法成功完成整个过程的一个重要因素。敏捷方法中的范围管理与传统方法的大致对比如图4所示。
敏捷方法中的范围管理允许变化并且可以减少不必要的变化，在范围上遵循迭代计划，需要满足高级别的要求。具有上述特征使得敏捷方法的范围管理保证了软件的时间表，并且软件产品可以在预算内以良好的质量交付。
传统方法中的范围管理中不可控的变化导致范围蠕变，往往使项目超出预算并且破坏软件开发时间表。同时，在传统方法中需要创建WBS，且管理的范围需要以全面的文档的形式进行详细定义。
基于上述比较分析，我们可以认为敏捷方法在产品成本、项目资源和软件开发时间表等方面都足以成为传统方法的更优替代。
参考文献：
[1] 张志丽.软件开发生命周期法比较之敏捷与传统[J].软硬件开发, 2013 (12) : 32-37.
[2] Rehman, I.U. & S.ullah & A.Rauf & A.A.Shahid. Scope Management in Agile Versus Traditional Software Development Methods[C]. New York: NSEC ‘10 Proceedings of the 2010 National Software Engineering Conference, 2010.
[3] 王冲.敏捷开发与传统瀑布模型的比较及教学[J].研究与探讨, 2011 (4) : 61-62.
[4] Shawky, D.M. Traditional vs Agile development a comparison using chaos theory[C]. Software Paradigm Trends (ICSOFT-PT), 2014 9th International Conference on, 2014。
[5] http://baike.baidu.com/item/%E8%8C%83%E5%9B%B4%E7%AE%A1%E7%90%86
[6] http://baike.baidu.com/item/%E7%89%B9%E5%BE%81%E8%A0%95%E5%8F%98
[7] http://baike.baidu.com/view/259207.htm
[8] http://baike.baidu.com/view/47193.htm