1、客户作为团队成员
谁是客户？XP团队中的客户是指定义产品的特性并排列这些特性优先级的人或团体。
最好是客户和开发人员在一个房间中工作。
2、用户故事
对于做计划而言，了解需求只需要做到能够估算它的程度就足够了，需求的特定细节很可能会随着时间而改变。新系统问世是关注需求的最好时刻。
在XP中，我们和客户反复讨论，以获取对于需求细节的理解，但是不去捕获那些细节。用户故事（user stories）就是正在进行的关于需求谈话的助记符。它是一个计划工具，客户可以使用它并根据它的优先级和估算代价来安排实现该需求的时间。
3、短交付周期
XP项目每两周交付一次可以工作的软件。
3-1、迭代计划
每次迭代通常耗时两周。一旦迭代开始，客户就同意不再修改当次迭代中用户故事的定义和优先级别。迭代期间，开发人员可以自由地将用户故事分解成任务（task），并依据最优的顺序来开发这些任务。
3-2、发布计划
XP团队通常会创建一个计划来规划随后大约6次迭代的内容。它表示了一次较大的交付，通常此次交付会被加入到产品中。发布计划是由一组客户根据开发人员给出的预算所选择的、排好优先级别的用户故事组成。
4、验收测试
验收测试使用能够让它们自动并且反复运行的某种脚本语言编写，这些测试共同来验证系统按照客户指定的行为运行。
一旦通过一项验收测试，就将该测试加入到已经通过的验收测试集合中，并决不允许该测试再次失败。
5、结对编程
所有的产品（production）代码都是由结对的程序员使用同一台电脑共同完成的。两个人强烈地（intensely）进行着交互，他们都全身心地投入到软件的编写中。
两人频繁互换角色。结对的关系每天至少要改变一次。团队的每个人都与其他成员一起工作过，并且都参与了迭代中所涉及的每项工作。
Laurie Williams 和 Nosek 的研究表明，结对非但不会降低开发团队的效率，而且会大大减少缺陷率。
6、测试驱动开发
当为了测试用例通过而编写代码时，这样的代码就被定义为可测试的代码。这样做会强烈地激发你去解除各个模块间的耦合，这样能够独立地对它们进行测试。
7、集体所有权
结对编程中的每一对都具有检出（check out）代码并修改的权力。没有程序员对任何一个特定的模块或技术单独负责。
8、持续集成
第一个检入（check in）的只要完成检入就可以了，所有其他的人负责代码的合并（merge）工作。
9、可持续的开发速度
软件项目是马拉松长跑，团队必须要有意识地保持稳定、适中的速度。
XP 的规则是不允许团队加班工作。除非是在发版前的一个星期，并且能够一蹴而就，则允许加班。
10、开放的工作空间
团队在一个开放的房间中一起工作，房间中有一些桌子，每张桌子上摆放了两到三台工作站，每台工作站前有给结对编程的人员预备的两把椅子，墙壁上挂满了状态图标、任务明细表、UML图等等。
密歇根大学的一项研究表明，在“充满积极讨论的屋子（war room）”里工作，生产率非但不会降低，反而会成倍地提高。
11、计划游戏
计划游戏（planning game）的本质是划分业务人员和开发人员的职责。业务人员（即客户）决定特性（feature）的重要性，开发人员决定实现一个特性所花费的代价。
12、简单的设计
XP 团队使他们的设计尽可能地简单、具有表现力（expressive）。
12-1、考虑能够工作的最简单的事情
XP 团队总是尽可能寻找能实现当前用户故事的最简单的设计。
12-2、你不需要它
除非有明显的证据表明引入一个基础结构更加合算时，团队才会引入这个基础结构。
12-3、一次，并且只有一次
XP 不能容忍重复的代码。
13、重构
重构是持续进行的，通过重构，我们可以持续地保持尽可能干净、简单并且具有表现力的代码。
14、隐喻
隐喻（metaphore）将整个系统联系在一起的全局视图：它是系统的未来景象，是它使得所有单独模块的位置和外观（shape）变得明显直观。
隐喻通常可以归纳为一个名字系统。这些名字提供了一个系统组成元素的词汇表，并且有助于定义它们之间的关系。
eg.一个每秒60个字符的速度将文本输出到屏幕的系统。
我们用装卸卡车拖运垃圾来比喻整个系统。缓冲区是小卡车，屏幕是垃圾场，程序是垃圾制造者。
