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 中描述的那样（请参阅参考资料）

让这种形式的计划得以发挥作用的关键因素是让客户做业务决定，让程序员小组做技术决定。如果没有这一前提，整个流程就会土崩瓦解。

程序员决定：

• 估计开发一个素材要花多长时间
• 使用各种技术选项所花费的成本
• 团队组织
• 每个素材的“风险”
• 每次反复中素材的开发顺序（先开发风险最大的那一个可以减轻风险）

客户决定：

• 范围（一个发行版的素材和每一次反复中的素材）
• 发行日期
• 每个发行版中的优先级（根据商业价值决定先开发哪些功能）

这种计划要经常进行，这样，就可以在客户或程序员学习新事物的同时频繁为他们提供调整计划的机会。

验收测试（新）
在上篇文章的“测试优先的开发方法”这一部分中我已经提到了验收测试，把它作为整个 XP 测试中由客户负责的那一半。实际上，我更喜欢把这些测试称为“客户测试”，因为它们的重点在于谁应该创建它。客户要确信每个开发素材都有客户测试来进行验证。客户可以自己写测试，召集他们组织中的其他成员（例如，QA 人员或业务分析师）写测试，或把这两种方式结合起来写测试。测试告诉他们系统是否具有所需的功能以及这些功能是否可以正确发挥作用。

理想情况下，在一次反复结束前，客户将写好这次反复中素材的客户测试。客户测试应该是自动进行的，并且要经常运行以确保开发者在实现新功能时没有破坏现有的功能。通常情况下，客户在写这些测试时需要程序员小组提供一些帮助。我们用 Ruby 为一个项目开发了一个可重用的自动化客户测试框架，在我看来 Ruby 是最有可能适合这项工作的语言（除非我能找到一种用 Smalltalk 做这项工作的方法）。这个框架让客户指定系统应该执行的“操作”。语法和英语很象。有趣的部分是客户编写的测试脚本是可执行的 Ruby 代码。Ruby 框架读每个脚本，执行每一个操作，并为每个操作输出“PASSED”或“FAILED”。该框架处理用 IBM Standard Widget Toolkit（SWT）写的 Web 应用程序和桌面应用程序。客户已经很快看到了它的价值。我所在的公司 RoleModel Software 正打算使这个框架成为开放源代码的框架。

并不是所有的客户测试都必须总是通过。客户可以决定哪些测试重要，哪些不重要 — 这就是业务决定。重要的是这些测试帮助客户测量项目已经“完成”到了什么程度。它们还允许客户就某个东西是否已经可以发行做出基于可靠信息的决定。

频繁发行（对应于小规模发行）
我有一种习惯是对于自己做的东西，在没有完全雕琢好之前不希望别人看到。这是很傻的。早点得到反馈经常可以使我免得在一些没有人真正想要的东西上浪费精力。频繁发行会把正在开发的软件放到实际用户的手中，这样他们就可以向您提供您需要的反馈。发行应尽可能频繁，同时还要使它们具有足够的商业价值。

只要感到有意义，就应该立即发行系统。这样可以尽早为客户提供价值（请记住，今天的钱要比明天的钱更值钱）。频繁发行还可以向开发者提供具体的反馈，让他们了解哪些满足了客户的需要，哪些没有满足。然后小组可以在为下一个发行版制定计划时把这些得到的教训包含进去。

为什么这被称为客户方法？因为客户小组需要推动程序员小组发行的东西。客户小组就是知道某些系统功能是否在任何时候都对用户有用的小组。另外，让客户小组负责频繁的发行可以让它们一直关注您首先开发软件的原因：开发出一个用户将实际使用的有用产品。做这项工作的最佳方法是让您的用户告诉您他们想要什么。大多数情况下，如果没有看得到、摸得着的东西他们就做不好这项工作。请为他们提供这些东西，他们将提供您需要的反馈。

不再使用的客户方法 — 现场客户
您可以已经注意到最初的 XP 方法中与客户行为有关的一条（尽管没有明显地对它归类）— 现场客户 — 在列表中已经不存在了。客户现在已经是“一个小组”的一部分。假设他们将在现场，离小组很近。

