极限编程的第一部分问题分析软件开发规范需要解决的问题的不同层次设定极限编程的前提。
我们将推进隐喻、四条指导原则、这些指导原则派生的原则以及根据我们新的发展规范组织的活动。
第一章风险：基本问题进度延迟(XP的发布周期很短，最多几个月)，项目取消) XP让客户选择具有最大业务意义的最低版本，最大化软件价值)，系统恶化维持)、缺陷率)基于程序员和客户的双重观点进行测试程序的编写)、业务误解(项目说明书在团队开发过程中不断改进)、业务变更)、客户用新功能替换未完成的功能)、错误特性多) XXX
第二章开发方案XP核心故事——开发方案：
两个程序员一起编程。 () )除非所有测试都能运行，否则测试驱动开发不会完成。 ) ) )程序员不仅要运行测试用例，还要改进系统的设计。 ) ) ) )集成时包括集成测试
第三章软件开发经济学对于不确定价值的新功能，等一下，可以防止徒劳无功。
第四章四个变量控制变量系统。 成本(突然增加不能解决问题，不能太少)、时间)、不能太多也不能太少)、质量)、牺牲的质量终究会用其他方法挽回)、范围)更小地解决客户业务问题的范围有助于提高质量)。 外力(客户、管理者)确定任意3个变量的值，开发团队确定第4个变量的结果值。
需求从来不明确，客户没有确切地告诉我需要什么。 我们将做很多报价和反馈实际结果的工作。 更好的估计可以减少必须放弃功能的概率。 首先实现客户最重要的需求。 这样，即使必须放弃其他功能，该功能也不比已经在系统上运行的功能重要。
第五章变化成本变化成本随着技术的提高逐渐趋于平缓。
第六章学习驾驶需要通过进行很多小的调整来控制软件开发，并以比较合理的成本进行这样的纠正。 变化总是发生的。 问题是实际发生变化时能否应对。
第七章四条准则XP的四条准则：
沟通：项目中出现的问题总是来自那些不想和别人讨论重要问题的人。 简单：今天做的简单的事情即使明天修改，今天做的事情很复杂，明天最好不要用。 反馈：通过测试提供系统反馈，帮助您快速发现系统问题。 勇气：要有重构坏代码的勇气，也要有支持降低系统复杂性的奇怪想法的勇气。 开发团队的成员之间只有互相尊重，才能使团队真正有效。
第八章基本原则快速反馈：快速反馈会带来我们学习上的巨大差异
假设的简单性：首先做好今天的工作，我相信将来根据需要可以很好地修改系统。
增量变更：变更小步骤
倡导改变：在解决最重要的问题时，保留最多的选择之一
高质量的工作：要保证做得真的很好
第九章基本问题回到软件开发的四项基本功。 编码、测试、倾听、设计。
代码可以用于交流。 表达战略意图，编写算法，指出未来可能发生扩张和收缩的地方。
测试既是资源，也是责任。 测试在程序员看来可以坚定信心，在客户看来系统可以正常运行。
找到构筑交流对象的方法，让应该交流的事情进行交流，以适当的详细程度进行交流。
产生好的设计，修正坏的设计，提供任何需要学习的人都可以学习现在的设计的环境。
第二部分解决方案第10章程序游戏简介：业务人员确定范围、优先级、版本配置、发布日期； 技术人员决定估算、结果、过程、详细的日程。
小版本：每个版本都应尽可能缩小，包括最有价值的业务需求。
隐喻：通过引入隐喻，我们得到了一个容易交流和解释的体系结构
简单的设计：基于测试添加功能是不理智的。 需要移除可以移除但不违反系统约定的部分。
测试：不需要为创建的每个方法创建测试，而是只为可能出现错误的方法创建测试。
重构：当系统向程序员请求代码副本时，也就是在请求重构。
配对编程：配对需要具有不同的角色。 一个作用是实现这种方法的最佳途径，另一个作用是战略思考。
集体所有权：如果一个人发现了改进部分代码的机会，就必须立即执行改进。
持续集成：开发人员需要在几个小时内进行代码集成和测试
每周工作40小时：保持良好的心态和精力
现场客户：让真正的系统用户坐下来，回答开发者的问题。
编码标准：对整个团队来说，必须自愿遵守这个编码标准
第十一章这如何发挥效果，任何实践都难辞其咎，需要其他实践才能保持平衡。
第十二章管理战略管理者有责任为团队服务，也要做好退出项目的准备。
第十三章设备策略如何合适，如何编码有效，设备应该如何配置。
第十四章划分业务责任和技术责任，可以使技术人员专注于技术问题，业务人员专注于业务问题。 项目必须由业务决策推动，但技术决策必须为业务决策提供成本和风险信息。
第十五章规划战略制定总体规划，然后在越来越短的时间内逐步深入完成。 收到合同后
，要立即开启计划游戏，才能够对自己按照合同交货的能力进行反复查对。 第十六章 开发策略持续集成减少了开发冲突并为开发过程创造了一个自然而然的结尾。复杂代码不会存在很长时间，由于每个人都会查看所以当被发现时就会有人去尽量简化它。结对编程是知会找到有空的人。同时会产生更多高质量的代码，使得人们不会犯重压之下的错误实践。
第十七章 设计策略从一个非常简单的起点出发，我们将继续完善系统的设计，并将去掉任何不能证明是有用的灵活性。
系统设计的目的首先是沟通程序员的意图，其次是为系统的逻辑提供生存的地方。
在第一次迭代的过程结束拥有一个体系结构可能它不是我们所期望的但是我们会了解一些东西。
第十八章 测试策略不应该测试那些不会在实践中出错的代码，应该测试可能出错的部分。
专职的测试员将客户比较模糊的概念转换为真实、自动化和独立的测试。
第三部分 第十九章 采用XP挑出最棘手的问题
以XP方式解决它
当它不再是最棘手的问题时，重复上述步骤。
第二十章 改进XP对于已有软件团队的改变要一点点来虽然会很慢，但是走一些XP形式化的内容会使得大家对于流程的接受更快。
第二十一章 理想的XP项目的生命期经历一个短暂的初期开发阶段，随后是多年同时进行的生产支持和优化，最后当项目失去意义时体面地退休。
第二十二章 人员的角色 程序员要有信心面对责任。客户要会给程序员解压同时学习如何编写故事和功能测试。测试员需要帮助客户选择并编写功能测试。跟踪者需要整体观察，记录团队历史，需要培养是在不打扰团队地流程而收集信息。教练在整体上负责这个过程。团队逐渐成熟的过程中也就教练这个角色也慢慢不再重要。顾问需要需要可以解决技术知识，并保持良好心态。大老板需要更多的勇气去接受XP团队诚实的沟通。 第二十三章 20-80原则将最有价值的20%功能投入生产，然后提供80%的收益，通过20-80原则延期优化。
第二十五章 什么时候不应使用XP当团队太大、客户多疑以及技术不能很好地支持更改。
第二十六章 工作中的XP 第二十七章 结论团队可以随时做好充分的准备，朝业务或系统要求的方向行进。放弃为应变做的直接准备后，他们反而变得能够适应任何变化。