[
自适应型过程
迄今为止，我们已经讨论了在一个适应型过程中适应性是如何迎合快速改变的用户需求的。但这里还有个需要注意的问题：过程自身也是在不断变化的。一个项目目前用的一个过程和一年后的项目用的过程肯定不同。随着时间流逝，一个团队会发现怎样才能更好的工作，从而相应改变过程。
自适应型过程的第一步就是阶段性的复审你的过程。你可以在每一次迭代结束的时候做这件工作。开一个短会，问自己几个问题：（精选自Norm Kerth）
我们什么地方做的好？
我们学到了些什么？
我们怎么才能做的更好？
我们还有什么疑问？
这些问题可以帮助你在下一次迭代中改进你的过程。每个过程开始的时候都带有疑问，然后在过程中解决疑问，改进过程。这样做可以使过程运作的更好。
如果这种自适应发生在一个项目中，它对于整个组织有更显著的作用。为了加深自适应的过程，我建议每个团队每个阶段召开正式的审查会，建立主要的项目里程碑，举办定期的项目回顾会议（outlined by Norm Kerth）。这种回顾会议包括一个二到三天一次的会议和一个训练机制。这不仅使团队有了学习的机会，也使整个组织有了学习的机会。
这种自适应的结果是你不可能找到一个简单的合作方法。实际上每个团队都不能够仅限于自身的过程，而应该积极的改变过程以配合整个项目的进行。尽管有那些成文的过程和项目的经验可以作为参考，开发人员还是有责任不断的改进过程以完成手头的工作。
这种自适应性在ASD和Crystal方法中尤为强调。XP方法严格的规定表面上看似乎是排斥这种自适应性，但实际上XP方法是鼓励人们去改变过程的。XP方法的最大的不同在于，它建议这种改变在实际作用于过程之前需要经历多个的迭代阶段。而审查并不是XP方法强调的，也不是XP过程的一部分。尽管有许多人建议XP的关键实践应该加入审查这个环节
方法
目前已经有几种方法能够体现敏捷的思想了。虽然这些方法都具有很多共通的特性，但是它们还是有很多的不同点。因为这篇文章只是起提纲挈领的作用，我没有办法一一指出这些不同点，不过我至少会指出一些重要之处。我也没办法谈论这些方法的精髓之处。尽管我在XP方法上花费了很多的心血，对于RUP我也略有心得。不过对于其它的方法来说，我就显得有些无能为力了。
XP（eXtreme Programming）
在所有的敏捷方法中，XP方法是最受瞩目的一种。一个很大的原因是他的发明者－－Kent Beck的非比寻常的耀眼光芒。Kent Beck做了大量的工作来推广XP方法，领导着XP方法的发展。在某些方面，XP方法的普及倒是带来了另一个反作用：它排挤了其它的敏捷方法和这些方法中的闪光点。
XP方法的产生于Smalltalk界，在80年代末，Kenck Beck和Ward Cunningham合力将XP方法细化，在90年代初，二人又从众多的项目中提炼出了XP方法的实践。把软件开发方法的思想提高到一个新的境界：适应性和以人为本。
XP方法从非正式的实践开始的又一次关键性的飞跃是在1996年春。Kent受邀参加了对克莱斯勒公司的一个员工工资项目的审查。这个项目是一家缔约公司用Smalltalk编写的，但却陷入了困境。考虑到整个项目都被低质量的代码所充斥，Kent建议抛弃掉所有的源代码，重新从草稿开始开发。在他的领导下，项目重新开始。而这个项目因为成为XP方法的一块试金石而在XP的发展历程上写下了重重的一笔。
软件于1997年初投入使用，运行顺利。一直到1999年，由于取消了持续开发的开发，这个软件逐渐出现了一些问题。不过，直到我写这篇文章为止，这个软件仍然为10000名正式雇员提供服务。
XP方法的核心价值观包括点点：交流、反馈、简单、勇气。在这四点核心价值观的基础上，XP方法又定义了十二个的必须遵循的实践。其实这些实践的大多数都已经是一些经过测试和实践证明的老方法了。然而他们却常常被忽略，即便是在有充分计划的项目中。随着这些方法的兴起，XP方法把他们又融为了一个相互影响、相互促进的整体。
其中最令人感到吃惊的是，XP方法极端的强调测试。我们知道，虽然几乎所有的过程都提到了测试，可是始终没有把测试摆在一个重要的位置上。而XP方法则不一样，测试被视作开发的基础。每一个程序员在写代码的同时还要做测试。测试已经整合成为一个不断持续的迭代过程，并且为将来的开发奠定了一个坚实的平台。
以这个平台为基础，XP方法发展起一个不断改进的设计过程。这个过程是在每一次的迭代中重构一个简单的基础系统来实现的。所有的设计都是围绕着当前的迭代，完全不用考虑以后的需求发展。这样，一个设计过程是规范的过程。这种组合的规范法使得XP方法成为众多适应型方法中的佼佼者。
XP方法已经成就了众多的领导者，他们绝大多数都是在那个工资项目中发展起来的。这里有一些他们的相关资源。Jim Highsmith的Cutter论文是最好的总结，不过那时他还是个门外汉。他自己的方法我会在下文中提及。Kent Beck写了Extreme Programming Explained一书。这本书是对XP方法的最好宣传，它解释了在XP方法论之后的理论基础，提供了众多的解释来帮助有兴趣的人们继续深入研究XP方法。
还有两本书更深入的讨论了XP方法。他们也是那个项目的成员：Ron Jeffries, Ann Anderson, 和Chet Hendrickson。他们写了Extreme Programming Installed一书。这本书用项目中的经验来解释XP方法。我和Kent Beck写了Planning Extreme Programming一书，讨论了你怎样用适应性的观念来计划项目。
除了书以外，这里还有相当多的WEB资源。XP方法的最着的拥护者是Ward Cunningham的wiki网站。如果你要寻找更加结构化的XP方法，你可以考虑以下两个网站，顺便一提，他们的作者也是那个项目的毕业生：Ron Jeffries的xProgramming.com和Don Wells的extremeProgramming.org。Bill Wake的xPlorations转载了一系列有价值的文章。著名的C++和面相对象设计的专业作家－－Robert Martin也是XP的拥护者之一。他的公司－－ObjectMentor的网站上有很多的文章：RUP经过裁减后的一个XP实例：dX。还有一个出名的讨论组：xp discussion egroup。
Cockburn的Crystal Family
Alistair Cockburn从90年代初为IBM公司撰写有关方法论的文章开始，已经有多年的方法论的经验了。他的方法不同与其它的大多数的方法。他并不是根据个人的经验来建立指导项目进行的理论，而是主动接触项目，获取经验，来发现项目应该如何进行。而且，他丝毫不但心新的发现会影响他的观点。这些都是我欣赏这位出色的方法学家的原因。
他的著作，Surviving Object-Oriented Projects，是他探究那些正在实施的项目的第一步成果。
在那本书之后，他的研究又更上一层楼。接着，他又写了Crystal family of methodologies一书。之所以称它为family，是因为他相信不同的项目需要不同的方法。他把项目中所需要的人和错误结果作为两个轴。每个方法都有其适合的位置。一个40人的，允许任意的损失的项目和一个6个人，严格制定生命周期的项目所采用的方法就完全不同。
Crystal方法也赞同以人为本，这点他和XP方法是一致的。但是他的做法有很多种。Alistair认为很难让人们在项目过程遵守严格的准则，更不要说XP的高标准的准则要求了。Alistair试图找到一个以最少的准则来保证成功的方法，用一定的生产力来换取易操作性。所以他认为他的Crystal方法比起XP方法来虽然在生产力上略逊一筹，但是更多的人愿意使用Crystal方法。
Alistair也非常注意每个迭代阶段结束时的审查，鼓励不断的改进过程。他断言说，把项目分成多个迭代周期可以更早的发现问题，这样人们就可以及早的纠正错误。这就要求人们需要花更大的注意力来监视整个开发过程。
2001年2月，Alistair宣布他将和Jim Highsmith一起合作把他们俩的方法合并起来。
开放源码
你也许会被这个标题吓一大跳。毕竟，开放源码是一种软件形态，而不是一个过程。然而，在开放源码的世界中，有很多固定的方法，其中的很多方法不但适用于开放源码，也同样适用于私有源码的。很特别的是，开放源码的开发过程都是一些地理位置相隔很远的团队完成的。这一点很重要，因为大多数的适应型过程都强调团队要本地合作。
绝大多数的开放源码项目都有一个或多个维护者，只有一个维护者允许修改源代码库。而除了维护者以外的人也可以改变代码库。关键的区别在于他们必须向维护者提交他们的修改，维护者会审核提交的代码并加到代码库中。通常这种改变的方式表现为打补丁的形式，这种形式会相对容易些。这样维护者的工作就变成整理这些补丁并维护软件的核心设计。
不同的项目对与维护者也有不同的约定。有些项目只为整个项目指定一个维护者，有些则把项目分为多个模块并为每个模块指定一个维护者。有些则采用几个维护者轮流的方式，有些则有多个维护者对同一部分源代码进行维护，还有一些则综合了以上的这些方法。几乎所有的开放源码工作者都是业余的。所以，那些职业的团队开发者也应该能够干得更好。
开放源码的开发过程中有一个很特别的地方就是高度平行性的调试。非常多的人加入调试工作，但他们找到一个错误之后，就会给维护者发送一个补丁。这对于那些不做维护工作的人来说是一个很好的角色，因为除错工作的大部分的时间会花在找臭虫上，也不需要很强的设计技能。
开放式过程还有很多值得一提的地方。这方面的最著名的文章是Eric Raymond的The Cathedral and the Bazar，还有一本权威书籍是Karl FogelCVS 代码库，书中的一些章节描述了开放源码的过程，写得非常棒，即使是那些从来不打算升级cvs的人也会感兴趣的。
Highsmith的适应型软件开发
Jim Highsmith在可预测型方法上已经有多年的研究经验了。他不断的研究、事实、传播这些方法，最终他发现这些方法有着不可弥补的缺陷，特别是在现代的商业应用上。
他最近的一本书中，他的研究重点转移到了新的适应型方法上。书中，他提出了一个被称为混乱理论的想法，解释了复杂的适应型系统的起源以及如何应用他们。和XP方法不同的是，他没有提供具体的实践，他提供了一个基础，解释了适应型开发的重要性和在组织和管理级别上的深化对开发的影响。
ASD的核心包括了三个非线性的、重叠的阶段：思考、合作和学习。
Highsmith认为在一个适应型的环境中，计划是自相矛盾的东西。因为结果通常是无法预测的。在传统的计划中，任何和计划背离的行为都被视作错误，都应该被更正。而在一个适应型的环境中，背离的行为通常可以指导我们走上正确的解决之道。
在这样一个无法预测的环境中，你需要让人们更加富有合作精神，以应付那些可能发生的不确定的事情。管理人员的注意力更多的集中与鼓励人们沟通，而不是告诉人们该如何做。这样人们就可以提出有创造性的解决方案。
在一个可以预测的环境中，学习往往是件令人沮丧的事情，一切都已经事先计划好了，你只需要根据设计来就行了。
在一个适应型的环境中，学习是所有涉众（包括了开发人员和客户）的一个挑战，所有的涉众都必须检查他们的设想，使用和改进每个开发周期的结果，以适应下一个周期。
这样，学习就成了一个不间断的重要的功能。所有计划和设计都会调整，以做为开发项目的收益。
适应型开发生命周期的最最最最大的好处就是迫使我们对抗那种自欺欺人的精神根源，他使我们更加的现实的评估我们的能力。
在这种思想的指导下，Highsmith的工作集中在适应型开发的最难的部分。特别是怎样鼓励大家在一个项目中合作、学习。同样的，他的书鼓励人们使用诸如XP、FDD、Crystal之类的方法来建立软件的“软”基础。而2001年2月他宣布他的方法要和Crystal合并也是体现了这种思想。
SCRUM
在面向对象的领域中，SCRUM已经存在了一段相当长的时间了。虽然我并不是很熟悉它的发展历程。不过它的重点是集中在可定义、可重复的环境中，可定义、可重复的人制定可定义、可重复的过程来解决可定义、可重复的问题。
SCRUM把一个项目分为多个迭代周期（在SCRUM方法中被称为sprints），每个迭代周期的跨度大约为30天。在你开始一个sprint之前，你必须要定义这个sprint的功能需求，然后交给团队来实现。关键之处在于每一个sprint的需求都是稳定的。
不过，管理人员必须要参与每一个sprint。每天，团队需要举行一个短会（大约15分钟），称之为scrum。会上，团队需要通过明天的工作安排。特别是要提出对项目进程有阻碍的一些问题以便管理人员来解决。同时，他们还要汇报已完成的工作以便管理人员能够得到项目进度的日更新表。
SCRUM的主要焦点都集中在每个迭代计划和过程跟踪上。这和其它的敏捷方法注重的方面非常的相似。如果能够辅以XP方法的编码实践的话，SCRUM会工作的更好。
目前好没有任何关于SCRUM的书籍面世。不过这里有一些WEB资源：Ken Schwaber主持的controlChaos.com网站是关于SCRUM的最好的导读网站。Jeff Sutherland在object technology杂志上也有一个网站有一些部分是讨论SCRUM的。PLoPD 4一书中也有一些篇幅介绍了SCRUM的一些实践，有一定的参考价值。
DSDM（动态系统开发方法）
DSDM方法开始于1994年的英国。它是那些希望建立RAD和迭代开发系统的英国公司建立的协会。最早它有17个成员，现在已经发展到了1000多个成员，范围也扩展到了英国之外。作为一个发展起来的协会，和其它众多的敏捷方法相比，它有自己的特色。有一个职业的组织来为这种方法提供手册、训练课程、认证程序等等诸如此类。当然，这些都是有标价的。因为这一点，我没有办法继续深入的研究这项方法。不过Jennifer Stapleton曾经写过一本书，是这种方法的概览。
这种方法最先最是要做可行性研究和商业研究。可行性研究要考虑DSDM方法究竟是不是适合这个即将开始的项目。商业研究则要对项目所在的商业环境进行一系列的研究。这些也就成为系统架构和项目计划的一个提纲。
剩下的过程可以划分为三个周期：功能建模周期主要集中在编写分析文档和建立软件原型。设计和构建周期将构建可以操作的系统。实现周期将部署开发完成的系统。
DSDM有一些根本的原则，包括了使用中用户交互、频繁交付、充分授权的团队、贯穿整个周期的测试。和其它的敏捷方法一样，DSDM方法把整个周期划分为一些较短的周期，大约在2到6个星期之间。这种方法针对不断变化的需求特别强调高质量和适应性。
除了英国外，好像并没有多少人使用这种方法，不过DSDM不但遵循了敏捷方法的原理，而且也适合那些成熟的传统开发方法有坚实基础的软件组织。
敏捷软件开发的宣言
在这么多的方法中，让它们以某种形式在一起合作是一件非常有意思的事情。例如，2001年2月，这些方法的代表就受邀参加了在犹他州的Snowbird举行的一场为期两天的工作会。我也是其中一员，但我并不报太多的期望。毕竟，当你把这么一大捆的方法学家放在同一间房间里，保持礼貌就已经是你所能奢望的全部了。
令人惊讶的是事情完全不是按照我所想的那样发展。与会的每个人都认识到他们有很多的共同点。并且这比他们之间的不同之处要多得多。在各个流程方法的领导者之间达成了多项影响深远的共识，他们甚至要发布一项联合公报，号召合作以支持更多的敏捷软件过程的发展。（在会上，我们一致同意采用敏捷这个词来表达我们的共同想法。）
会议的成果是敏捷软件开发宣言，敏捷过程的共同价值和原则的宣言。大家还希望在未来能够进一步的合作，鼓励技术人员和商业人员使用和要求敏捷方法用于软件开发。commentary and explanation of the manifesto和比较短的future of the agile manifesto也作为文章发表。
RUP是一个敏捷方法吗？
不论什么时候，我们在面向对象领域谈论方法，我们都会不可避免的提到Rational Unified Process所扮演的角色。这个统一过程是由Philippe Kruchten, Ivar Jacobson和瑞理公司的其它人发展起来的，作为UML的过程实现。RUP是一个过程框架，他能够容纳各种各样不同的过程。实际上，这也是我对RUP最主要的批评，既然它能够是任何的方法，那也意味着它任何方法也不是。我倒宁愿一个过程告诉你应该如何做，而不是提供永远不会结束的各种选项。
既然是过程框架，那就意味着RUP既可以被用作非常传统的瀑布模式，也可以被用在敏捷方法上。所以我们可以在敏捷过程中使用RUP，也可以在重量级过程中使用它。这一切都取决于你怎样在你自己的环境中裁减RUP。
Craig Larman强烈建议以敏捷方法的思维方式来使用RUP。他的那部introductory book on OO development就介绍了一个基于他的轻型的、RUP的思维方式的过程。他的观点是敏捷方法除非能够和RUP整合起来，否则它永远也无法成为主流的OO开发方法。Craig会在时间跨度为一个月的迭代周期开始花费二到三天的时间来和他的全部团队使用UMl来勾画出整个迭代过程中该做的工作的设计。这并不是什么不能够违背的蓝图，这只是一份草图，勾勒出系统在迭代后会是什么样子。
另一个敏捷型RUP方法是is Robert Martin的dX process。dX过程是RUP的一个完整的、相容的实例，对XP方法也一样（把dX翻转过来试一试。）。dX是为那些必须使用RUP，但又想要使用XP的人设计的。这样，它既是XP又是RUP，这也算是RUP的敏捷型应用的一个好例子吧。
对于我来说，使用RUP方法的关键是RUP的工业应用领导者必须重视他们开发软件的方法。我就不止一次的发现那些使用RUP的人其实是在使用瀑布模式开发软件。由于我和工业界保持一定的接触，我知道Philippe Kruchten和他的团队对迭代式开发坚信不疑。弄清楚这些事情，鼓励诸如Craig's和Robert那样发展出RUP的敏捷实例都有重大的影响。
其他资源
这里还有一些讨论轻型方法的文章和讨论。虽然他们都不是完整的方法论，但他们都对这个正在成长的领域提供了一些见解。
Patterns Language of Programming讨论会包括了这方面的一些讨论，因为那些对模式感兴趣的人们通常对更适应性、更人性话的方法感兴趣。最早的论文是Jim Coplein在PLoP1上发表的论文。还有PLoP2上Ward Cunningham的模式语言。Jim Coplein现在正在主持OrgPatterns站点，收集组织型的模式。
在XP2000上，Dirk Riehle发表了他的论文，讨论XP方法和适应型软件开发的价值系统的比较。Coad letter的7月号对比了XP方法和FDD方法。IEEE软件的7月号也发表了几篇“过程差异性”的文章，也涉及到了这些方法。
Mary Poppendieck写了一篇优秀的文章来讨论敏捷方法和lean制造业的对比。
你应该使用敏捷方法吗？
并不是所有的人都适合使用敏捷方法的。如果你要走上这条路的话，有一些事你必须记住。不过我确信这些新的方法将会广泛应用，而且会有比现在多得多的人们使用。
在目前的环境中，最常见的方法仍然还是“code and fix”。比无序方法应用更多的规则当然有用。而敏捷方法的优势在于比重量级方法少了很多的步骤。敏捷方法的最大的好处就是它们较轻的重量。当你已经习惯于根本没有流程的时候，简单的流程似乎更容易被接受。
这些新方法的最大的限制就是如何使它们适合更大的团队。Crystal大约能够支持到50人，如果超出这个范围，目前还没有证据能够证实你是否能够采用这种方法。也许它能够工作更好也说不定。
这篇文章很明白的表达了一个信息：适应型的方法在你的需求不确定或不稳定的时候很好用。如果你没有稳定的需求，你也就没有办法遵循一个计划好的过程来进行一项稳定的设计。在这种情况下，适应型过程执行起来虽然会比较难受，不过会更加有效。通常最大的障碍是顾客。依我之见，最重要的就是要让客户明白遵循一个可预测的过程，需求的改变对他们，对开发者来说都是一件冒险的事。'
[本文共有 2 页，当前是第 2 页] <<上一页 下一页>>
]
您的位置：
