4.1.3敏捷方法

1.敏捷方法的特点

敏捷型方法主要有两个特点，这也是其区别于其他方法，尤其是重型方法的最主要的特征。

敏捷型方法是"适应性"（adaptive）而非"预设性"（predictive）的。重型方法试图对一个软件开发项目在很长的时间跨度内做出详细的计划，然后依计划进行开 发。这类方法在计划制定完成后拒绝变化。而敏捷型方法则欢迎变化。其实，它 的目的就是成为适应变化的过程，甚至能允许改变自身来适应变化。

敏。捷型方法是，"面向人的"（people-oriented ）而非"面向过程的" （process-oriented）。它们试图使软件开发工作能够利用人的特点，充分发挥人的 创造能力。它们强调软件开发应当是一项偷快的活动。

下面是对上面两点的详细解释：

1）适应性和预设性

传统的软件开发方法的基本思路一般是从其他工程领域借鉴而来的，比如土木工程

等。在这类工程实践中，通常非常强调施工前的设计规划。只要图纸设计得合理并考虑 充分，施工队伍可以完全遵照图纸顺利建造，并且可以很方便地把图纸划分为许多更小 的部分交给不同的施工人员分别完成。

但是，软件开发与上面的土木工程有着显着的不同。软件的设计是难以实现的，并 且需要昂贵的有创造性的人员》土木工程师在设计时所使用的模型是基于多年的工程实 践的，而且一些设计上的关键部分都是建立于坚实的数学分析之上。而在软件设计中，完全没有类似的基础。我们对开发计划所能做的只是请希赛网审阅。这就使得我们无法将 设计和实碑分离开来，一些设计错误只能在编码和测试时才能发现。根本无法做出一个 交给程序员就能直接编码的软件设计。

所以，软件过程不可能照搬其他工程领域原有的方法，需要有适应其特点的新的开 发方法。

软件的设计之所以难以实现，问题在于软件需求的不稳定，从而导致软件过程的不 可预测。但是传统的控制项目的模式都是针对可预测的环境的，在不可预测的环境下，就无法使用这些方法。

但是我们必须对这样的过程进行监控，以使得整个过程能向我们期望的目标前进。

于是Agile方法引入"适应性"方法，该方法使用反馈机制对不可预测过程进行控制。

2）面向人而非面向过程

传统正规方法的目标之一是发展出这样一种过程，使得一个项目的参与人员成为可 替代的部件。这样的一种过程将人看成是一种资源，他们具有不同的角色，如分析员、程序员、测试员及管理人员。个体是不重要的，只有角色才是重要的。这样考虑的一个 重要的出发点就是：尽量减少人的因素对开发过程的影响。但是敏捷型方法则正好相反。

传统方法是让开发人员"服从" 一个过程而非"接受" 一个过程。但是一个常见的。 情况是：软件的开发过程是由管理人员决定的，而管理人员已经脱离实际开发活动相当 长的时间了，如此设计出来的开发过程是难以为开发人员所接受的。

敏捷型过程还要求开发人员必须有权作技术方面的所有决定。IT行业和其他行业不 同，其技术变化速度非常之快。今天的新技术可能几年后就过时了。只有在第的开 发人员才能真正掌握和理解开发过程中的技术细节。所以技术方面的决定必须由他们来 做出。这样一来，就使得开发人员和管理人员在一个软件项目的领导方面有同等的地位， 他们共同对整个开发过程负责。

敏捷方法特别强调开发中相关人员之间的信息交流。Alistair Cockbum在对数十个项 目的案例调查分析后得出一个结论，"项目失败的原因最终都可以追溯到信息没有及时 准确地传递到应该接受它的人".在开发过程中，项目的需求是在不断变化的，管理人员 之间、开发人员之间以及管理人员和开发人员之间，都必须不断地了解这些变化，对这 些变化做出反应，并实施在随后的开发过程中。敏捷方法还特别提倡直接的面对面交流。 Alistair Cockbum认为面对面交流的成本要远远低于文档交流的成本，因此，敏捷方法一般都按照髙内聚、松亲合的原则将项目划分为若干小组，以增加沟通，提髙敏捷性及应 变能力。

2.敏捷方法的核心思想

敏捷方法的核心思想主要有下面三点：

（1）敏捷方法是适应型，而非可预测型。与传统方法不同，敏捷方法拥抱变化，也 可以说它的初衷就是适应变化的需求，利用变化来发展，甚至改变自己，最后完善自己。

（2）敏捷方法是以人为本，而非以过程为本。传统方法以过程为本，强调充分发挥 人的特性，不去限制它。并且软件开发在无过程控制和过于严格繁琐的过程控制中取得 一种平衡，以保证软件的质量。

（3）迭代增量式的开发过程。敏捷方法以原型开发思想为基础，采用迭代增量式开 发，发行版本小型化。它根据客户需求的优先级和开发风险，制定版本发行计划，每一 发行版都是在前一成功发行版的基础上进行功能需求扩充，最后满足客户的所有功能 需求。

3.敏捷型方法的含义及其特征

我们把软件开发过程中拥有大量中间产品（如需求规约、设计模型等）和复杂控制 的软件开发方法称为重型方法；由此，我们称中间产品较少的方法为轻型方法。从表象 来看，重型方法注重开发文档的完备性和充分性；而敏捷型方法认为最根本的文档应该 是源码，而不是繁琐的文档。从实质上说，有如下两方面更深层次的区别：

