From www.chinaxp.org


翻译自Pete Mcbreen的Questioning XP( Draft version)


Part 1 介绍

Extreme Programming 是一个“牛皮”？还是一个真正高效（牛鼻）的软件开发方式？Extreme
Programming不过是符合程序员的本性？还是真的在一些环境中需要如此的注重Coding作为项目的关
键？这些极限家伙们是在摧毁软件工程的基础还是他们真的找到提高小规模的开发队伍生产力的方法？

这样的问题其实是很难回答的，因为这样的问题太大了，导致很难去发现这些问题覆盖下的很多的细微
的疑问。本书的一个任务就是去改变这种大而华丽的讨论方式。而Extreme programming在推广的初期
也是用同样的华丽的的口吻。一个经典就是“所有的Models都是谎话罢了”，这个说法引来无数争论因
为他显然枰击了用UML来做设计的方法。

尽管引来雾一般混乱不清的争论，但Extreme Programming确实重新启动了关于软件开发管理的对话。
而Agile Alliance也部分因为围绕XP争论而成立。当Agile Alliance尝试去比较传统的软件工程和敏捷
方法的时候，Agile alliance发现在敏捷开发过程中，“人和沟通”比“过程和工具”更重要。

这是个有趣的发现，因为在大部分对Extreme Programmign的评论都是针对它的流程和实现方法。但好
像把XP称作一个优化的流程本身就已经把XP拖离了XP所代表的敏捷基础：“对开发人员的尊重和他们之
间的有效沟通”是最不一样的地方。

XP是一个满神奇的东西，它在没有任何一个大机构作为背景下却能引起这么多的人的兴趣，也许“尊重
开发人员”是一个原因吧。当然，那些早期的XP的拥护者们采用XP也是一个原因了，因为他们挑战传统
的软件开发并迫使人们开始在传统和敏捷之间进行选择了。

第一章 XP：泡沫还是神话？（牛皮还是牛X？哪个更好:-)）

“Extreme Programming：你要做的所有事情就是‘写程序’”！！--Ron Jeffries/Chet
Hendrickson，Smalltalk Solutions 1998

这是我当时听到的最让人惊讶的关于XP的描述。那时候，我正在和Ron Jeffries就他所说的“整个项目
开发组都认为这是我们做过的最好的项目”进行第一次交谈。其实也不奇怪，因为所有的XP拥护者都是
这么异口同声地赞美XP的，而且都快到了宗教崇拜的程度。而且，通过一些方法，XP一直设法让软件开
发过程在程序员的眼中变得更有趣。

也有一些人认为XP是吹牛皮——XP居然声称解决了软件开发中的所有难题，因此大量的精力可以投入到
编程中！——所以名字叫极限“编程”。他们认为，XP实际所做的不过是厚此薄彼：将以前软件开发中
的主角，不写成程序的系统分析员和设计员，变成了配角；而把以前的配角，程序员，变成了主角。

很多围绕XP的争论都是因为程序员引起的。虽然XP的网龄很小而且没有大机构撑腰，但它却变成软件开
发领域中最引人注目的一员，是因为很多程序员推动并要求他们的经理使用XP。

程序员的这种做法引起很多争议，因为这样做不符合引进新软件工程方法的常规。通常，经理们应该在
仔细评估了不同开发商的众多建议后才采用一个新的软件工程方法。

XP改变了所有的事情。程序员们都变成了XP的免费布道者，他们对XP的了解比经理们更多。而那些听起
来好得让人怀疑的关于XP的故事，让XP的推广看起来更象布道了。



一些典型的关于XP的声称、驳斥和误解

——一个好的XP项目开发组的效率是传统软件开发项目组的6倍；

——每个两到三周的开发周期（Iteration）的后期，有所改变的应用系统都能作为一个产品发布；

——重构（Refactoring）让传统软件开发中的设计（Big Design Up Front）失去意义；

——源码中的注释表示这段代码不够清晰，需要重构；

——所有的测试都是自动化的；

——所有你要做的事情就是编程；

——XP宣扬牛仔式的编程（不顾设计和公共规则，可以随意为之等）；

——所有的模型都是谎话，只有测试才是真的；

——XP是一种被美化了的剽窃；

——XP让软件工程学倒退了30年；

——XP仅仅是一些荒谬的经验之谈；

——如果仅仅是为了让用户积极参与软件开发过程而提出一个新名字，当然行；但我们已经这样做很久
了。XP并没有什么新东西。

找到了有力的证据支持XP吗？

