Extreme Programming Refactored::The Case against XP
副标题：无
作 者：(英)Matt Stephens，(美)Doug Rosenberg著;汪丰，赵浩等译
分类号：
ISBN：9787302095293
微信扫一扫,移动浏览光盘
简介
在开始之前，我们想请读者注意本书一些非常独特的元素。这不是一本普通的，一般性的计算机科学类的书籍! 我们感觉这样一个主题适合采用讽刺的手法，因此我们下决心赋予它这样的风格。除讽刺之外，还有许多冷静的幽默。我们有时确实变得严肃，并对了极限编程(xp)固有缺陷和危险进行认真的系统分析。
说到这一点，这本书并非完全“抨击”xp的一部著作。正如后面指出的，不是所有xp都是糟糕的。我们打算提供一个中肯的批评，并指出xp中可以被抢救或重构的部分，以更加健壮的方式实现同样敏捷的目标。
xp受到了名不副实的炒作，并且新的xp书籍继续以难以置信的速度出版。围绕xp恶性膨胀的呼声从各方面影响了产业界(有些是正面的，如同我们探求的，但大多数是负面的)。有鉴于此，我们感觉一本逆着xp浪潮，抵制xp的书是重要的。
这里有一个小例子，说明xp如何影响业界。matt(本书勇敢无畏的共同作者)收到来自一位顾问的电子邮件，这位顾问最近失去了一份重要合同，因为他拒绝在没有首先进行一些详细的需求分析和预先设计之前启动项目。客户通过阅读知道xp编程，他告诉那位顾问：“即然xp认为以那种方式启动项目没有问题，那么我们将找到跳过需求和预先设计而直接启动项目的人!”
虽然一些业务人员听说xp后，立刻陷入疯狂(像上面的顾问故事提示的那样)，但仍有一些人立场坚定，拒绝变化。实际上，想要将xp引入其组织的团队面对的一个主要问题是，xp要求在整个组织中有显著的思想改变，从团队的组织方式到公司与客户做业务的方式。本书分析了xp的缺点，并提出一种可选择的实现敏捷性的方法，与xp相比，它对现有组织要求少得多的变化，同时仍然保留了xp的敏捷目标。您能使用这一“可选择的方法”作为蓝本来设定自己的敏捷方法学（本书临近结尾处提供了一些指针，指向我们感觉比xp更为严谨的其它敏捷过程）。
然而，本书最重要的目的是打碎一些紧随xp浪潮开始出现的神话，譬如无需记录工作的神话，一位现场客户和一些自动化测试足以替代书面需求规范的神话，以及个人的需要和舒适是项目次要元素的神话(即，“和我们结对编程或另谋高就”)等。并且我们打算以娱乐和幽默的方式来实现我们的目的，因为……很好，因为相关的主题要求这样。
读者对象：
xp经常由程序员引入组织。这毫不奇怪，因为xp是“对程序员非常友好的”方法。它提升了程序员的作用(本质上不是一件坏事)，并把他们置于与客户齐舞的水平。因此，如果您是经理或客户，正被兜售在下一个项目中使用xp的想法，本书提供了一个颇有价值的反面观点。
如果您是将xp引入组织的程序员，本书应该对您有所帮助，因为它概述了xp的许多危险，它们可能是潜在的项目杀手，而这些危险在其他有关xp的书籍中倾向于被一带而过。
如果您正在考虑剪裁xp以提取它的所有长处，但又想避免“多末诺骨牌”效应，也就是说，避免过程的一个小的变化引起整个过程崩溃，这本书提供了一些可贵的指导。
目录
第ⅰ部分 另一个美好的混乱
第1章 疯狂的xp 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.2.2 现有方法学中还有哪些问题可以作为xp的目标 16
1.3 实践中的极限编程: 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章 反xp案例 43
3.1 一个自反安全网络(蛇圈) 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的社会效应
第4章 extremo文化 65
4.1 "xp不是无节制的删减！” 66
4.1.1 为什么xp实践者们觉得xp不是真的删减 66
4.1.2 把文档丢给狮子 67
4.1.3 为什么在开始编码前详细记录设计 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 ifxpisntworkingyourenotdoingxp 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 现场客户：新约 99
5.3.1 我们能对xp客户团队有何期望 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 结对编程说明 121
6.6.1 不同类型的程序员的结对问题 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
第ⅲ部分 无需永久性的规范和预设计
第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
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
第ⅴ部分 全 局 图
第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.1 手写故事卡和口头文档 265
14.3.2 集体所有权 265
14.3.3 xp教练 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
第1章 疯狂的xp 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.2.2 现有方法学中还有哪些问题可以作为xp的目标 16
1.3 实践中的极限编程: 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章 反xp案例 43
3.1 一个自反安全网络(蛇圈) 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的社会效应
第4章 extremo文化 65
4.1 "xp不是无节制的删减！” 66
4.1.1 为什么xp实践者们觉得xp不是真的删减 66
4.1.2 把文档丢给狮子 67
4.1.3 为什么在开始编码前详细记录设计 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 ifxpisntworkingyourenotdoingxp 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 现场客户：新约 99
5.3.1 我们能对xp客户团队有何期望 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 结对编程说明 121
6.6.1 不同类型的程序员的结对问题 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
第ⅲ部分 无需永久性的规范和预设计
第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
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
第ⅴ部分 全 局 图
第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.1 手写故事卡和口头文档 265
14.3.2 集体所有权 265
14.3.3 xp教练 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
Extreme Programming Refactored::The Case against XP
- 名称
- 类型
- 大小
光盘服务联系方式: 020-38250260 客服QQ：4006604884
云图客服：
用户发送的提问，这种方式就需要有位在线客服来回答用户的问题，这种 就属于对话式的,问题是这种提问是否需要用户登录才能提问
Video Player
×
Audio Player
×
pdf Player
×