（1）敏捷型方法的思想是"自适应"的，而非如"预设''的重型方法试图预先固定 需求并拟定详细开发计划；敏捷型方法适应需求的变化，甚至可以说其初衷就是针对变 化的需求的。

（2）敏捷型方法的思考角度是"面向人"的，而非"面向开发过程"的。重型方法 在实践原则中总是把开发者看作是一个泛化的生产要素，而忽视了作为决定性因素的人 的特殊性；而敏捷型方法则强调以人为本，并贯穿实践始终。由上可知敏捷型方法其实 是软件开发方法论从无到重型再进一步发展的成果。

4.敏捷方法的适用范围

实际上，满足工程设计标准的文档是源代码清单。"软件项目的设计是一个抽象 的概念。它涉及了程序的概括形状（shape）、结构以及每一模块、类和方法的详细形状。" 系统设计得到了有关系统的一个清晰的"图像",这一图像可以保持到首次发布。但随着 项目的开发，程序"片段"就可能像不断腐化的"面包碎片",发出"臭味",并不断蔓 延和积累，使得系统越来越难以维护，以至于不得不要求重新设计。但这样的重新设计 是很难成功的。

因此，与这种传统的方法相比，敏捷方法比较适合需求变化比较大或者开发前期对 需求不是很清晰的项目，以它的灵活性来适应需求的变化，有效地控制项目进度和成本。 另外，敏捷方法对设计者、开发者和客户之间的有效沟通和及时反馈要求比较高，所以不易在开发团队比较庞大的项目中实施，当然这也不是绝对的。

5.敏捷方法的主要内容

敏捷方法的主要内容包括4个核心价值观和12条过程实践规则。4个核心价值观分 别为沟通、简单、反馈和勇气。沟通，它强调设计者、开发者和客户三者之间的有效交 流是开发成功的关键：简单是设计和编码的指导原则，它强调只满足当前功能需求，不 做假想设计，尽量使代码简单化；反馈，强调设计者、开发者和客户之间及时和详尽的 意见反馈是开发成功的保证：勇气，是开发适应变化的前提，要求设计者和开发者在必 需做出取舍或重构时，勇于抉择，？勇于实践。

依据敏捷方法的4个核心价值观，提出12条过程实践规则，分别为简单设计、测试 驱动、代码重构、结对编程、持续集成、现场客户、发行版本小型化、系统隐喻、代码 集体所有制、规划策略、规范代码、40小时工作机制。

6.主要敏捷方法简介

手工作坊式的软件生产方式已经被无数次的项目失败证明为低效和应被舍弃的：传 统软件开发方法（如IS09000和CMM）在规范和保证开发进程的同时，由于其繁琐的 过程控制和严格的文档要求招致了开发者潜在的抵触；此外，开发人员流动性大于软件 的可持续开发之间的矛盾日渐显露，如何保证软件的高可传承性以及尽可能地延长软件 生命周期成了摆在开发者和管理者面前的难题。为了应对这种局面，近年来，己经出现 很多敏捷型方法，它们有许多的共同特征，但也有一些重要的不同之处。这里就其中影 响比较大的几种敏捷方法作一些简单的介绍。

（1）XP （Extreme Programming,极限编程）在所有的敏捷型方法中，XP是最引人 瞩目的。它源于Smalltalk圈子，特别是Kent Beck和Ward Cunningham在20世纪80年 代末的密切合作。XP在一些对费用控制严格的公司中的使用，已经被证明是非常有 效的。

（2）Cockbum的水晶系列方法。水晶系列方法是由Alistair Cockbum提出的。它与 XP方法一样，都有以人为中心的理念，但在实践上有所不同。Alistair考虑到人们一般 很难严格遵循一个纪律约束很强的过程，因此，与XP的髙度纪律性不同，AHstair探索 了用最少纪律约束而仍能成功的方法，从而在产出效率与易于运作上达到一种平衡。也 就是说，虽然水晶系列不如XP那样的产出效率，但会有更多的人能够接受并遒循它。

（3）开放式源码。这里提到的开放式源码指的是开放源码界所用的一种运作方式。 开放式源码项目有一个特别之处，就是程序开发人员在地域上分布很广，这使得它和其 他敏捷方法不同，因为一般的敏捷方法都强调项目组成员在同一地点工作。开放源码的 -个突出特点就是查错排障（debug）的髙度并行性，任何人发现了错误都可将改正源码 的"补丁"文件发给维护者。然后由维护者将这些"补丁"或是新增的代码并入源码库。

（4）SCRUM.SCRUM已经出现很久了，像前面所论及的方法一样，该方法强调这 样一个事实，即明确定义了的可重复的方法过程只限于在明确定义了的可重复的环境中，为明确定义了的可重复的人员所用，去解决明确定义了的可重复的问题。

（5）Coad 的功用驱动开发方法（Feature Driven Developments FDD）。 FDD 是由 Jeff De Luca和大师Peter Coad提出来的。像其他方法一样，它致力于短时的迭代阶段和可 见可用的功能。在FDD中，一个迭代周期一般是两周。

在FDD中，编程开发人员分成两类：首席程序员和"类"程序员（class owner）。 首席程序员是最富有经验的开发人员，他们是项目的协调者、设计者和指导者，而"类" 程序员则主要做源码编写。

（6）ASD 方法。ASD （Adaptive Software Development）方法由 Jim Highsmith 提出， 其核心是三个非线性的、重叠的开发阶段：猜测、合作与学习。