在文章远离极限编程(Don’t do XP) 里, Tobias Mayer 建议人们不要去搞极限编程(XP)。 我和Tobias相知已久，我想他这个问题上错了。 我不知道他在跟谁争论，但他们的有些争论就是“嚼舌根”。我想如果他曾经试过一次XP，那他的言论会更有说服力。 XP并不是一个万能的解决方案，但它确实是一种方案，而且我们知道如何使用它。

作为一个临时的XP支持者，我并不抱怨 “在软件工业中Scrum没有提供很好的开发原则”，我只抱怨这个产业。 如果我们能在这个产业里有效率的工作，那我们也就不会有这场关于方法论的战争了，因为我们的目地就是出产品。 如今当人们把Scrum概念应用到这个产业时，Scrum也不幸被人们使用的混乱不堪。 另一方面，责备XP阻碍了实施方法的进步显然有些牵强。

XP是一种很小的运动，只吸引了一部分人的目光。 XP（第一版）所实现的成果是让大家知道解决一直困扰很多开发团队的无法负担开发工期压力的问题是有办法解决的，而且是在不须求助高人协助的情况下。 它提供了我一套好的实践方法让我们在开发中使用。 当然了， XP 并不能解决世界上的所有问题 ，它并不是对每个人都适用，至少一个原因是你必须对它有相当的认识和研究，这是一般的团队所不具备的。 Kent beck所论述的第一版XP极具有针对性：它的设计目标是让我们控制混乱，拓宽我们软件开发的思路，重新制定研讨框架。

我 想Tobias似乎已经忘了这十年来发生的事情。 其实我们所处的完全是一个理论性的运动，因为XP把推迟代码实现作为论述的中心—— 只需看看与此相关的人，他们是相同的一群人。 他似乎也忘了众多的XP实施建议直接和我们的直观感觉有冲突，特别是和当前的产业发展方向有冲突。

Tobias说这些优秀的开发实施意见传播的如此缓慢，而我要说的是，没有XP，我们估计仍在原地等待。 测试驱动开发一直没有被广泛的接受，甚至连最初的C3小组也没有完全的接受它——直到有一天Kent写出了这本书。 持续反省理论有一小群学院派的人追随，但是这种理论的实践如果没有TDD很好的支持会存在一定的风险情。 我怀疑大多数的团队仍旧不愿轻易重整代码，除非要添加新的功能。 结队编程方式也在滞销，同样，这种方式在TDD的环境中发挥的会更好。 我知道有相当多的Scrum团队都没有找到一套系统的方法理论。 如果说他们需要改进Scrum的实施方法，这是把问题归咎于他们如何使用Scrum和他们的自我组织问题。

最的的一点挑剔。 XP的论著有二版，第二版发布不是很久远，而且里面提到的方法论更加“柔和”。 与这些实践理论相关的一件事情：C3 项目组是在 (Smalltalk/Gemstone) 这样的环境中工作的，落后于大多数我们今天使用的环境。 XP社团里的很多工作都是在增加XP的灵活性，让它能在新的开发环境中使用。 真正让人恐怖的事是这个产业缓慢的发展速度。

英文原文：Do do XP

分享这篇文章：