XP 主题的变奏

为什么要购买方法论？

为了帮助回答这些问题，我认为我们必须退一步问问自己：方法论的目的是什么？为什么有人会想要使用方法论？我认为答案是，方法论的客户是那些关心如何正确开发软件的人，他们期望通过遵循方法论，他们将走上一条经过验证的道路，从而提高他们成功的几率。

人们也可能说，通过遵循方法论，他们正在通过说“我已经尽我所能——我遵循了一个受人尊敬的方法论”来保护自己免受失败的后果。虽然人们通常会谴责后一种理由，但事实是，在许多学科中，你被期望遵循一个特定的流程来完成一项任务，如果你不遵循，你可能会对以后出现的问题承担更大的责任。

无论哪种情况，人们都希望遵循一些步骤来提高他们成功的几率。这是合理的。毕竟，我们已经开发软件几十年了。我们应该能够从他人的经验中吸取教训。

方法论的可变性

残酷地说，大多数方法论都是方法论者根据他们曾经做过的事情做出的陈述。如果他们幸运的话——我怀疑他们中的大多数都是基于他们希望自己能够做的事情。最好的情况是，你可能会有几个人将想法结合起来：但是否有人真正做过这些事情，则是另一回事。

软件也是极其多变的。首先，软件中的一个关键变量是人。不同的方法对不同的人会有不同的效果。公司文化也会产生很大的影响。还有软件的风格。我不相信为电话系统设计的流程适用于信息系统，也不适用于游戏。

公平地说，很大一部分方法论者都认识到这一点。他们知道，他们不能给出人们应该遵循的简单步骤序列，并获得完美的结果。总有一些适应，一些调整要做。但我们如何指导调整？方法论的客户如何知道什么是合理的调整，什么是违反方法论的？

对于那些遵循敏捷方法论的人来说，这个问题尤其重要。这些方法论的一个关键特征是它们是我所说的自适应的：也就是说，你应该在使用过程中随着时间的推移改变方法论。在这种情况下，可接受变化的边界更加灵活。不仅在同一个项目使用方法论之间存在差异，在同一个项目中随着时间的推移也存在差异。

这就是方法论者的困境。你如何描述方法论内部的变化，以便你能够确信真正试图遵循你建议的人会获得你期望的好处，同时又允许他们调整你的建议，使其更好地匹配他们的具体情况？

可变性和方法论

当我们研究方法论的灵活性问题时，值得记住的是，目前存在着各种风格的方法论。每一种都给变化问题带来了一组不同的问题。因此，这里有一组方法论分类供你思考。请记住，我在这里使用的术语是我为本文创造的，它们之间的界限非常模糊。

首先是具体流程。具体流程会给你一套固定的实践，你应该遵循这些实践。具体流程允许很少或根本不允许变化。具体流程的优势在于它非常清楚地说明了你要遵循什么。具体流程的明显局限性在于你无法改变它。实际上，你可以改变它。人们总是会采用一个具体流程，并对其进行本地修改。问题是，方法论没有给你任何关于如何做到这一点的指导。此外，一旦你开始改变，你就严格地脱离了流程，尽管你可能足够接近，以至于流程的粉丝会说你仍然在流程中——特别是如果你成功了。

由于具体流程是如此固定，因此许多流程都附带了关于如何改变它的明确指南。我将这种流程称为可定制流程。可定制流程通常有一部分流程描述专门针对哪些变化是可接受的，以及何时使用这些变化是合适的。因此，它们比具体流程更胜一筹，因为它们确实提供了关于变化的建议。然而，它并不完美，因为理解如何正确地做到这一点通常非常困难。你必须理解基本流程和所有变化，才能决定该怎么做。

此时，值得思考一下流程的大小。理解流程的大小并不容易，但一种方法是思考你阅读了多少内容才能掌握流程。一个常见的模式是拥有大型可定制流程。其理念是告诉你所有应该做的事情，然后告诉你哪些可以省略。然而，要做到这一点，你需要先理解大型流程，然后才能弄清楚小型流程。如果你需要一个更小的流程，这可能比你想要的要多得多工作。

有许多流程是可定制的，也许目前最著名的一个是Rational Unified Process。它比大多数流程更可定制，以至于被称为流程框架。它的解释方式是，任何使用 RUP 的人都将使用一个特定的流程，该流程是 RUP 的一个实例，并且不需要使用或理解 RUP 的全部灵活性。因此，完全有可能同时使用一个具体流程和 RUP（一个可定制流程）。在我看来，如果你这样做，并且没有真正查看 RUP，那么你使用的是具体流程。但 RUP 可能会帮助你获得具体流程所缺乏的变化建议，并帮助你与使用 RUP 其他具体实例的人进行沟通。