这是关于XP的争论的核心，也是争论还会继续下去的原因。软件开发是一种人类的社会化活动，因此也
不可避免霍桑效应——一个在研究小组及其生产力时的重要影响因素。
[http://staff.psy.gla.ac.uk/~steve/hawth.htm/]

一旦你开始研究一个小组，研究本身就已经对这个小组造成了很多变化。在最早的霍桑研究中，绝大部
分的改变都使产出增加；即使研究人员将所有条件恢复至研究开始时的样子，产出仍然在增加。研究人
员对一个6人小组观察了5年，虽然有人就规模太小以及更换过两个小组成员而质疑该研究过程，但该研
究还是突显了实验设计的重要性。

霍桑效应在研究XP时也很重要，因为动机等心里因素对软件开发影响很大——事实上一些人宣称，人的
因素最大程度地决定了项目结果[Cockburn，2002，p 43]。如果一个开发小组被鼓动了很久并最终决定
采用XP，他们当然会尽一切努力使之成功。同样的，如果一个小组被迫地采用XP，他们首先从心理上抗
拒它，从而最终以项目的失败来证明XP是不可行的。

也许可以找到一些对XP持中立态度的程序员，但他们的态度在研究过程中也会发生变化。因为当他们实
践XP时，XP会一点一点地彻底改变他们的态度。Pair Programming和测试优先（Test First Design）
是两个最突出的例子。在XP项目中，程序员们不再是一个坐在那里先写程序然后测试自己的程序；而是
每两人一组一起工作，先写测试代码，然后写程序，之后再运行测试来检查写的程序是否合格。这和传
统的软件开发过程差别太大了，“文化冲击”这个词都不足以描述这种差别。正是因为XP给程序员带来
了这么大的变化，所以很难找到真正中立的程序员。

另外，即使你能找到一组适合XP研究的程序员，你也很难找到做参照的（使用传统开发方式）一组程序
员。因为做参照的一组为了超过被研究的一组，会尽他们最大的努力（亨利效应）。




附，亨利效应：

有一位叫亨利的青年，三十多岁了仍一事无成，他整天在唉声叹气中度日。一天，他的一位好友告诉
他：“我看到一份杂志里面讲拿破仑有一个私生子流落到美国，这个私生子又生了一个儿子，他的全部
特点跟你一样：个子很矮，讲的也是一口带法国口音的英语……”亨利半信半疑。但当他拿起那本杂志
琢磨半天后，终于相信自己就是拿破仑的孙子。此后，亨利完全改变了自己对自己的看法。从前，他以
自己个子矮小而自卑；如今他欣赏自己的正是这一点，“矮个子真好！我爷爷就是靠这个形象指挥千军
万马的。”以前，他觉得自己英语讲得不好；而今他以讲带有法国口音的英语而自豪！当遇到困难时，
他会认为“在拿破仑的字典里没有‘难’字”。就这样，凭着他是拿破仑孙子的信念，三年后，他成了
一家大公司的董事长。后来，他请人调查他的身世，才知道他并不是拿破仑的孙子，但他说：“现在我
是不是拿破仑的孙子已经无关紧要了，重要的是我懂得了一个成功的秘诀：当我相信时，它就会发
生。”

在做研究时，被研究的一组可能因为被重视而更加努力（霍桑效应）；但被对照的一组也会不甘落后而
被激发自尊心，这就是约翰亨利效应。


我们是否需要通过研究来比较XP和其他软件工程方法？

虽然XP的反对者们一直要求关于XP的成效的研究，但如果你看看其它的软件工程方法，就会发现没有任
何类似的实际研究可以支持它们。人们从来没有在合理规模的项目上进行过研究来对比这些软件开发方
法。事实上，人们不能相信软件工程领域中的任何研究，因为这些研究不是太旧，就是持续时间太短
（几个星期）并且数量规模太小。

——不能相信在10年以前进行的研究。因为软、硬件开发工具在过去几年内日新月异。以前我们使用的
是低级编程语言，用批处理方式编译，一天能编译成功3、4个程序就已经很幸运了；而现在我们是在交
互式开发环境中进行面向对象的编程。个人认为，二者的差别非常巨大。

——小规模的短期研究也因其短期学习效应而受到质疑，因为这些研究中的程序员多数是开发新手。新
手使用的方法和策略与熟手不同，而熟手转用一个新方法时效率会下降很多。因此，不能根据这些短期
研究得出的结论去推断一个熟练开发人员的情况。


那还有可能做这样的研究吗？有一个可能，就是对一个为期2-3年的项目，对其开发、进展和维护过程
应用不同的软件开发方法。但这又基本上时不可能的。因为首先这个项目要比较复杂，需要至少一组6
个程序员；而且为了平衡个人的工作效率和能力，你还要同时应用几组不同的程序员；另外，为了覆盖
众多的开发语言和平台，研究费用更会急剧上升。




重新评估变化的代价

人们经常引用的一个研究结果是项目变化会带来指数级的成本增长，现在我们一定要重新确认这个结论
的有效性。这个结论源于 Boehm 的《软件工程经济学》[Boehm，1981，p40-41]，但其中使用的是1980
年或更早期的数据。Kent Beck 在《Extreme Programming Explained》一书中已经指出，变化导致成
本大幅上升已经成为过去，事实上他称之为“XP可行的技术前提”。

我们很难得到变化引起的成本变化的具体数字。因为，你所使用的软件开发方法影响变化带来的成本代
价，而你对成本和可能的变化的预期又影响了你采用的开发方法。我们同时必须记住，软件开发是一种
经济活动，每种针对变化的策略所需的代价都会随着具体项目而变化。

——是否需要进行详尽的分析和灵活的设计，以便将来只要简单地修改配置文件就可以满足所有可见的
变化？

——是否需要进行详尽的分析以便理解哪些地方需要容纳变化，并增加额外的投资使那些相应的软件模
块非常灵活？

——是否需要让系统中的各模块尽量不相干，以便将来能根据需要灵活地改动？

——是否应该只关注如何开发好当前版本的系统，因为将来的变化是另一个独立的项目开支？

还有更多的类似策略，它们各自非常适合某个环境，但哪个才适合你的项目呢？


术业有专攻

软件开发中没有“一个最好的方法”。事实上，就软件开发而言，说有一个“最好的方法”是错误的。
就象我在《软件技巧》[McBeen，2001]一书中所说的，“最好的方法”这个念头是科学化管理中的过时
的东西，也不应该出现在软件开发中。软件开发中的所有方法都有其适用之处，一个方法是否合用取决
于很多因素，包括开发小组、项目、环境等等。

评价软件开发方法的困难，和围绕XP产生争执的原因，本质上在于结果不可复制性。即，某个开发小组
在某个项目上成功地应用了某个开发方法，不意味着另一个开发小组在另一个项目上也能成功地应用同
样的开发方法。

 回复: 新书：质疑Extreme Programming预览（1,2,3）
　

---

经过实践XP开放方法还是不错的，尤其适合人数少的小项目。