新方法学新方法学MartinFowler过去几年中兴起的敏捷型（agile）软件开发方法，以矫正官僚繁琐过程，或者许可对过程进行自主调整为特征，在软件业引起了极大的兴趣。在这篇文章里，我将探索敏捷型方法的合理性，着重点并不是放在其“轻重”上，而是于它们的适配性（adaptive）性质和以人优先的理念。我在本文也简要介绍了一些敏捷型方法并给出了进一步的参考材料。另外，我还给出了一些你在决定是否要走这条刚踏出来的敏捷之路时需考虑的因素。在SDEast上我作了一次演讲“让软件恒软〔KeepingSoftwareSoft）”其材料就是基于这篇文章（你若有充足的时间可浪费的化，不妨一观）。此文的节略版发表于SoftwareDevelopmentMagazine（软件开发杂志）的2000年12月期。从无，到繁重，再到敏捷多数软件开发仍然是一个显得混乱的活动，即典型的“边写边改”（codeandfix）。设计过程充斥着短期的，即时的决定，而无完整的规划。这种模式对小系统开发其实很管用，但是当系统变得越大越复杂时，要想加入新的功能就越来越困难。同时错误故障越来越多，越来越难于排除。一个典型的标志就是当系统功能完成后有一个很长的测试阶段，有时甚至有遥遥无期之感，从而对项目的完成产生严重的影响。我们使用这种开发模式已有很长时间了，不过我们实际上也有另外一种选择，那就是“正规方法”（methodology）。这些方法对开发过程有着严格而详尽的规定，以期使软件开发更有可预设性并提高效率，这种思路是借鉴了其他工程领域的实践。这些正规方法已存在了很长时间了，但是并没有取得令人瞩目的成功，甚至就没怎么引起人们的注意。对这些方法最常听见的批评就是它们的官僚繁琐，要是按照它的要求来，那有做太多的事情需要做，而延缓整个开发进程。所以它们通常被认为是“繁琐滞重型”方法，或JimHighsmith所称的“巨型”（monumental)方法。作为对这些方法的反叛，在过去几年中出现了一类新方法。尽管它们还没有正式的名称，但是一般被称为“敏捷型”方法。对许多人来说，这类方法的吸引之处在于对繁文缛节的官僚过程的反叛。它们在无过程和过于繁琐的过程中达到了一种平衡，使得能以不多的步骤过程获取较满意的结果。敏捷型与滞重型方法有一些显著的区别。其中一个显而易见的不同反映在文档上。敏捷型不是很面向文档，对于一项任务，它们通常只要求尽可能少的文档。从许多方面来看，它们更象是“面向源码”（code-oriented）。事实上，它们认为最根本的文档应该是源码。但是，我并不以为文档方面的特点是敏捷型方法的根本之点。文档减少仅仅是个表象，它其实反映的是更深层的特点：敏捷型方法是“适配性”而非“预设性”。重型方法试图对一个软件开发项目在很长的时间跨度内作出详细的计划，然后依计划进行开发。这类方法在计划制定完成后拒绝变化。而敏捷型方法则欢迎变化。其实，它们的目的就是成为适应变化的过程，甚至能允许改变自身来适应变化。敏捷型方法是“面向人”的(people-oriented)而非“面向过程”的(process-oriented)。它们试图使软件开发工作顺应人的天性而非逆之。它们强调软件开发应当是一项愉快的活动。在以下各节中，我将详细地探讨这些差别，这样你可以了解适配性和以人为中心的过程是什么，它们的好处与不足，以及你作为软件开发人员或用户时是否应该使用它们。预设性与适配性将设计与建造分离开来传统的软件开发正规方法的基本思路一般是从其他工程领域借鉴而来如土木工程模式对软件工程的影响较大。这类工程实践中，在实际建造之前，通常非常强调设计规划。工程师首先给出一系列的图纸，这些图纸准确地说明了要建造什么以及如何建造（包括部分和整体）。许多工程问题，如怎样处理一座桥梁的负荷，图纸上都有说明。然后，这些图纸分发给另外一组人员，通常是另外一个公司，去建造。这种方式其实已假定了建造过程将按图纸而来。当然，施工中也会碰到一些问题，但这些都是次要的。图纸其实就是一个详细的建造计划，它说明了一个项目中必须完成的各项任务，以及这些任务之间的依赖关系。这样，管理层能较为合理地制订出生产进度表和项目预算。这种模式实际上也规定了建造者如何做（施工），这也隐含着建造者不须是高智能型的，尽管他们可能都有非常高超的手上功夫。在此，我们看到的是两类非常不同的活动。设计是难于预设的，并且需要昂贵的有创造你的人员，建造则要易于预设。我们有了设计之后，便可对建造进行计划了。而有了建造计划后，我们进行建造则可以是非常可预设性的了。在土木工程中，建造不论在经费上还是在时间上的花销都要比设计和计划大得多。所以，多数正规方法的途径是象这样的：我们想要可预定的生产进度计划，以便能使用技能较低的人员。要达到