第一部分：基本概念 2
第1章 程序员不死 2
1.1 开发软件与修建隧道相比 3
1.1.1 美好的旧时光 3
1.1.2 情况越变化，他们越相同 4
1.1.3 软件产品的背后 5
1.1.4 成交或不成交 8
1.2 哆來咪哆來咪 10
1.2.1 迭代模型 12
1.2.2 编码后修复模型 14
1.2.3 混沌 15
1.2.4 重要的方法 19
1.3 软件开发韵律 22
1.3.1 五线谱示例 23
1.3.2 博弈理论 26
1.3.3 启动—结束示图（In-Out Diagram） 28
1.3.4 精通—培训示图 29
1.3.5 不用数学 30
1.3.6 去哪里探索韵律 31
参考文献 32
第2章 了解程序员 34
2.1 个性及智力 36
2.1.1 编程高手 37
2.1.2 了解你的团队 38
2.1.3 招募程序员 40
2.2 外包程序员 42
2.2.1 本土化的程序员 43
2.2.2 程序员，文化及团队 44
2.3 经验式管理 45
2.3.1 对待因果关系不严谨 46
2.3.2 谨慎借用经验 47
2.3.3 从现在做起 49
参考文献 51
第3章 从开源做起 52
3.1 流程和实践 55
3.1.1 项目的四个P 57
3.1.2 敏捷的价值 60
3.1.3 零起点合作 61
3.2 开源软件开发 62
3.2.1 软件克隆 63
3.2.2 软件质量 64
3.2.3 启动流程 65
3.2.4 开源开发团体 66
3.2.5 用户程序员 67
3.2.6 参与者角色 68
3.2.7 快速发布 69
3.2.8 黑盒编程 72
3.2.9 OSS实践 74
3.3 类OSS开发 74
3.3.1 敏捷实践 75
3.3.2 近邻交流 76
3.3.3 松耦合和紧耦合 77
3.3.4 同一地点的软件开发 78
3.4 结论 79
参考文献 80
第二部分：韵律 84
第4章 抄袭编程 84
4.1 抄袭 86
4.1.1 已有的代码 87
4.1.2 社交网络分析 88
4.1.3 被抄袭 89
4.1.4 让人人成为程序员 92
4.1.5 模式语言 96
4.1.6 软件团队能力 98
4.1.7 粗线条设计 101
4.1.8 培训不是解决方案 102
4.2 抄袭最快 103
4.2.1 不道德 104
4.2.2 无先例的代码 105
4.2.3 人际关系网 106
4.2.4 抄袭的韵律 107
4.2.5 工作中抄袭 110
4.3 抄袭的生意与韵律 112
4.3.1 15分钟的商业报告 113
4.3.2 市场调研 115
4.3.3 聊天机器人 117
4.3.4 老歌新唱 122
参考文献 125
第5章 结对编程 127
5.1 艺术与科学 128
5.1.1 最佳搭档 129
5.1.2 喧闹的程序设计 130
5.1.3 仅仅是培训 131
5.1.4 付费给观众 131
5.2 两个世界 132
5.2.1 没钱的世界 133
5.2.2 金钱引导的世界 135
5.2.3 经济学 136
5.2.4 虚构的质量——时间关系 136
5.2.5 加速运行时间 137
5.2.6 关键路径法 138
5.2.7 为什么是两个结对而不是三个：反组织现象 141
5.2.8 软件的需求是个拼图 142
5.3 程序设计任务需求 144
5.3.1 2+4=6 144
5.3.2 2+4=4 145
5.3.3 2+4=3 146
5.3.4 2+4≥2 147
5.3.5 2+4=? 148
5.4 结对编程不仅仅是程序设计 149
5.4.1 用代码设计 150
5.4.2 结对设计 152
5.4.3 韵律结对编程 154
5.5 结对编程团队指导 156
参考文献 158
第6章 重复编程 161
6.1 结对编程的争议 164
6.1.1 编程是一项特殊的工作吗 164
6.1.2 三个脑袋是否比两个好 165
6.1.3 不可重复的实验 166
6.2 重复编程 167
6.2.1 相反的结果 171
6.2.2 原理 173
6.2.3 三人一组编程的效率不高 174
6.3 旋律：结对－单独－结对－单独 176
6.3.1 持续性 177
6.3.2 联系 179
6.3.3 动机 183
6.4 证明布鲁克斯法则的一个特例 186
6.4.1 士气低落 188
6.4.2 沟通的成本 189
6.4.3 适用于延误项目的旋律 191
参考文献 193
第7章 敏捷组队 196
7.1 项目团队 199
7.1.1 自组织团队 201
7.1.2 团队中的团队 202
7.1.3 项目团队的组成 204
7.1.4 团队生命周期与学习曲线 205
7.2 生产力 208
7.2.1 生产力的错觉 208
7.2.2 集体代码所有权 209
7.2.3 责任、职责和透明度 210
7.3 问题与出问题的人 211
7.3.1 旋律：困难——重组 213
7.3.2 组队原则 215
7.4 拯救即将失败的项目 217
7.4.1 项目红绿灯报告 218
7.4.2 一个商业案例 219
7.4.3 指导委员会会议 219
7.4.4 敏捷组队发挥作用 221
7.5 提防Iago（埃古） 222
参考文献 223
第8章 增量设计 225
8.1 建模和计划 226
8.1.1 敏捷计划 227
8.1.2 使用功能性模块进行设计 230
8.1.3 简洁设计 231
8.1.4 总体成本的概念 232
8.2 返工还是复用 235
8.2.1 无法避免的返工 236
8.2.2 即兴创作 237
8.2.3 预先设计 239
8.3 即时的软件开发 240
8.3.1 CMM的旋律 241
8.3.2 一次工厂参观 244
8.3.3 走来走去的工人 245
8.3.4 即时软件开发 247
8.3.5 增量式设计 248
8.4 需求复杂性 250
8.4.1 遗漏的需求 253
8.4.2 冲突的需求 254
8.4.3 迅速改变的需求 254
8.4.4 需求和设计 256
8.5 重构 256
8.5.1 重构活动 259
8.5.2 通过挑战进行重构 260
8.5.3 为了设计模式进行重构 263
8.5.4 故意制造错误 264
参考文献 264
第9章 测试驱动开发 267
9.1 逆向瀑布 270
9.1.1 设计－编码－测试 270
9.1.2 测试－编码－设计 271
9.2 测试优先编程 272
9.2.1 测试和验证 272
9.2.2 断点测试 273
9.2.3 支撑实践 275
9.3 韵律：测试－编码－重构 276
9.3.1 简单的案例 278
9.3.2 自动操作 279
9.3.3 意识革命 281
9.3.4 用来合作的测试案例 284
9.4 快速的软件过程升级 286
9.4.1 培训程序 286
9.4.2 项目规划 287
9.4.3 项目跟踪 288
9.4.4 软件质量 289
9.4.5 软件配置 290
9.4.6 人员纪律 291
参考文献 291
尾声 各种乐声的混合 293
开发旋律和您 294
适用于具有更多重复性编程任务的开发旋律 295
适用于具有挑战性的任务的开发旋律 295