【IT168 技术文章】
Roy Miller 通过探讨客户方法（customer practice）与管理人员方法（management practice）完成了对 XP 方法的回顾。客户方法解决了确定在每个发行版中应该包含哪些功能的问题。管理人员方法帮助管理人员为整个小组提供业务方向，并使他们始终把注意力集中在手头的问题上。加上前面几篇文章中介绍过的程序员方法（programmer practice）与联合方法（joint practice），现在您已经全面了解了 XP 方法。
在过去的几个月中，我们已经讨论了联合方法和程序员方法。联合方法把我们“一个组”的所有成员都组织在一起；每个人都要始终进行这些方法。程序员方法详细描述程序员需要遵循的方法；虽然其他人可能也关心那些方法，但程序员却每天都需要与它们打交道。
这个月我们将探讨客户方法和管理人员方法。与程序员方法和联合方法一样，这些方法中有一些并不在最初的 12 种 XP 方法之列。在下面的各部分，在每个名称后，我都会用括号注明该方法是新的、未改动的还是对应于某个原来的名称。请注意，这些名称是不断变化的，但原则或许不变。
客户方法
客户小组并不关心编程本身，但他们确实关心输入和输出。客户确定在每个发行版中应该包含哪些功能，那些功能中的每一个有什么意义，程序员能不能说他们已经“完成”了某个功能的编码工作。
素材描述（新）
我曾经参与的典型的软件项目开发都在大家称之为“需求文档”的相当正式的文档中指定需求。由于在项目开始时极少能知道所有的需求（并且在小组了解项目的过程中，这些需求经常发生形形色色的改变）这个主要的原因，XP 有所不同。
静态文档给人的感觉象是合同，不能很好地适应 XP 的情况。XP 小组是边做边学。这并不表示您在开始编写代码前不应该思考。这只是表示您在考虑将来时应该现实一些，根本不需要考虑太远。那么，我们应该放弃计划吗？不，我们仍需要计划，但计划的方式有所不同。发行计划方法阐明了这一点，但对于 XP，存在一个涉及到新的沟通方式的先决条件，这个新的沟通方式就是：素材描述。
请回想一下您曾经参与过的一些需求收集活动。您可能已经举行过会谈、召开过冗长的会议，等等。您可能问了些要澄清的问题并且更详细地了解了问题。最后，您创建了一个文档并把它发给每一位相关的人员（有些人是不相干的，但出于政治原因也不得不拿这个文档）。他们应该审阅这个文档，然后签收，表示您已经掌握了所有需求。但那样行得通吗？我经历过的这种办法行得通的唯一一次是假设系统的价值不高的情况。大多数不得不签收需求的人在这样做的时候都感到不安。他们经常这样说，“眼下我要签收，因为这样就可以继续往前进行，但我并不确信您已经捕获了所有需求。”当我一想到可能会在最后时刻发现漏掉了重要的需求时就感到很不安。这显然不是取得成功的方法。
XP 方法是截然不同的。它建议小组成员坐在一个房间里讨论所提议的系统需要做什么，以及需要如何做。程序员或客户把这些内容写在记事卡片上。每张记事卡片都记录着类似如下所示的内容：
As a <some user role>, I need the system to <functional requirement> so that I can <business reason for the requirement>.
这一堆卡片就成了系统需求集合，因为他们马上就会知道这些需求。卡片上并不记录详尽的细节。相反，每个卡片只是许诺将来会进行对话以充实细节内容。同时，这些卡片只需要有足够的内容，让程序员知道构建这个系统需要做多少工作，并为客户提供编写验收测试所需的充足的详细信息（请参阅验收测试）即可。
这种需求收集方式要求提供需求的业务人员掌握一种不同的技能。根据我的经验，人们在需求会议上都倾向于抛出一些陈旧的内容应付一下，就算是已经说过了。那样，如果有什么内容漏了的话也不算他们的错。对于整个小组来说，这样是不好的，这是项目失败的一个很重要的原因。我们真正需要的是擅长描述素材的需求提供者。他们以适当的详细程度描述素材，当结对开发人员实际尝试为这些素材编写代码时，他们负责充实这些素材。
有些人批评这种 XP 方法太不正式了。我猜他们的意思是大多数项目都有的需求文档包含更正式的语言，每个需求都有一个索引号，需求收集过程更集中在有各个股东参与的安排好的会议上。根据我的经验，那些都不可以收集到更好的 — 或者更完整的 — 需求。实际上，我的经验告诉我，当您把这些需求记录到纸面上时它们已经成了一堆过时的垃圾。
我曾经参加过的一些使用这种正式的需求文档和需求收集方法的项目也取得了成功，但在内心深处，我感觉那些成功和这些正式的需求文档及需求收集过程无关。我所在的小组在进行编码时仍不得不深入研究每个需求。我们仍不得不请求需求提供者来描述那些素材，而 XP 方法却说，这些素材是他们在刚开始时就应该告诉我们的。为什么不缩短这个流程，从素材开始呢？这就是这种方法的意义所在。素材描述是一种技巧，有些人在这方面要比其他人出色，但为 XP 项目提供需求的每个人都必须做这项工作。幸运的是，每个做这项工作的人都可以通过实践来提高。
发行计划（对应于计划游戏）
我从没有太在意过计划游戏中“游戏”这一部分。这听起来好象不够专业，倒不是说在工作中寻点开心有什么错。发行计划是要理解程序员和客户所描述的素材。发行计划只在每次发行时进行一次。
有些人喜欢批评 XP，说它是一种美其名曰的“玩票”编程，只是一群牛仔在没有任何规则的情况下拼凑出一个系统。错。XP 是为数不多的几种承认您在开始时不可能事事通晓的方法之一。无论是客户还是开发人员，都是随着项目的进展过程才逐步了解事物的。只有鼓励和信奉这种适应性的方法才是有效的方法。“现状”方法学忽视了改变。XP 认真倾听客户的意见。XP 倾听客户意见的方法是通过发行计划。
这种方法背后的主要思想是迅速制定一个粗略的计划，然后随着事物逐渐变得更加明朗来完善这个计划。发行计划的产物包括：
. 一堆索引卡，每个索引卡都包含一个客户素材，这些素材将驱动项目的反复。
. 对下一两个发行版的粗略计划，如 Kent Beck 与 Martin Fowler 合写的 Planning Extreme Programming 中描述的那样（请参阅参考资料）
让这种形式的计划得以发挥作用的关键因素是让客户做业务决定，让程序员小组做技术决定。如果没有这一前提，整个流程就会土崩瓦解。
程序员决定：
. 估计开发一个素材要花多长时间
. 使用各种技术选项所花费的成本
. 团队组织
. 每个素材的“风险”
. 每次反复中素材的开发顺序（先开发风险最大的那一个可以减轻风险）
客户决定：
. 范围（一个发行版的素材和每一次反复中的素材）
. 发行日期
. 每个发行版中的优先级（根据商业价值决定先开发哪些功能）
这种计划要经常进行，这样，就可以在客户或程序员学习新事物的同时频繁为他们提供调整计划的机会。
