KIM MAN LUI博士，是一位大学（Hong Korlg Polytechnic  University）电子计算学系的访问教授。他是Oracle认证数据库管理员和Sun认证、Java程序员。
　　KEITH C.C.CHAN博士,是香港理工大学电子计算学系的教授和系主任，他曾经是IBM设在多伦多的IBM加拿大实验室（IBM Canada Laboratory）的高级分析员。
　　译者简介：
　　杨艳，长安大学信息工程学院讲师。研究方向包括：智能交通系统、交通安全、驾驶员心理学和软件工程管理等。主要研究兴趣：检测评价车内外驾驶环境，为科学地制定交通策略提供理论依据，并致力于利用改善车内外软硬件环境以提高交通安全。
　　丁大江，大学毕业后就一直做软件编程，迄今已有十余年，有完成任务的喜悦，更多的是陷入几乎绝望的烦恼。好的编程方法可以大大缩短编程过程，希望这本书能对大家有所帮助。
　　倪神昭，福建泉州籍人。2005年毕业于厦门大学自动化系，同年进入英国伦敦大学研读智能系统硕士学位。2010年博士毕业于南安普顿大学计算机系，主修机器学习与机器翻译。
　　王天骄，本科毕业于北京交通大学交通运输学院，取得学士学位。至本书截稿时，就读于英国南安普敦大学土木与环境工程学院交通运输研究组，攻读博士学位。研究兴趣包括：道路使用者行为，交通建模与仿真，智能交通系统等。
　　杨军，总后直属某部助理工程师，管理学、军事学学士，后勤管理信息化硕士。研究方向：后勤信息化理论与实践、基于多Agent的信息系统协同等。
　　张靖，2004年毕业于长安大学，2005年就读于南安普顿大学交通规划与工程硕士专业，2006年毕业后继续在该校攻读博士学位。

　　《软件开发之韵：和谐敏捷、珠联璧合的开发》是一本关于推荐、推广、推崇敏捷开发的软件方法学教材，这种方法同时尊重人员与实践的软件开发的双重韵律。全书包括两部分，共9章。第一部分由三章组成。第1章介绍软件开发韵律的概念，第2章、第3章分别讨论人与实践，阐明软件开发的一些基本概念并提出几个重要的问题，如：“什么是敏捷价值？”“从开源软件开发中我们能学到什么”等。第二部分包括其余的六章，都是关于开发韵律的。软件开发韵律是一个强大的比喻，可帮助我们分析何时更好地采用一种软件开发的方法，使软件开发实践更加和谐，软件的质量也得以提升。
　　另外，《软件开发之韵：和谐敏捷、珠联璧合的开发》以软件开发实践中的点滴作为出发点展开讨论，描述了一些项目片段和工业实例，注重用事实说话。全书行文深入浅出，亲切自然，并配以很多有趣的漫画来阐述书中的概念，值得读者细细品读，定当回味无穷。
　　适合阅读《软件开发之韵：和谐敏捷、珠联璧合的开发》的，不仅仅是处在软件行业第一线的程序员；各个软件开发单位的团队领导、项目主管、高层管理人员，以及人力资源经理、文档撰写人员、程序开发工具的设计者、程序开发语言的设计者，甚至所有其工作与程序开发有关的人，都能从《软件开发之韵：和谐敏捷、珠联璧合的开发》中得到启发。

　　最终而言，历史和市场可能会消除这些差异，但是在项目实施的当下，对每个项目管理者来说这都是需要解决的问题。管理者需要了解他们要外包的地区信息，而这些外包地区的人员及文化有着一系列你所不熟悉的、他们本土化的标准。我们不能因为当今众多事物的全球化，因为有时你不需要跟你的团队成员面对面接触，就想当然地认为团队成员的性格与你无关了。
　　对于一个良好的团队工作来说，用人得当非常必要。要是你对发展中国家影响到程序员行为的地区约束缺乏了解，那你就必须把自己的最好水平准备到位，当然这来自于你培训或带领过的各地软件开发团队的经验。
　　2.2.1 本土化的程序员
　　在欧洲，制造业已经移到了东欧；在美国，从北部移到了南部，甚至跨过国界移到了墨西哥。在亚洲，制造业在曾经的农村地区找到了其适应的场所。制造业一直在这么做——那就是转移到地价和劳动力更便宜的地方，转移到那些当地政府一心想提供资助、打算新建的基础设施上。同样的道理，像制造业的进发一样，无数小型的当地软件开发团队也以同样的方式出现了，他们或是用自己的团队或是将软件项目转包出去，从而对外提供系统解决方案。
　　这些软件开发团队往往会受到当地环境的约束。他们大多数是由当地人组成的，各自为了不同的目的，队伍中也缺乏精英人才。在这种地区中，一个人如果想组建软件开发团队，除了在大型公司总部及顶级研究型大学之外，都一定要意识到在欠发达城镇和发达城市中团队的业务水平和工作态度往往有着巨大的差别——即使这两个地区的地理位置非常接近。而当政府着力扶持某个城市或地区时（比如在中国），这个地区与其他地区之间的差异会更加迅速地持续扩大。

第一部分：基本概念
第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

第二部分：韵律
第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