有些流程根本不提供非常具体的步骤，而是专注于教授软件开发的哲学，这种哲学是流程的基础。这种哲学流程本质上是灵活的，因为你可以用许多方法来执行符合这种哲学的项目。由于它们没有详细介绍步骤和变化，因此它们可以在不像可定制流程或流程框架那样庞大的情况下做到这一点。然而，由于它们缺乏具体的步骤，因此它们通常更难遵循，它们没有明确地告诉你星期一需要做什么。吉姆·海斯米斯的ASD 是哲学流程的一个很好的例子。

虽然人们通常不会称它们为流程，但相关的一组知识是最佳实践的集合。最佳实践集合的一个很好的例子是麦康奈尔在他的优秀著作Rapid Development中收集的最佳实践。这种集合是一组相对独立的好的做法，你可以以几乎任何顺序应用它们。与哲学流程不同，它们是具体的片段，但选择哪些最佳实践应用于你的项目完全取决于你。

最佳实践的好处在于，你不必理解复杂的步骤网络就能利用它们。相反，你可以选择你认为最能给你带来价值的实践。由于我一直不信任方法论，所以我喜欢这种方法。但 XP 向我明确表明，实践并非独立的片段。XP 的力量并非来自个别实践，而是来自肯特选择的实践之间的相互作用。如果你将 XP 实践视为个别实践，你就错过了 XP 的大部分意义。从中学到，实践之间的相互作用与实践本身一样重要，而具体流程或可定制流程擅长捕捉这种相互作用。

因此，所有这些方法在某种程度上都是不完美的。具体流程理论上根本不可变，实际上它没有给你任何关于改变它的指导。可定制流程在理论上运行良好，但要定制它们，你必须理解大量材料。哲学流程为你提供了良好的基础，但没有真正给出关于该做什么的具体建议。最佳实践集合告诉你该做哪些事情，但不会谈论实践之间的相互作用。

什么是 XP？

为了研究可变性和 XP，我们首先必须认识到 XP 属于哪一类。对于许多人来说，很明显 XP 是一个具体流程。它有 12 个必须遵循的实践，如果你在任何 XP 讨论组中花很多时间，你会很快发现 XP 的倡导者付出了很多努力让大家遵循所有 12 个实践。因此，许多人因过度狂热地提出他们的观点而声名远播。

但 XP 的吸引力很大程度上来自那些被 XP 的底层哲学而不是具体实践所吸引的人。XP 对适应性、以人为本、轻量级和涌现行为的关注是一个引人注目的组合。有很多人想要使用 XP，但超出了具体流程的范围。

XP 的一个我特别喜欢的非同寻常之处在于它确实为自己设定了非常明确的界限。它假设一个最多有 12 名开发人员的同地团队。这些界限非常清晰，但 XP 中的许多内容都吸引了那些不符合这些界限的项目。如果你有一个拥有 30 名开发人员的项目，或者一个有很多人远程办公的项目，会发生什么？适应性和以人为本的原则仍然有效。为什么不尽可能接近 XP？

因此，你就会有争论，那些偏好狭义 XP 的人和那些偏好广义 XP 的人之间的争论。争论之所以加剧，是因为 XP 已经获得了大量的品牌知名度。人们热衷于说他们使用 XP，因为他们知道，说这句话传达了关于他们工作背后的价值观和原则的很多信息，即使你有一个大型或分布式团队，这些价值观也很重要。

XP 没有一个指导委员会来对什么是 XP 或不是 XP 做出官方声明。它更像是一个社区，只有非正式的安排，而且这个社区在这个问题上仍然没有达成一致。Kent 表示他更喜欢 XP 成为一个具体的流程——一个“立足点”。作为 XP 社区的公认“领头羊”，他的偏好具有很大的分量。因此，主流观点是 XP 指的是具体的流程。

XP 和自适应性

所以我们把 XP 视为一个明确定义的流程，一个立足点。我们如何将这一点与自我适应的需求相协调呢？

答案的线索来自 Kent Beck 在有人问他关于为 XP 设置成熟度级别的问题时所说的话。大多数人对这个问题的反应是，对 XP 存在任何类似 CMM 的成熟度级别的概念感到恐惧。Kent，像往常一样，以一种沉思的严肃态度回答了这个问题，这经常让人感到惊讶。他说 XP 有三个成熟度级别。

• 级别 1 是你严格按照书本上的做法执行所有实践的地方。
• 级别 2 是你根据本地情况调整 XP 的地方。
• 级别 3 是你不再关心是否在做 XP 的地方。

在这里，我们看到了自我适应性——你必须调整 XP 以继续做 XP。正如我所说：如果你在第 6 次迭代中仍然像在第 1 次迭代中那样做 XP，那么你就是在不做 XP。

但请注意这里的成熟度步骤。这些级别假设在进行调整之前，人们严格按照书本上的做法执行 XP。这里的重点是，如果不做 XP，就很难理解 XP 的工作原理。构成 XP 的实践组合以一种非常难以理解的方式协同工作，除非你将它们一起执行，才能看到它们如何相互作用和协同工作。阅读和推测效果是实际参与的糟糕替代品。我当然可以证明，我对 XP 的工作原理的看法和我参与 C3 项目时看到的情况之间存在很大差异。

