第Ⅰ部分 另一个美好的混乱 1
第1章 疯狂的XP 1
目录 1
1.1 理论上的极限编程 2
1.1.1 XP的中心前提 2
1.1.2 价值 3
1.1.3 实践 4
1.1.4 活动 11
1.1.5 角色 13
1.1.6 XP的生命周期 14
1.2 XP面向什么问题 15
1.2.1 典型软件项目中反映出的什么问题可以作为XP的目标 15
1.3 实践中的极限编程：XP实际经历的评价 16
1.2.2 现有方法学中还有哪些问题可以作为XP的目标 16
1.4 先拆下，后重建 19
1.4.1 价值 19
1.4.2 活动 19
1.4.3 其他要素 20
1.5 小结 20
第2章 XP诞生于何处 22
2.1 C3概述 24
2.2 XP项目的生命周期（如C3的活动所展示） 24
2.2.1 大肆宣传和吹嘘 25
2.2.2 做可能实现的最简单的事 27
2.2.3 产生一个快速成功的错觉 27
2.2.4 无休止的重构 29
2.2.5 放弃发货！ 30
2.2.6 取消 31
2.2.7 胜利和成功的声明 32
2.2.8 新闻组中的困惑 34
2.2.9 声明它并不那么重要 37
2.3 C3的问题 39
2.3.1 现场客户的工作过于艰难 40
2.3.2 厨师太多 40
2.3.3 逐渐增加得不够 41
2.3.4 开发人员偏离了正确路线 41
2.4 小结 42
3.1 一个自反安全网络（蛇圈） 43
第3章 反XP案例 43
3.1.1 从合作衍变为象征意义（symbolism） 44
3.1.2 生命周期还是蛇圈 47
3.1.3 把蛇拆散开 50
3.1.4 将蛇捆绑在一起：部分的XP 59
3.2 因此制宜XP颠倒的原因 60
3.2.1 逻辑性与情绪化 61
3.2.2 把您的鸭子固定成一排 63
3.3 小结 64
第Ⅱ部分 XP的社会效应 65
第4章 Extremo文化 65
4.1 “XP不是无节制的删减！” 66
4.1.1 为什么XP实践者们觉得XP不是真的删减 66
4.1.3 为什么在开始编码前详细记录设计 67
4.1.2 把文档丢给狮子 67
4.2 XP进入主流 68
4.2.1 XP实践者不做设计 69
4.2.2 XP实践者不编写文档 70
4.2.3 主流世界中的XP 70
4.3 XP和．com的繁荣 71
4.4 XP作为人的过程 73
4.4.1 敏捷过程中的“嬉皮士” 73
4.4.2 IfXPIsnt Working YoureNotDoingXP 74
4.4.3 把人的过程极端化 75
4.4.4 XP和点心 76
4.4.5 XP宣言：再多些奶酪，伙计？ 77
4.5 XP术语 78
4.6 像Constantinople和TerminationCanbeSuccess这样的长词 79
4.7 向发信人攻击 81
4.8 恐惧 84
4.8.1 恐惧和Extremo文化 85
4.8.2 恐惧和Extremos 85
4.8.3 恐惧是C3失败的原因吗 88
4.8.4 如果您没在做XP，那么您一定是害怕了 89
4.9 小结 90
第5章 现场客户 91
5.1 那是客户的问题 92
5.2 现场客户：旧约 94
5.2.1 “旧约”现场客户的问题 95
5.2.2 现场客户的问题促使C3项目失败吗 96
5.2.3 警告：当一名现场客户可能对健康有害 97
5.3.1 我们能对XP客户团队有何期望 99
5.3 现场客户：新约 99
5.3.2 厨师太多 100
5.3.3 接受度测试 101
5.3.4 没有安全保障网络 102
5.4 小结 103
第6章 结对编程 104
6.1 结对编程基础 105
6.2 有项研究能证实我的观点 107
6.3 为沉默的声音祈求 111
6.4 这是一种爱的工作，却要用强迫的手段来实行 112
6.5 生产率：程序员数量／2＝＝程序员数量 114
6.6.1 不同类型的程序员的结对问题 121
6.6 结对编程说明 121
6.6.2 其他问题 123
6.6.3 小心，桌子底下有蛇！ 124
6.7 小结 125
第7章 口头文档 126
7.1 “但是我以为您的意思是……” 127
7.1.1 需求文档 127
7.1.2 设计文档 129
7.2 只是无知的白痴 132
7.2.1 在其位，谋其政 133
7.2.2 仅稍稍超前他的时代 133
7.2.3 专题小组的成员们脱离了现实 135
7.2.4 别打扰我，我正忙着——去看录像带吧 135
7.2.5 项目过程中被雇佣的新程序员会怎样呢 136
7.2.6 单元测试是文档（是的，很对） 137
7.3 小结 140
第Ⅲ部分 无需永久性的规范和预设计 142
第8章 先测试后设计 142
8.1 当只有锤子时 143
8.2 XP设计的口头禅：没有BDUF 146
8.3 单元测试的问题 147
8.3.1 面向异步消息传递和多线程系统的测试 147
8.3.2 其他问题 149
8.3.3 单元测试很简单——客户需要编写那些令人讨厌的接受度测试 150
8.3.4 没有安全网的编程 156
8.4 小结 158
第9章 编程后的持续重构 159
9.1 重构的天堂 161
9.2 XP设计的口头禅：残忍地重构 163
9.2.1 当重构有用时 165
9.2.2 当重构变得简短时 166
9.3 预先设计能否完全避免后来的重大重构 169
9.3.1 代码真的就是设计吗 169
9.3.2 预先设计真的是一件坏事吗 170
9.3.3 进行多少预先设计才足够 172
9.4 在固定的用户库下进行重构 174
9.4.1 不间断的全面维护 175
9.4.2 惹恼用户：重构实际的用户界面 176
9.4.3 的确惹恼了用户：破坏了他们的真实数据 177
9.5 小结 180
第10章 用户故事和接受度测试 181
10.1 爸爸，给我讲个故事 182
10.2 用户故事与用例 185
10.2.1 用例 186
10.2.2 什么是用例驱动的开发 186
10.2.3 用例要比故事更严格 188
10.3 用户故事与需求 189
10.3.1 需求 189
10.3.2 在非XP项目中，不确定的需求是怎么处理的 191
10.3.3 体系结构变化的需求 193
10.4 作为接受度测试的“文档化”需求 193
10.5 小结 196
第11章 软件开发无止境 197
第Ⅳ部分 永久编码机 197
11.1 进度表本身并不存在 198
11.1.1 拒绝已完成的概念 198
11.1.2 拥抱蔓延的项目需求范围渐变 201
11.1.3 如果不知道项目完成期限 204
11.2 范围可变的合同 207
11.3 小结 213
第12章 紧急结构和设计 214
12.1 XP设计的咒语：YAGNI 219
12.2 构建紧急设计的基础构造 221
12.1 代码有设计价值而没有商业价值 223
12.3 紧急结构与早期原型 232
12.4 小结 234
第13章 拥抱变化 235
13.1 变更成本曲线（修改错误成本的曲线） 237
13.2 早期发布，经常发布 239
13.3 发布计划 241
13.4 迭代计划 242
13.5 永久编码机（拥抱变化） 243
13.5.1 故事变更 244
13.5.2 敏捷意味着快速吗 244
13.5.3 设计变更 245
13.6 变化是什么 247
13.7 使用预先设计来增强敏捷性 248
13.7.1 管理变化 248
13.7.2 设计抽象的平衡 249
13.8 小结 251
第Ⅴ部分 全局图 252
第14章 可伸缩性 252
14.1 问题描述：在50人的项目中使用XP方法 253
14.1.1 避开实践 254
14.1.2 ATLAS规模大小项目中的紧急设计 257
14.1.3 结论 258
14.2 体系结构的可伸缩性 259
14.2.1 可伸缩性驱动体系结构 260
14.2.2 Extreme Programming Installed中的例子：病人记录数据库 260
14.3 当XP开始失效时 264
14.3.2 集体所有权 265
14.3.3 XP教练 265
14.3.1 手写故事卡和口头文档 265
14.3.4 现场客户 266
14.3.5 公共编码房间 266
14.3.6 紧急结构 267
14.4 小结 269
第15章 重构XP 270
15.1 如何既敏捷又不脆弱 271
15.1.1 良好的敏捷过程应该减少风险 272
15.1.2 良好的敏捷过程应该支持应急 272
15.1.3 良好的敏捷过程应该避免脆弱性 273
15.2 拔掉极限编程的毒牙：除去XP中的“极限” 275
15.2.1 重构XP实践／Xtudes／价值／原则 275
15.2.2 附加实践 286
15.2.3 交互设计师 287
15.3 案例研究：服务器工具项目 289
15.3.1 概述 289
15.3.2 XP能满足需要吗 290
15.3.3 框架 292
15.3.4 不止一个雇主 293
15.4 小结 294
第16章 结论：消除事实曲解的地方 295
16.1 运用中的无形技巧 296
16.1.1 太多琐碎的讨论 296
16.1.2 微妙玄通，深不可识 297
16.1.3 差建议就是差建议 298
16.2 在结束之时 302
16.3 结束语 304