验收测试（新）
在上篇文章的“测试优先的开发方法”这一部分中我已经提到了验收测试，把它作为整个 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）是浪费时间。实际上，让您的代码保持洁净会使您的速度加快；而如果代码比较粗糙，则迟早会影响您的速度。管理人员需要确保小组有完成重构和其他必需的任务的时间。
