软件业的“敏捷流程”

　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本人也较为思想开放，乐于接受“异见”。

原文转自：http://www.ltesting.net