程序员－－有责任感的专业人员
Taylorist理论最关键的一点是他认为那些工人并不会主动改进工作，从而更好的完成工作。在一个工厂里，这个理论也许成立。原因有二：一是工厂中有相当一部分的工人都不是那种绝顶聪明，又富有创造力的人；二是管理者和工人间的关系很紧张，因为工人的酬劳越低，相应工厂所有人的收入就越高。
近来的历史经验表明，这个理论在软件开发中是站不住脚的。受到软件行业的耀眼光环和潜在高收入的吸引，有越来越多的聪明能干的人投身到这个行业中。（我也是其中的一位，离开电气工程行业进入软件行业。）例如现在的股票期权也是为了让程序员的发展能够和公司发展相一致。
如果你想要使用最优秀的员工并能够留住他们。你就必须认识到他们都是真正的专家，而且，他们都是最棒的，完全能够完成你的技术活儿。Taylorist 的那种把计划部门单独出来的做法只有在计划者比那些工人更优秀、更能胜任工作的条件下才成立。如果你确实很聪明，把你的聪明才智放在如何激励你的属下上吧，而不是去阻碍他们。
面向过程的人员管理
敏捷方法中以人为本有很多种的实现方法。这些方法的效果各不相同，而且其中一些方法之间也无法共通。
一个是改被迫接受为主动接受。常常管理者都会给程序员强行施加一些任务，通常开发人员都对这种任务很敌视，如果这项任务需要占用大量的时间使得程序员不得不从手头的任务中挤出时间的话，这种敌视的程度还会加剧。改被迫接受为主动接受需要开发人员主动承担，而且需要整个团队的积极参与。
这就有了一个有趣的结果，只有开发人员自己有权利选择开始一个适应型过程。正在XP中已经做到了，当然还有许多的准则来保障。而这也是Crystal的长处：只有很少的准则，却能够有效的完成任务。
另一个观点是开发人员必须做出所有的技术决策。XP就体现了这个观点的核心思想：它规定在计划阶段，只有开发人员才能预估出任务需要的时间。
这样，技术领导者的身份有了很大的转变，众多的开发人员成了管理者。这种方法需要一个项目中开发人员和管理者是平等的，有着同等的地位，同样的责任。注意，我说的平等指的是仍然存在管理者这个职位，但可能是由那些资深的开发人员来担任。
这样做的一个很重要的理由是计算机产业中技术以极高的速度发展。短短几年，技术就可能已经过时了。这个产业的技术能力和其它产业简直不可同日而语。技术人员必须意识到，进入管理领域将会使他们的技术能力迅速萎缩。那些资深的开发人员也必须认识到他们的技能也会很快的消失，你必须相信、依靠其他的开发人员。
业务领导者的角色
技术人员是没有办法独自完成整个开发过程的。他们需要业务需求上的指导。这就引出了适应型过程中的另一个重要的概念：开发人员需要和业务专家保持非常紧密的接触。
大部分的项目中都准备了业务的角色，一个敏捷团队决不仅仅只是和客户做短暂的交流，他们会和业务领域的专家不断的交流。而且这种交流并不只是停留在管理层面上，而是深入到每个开发人员，每一个的细节。开发人员和业务领域专家一样都遵循一定的准则。
这样的主要是因为适应型的方法强调本性。既然适应型方法假定事务总是迅速变化的，你就必须不断的和业务专家保持交流以保证改变。
恐怕对开发人员最大的打击就是看到自己的努力成果付诸东流。所以，重点在于，必须要有一个高素质的业务专家，开发人员能够从他那里的到帮助。
自适应型过程
迄今为止，我们已经讨论了在一个适应型过程中适应性是如何迎合快速改变的用户需求的。但这里还有个需要注意的问题：过程自身也是在不断变化的。一个项目目前用的一个过程和一年后的项目用的过程肯定不同。随着时间流逝，一个团队会发现怎样才能更好的工作，从而相应改变过程。
自适应型过程的第一步就是阶段性的复审你的过程。你可以在每一次迭代结束的时候做这件工作。开一个短会，问自己几个问题：（精选自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一起合作把他们俩的方法合并起来。
开放源码
你也许会被这个标题吓一大跳。毕竟，开放源码是一种软件形态，而不是一个过程。然而，在开放源码的世界中，有很多固定的方法，其中的很多方法不但适用于开放源码，也同样适用于私有源码的。很特别的是，开放源码的开发过程都是一些地理位置相隔很远的团队完成的。这一点很重要，因为大多数的适应型过程都强调团队要本地合作。
文章来源于领测软件测试网 https://www.ltesting.net/
