联合实践：建立一个团队

    这组实践适用于每个人。团队中的每个人（程序员、客户和管理）需要一直进行这些实践。这些实践使子团队聚集在一起以建立我们需要的一个团队。

    公共词汇表（映射到比喻）

    最初的比喻（metaphor）实践失败了。但其思想并非很糟糕：这是一幅控制图，其中的系统是用每个人都能理解的术语描述的，而且赋予该系统一个统一的主题，该主题使团队知道新事物适合哪方面。问题是，该实践确实偏离了主要目的：对系统的共同理解。团队中的每个人都需要理解它。有时不能获得一个非常好的比喻，或要想出这样的比喻非常费时。请不要仅仅因为不能对您正设法构建的系统找到一个恰当的比喻描述而耽搁时间了。应将重点集中于每个人都能使用的共享词汇表（Ward Cunningham 称之为“名称系统”）。如果比喻有帮助的话，那么就使用一个。如果您不能找到一个很好的比喻，那就用共享词汇表（它列出了类、方法等的名称）吧。

    在 Extreme Programming Explored（请参阅参考资料）中，Bill Wake 也谈到了比喻。他说：

    当项目已经开始并有所成果时，在研究阶段确定比喻。随着进展来修改它。让比喻来指导您的解决方案。将其名称用于较高级的类。理解那些类是如何交互的。

    他建议当您不能想出一个更好的名称时，就使用“自然的比喻”（即，让对象成为其自身）。真是好建议。

    开放式工作区（新）

    大部分时候非正式的交流比正式交流更有效。办公室小房间使非正式交流比较困难。非常好的解决方案是采用开放式工作区，其中人们可以在旁边听到讨论，当交流的内容有意义时，可以一起讨论，提出自己的想法，而且还可以对任何重要的事情进行即时讨论。这种群体交互可以产生令人惊奇的意外结果。我已经在工作中看到了成效。“推倒墙壁”。您的团队将因此而合作得更好。如果您的组织不同意搬动家具，那么您就有更大的问题了。
   
    对开放式工作区实践的典型反应是怀疑一群人在同一个区域讨论会相互分散注意力。从经验来说，这确实会发生。当团队中的成员相互足够尊重，以致可以在开放式工作区一起工作，而不是滥竽充数时，开放式工作区就会发挥作用。如果有人想偷懒，就让他到可以偷懒的区域，那当然是另外一个地方。这并不意味着工作区不能有乐趣。它应该有乐趣，但它也应该是可以完成工作的地方。如果团队成员相互关心并关注他们正从事的工作，那么他们就能使开放式工作区起作用。您应该设想它不会有问题，并且只在真有问题时才处理它。

    我听说有人提出开放式工作区实践意味着 XP 不适用于大型的团队。他们认为一大群人在一个大空间（或一些其它开放式工作区）的地方会很混乱。可能他们是对的。坦率地说，我认为这个侧重点是错误的。他们似乎假设了两点：您需要大型的团队，以及没有支持团队的协作式环境。

    可能您需要大型团队。但是您真的这么认为，还是刚有这个想法？可能在一个有助于顺利完成工作的环境中共事的一小组优秀的开发人员 — 拥有他们需要的支持 — 可以比一个大型团队做得更多、更好和更快。也可能不是这样，但它值得考虑。

    假设您真的需要一个大型团队。为此您如何为它建立一个合作的环境，而完全没有产生混乱呢？如果您有多个相邻的开放式工作区，彼此处于半隔离状态（敞开的大门、半堵墙、在大空间之间有通道等），那么怎么样呢？有些人指出不能创造支持大型团队的合作环境，我认为他们中的大多数通常不太喜欢这个想法 — 不管是对于小型团队还是大型的。假设开放式工作区不适合大型团队是个错误。

    迭代（新）

    使用 XP 的人经常谈论项目的“节奏”。这个节奏有不同的级别，但迭代的节奏级别简直就象心脏跳动那样快。每隔一到三个星期，团队就交付具有客户要求的新功能的工作系统。那是基本思想。但人们不习惯以这种方式创建软件。大多数方法注重在编写代码之前先进行大量的工作。XP 要求您编写代码、让人们使用它，并让他们的反馈把握项目的方向（我们将在以后的文章中更详细地讨论这个概念）。

    每次迭代从制定一些规划开始。我（以及许多其他人）称之为迭代规划，我们在迭代规划会议上完成它。在这个会议上制定的规划看上去非常象发行规划（我们也将在以后的文章中更详细讨论这个概念），只不过是更详细的级别。我们只关心下一次迭代。我们询问客户，“如果项目在下一次迭代之后将结束，您想要项目具有什么功能？”然后我们估计构建那些功能所需的工作。我们在这次迭代中加入可以加入的东西，而推迟完成其它东西。客户确定优先级；程序员确定成本。那意味着有些事情必须推迟进行，让位给当前的迭代。您不能对此采取折衷办法。您不可能获得更多的时间。

    时间定量（timeboxing）一词在这里非常重要。时间定量是对某些工作设置完成期限的做法，在未到期限之前，一直从事这些工作，期限到时，就停止，然后评估您完成了多少。它是一种技术，防止团队在某些任务上花的时间太长，而影响其它需要完成的工作。迭代实践不仅仅是关于时间定量的。实际上迭代实践是关于要求人们作出艰难决定的，而这些人最有资格作出相应的决定。客户决定下一步要构建哪些最重要的功能。程序员对关于如何构建功能以及需要多少工作作出技术决定。管理层就有关项目的战略方向以及该项目如何才能适合于组织的其它部分而作出决定。这涉及项目团队中的每个人，但他们坚持遵循他们知道的。他们当然经过深思熟虑，但还要相信别人也同样如此。

    对于将这个实践称作什么有些争论。我们应该称它短迭代以强调迭代的节奏快，还是该称作迭代规划以强调集合每个人进行规划的合作方面？我喜欢短迭代，因为它强调使用户获取真正的、有效的软件以返回具体反馈的需要。

    回顾（新）

    这是我职业生涯中很罕见的项目，团队中每人都花少量时间进行回顾，并公开指出什么地方确实没有做好。我必须自己来完成。当我这样做（如果我有时间的话）时，我通常发现如果团队花一点时间来解决项目中的问题，那么通常这些问题在它们成为“问题”之前就被解决了。那就是回顾（Norm Kerth 创造的术语）所要做的。

    不反思您正做的工作就继续做下去会使您陷入重复失败的境地。团队中每人都最好反思他自己的工作以及他吸取的经验和教训，然后与团队中其他成员分享反思的结果。正如我和 Chris Collins 在我们的 XP2001 论文 Adaptation: XP Style（请参阅参考资料）中所概述的那样，我正讨论的个人行为是自省。回顾时，您公开您的自省。

    思考您在项目中吸取的经验和教训。思考哪些做得好，哪些搞砸了。思考团队是如何运行的。思考团队整体产生了什么。可否将工作完成得更好？为什么？更重要的是，怎么做？什么是您做得好的，是您确信要继续保持的？该怎么做？这种共同评审应该以有组织的方式至少在每次发布后进行一次，最好在每次迭代之后进行。不会花很长时间。在迭代规划会议时留出头一到两小时用于回顾上一次迭代。可能的话留出一天（或几天）用于发布后的回顾。不要有任何松懈。在这里您正设法使团队更优秀，设法提高您可以对组织增加的价值，设法通过在工作中添加一点乐趣使自己的生活更美好。这是至关重要的。

    我和大部分同事都觉得团队中的每两个成员结成对在每天结束时进行“迷你回顾”很有帮助。反思只需几分钟。如果我们学到了值得共享的东西，那么我们可以在第二天的团队会议中提出。通过这种方法我们学到了很多。

    回顾当然要使一些薄弱环节得到有效解决。弥补了团队的不足后，团队就变成了一个更完整的团队。每个人都要参与回顾，包括技术和非技术成员。如果这需要太多的人，以致在一个场所容纳不下（而且是可能的）时，则子团队（例如管理）可以进行他们自己的回顾，然后派一名代表参加一个较小型的会议。关键是吸取经验和教训，这样我们就减少了重复犯相同错误的机会。这就需要一个团队和每个人都全身心地投入其中。

    组织性变革

    最后，XP 是关于组织性变革的 — 它只是从软件开始。使每个人参与同一个团队，但分配不同的工作，这是我所能想像到的发生有效变革的非常好的途径。这个月我们讨论了 XP 的联合实践，它有助于创建为产生那种真正的、持久的组织性变革所需的一个团队。