尽管管理团队对某些重大业务作决策，但管理开发工作并不是由一个团队负责的。每个人都属于一个团队，不同的人担任不同的角色。当然，说要比做容易。需要有许多人愿意完成不同的工作。有失败（并可能终止）的风险，但回报也可能是可观的。

    非常好。我们有了一个团队。每个人做什么呢？就象一年前那样，所有 XP 实践将四个价值转换成了作为一个软件开发团队成员每天应该做的工作，不管是不是技术方面的工作。对成员而言，不管是否从事技术工作都没有什么十分新的东西。XP 编程实践被业界公认为非常好的实践已经有好几年了，而且更关注于业务的实践被认为很有效（请参阅参考资料的 Standish Group CHAOS Report 以获取证据）。极端编程中的“极端”一词来自两方面，这一点仍然正确：

    . XP 采取经过证明的业界非常好的实践并将其发挥到极致。
    . XP 将这些实践以某种方式进行组合，使它们产生的结果大于各部分的总和。

    如果每个人都在同一个团队中，那么第二点会令人惊奇。但只要您砍掉凳子的一条腿，那就准备掉在地上吧。XP 从未保证 — 以后也不会保证 — 人们始终会做得正确，但它给予他们尝试的机会。这适用于团队中所有成员，不管是不是技术人员。团队中使用所有实践的成员一起工作会在速度和效率上得到明显的提高。这些实践可以营造使组织产生出优秀软件的环境。是否还有任何其它种类的实践呢？

    修订的实践

    XP 的 19 个实践（请参阅表 1）定义了团队各种成员应有的习惯。这个月，我们将较深入地研究联合（joint）实践，因为它将一个团队中的所有成员都聚集在一起。下个月，我们将讨论开发（development）实践，它形成了最初的 12 个 XP 实践的主体。再下个月，我们将讨论客户（customer）和管理（management）实践。这将使您更好地理解用 XP 开发软件意味着什么。

    表 1. XP 的 19 个实践 联合实践 迭代

    在我们讨论联合实践之前，让我先澄清什么是实践，以及什么不是实践。实践不是 XP。XP 不只是实践。事实上，XP 的价值也不是 XP。Ken Auer、Erik Meade 和 Gareth Reeves 共同写了一篇称为“The Rules of XP”的文章（请参阅参考资料），其中对此描述得非常好。他们简明扼要地说：

    XP 的价值使 XP 灵活。XP 的实践没有定义 XP . . . XP 是由它的规则定义的。

    他们使用 Alistair Cockburn 的游戏作类比，接着描述了“交战规则”，该规则说明了进行有效的软件开发所需的环境。然后他们讨论了“游戏规则”，它定义“交战规则”框架内每一分钟的活动和规则。他们建议：

    . “游戏规则”确保 XP 的唯一性。
    . 遵守“游戏规则”就是极端编程。
    . 遵守“游戏规则”和“交战规则”就是极端软件开发。

    XP 实践很重要，因为它们强制了一些行为，这些行为增加了团队生产出与团队成员期望值相符的优秀软件的可能性。但 XP 不只是如此。它不仅是编程，还扩展至包括整个软件开发过程。修订的 XP 实践考虑到了这一点，它们要求所涉及的每个人都有不同的行为。

    XP 实践的四个类别正逐渐变得清晰。一个团队中的每个子团队有一个集合，而且还有将三个子团队聚集起来的集合。最初 12 个实践中的大多数都在开发团队集合中，但有些可能会去掉。有些名称已改变，主要因为最初的名称要么不太合适，要么没有反映它们应有的意义。有些实践没有列在最初 12 个实践的列表中。在下一节（以及以后的文章）中，在每个名称后，我将附加说明该实践是新的、未更改的还是到最初名称的映射。请注意这些名称还会有更改，但原则或许不变。

    在描述实践之前，阐述我如何看待“‘部分’观点”，这一点很重要：团队必须使用所有实践，还是只需挑选它所喜欢的呢？作为规则，XP 假设团队一直使用所有实践，但团队可以挑选几个实践，并成功使用它们（诸如重构或结对编程）。您可以在您的团队中随意这样做。对于我的团队，我不选择这样做，因为我认为实践会相互补充，一起使用效果好，所以如果我不选一个或多个实践，那么就会放弃一些令人惊奇的东西。但应由您自己来作出决定。如果您想尝试 XP，我建议您暂且一直使用所有实践，来确定您要放弃哪些实践。我敢打赌您要放弃的那些实践所组成的列表会很小。

    好了，让我们来描述实践吧。本月我将讨论联合实践来为所有其它实践打基础。首先我们需要确保我们有一个使用所有实践的团队。这是先决条件。