敏捷型方法
在所有的敏捷型方法中，XP是最为引人瞩目的。部分原因是因为XP的领军 人物们的卓越能力，特别是Kent Beck，他能够把人们吸引到这种方法来， 并一直处于领先地位。但是XP热也带来了一个问题，就是它把其他一些方法 和它们非常有价值的思想给挤了出去。
XP根源于Smalltalk圈子，特别是Kent Beck和Ward Cunningham在（19）80年代末的 密切合作。90年代初，他们在一系列项目上的实践深化扩展了他们关于软件 开发应是适应性的、应以人为中心思想。
从非正式的、探索性的实践到形成系统化的正规方法的关键一步是在1996年 春。Kent被邀对Chrysler的一个工资管理项目（C3〕的开发进度进行审核。 该项目由一个签约公司用Smalltalk开发，正处于困境之中。由于源码质量 低劣，Kent建议推倒重来。该项目然后在他的领导下从头开始并成了早期 XP的旗舰和培训基地。
C3的第一期系统在1997年初投入运行。项目继续进行了一段时间后，遇到 了麻烦，导致了在1999年开发计划被撤销。（这也证明了XP并不是成功的保证）
XP的四条基本价值原则是：交流，反馈，简洁和勇气。在此基础上建立了 十多条XP项目应遵循的实践准则。其实，许多准则是以前就存在的并经过实 践检验的，而常常被忽略了的。XP重新建立了这些准则，并把它们编织成 了一个和谐的整体，使得每一项准则都能在其他准则里得以强化。
XP有一个最具冲击力的，也是最初吸引我的特点，是它对测试的极端重视。 诚然，所有的过程都提到测试，但一般都不怎么强调。可是XP将测试作为 开发的基础，要求每个程序员写一段源码时都得写相应的测试码。这些测 试片段不断地积累并被整合到系统中。这样的过程会产生一个高度可靠的 建造平台，为进一步开发提供了良好的基础。
在此基础上XP建立了一个渐进型的开发过程，它依赖于每次迭代时对源码 的重整（refactoring〕。所有的设计都是围绕着当前这次迭代，而不管将 来的需求。这种设计过程的结果是“纪律性”与“适应性”的高度统一， 使得XP在适应性方法中成为发展的最好的一种方法。
XP产生了一批领军人物，许多是从C3项目中出来的。关于XP有许多文献可 读。Kent Beck写的 Extreme Programming Explained， 是一篇XP的宣言，它阐述了隐藏在XP后面的理念。此书对有心于XP并致 力于将其发扬光大者提供了充足的说明和解释。过去两年里也出版了一 批“多姿多彩”的XP书籍，但多数都很相似，主要是从一些XP早期的实 践者们的角度上描述了XP的整个过程。
除了书之外，还有不少网上资源。如果你想找到更有结构性的材 料，你最好访问两位C3成员的网站：Ron Jefferies的 xProgramming.com 和Don Wells的 extremeProgramming.org。 许多XP早期的倡导和发展可在Ward Cunningham的 wiki web （合作写作〕中找到。wiki是个令人着迷的地方，尽 管它的漫游性质常令人身不由己地陷入其中。 XP讨论组〔xp discussion egroup〕也很有意思。 还有一篇很有意思的文章从（XP圈）“外面”来审视XP，这就是Mark Paulk所写的 从CMM的角度看XP。Mark Paulk是CMM的领军人物之一。
Cockburn的水晶系列方法
Alistair Cockburn 在90年代初受IBM之约进行正规方法的研究，从那时起他就活跃于这个领域。 但他的研究途径和其他方法学者有所不同。一般的方法 学者是将他们个人的经验升华成理论，而Cockburn除了归纳整理他自己的实 践经验以外，他还积极地造访其他项目，和项目组成员进行广泛的讨论， 考察这些项目是怎样运作的。难能可贵的是，他从不固守自己的观点， 他会根据新的发现而随时修正自己的理论。他的这些特点使得他成为我 最喜欢的方法学者。
他的著作 Surviving Object-Oriented Projects 汇集了很多如何顺利运行软件开发项目的建议，此书也是我推荐的运行迭代 式项目的首选书。最近，Alistair写了一本关于 敏捷型软件开发 的综述性著作，探讨了这些方法的基本原则。
Alistair还更进一步地探索了敏捷型方法，并提出了 水晶（Crystal〕 方法系列。 之所以是个系列，是因为他相信不同类型的项目需要不同的方 法。他认为决定一个方法与两个因素有关：项目参与人数和出错后果。如果用 两个坐标轴来分别表示这两个变量的话，那么在这张图上，每一种方法都 有其相应的坐标位置。例如，有两个项目，一个是有40人参加，如果失败造成 的资金损失可以接受；另一个项目只有6人，其成败生存悠关。那么这两个 项目所用的方法在坐标图上就有不同的位置。
水晶系列与XP一样，都有以人为中心的理念，但在实践上有所不同。Alistair 考虑到人们一般很难严格遵循一个纪律约束很强的过程，因此，与XP的高度 纪律性不同，Alistair探索了用最少纪律约束而仍能成功的方法，从而在产出 效率与易于运作上达到一种平衡。也就是说，虽然水晶系列不如XP那样的产 出效率，但会有更多的人能够接受并遵循它。
Alistair也费了不少笔墨强调每次迭代后的总结回顾，因而鼓励过程本身的 自我完善。他的理由是迭代式开发是用来尽早发现问题并解决之。这样就更 加强调了开发人员要随时观察他们所用的过程，并随着项目的进行而调整。
开放式源码
看到这个标题你可能会有些意外。毕竟，开放式源码（Open Source〕 是软件的一类风格，而非一种过程。这里我是指开放源码界所用的一种 运作方式，这种方式适用于开放源码项目，其实它的许多做法也可为封闭式源 码项目所用。开放式源码项目有一个特别之处，就是程序开发人员在地域上分 布很广。注意到这点相当重要，因为一般适应性过程都强调项目组成员在同一 地点工作。
多数开放源码项目有一个或多个源码维护者（maintainer〕。只有维护者 才能将新的或修改过的源码段并入源码库。其他众人可以修改源码，但需将他们 所做的改动送交给维护者，由维护者对这些改动进行审核并决定是否并入源码库。 通常来说，这些改动是以“补丁”（patch〕文件的形式，这样处理起来容易一些。 维护者负责协调这些改动并保持设计的一致性。
维护者的角色在不同的项目中有不同的产生和处理方式。有些项目只有一个 维护者，有些项目把整个系统分成若干个模块，每个模块有一个维护者。有 些是轮流做维护者，有些是同一个源码部分有多个维护者，有些则是这些方 式的组合。许多开放源码项目的参与者只是部分时间（或业余时间〕干，如 果项目要求是全日制的，那么这有一个问题，就是怎样才能把这些开发人员 有效地协调组织起来。
开放源码的一个突出特点就是查错排故（debug〕的高度并行性，因为许多 人都能同时参与查错排故。如果他们发现了错误，他们可将改正源码的 “补丁”文件发给维护者。这种查错排故角色对非维护者来说合适，对那 些设计能力不是很强的人来说，也是一项挺好的工作。
关于开放源码的方法过程还没有很系统的文献。目前最著名的一篇文章是 Eric Raymond写的 The Cathedral and the Bazaar（教堂与集市〕， 文章虽短，但很精彩。另外，Karl Fogel所著的 关于CVS的书中也有几章 描述了开放源码的方法。即使你不想使用CVS，这几章还是值得一看。
Highsmith的适应性软件开发方法（ASD－－Adaptive Software Development)
Jim Highsmith 多年来一直从事可预见性方法的研究，建立和教学，而最后得出的 结论是这些方法都有着根本性的缺陷，特别是在用来作现代应用系统 的开发时。
他最近的 一本书 集中论述了新方法的适应特性，重点讨论了把一些起源于 复杂适应性系统（通常称之为混沌理论－－chaos theory〕的思想在软件 开发中加以应用。此书没有象XP那样提供详尽的实践准则，但它从根本上 说明了为什么适应性开发方法是重要的，并进一步说明了其对组织结构和 管理层的影响。
ASD的核心是三个非线性的、重迭的开发阶段：猜测、合作与学习。
在一个适应性环境中，因为结果是不可预见的，Highsmith把计划看成是一个 “反论”〔paradox〕。在传统的计划中，偏离计划是错误，应予纠正。 而在一个适应性环境里，偏离计划则是在引导我们向正确的目标迈进。
在不可预见的环境里，你需要大家能以多种多样的方式合作来对付不确定性。 在管理上，其重点不在于告诉大家做什么，而是鼓励大家交流沟通，从而 使他们能自己提出创造性的解决方案。
在可预见性环境里，通常是不大鼓励学习的。设计师已经都设计好了，你跟着走就行了。
在适应性环境中，学习对所有各方，包括开发人员和客户， 都是一个挑战。他们需要学习以检验他们作的假设，需要学 习以便能用每次开发周期的结果去适应下一个周期。
-- [Highsmith]
这样的学习是连续不断的，这已成为这种方法的一个重要特点，因此我们 必须得认识到计划和设计都得随开发的推进而改变。
适应性开发周期的最强力的、不可分割的好处是其对我们自以为是的心理 模式的挑战，它迫使我们更实际地估计自己的能力。
-- [Highsmith]
有了这样的出发点，Highsmith把他的工作集中放在适应性开发的难点上， 特别是如何在一个项目中增强合作和学习。基本上说，他的这本书 是侧重于“软”方法，这样对那些从开发实践中提炼出来的方法如XP，FDD 和水晶系列来说，这本书将是一个很有益的互补。
SCRUM
SCRUM在OO界里已很有些时日了，不过我得承认我对其历史发展并不是 太知其详。象前面所论及的方法一样，该方法强调这样一个事实，即明 确定义了的可重复的（defined and repeatable〕方法过程只限于在明 确定义了的可重复的环境中，为明确定义了的可重复的人员所用，去解决 明确定义了的可重复的问题。
SCRUM把一个项目分成若干个为期30天的迭代阶段，称之为一“冲” （sprint〕。开“冲”之前，你得明确这一“冲”要实现的功能，然后 交给开发组去完成。但是，在“冲”期间，需求必须是固定的。
管理人员并非在“冲”的时候就撒手不管了。每天，他需召集一个短会 （15分钟左右〕，称之为一个scrum，会上大家讨论决定第二天干什么。 特别是大家会对管理层提出那些阻碍项目进行的因素，并希望管理层能 予以解决。当然，他们也需要报告目前完成了什么，这样管理层每天都能 了然项目的进展情况。
SCRUM文献多集中论述迭代阶段计划与进度跟踪。它与其他敏捷型方法在 许多方面都很相似，特别是它可以与XP的编程准则很好地结合起来。
相当长的一段时间没有关于SCRUM的专门书籍，直到最近 Ken Schwaber和Mike Beedle写了 第一本SCRUM的专著。Ken Schwaber还 主持了一个网站 ControlChaos.com，可能是对SCRUM的最好的综述。Jeff Suthurland有个总是很活跃的网站讨论OO技术，其中有 一部分是专门讨论SCRUM的。另外，在 PLoPD 4书中也有一篇关于SCRUM的很好的综述。 Scrum也有一个 Yahoo讨论组.
功用驱动开发方法（FDD－－Feature Driven Development〕
FDD是由Jeff De Luca和OO大师Peter Coad提出来的。象其他方法一样， 它致力于短时的迭代阶段和可见可用的功能。在FDD中，一个迭代周期 一般是两周。
FDD有以下五项任务：
。建立总体模型
。提出功用清单
。针对功用逐项制订计划
。针对功用逐项进行设计
。针对功用逐项开发实现
头三项在项目开始时完成，后两项在每一次迭代周期时都要做。每一项 任务又可进一步分解并制订出相应的检验准则。
在FDD中，编程开发人员分成两类：首席程序员和“类”程序员（class owner〕。首席程序员是最富有经验的开发人员，他们负责开发实现 系统的各项功能。对每一项功能，首席程序员要定出需要哪些类（class〕 来实现这项功能，并召集“类”程序员们组成一个针对这项功能的开发 组。首席程序员作为协调者，设计者和指导者，而“类”程序员则主要 作源码编写。
关于FDD的文档资料比较少。直到最近终于有了一本全面 论述FDD的著作。FDD 的主要提出者Jeff De Luca现已建立了一个 FDD门户网站， 收录了一些文章、笔记和讨论。FDD的最早的论述见于Peter Coad等所著的 UML in Color 。他的公司 TogetherSoft 也从事FDD的咨询和培训工作。
动态系统开发方法〔DSDM－－Dynamic System Development Methods〕
DSDM在1994年始于英国。 英国一些想用RAD和迭代方式进行系统 开发的公司组成了一个社团〔Consortium〕。刚开始有17个组建成员， 到现在成员已超过1000个，遍布英国内外。DSDM由于是由一个社团所 发展，它与其他一些敏捷型方法有些不同。它有专门的组织支持， 有手册，培训课程，认证程序等。因为它 上面的价格标签而限制了我对此方法的进一步调查。不过Jenifer Stapleton已写了 一本书来介绍这种方法。
如果你要用这种方法，你得先作可行性和业务分析。可行性分析要考虑 DSDM是否适合手上这个项目。而业务分析则是开一系列的讨论会， 以期能充分了解应用域，同时也要提出大致的系统结构与项目计划。
余下的工作由三个互相交织的周期组成：功能模型周期产生文档和原型 （实验系统），设计建造周期生成可操作使用的系统，实现周期 处理系统安装部署（deployment〕问题。
DSDM有一些基本的原则包括与用户积极的交流，频繁的交付（delivery）。 有充分职权的项目组，完全的系统测试。象其他敏捷型方法一样， DSDM的一个周期在2－6周之间。它强调高质量的系统以及对需求变更的高 度适应性。
我还没有在英国之外的地方看到有项目使用DSDM。DSDM的基本结构有许多 成熟的传统方法的东西，同时又遵循了敏捷型途径。但这里的确有一点 值得注意，即是这种方法是否有鼓励一种面向过程与繁琐的倾向。