论敏捷开发方法.doc

论敏捷开发方法 刘舒翔 （广东省民政职业技术学校 广东 广州 510310） 传统软件开发方法 件。 传统的软件工程方法认为只要开发人员努力工作，就可以在早期 确定所有的需求，从而减少后期需求变动引发的成本增加。 而且传统 的软件工程方法认为变动是前面工作中的错误造成的，所以总是努力 把变动排除在开发进程之外。 事实上， 外部环境变化往往引起软件开发过程中的重大变动，这 一点并不是开发人员可以控制的，但在今天飞速发展的世界中不可避 免，比如需求、范围、技术的变化，其中需求的变化是非常难以管理的。 项目开始的初期，客户并不清楚了解他们要的系统是什么样的，开发 人员往往需要多次修改系统的功能。 在系统开发的过程中，客户很可 能会提出新的需求，或者调整不同需求的优先级，而软件开发人员必 须对这些变化做出合适反应，拒绝变化意味着对客户不负责任。 另一 方面，如果开发团队接手的是一个以前没有做过的项目类型，面临的 风险非常大，其中必然存在着许多不可预知的变化。 所以正确的策略 不是排斥变动，而是尽量减少变动的成本。 随着技术的迅速发展和经济的全球化， 软件开发出现了新的特 点，即在需求和技术不断变化的情况下实现快节奏的软件开发，在此 情 况 下 ， 出现了一些新的开 发 方 法 ， 如敏捷软件开发方法 (Agile Methodologies)。 与传统的软件工程方法低生产率相比，敏捷方法在质量和生产率 这两个核心目标保持灵活的平衡： 相对于传统软件开发方法的繁琐， 敏捷方法在无过程和过于繁琐的过程中达到了一种平衡，使得能以不 多的步骤过程获得较满意的结果，因此也称为轻量级的(Light Weight) 软件开发方法。 所谓的“轻量型”或者叫做“灵活”的方法，比如 Crystal 方法、适应 性软件开发方法和极限编程方法(XP)， 它们都有这样一个事实 ， 即需 要人们共同来开发软件。 成功的软件过程必须将人们的长处最大化， 将他们的缺点最小化，因为优点和缺点毋庸质疑都存在。 1 1986 年， 在 NATO （ 北大西洋公约组织 ） 工作会议上首次提出了 “ 软件工程 ” 的概念 ， 主要是针对 20 世纪 60 年代 “ 软 件 危 机 ” 而 提 出 的。 它对计算机软件开发的标准、方法和技术作了首次规定，自这一概 念提出以来，围绕软件项目，开展了有关开发模型、方法以及支持工具 的研究。 随着软件工程思想逐渐形成与发展，也出现了很多软件开发 模型与方法，例如瀑布模型、快速原型、增量模型和螺旋模型等等。 在 90 年代以后 ， 卡耐基梅隆软件学院推出的 CMM， 更是对于软件 开 发 的过程管理，提出了确切的衡量指标。 人们认为，只要能够制定出足够 的规则和方法，覆盖到软件开发的所有的方方面面，程序员们就能够 按时生产出完美的软件。 然而，随着越来越多的规则和方法被加了进来，用以达到应付所 有可能发生的问题的目的，软件工程学变得越来越庞大而复杂。 到了 二十一世纪，随着信息技术的迅猛发展和市场竞争的不断增强，特别 是面对目前高度竞争的 Internet 时代环境下对于进度方面不断增长的 挑战性要求，软件开发者们发现，在实际的开发中，要完全遵循那些被 详细制定好的规则和做法是相当困难的，步骤复杂且难于理解，而且 大量使用某种抽象符号所写的文档正在失去控制。 根据美国 GSM 研究机构的数据表明， 软件开发领域的项目情况 与软件工程刚提出的时候相比，只是有很小的提高。 详细的数据如下 表所示。 表 1 软件开发领域的项目情况比较 30%项目超出预算，平均超支 167% 29％无法交付 敏捷软件开发方法介绍 3 传统的软件开发过程，以 RUP 为代表 ， 强调项目的可控性 ， 是一 个用例驱动的基于 UML 和构件式架构的迭代增量式开发过程。 RUP 定义了初始、细化、实现和部署 4 个阶段，分别对应着关键里程碑的划 分。RUP 对于角色、流程、工件和活动的要求是灵活、可配置的，所以它 广泛的适用于各种类型的项目。 但是，在 RUP 的各个里程碑，都规定 了要交付的成果，尤其是对于需求的变更以及文档，它强调及时的更 新与同步。 以上这些都决定了 RUP 是一种重量级的软件开发方法。 传统的重量级软件开发方法存在很多局限： （1）传统软件开发过程是基于设计之初正确的设计与估计，并通 过开发人员开发出完美的产品。 开发方式以“明确需求”为核心，从需 求分析、软件设计到系统实现，再进行集成和测试。 这样，系统集成进 行得比较晚，集成的时间周期比较长，集成时发现的缺陷也比较多。 （2）虽然目前有许多项目采用增量迭代的开发周期，但是通常项 目在部署前才发布版本， 用户只有在部署后才能看到真正的系统，因 此，用户会提出很多