10. 现场客户 On-Site Customer

在XP中，每个对项目做贡献的人都应该是项目开发小组中的一员。而且，这个小组中必须至少有一个人对用户需求非常清晰，能够提出需求、决定各个需求的商业价值（优先级）、根据需求等的变化调整项目计划等。这个人扮演的是“客户”这个角色，当然最好就是实际的最终用户，因为整个项目就是围绕最终用户的需求而展开的。

11. 计划游戏 Planning Game

在项目规划阶段，需要获取用户的需求。XP的需求获取技术与传统的软件工程方法有显著的不同。XP通过“用户故事卡“(User Story Card）来获取用户的需求。用户故事卡用自然语言描述用户的需求，不拘泥于形式，也不去识别故事卡之间的依赖关系。开发人员预测每个故事精确实现需要的时间，而用户则为这些故事卡排列优先级。然后开发人员和用户一起玩“计划游戏”，也就是和用户一起出那些他们认为最重要而能够在本次的一个迭代内时间里实现的故事卡。这个迭代周期结束后，用户验证和接受这些故事卡的实现。在下一个迭代周期开始以前，用户可以修改剩下的故事卡，重新给它们排列优先级；开发人员修正对故事卡实现时间的预测，然后再一起“计划游戏” ，开始下一轮的迭代周期。

12. 小规模发布 Small Release

每个周期（Iteration）开发的需求都是用户最需要的东西。在XP中，对于每个周期完成时发布的系统，用户都应该可以很容易地进行评估，或者已经能够投入实际使用。这样，软件开发对于客户来说，不再是看不见摸不着的东西，而是实实在在的。XP强调每隔3~4周就应该发布系统的迭代版本给用户。每次迭代的结束，用户都要检杳这个过渡版本，找出缺点，调整下一次迭代的需求。

13. 客户测试 Customer Test

验收测试驱动开发 Acceptance Test Driven Development

• ATDD与TDD相似，因为它基于在编码之前生成测试的相同概念。然而，现在重点从代码扩展到业务需求。ATDD的最终目标是编写更好的故事，在编码开始之前提出接受标准，并交付通过标准的功能。ATDD发生在业务级别，与TDD很好地集成在一起，TDD位于开发人员级别。

  步骤：（4D’s：Discuss、Distill、Develop、Demo）

  （1）讨论 Discuss

• 开发团队、产品所有者、运营人员、分析师和业务代表讨论用户故事及其期望的验收标准。

  （2）提取 Distill

• 开发团队收集验收标准，并将其转换为可存储在测试工具/自动化框架中的验收测试。

  （3）开发 Develop

• 团队开发通过验收测试的代码。此阶段与TDD集成，形成一个迭代周期，直到测试通过。

  （4）演示 Demo

• 一旦通过了测试，团队就会向干系人演示已完成(DoD)的特性，以及验收测试的结果，并寻求反馈。

行为驱动开发 Behavior driven development (BDD)

TDD概念的另一种变体是BDD。BDD更以客户为导向，因为它关注的是系统的行为方面，而不是技术细节。TDD中的测试是用编程语言编写的，而BDD中的测试是用更像英语的语言编写的，以描述所需的系统行为。例如，BDD工具之一Cucumber使用了一种名为Gherkin的语言，该语言使用“给定时间”的格式来描述验收测试。