绝大多数的开放源码项目都有一个或多个维护者，只有一个维护者允许修改源代码库。而除了维护者以外的人也可以改变代码库。关键的区别在于他们必须向维护者提交他们的修改，维护者会审核提交的代码并加到代码库中。通常这种改变的方式表现为打补丁的形式，这种形式会相对容易些。这样维护者的工作就变成整理这些补丁并维护软件的核心设计。
不同的项目对与维护者也有不同的约定。有些项目只为整个项目指定一个维护者，有些则把项目分为多个模块并为每个模块指定一个维护者。有些则采用几个维护者轮流的方式，有些则有多个维护者对同一部分源代码进行维护，还有一些则综合了以上的这些方法。几乎所有的开放源码工作者都是业余的。所以，那些职业的团队开发者也应该能够干得更好。
开放源码的开发过程中有一个很特别的地方就是高度平行性的调试。非常多的人加入调试工作，但他们找到一个错误之后，就会给维护者发送一个补丁。这对于那些不做维护工作的人来说是一个很好的角色，因为除错工作的大部分的时间会花在找臭虫上，也不需要很强的设计技能。
开放式过程还有很多值得一提的地方。这方面的最著名的文章是Eric Raymond的The Cathedral and the Bazar，还有一本权威书籍是Karl FogelCVS 代码库，书中的一些章节描述了开放源码的过程，写得非常棒，即使是那些从来不打算升级cvs的人也会感兴趣的。
Highsmith的适应型软件开发
J im 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人，如果超出这个范围，目前还没有证据能够证实你是否能够采用这种方法。也许它能够工作更好也说不定。
这篇文章很明白的表达了一个信息：适应型的方法在你的需求不确定或不稳定的时候很好用。如果你没有稳定的需求，你也就没有办法遵循一个计划好的过程来进行一项稳定的设计。在这种情况下，适应型过程执行起来虽然会比较难受，不过会更加有效。通常最大的障碍是顾客。依我之见，最重要的就是要让客户明白遵循一个可预测的过程，需求的改变对他们，对开发者来说都是一件冒险的事。
文章来源于领测软件测试网 https://www.ltesting.net/
