XP 与 Scrum，只取其一，两者都取，还是全都抛弃？

Scrum 还是 XP，哪个更好呢？是其中一个比另一个更适用，还是另有其他选择？

Tobias Mayer 最近在其博客文章《不要用 XP》中写到：

好多人坚持说：Scrum 要是没有 XP 配合就行不通，跟他们反反复复的讨论让我开始有点厌烦了。如果理解了 Scrum 基础的价值观和原则再应用的话，Scrum 是没有问题的。你实施 Scrum 的环境，决定了你需要应用的实践。教堂里的 Scrum 和软件业的 Scrum 会有一套不同的好做法，而他们与法律行业中的 Scrum 又都不一样。

因为 Scrum 在软件业中缺乏好的开发实践，XP 的鼓吹者很快就对其进行责难。可是考虑到 XP 实施如此之慢，也可以争辩说（我也会这样干），实际上 XP 本身要对我们这一行业缺乏好的实践负责。

似乎 Tobias 所说的是，Scrum 足以“拉出”（就精益开发而言）必要的技术实践，而无需使用全部 XP 实践。XP 是个很大的负担，其采用者寥寥即是明证。

Steve Freeman 以《就要用 XP》来回应 Tobias 的博文：

作为一个偶尔鼓吹 XP 的人，我没有“因为 Scrum 在软件业中缺乏好的开发实践而对其进行责难”，我责难的是软件业。如果我们在行之有效的行业工作，就不会有方法论之争了，因为事物本来就会正常运转。现在这个行业也在乱搞 Scrum，只从事它仪式化的部分。而另一方面，责难 XP 阻碍了好的实践，也够匪夷所思的。

XP 是一个规模不大的运动，获得了一些关注。很多开发团队仍然被各种过于谨慎的各种条条框框所约束，有可能会求诸于胡乱省略式的开发，而且敏捷让人们看到避免类似状况的可能。它给了团队一套可靠而起作用的实践。当然 XP 没能掌管全世界，因为不是人人都适合它，在一定程度上它需要人们集中精力投入，还有技能上的要求，而这对很多团队并不合适。Kent Beck 对 XP 第一版的演示是故意走了极端：其设计是要启发我们这些畏首畏尾的大众，拓展软件开发中可行之事的界限，以重构大家的探讨。

Steve 接着说道，XP 与当今出现的技艺（craftsmanship）运动颇有渊源：

Tobias 写道，好的开发实践当时传播缓慢，但我会争辩说，没有 XP 的话，我们到现在还等着呢。测试驱动开发（TDD）仍然没有被广泛接受，而且在 Kent 写书之前，甚至最初的 C3 团队也没有全部采纳它。重构（Refactoring）有一小批学院派的追随者，但如果没有 TDD 实践的补充，它也不是那么安全。我怀疑大多数团队仍然禁止改变代码，除非是为了改动一项功能特性。结对编程仍然很难推广，这又跟 TDD 相关，因为它在 TDD 的上下文中要成功得多。我见多了那些 Scrum 团队，他们没有找到一套有条理、游系统的技术实践。要断言他们只是需要改善 Scrum 的实施，就不得不回答诸如 Scrum 如何被采行、自组织的局限等等问题。

上述和其他很多对话，促使 Yves Hanoulle 提出：也许敏捷社区正在经历“初起炉灶—暴风骤雨—照本宣科—大放光彩”循环的第二阶段：

看起来，我们的大量讨论都是在质疑我们所在的行业。

我感觉这一次的规模前所未有。也许我太年轻了；也许我现在更为投入，或是更有对错主见了；也许是这个总是紧密联系、充满推客和博客的世界让这些讨论如此地公开化。

这让我总是想起团队生命周期中的“暴风骤雨”阶段，或是 Satir 模型中的混沌期。所以从一个教练的角度看，这些讨论及其未来进展，都十分有趣。

在这些讨论中，很明显没有领导者。或者让我换种说法，没有人人都认可的领导者。

所以，我们社区内的这次争执，可能就是我们逐渐成熟的一个标志。本文作者从自己的经历中发现，任何事情在一定环境中都是合理的。有些成功团队从 Scrum 开始，另一些从 XP 开始，还有很多人使用这两种方式却都失败了。我们在敏捷社区里擅长的是，从试验中学习，同时从不忘记：所有这些实践和流程都只是通向结果的方法而已。

查看英文原文：XP or Scrum, Either, Both, or Neither?