1991年秋，在美国勒海大学亚科卡学院的一份研究报告《21世纪美国制造业的战略：一个工业主导的观点》中，首次提出了敏捷竞争的概念。何谓敏捷（Agility）？对于企业而言，敏捷意味着企业能够在顾客机会不断变化、难以预测的竞争环境中赢利运营；对于个人而言，敏捷指在企业对难以预测的顾客机会做出反应，不断重组其人力和技术资源的过程中，个人能够对赢利底线做出贡献，提高企业的净收入。因此，敏捷可以看作是对变化和不确定的全面反应。
变化和不确定，对于软件业来说，是多么熟悉而又让人烦恼的名词。软件工程自诞生以来，一直试图通过技术和管理的手段来降低软件项目的不确定性。在这个美好的愿景指导下，专家们发明了结构化、发明了面向对象、发明了CMM，这些新的技术和方法的确有助于“软件危机”的解决，促进了软件业的发展；然而，超支、超时、低质量的老问题并未得到根本解决。为了对抗不确定，软件开发越来越复杂，越来越庞大，传统的重量级（Heavy Weight）方法的副作用也越来越明显——组织臃肿、办事低效、官僚主义...
相对于重量级方法，软件业一直有另一种声音在，那就是轻量级方法（Light Weight），其目标是以较小的代价获得重量级相当的效果。
最负盛名的轻量级方法是XP。XP是Extreme Programming的缩写，从字面上可以译为极端编程。但是，XP并不仅仅是一种编程方法，也不是中文中理解的那种不可理喻的“极端”化做法。实际上，XP是一种审慎的（deliberate）、有纪律（disciplined）的软件生产方法。XP（Extreme Programming）植根于上个世纪80年代后期的Smalltalk社区。90年代，Kent Beck和Ward Cunningham把他们使用Smalltalk开发软件的项目经验总结和扩展，逐步形成了一种强调适应和以人为导向的软件开发方法。
XP的核心是四大价值，即改善沟通（communication），寻求简单（simplicity），获得反馈（feedback）和富有勇气（courage）。在此基础上，XP总结出了软件生产的十余条做法（practice），涉及软件设计、测试、编码、发布等各个环节。与其它轻量级方法相比，XP独一无二的突出了测试的重要性，甚至将测试作为整个开发的基础，每个开发人员不仅要书写软件产品的代码，同时也必须书写相应的测试代码；所有这些代码通过持续构建和集成（Continuous Build & Integration）为下一步的开发打定了一个高度稳定的基础平台。有了这样的基础平台的保证，XP就可以实施软件设计的再造（Refactoring）。XP的设计理念是，在每次迭代周期仅仅设计这次迭代所要求的产品功能，上次迭代周期中的设计通过Refactoring形成此次的设计。
2001年2月，在美国犹他州的一个滑雪场，17位轻量级软件开发方法的创始人和专家，包括Kent Beck（Extreme Programming）、Alistair Cockburn（Crystal Methodologies）、Jim Highsmith（Adaptive Software Development）等等，共同发布了“The Manifesto for Agile Software Development”（敏捷软件开发宣言）。这表明，在软业经历了无数次的项目失败之后，人们开始反思软件开发的工程特性，反思计划和控制的有效性，反思过去对于不确定性的态度和反应。敏捷终于为这个行业，以及这个行业中的一些人所认识、理解和推崇。
与会者之一Martine Fowler在其后来的文章“The New Methodology”中这样解释重量级、轻量级和敏捷：
轻量级与重量级的差异来自于人们对两种方法的文档数量的直观感受，即轻量级方法较少产生和依赖于庞大的文档，但这只是一个表面现象；在诸多的轻量级方法之间存在着很多相通的地方，敏捷更恰当的表达了这些轻量级方法的最根本之处。首先，敏捷强调适应，而非预测。重量级方法花费大量的人力物力，试图制订详细的计划来指导长期的工作，而一旦情况变化，那么计划就不再适用。因此本质上重量级方法是抵制变化的，而敏捷方法则强调适应变化。其次，敏捷方法以人为中心，而非以流程为中心（即以事为中心）。敏捷方法强调软件开发应顺乎本心（work with people’s nature ），软件开发应带来乐趣。
敏捷流程（Agile Process）汲取众多轻量级方法的“精华”，更加强调对变化的适应和对人性的关注。除了上面介绍的XP以外，其他知名的敏捷流程包括：
1. Crystal
Cystal事实上不是一种开发方法，而是一系列的方法。因为Crystal的发明人Alistair Cockburn认为，不同类型的项目需要采用不同的方法。Alistair Cockburn从两个维度来划分项目，一是项目规模，以人数计算；二是产品发生错误的后果，以严重性计算。
Crystal方法集也形成于90年代，当时，Cockburn接受了IBM的任务去写一些关于开发方法的东西。相对而言，Crystal的个人色彩要淡些，因为它不仅来源于Cockburn的个人经验，而且也来源于Cockburn走访的很多不同的项目；而Cockburn本人也较为思想开放，乐于接受“异见”。
在以人为导向上，Crystal和其他敏捷方法有些差异。在Cockburn看来，自由是人之本性，要人遵守纪律总是有难度的；因此，要在工作生产率和流程的纪律性之间作一权衡。流程要易于遵照执行，而这是以牺牲生产率为代价的。Cockburn认为，XP的流程规范仍太复杂和难于执行，而采用Crystal虽然生产率不如XP，但开发人员更乐于采用。
Cystal也强调在每个迭代后的Review，并以此进行Cystal方法的自身改进。
2. ASD
ASD（Adaptive Software Development）的发明人Jim Highsmith本来是一个传统开发方法的工作者，他有多年的预测型方法的研究、教学和实施经验，但后来，他发现这些预测型方法根本就存在很大缺陷，尤其不适合当前的软件业务。
ASD强调开发方法的适应性（Adaptive），这一思想来源于复杂系统的混沌理论。ASD不象其他方法那样有很多具体的实践做法，它更侧重为ASD的重要性提供最根本的基础，并从更高的组织和管理层次来阐述开发方法为什么要具备适应性。
3. SCRUM
SCRUM同样也包括了很多具体做法，这些做法并无多少特别之处，但多数有一个“怪异”的名称。比如，SCRUM将开发过程划分为30天的迭代周期，每个迭代周期叫做一个Sprint；每天有一个15分钟的短会，用来决定第二天的任务安排，这样的短会就叫做scrum。
SCRUM较为有特色的，是它特别强调开发队伍和管理层的交流协作。每天，开发队伍都会向管理层汇报进度，如果有问题，也会向管理层要求帮助解决。
4. FDD
FDD（Feature Driven Development）的发明人是Jeff De Luca和Peter Coad。FDD在OO社区较为人所知。
FDD定义了5个流程，分别是Develop an Overall Model、Build a Features List、Plan by Feature、Design by Feature和Build by Feature。其中前3个流程是在项目开始就进行的，而后两个则出现在每次迭代周期中。FDD的迭代周期是两周。每个流程被划分为不同的任务和相应的验证标准。
开发人员被归为两种，一种是主程序员，另一种是class所有者。主程序员不作具体的编程工作，但要负责将Feature和Class对应起来，并充当开发协调者、设计者、技术支持和指导者等；class所有者则进行实际的编程。
在软件业，敏捷流程还犹如星星之火，特别是在国内，敏捷流程还鲜为人知。在即将到来的未来，敏捷流程将何去何从，中国的软件从业者又将在其中扮演何种的角色，套用一句中国的古话，“路漫漫其修远兮，吾将上下而求索”。
您的位置：
