1.
任何情况下，变化是绝对的，不变是相对的，我们不要抱怨变化的发生，重要的时要有应付变化的能力。但是那绝对不是听从别人来变化，而是自适应形势的变化。
2.
四个变量：成本、时间、质量、范围
3.
四个原则：沟通、简单、反馈、勇气
4.
所有的实践：
a)
计划游戏
i.
业务人员需要决定的内容：
1.
范围
2.
优先级
3.
版本的组成
4.
发布的日期
ii.
技术人员决定的内容：
1.
估算
2.
后果
3.
过程
4.
详细的日程计划
b)
小版本
包含最有价值的业务需求。
c)
隐喻
每个XP软件项目都是由一个全面的隐喻指导的。
d)
简单设计 任何时候，正确的软件设计都具有下面的特征：
i.
能够运行所有测试
ii.
没有重复的逻辑
iii.
陈述每个对程序员重要的意图。
iv.
有尽可能少的类别和方法
e)
测试
测试有助于增强程序员的信心；只对有可能出错的方法编写测试代码。
f)
重构
g)
结对编程
一个人思考实现此方法的最佳途径，另一个应更加偏重于战略性的角度进行思考。
h)
集体所有权
只有代码的正式所有者才可以更改代码
i)
持续集成
用一台计算机专门作集成工作
j)
每周工作40小时
加班时项目存在严重问题的征兆
k)
现场客户
指的是在系统投产后真正使用系统的人
l)
编码标准
标准应强调沟通，并必须被整个团队自愿地采纳。
5.
环境可能是最后被考虑到的东西，但是往往是非常重要的。
6.
一定要保证一个小组在工作的时候不被干扰，否则就无法真正集中精力工作。
7.
业务人员应该选择：
a)
发布的范围或时间
b)
提出的功能的相对优先权
c)
提出的功能的确切范围。
8.
开发组织必须确定：
a)
实现各种功能所需的时间估算
b)
各种可选的技术方案的后果估算
c)
适合他们的个性、业务环境和公司文化的开发过程。
d)
使用哪组时间来开始，即以使用什么样的进程来评审实践的效果和对变化进行试验。
9.
制定计划的目的：
a)
团结和组织开发团队
b)
决定范围和优先级
c)
估算成本和日程
d)
让大家对系统的成功信心百倍
e)
为反馈提供一个基准
10.
制定计划的原则：
a)
只制定下一个阶段所需的计划（计划需要不停的进行迭代）
b)
接受的责任（责任只能被接受，而不能被强加）
c)
负责实现的人进行估算
d)
忽略个部分之间的依赖关系
e)
为优先级作计划与为开发作计划的比较—谨记计划的目的
11.
首要的一个问题是如何处理好人与人之间的关系，如果大家都能够做到权责明确，并且和睦相处，那么就具备了一个好团队所必须的一点。
12.
业务方和开发方一定要做到相互信任，相互尊重。
13.
如果能够把一项工作做的像是大家在共同进行一个游戏的话，大多数人都会乐意去做，而且很快乐。
14.
配对编程是一种非常值得尝试的方式，可能一旦使用就会永远喜欢上这种方式。
15.
最佳设计：能运行所有测试用例的最简单的设计
16.
最简单的四种约束：
a)
系统必须能够沟通任何你希望沟通的内容
b)
系统不能够包含重复的代码
c)
系统拥有尽可能少的类
d)
系统拥有尽可能少的方法
17.
软件的设计不可能没有变化，我们要做的是如何来面对并处理这些变化。在极限编程中，对于变化我们会返工，但是那就像是修改一篇文章一样，是一件令人快乐的事情。
18.
不停的进行测试的方法似乎与制作网页的过程有些类似，在制作网页的过程中我们会不断的进行预览，查看在浏览其中实际的效果，而且所有的网页都是在持续集成的过程中完成的。
19.
测试先行并不意味着我们在什么情况下都要先编写测试，然后编写代码。在Eclipse中，如果没有一定的代码，测试程序根本就是无法通过的，又来的什么正确不正确呢。而且，在编好了基本的类之后，使用自动化的工具来生成测试程序，在一定程度上也可以提高工作的效率，何乐而不为呢？
20.
当一个人编写的程序里面Bug太多的时候，并不意味着他没有重视测试，大多时候是因为他还没有掌握测试的方法和工具。不知道怎样来测试，怎么可能做好呢？
21.
在保存项目的时候，如果使用极限编程，应该不仅保存项目的源代码，而且要保存所有的测试用例。而且在写注释的时候，不仅在程序的源代码里面要有详尽的注释，在测试用例的代码中也应该做到这一点。