根据我的经验，我发现接近客户非常重要。理想情况下，我喜欢客户坐在我身边，距离近到小组中的人说什么他都能听到。那样的话，一出现问题我们就可以马上问他。遗憾的是，这种亲近的距离不可能一直保持。其次是让客户在旁边，这意味着程序员小组必须与客户在一起。但如果您与客户的距离不能近到立即问问题，至少是很快问问题，那么就几乎不可能有效地使用 XP。我们已经尝试通过“随时”电话联系使远程客户能提供帮助，但效果不是太好。

管理人员方法
大多数人在听到“经理”这个词时可能都会想到那些告诉别人该做什么事的人。对于一个项目来说，管理人员创建工作计划、为“小组”召集开发人员并保持每个人都有任务、按调度进行并且开销在预算内。在 XP 小组中，管理人员也是小组的一部分，但可能与您（和他们）想象的不同。

接受的职责（新）
好的管理者几乎不必告诉每个人去做什么事。相反，好的管理者会指出小组可能没发现的问题（因为他们身在庐山中），然后让小组找出解决这些问题的方法。对于许多管理者来说，这是一种截然不同的思考方式。就象 Kent Beck 在他的文章中针对修订后的方法所说的那样：

这种[方法]是管理上的重大转变，因为它暗示要放弃控制，同时仍然要负责让整个小组高效率地运转。

我曾经做过项目经理，我知道这种方法听起来有点吓人。但象对待奴隶一样赶着别人工作 — 或者想对孩子一样对待他们 — 对我来说感觉更糟，并且是一种很可能会失败的方法。强迫别人用您的方式做事情是很困难的。相反，我宁愿提出问题、让大家面对这些问题，然后让他们找出解决这些问题的方法。这样，您就可以让开发者和客户接受责任而不用责骂他们。

空中掩护（新）
在第二次世界大战中，盟军在西欧登陆日之后通过欧洲向东推进时，他们取得成功的最大因素是强有力的空中掩护支援了地面部队。轰炸机和战斗机对敌人进行连续的攻击并摧毁他们的防线，这样盟军的地面部队就可以少费点事。虽然不在项目组中的人并不是真正的敌人，但他们可以很容易地让小组偏离自己的计划、编码、发行和获得反馈的最终目标。管理人员必须处理这些中断。

还有好多管理和组织方面的东西会妨碍小组的软件开发工作，比如无法获得访问某个环境的批准或者维修崩溃的工作站。管理人员需要除去那些障碍。

最后，小组成了组织中的某一部分，组织中的其他小组需要知道这个小组正在做什么，以及为什么要做。管理人员需要负责这种沟通。

季度回顾（新）
管理人员应该参与我在这个系列的第 1 部分讨论的回顾。季度回顾不同。它的目的是让尽可能多的管理人员协同工作以确保每个人（小组和管理者）都拥有他们所需的信息。这些管理人员包括任何为小组花费了很多时间的管理者。邀请有可能延伸这条链的其他人（他们没有对小组花费那么多时间，比如经理上司或者项目的投资者）也是明智之举。召开常规的会议能使这种沟通成为生活的一个常规部分。

镜子（新）
或许 XP 小组的管理人员需要发现被丢掉的管理艺术。管理人员需要通过艺术的语言、词语或者这两者让他们确切了解自己在任一点上的重要性。如果开发者或客户遇到了问题，无法前进，管理人员可以通过指出问题、提出建议、给出劝告或者鼓励他们来提出一些打破僵局的方法。这种方法只在极少数情况下才告诉人们去做什么。

支撑得住的步调（对应于每周 40 小时）
如果没有步调调整者，整个小组很可能会耗得筋疲力尽。管理人员需要安排小组的步调。如果小组中的成员工作太辛苦了，管理人员需要让他们把节奏放慢一些，回家休息一下。疲惫的人会开发出糟糕的软件。工作的小时数并不重要；疲劳程度却很严重。

管理人员还需要确保小组拥有做需要做的事所需的时间。例如，许多人认为重构（refactoring）是浪费时间。实际上，让您的代码保持洁净会使您的速度加快；而如果代码比较粗糙，则迟早会影响您的速度。管理人员需要确保小组有完成重构和其他必需的任务的时间。

下个月
刚开始时，您会感到 XP 比较怪。这是因为它要求小组内的每个成员的想法都不同。有时候您可能想退出。但进行更改要花费时间并且要集中起来去做。那不是随便进行的。许多更改都需要有意识地进行。下个月的文章将帮助您理解如何开始转变思路，这是做 XP 工作所必须的。