这就是为什么许多 XP 支持者如此强调在进行关于如何改进 XP 的推测之前，要严格按照书本上的做法执行 XP。这通常会让人觉得，出于某种原因，他们过于封闭和狂热。但很多时候，这是因为 XP 支持者记得他们自己早期的怀疑和他们想要以不同方式做事的想法。只有当他们真正做 XP 时，他们才意识到它以一种让他们感到惊讶的方式起作用。一旦你自己感到惊讶，你就会倾向于认为其他人也会感到惊讶，因此不愿意听那些没有经历过这种体验的人的话。

改变具体的 XP

这意味着要以一种不同的方式思考如何使流程变得可变，即使用一个具体的流程作为基础。不要一开始就试图弄清楚如何使用复杂但可定制的流程，而是从一个具体的流程开始，即使它显然不是最适合你的需求的。使用这个次优但具体的流程。这样做将让你了解关于流程的重要信息，否则你会错过这些信息。完成之后，就可以开始进行调整了。使用其他流程中的技巧来帮助你进行调整。

所以这就是 XP 中变异工作原理的核心。只有真正理解一个方法的工作原理，你才能真正理解如何定制它。对于一个复杂的、重量级的流程来说，这需要大量的努力。一个敏捷方法，只有几个实践，并且强烈倾向于增量开发和循环学习，使得这变得容易得多。从根本上说，通过添加部分来改变小东西比通过删除部分来改变大东西更容易。

但理解 XP 的工作原理，尤其是理解 XP 的工作原理的难点在于，如果不做 XP，就很难真正理解 XP 的工作原理。因此，在对 XP 进行调整之前，你必须非常小心，直到你做了足够多的 XP，才能对它的工作原理有所了解。

最好的解决方案是在项目开始时严格按照书本上的做法执行 XP，让它稳定运行几个迭代，然后进行调整。然而，在大多数情况下，人们无法做到这一点。相反，他们需要逐个应用实践，以便在能够解决各种问题时解决这些问题。我认为，后一种方法虽然更容易执行，但也存在更大的风险，因为你可能会错过实践之间的相互作用。因此，我认为，对于后一种方法来说，拥有一个见过 XP 成功的、能够从知识的角度指导你的人，就显得尤为重要。

因此，对于 XP 来说，你仍然会得到一组实践和经验来开始。但这仅仅是一个开始。你需要根据自己的情况调整 XP，但重要的是在理解 XP 的工作原理的基础上进行调整。在我看来，这意味着你应该尽可能地尝试严格按照书本上的做法执行 XP 一段时间，即使你认为它不像某些修改那样有效。将这个阶段视为学习阶段。经过几个迭代之后，就可以开始进行调整了。如果你的调整与你最初想到的初始调整相同，我会感到惊讶。

XP 和边界

那么 XP 的未来以及它边界之外的未来是什么呢？在 Thoughtworks，我们一直在使用 XP 作为大约 60 人项目的基石，其中一半是开发人员。这显然太大，无法成为 XP。然而，我们称之为 XP，因为 XP 一直是我们所做工作的指导理念。那里存在着我无法否认的矛盾。也许我们最好不要称之为 XP。当然，我们不得不对实践进行大量的调整才能使其发挥作用，而且由于规模的原因，我们从未处于整个团队都体验过“严格按照书本上的做法执行”的 XP 流程的情况。

尽管如此，我仍然希望 XP 能够保持在它明确定义的边界背后的立足点。我们正在做的事情可能是受 XP 影响的，但它是一个不同的流程。我们可能不会给它命名，毕竟它现在已经高度适应了特定的项目，并且会继续以这种方式进行调整，所以我们几乎不再关心它是否还是 XP。我认为其他流程将会而且应该以这种方式出现，我们将看到受 XP 影响的流程蓬勃发展。也许思考 XP 的最佳方式是将其视为一颗种子，而不是一棵树。

所以，当我们选择“购买”XP（毕竟没有购买成本）时，我们得到的是种子。我们可以从一个小型、具体、因此更容易理解的流程开始，并利用 XP 社区在这个流程方面的经验，而不是一个需要调整的流程。在几个迭代中，我们遵循了这些建议。但很快，我们就必须在此基础上进行构建，以适应我们的情况。因此，我们仍然在构建经验，但我们不能考虑使用 XP 作为“免责声明”。我认为 XP 和其他敏捷方法不适合这样做，而且我认为这不是问题。敏捷方法只有在你拥有一个真正赋权的团队时才会起作用，最终这个团队将控制自己的流程。种子是任何树木的重要组成部分，但正如任何园丁都会告诉你，仅仅将种子扔到地上并不能保证成功。