标题：软件开发之韵
图书信息
书名：软件开发之韵：和谐敏捷、珠联璧合的开发  作者：[中国香港]  KIM MAN LUI  KEITH C.C. CHAN  著
杨 艳   丁大江   倪祎昭   王天骄    等译
出版社：电子工业出版社 
ISBN：978-7-121-10816-7
出版日期：2010年5月
定价：39.00元
开本：24开 
页码：316页
内容简介
全书包括两部分，共9章。第一部分由三章组成。第1章介绍软件开发韵律的概念，第2章、第3章分别讨论人与实践，阐明软件开发的一些基本概念并提出几个重要的问题，如：“什么是敏捷价值？”“从开源软件开发中我们能学到什么”等。第二部分包括其余的六章，都是关于开发韵律的。软件开发韵律是一个强大的比喻，可帮助我们分析何时更好地采用一种软件开发的方法，使软件开发实践更加和谐，软件的质量也得以提升。
全书行文深入浅出，亲切自然，并配以很多有趣的漫画来阐述书中的概念，值得读者细细品读，定当回味无穷。
前  言
本书帮助我们发现自己的软件方法学，这种方法同时尊重人员与实践的软件开发的双重韵律。
深夜，躺在马拉维湖的康帝海滩，我们仰望晴朗的天空。无数小星星向我们眨着眼。有一点疲倦，或许是这遥远神秘的光使人迷幻，我们闭上眼睛，开始倾心聆听：湖水轻柔地拍打着岸，深夜那微小和谐的声音，心好像随着有韵律的、深深的呼吸而悸动。大自然就是一曲不可思议的韵律合奏。我们的地球在太阳系的轨道上转动不息，日日夜夜，四季循环，永不休止。随着自然的韵律，我们醒来学习，入睡记忆，写写改改我们的程序，在完美的韵律合奏中与宇宙间全能的程序融为一体。从心跳到步伐，韵律是动力十足、充满生机的力量。这世界如此复杂、好似混沌，我们努力追求缘由并确认关联，但有时只有发现韵律才可以让我们看到普遍存在的规律。
就像人类其他的努力一样，软件开发复杂并充满了泛化与关联，但是没有规则。我们用规范的软件开发模型和管理学帮助构造软件，但是纷扰的软件开发、不断变化的开发团队、新的需求与任务，意味着根本无法保证上一次成功的方法就能在下一次同样成功。实际上，有的团队领导看上去并没有采用什么开发方法，因而被别人嘲笑是“即兴开发”，他们反而能够按时完成软件项目。他们成功的秘密就在于能够理解软件开发的韵律。
面对最让人头疼的软件开发问题，了解韵律将给予我们一个新的视角。一个团队的成功方法有时并不适合另一个团队，因为即使是最积极肯干的软件团队，也必须在理解一种新方法的韵律后，才可以成功地得以运用。在管理复杂而多元的软件开发项目时，团队和个人的开发与进程之间的和谐运作是最关键的，然而韵律却是一个经常被忽视的主题。
韵律并不是一种新的开发方法。当前已经有许多种不同的开发方法，本书并不打算介绍一种新的软件开发和项目管理的框架。目前最需要的不是更多的方法，而是更智慧地使用我们选择的方法。最好的方式是，理解并和谐地在团队所采用的开发方法的韵律下工作。如果不理解，不在韵律下和谐地工作，则反而会被选用的开发方法拖累而并非从中受益，会使项目冗长艰难。
本书不是为新手所写的。实际上，我们认为你可以钓鱼并已经钓到了一些鱼了。本书是为了那些老手，想改进甚至于想重新发现软件开发的技巧与技术的人而写的。当我们习惯于只从一个单一的角度看问题时，这些东西很容易被遗忘。就像正在钓鱼的人，用灵巧的手腕，稳定的韵律甩出鱼线，我们希望能帮助你钓到更多的鱼，并帮助你享受这一过程。
读者
我们尽力用平易的语言写一本技术书籍。那些对软件开发和项目管理有兴趣的人（例如软件经理、程序员、研究人员，等等）看此书应该没有任何问题，因为对于任何在这个领域外的术语，我们都提供了解释和清晰的例子。
与肯特·拜克的《解析极限编程》（第2版）一道，此书可以作为敏捷软件开发的高级教材。本书描述了一些项目片段和工业实例，适合于实例学习，也可以向学生展现将来团队合作项目的基本知识。此书也是一本论文专著，因为书中提出了很多概念，这些概念之前没有在工程管理和软件工程的学术论著中充分和适当地予以考虑过。
本书面向广泛的读者群，尤其针对那些有思想深度的读者，那些寻找有创意的项目管理解决方案并对软件开发的复杂领域进行探索的人。
怎样读此书
一般来说，我建议按章节顺序读。本书包括两部分。第一部分由三章组成。第1章介绍软件开发韵律的概念。第2章、第3章分别讨论人与实践，阐明软件开发的一些基本概念并提出几个重要的问题，例如：“为什么我们不可以从经验中学习？”，“什么是敏捷价值？”，“怎样才可以衡量不同的无形的软件开发工作孰轻孰重？”，还有“从开源软件开发中我们能学到什么？”
本书第二部分都是关于软件开发的韵律。我们过去常常用相似的术语：进程，实践。虽然不是每个人都自信知道它们之间的差别，但我们是在软件开发实践的基础上谱写韵律。当我们分析何时更好地采用一种软件方法时，软件开发韵律是一个强大的比喻。为了更有效地展现这一点，我们采用了一些有争议的软件实践并且考虑它们的韵律，将它们与其他一些广泛接受的软件实践进行比较。
一旦你理解了软件韵律分析是怎样使实践更加和谐的，你就可以作为一个中间步骤，采用本书呈现的韵律或者尽情修改它们。然而，最重要的是意识到：韵律不是模型，最终我们都需要谱写自己的韵律。
鸣谢
本书涉及几个软件开发领域之外的概念和观点。幸运的是，众多这些领域的著名专家给我们提供了友善的建议和指导，让我们深深受益。对于他们宝贵的时间和专业的建议，我们的感激无以言表。下面按字母顺序列出了他们的名字：
Paul Davies，审定了我们关于物理学家和结对编程的描述；
Don Forsyth，从很多动态视角提供了他关于结对编程的洞察；
Michael McClellan，审核了本书的音乐符号；
Richard Schonberger，审核了有关精益制造和工程项目的部分；
Frank Vigneron，对天使的性别进行了讨论；
Joel Watson，审核了“成交还是不成交”和博弈理论的类比；
Philip Zimbado，关于他的监狱实验给了我们建议。
许多资深程序员都审阅了本书的一到两章并提供了宝贵的意见，对此我们深表感谢。十分感谢（以字母表顺序）：Lawrence Bernstein, Grady Brooch, Magne J&Oslash;rgensen, Pete McBreen, George Metes, Peter Middleton, Mark Paulk, Ioannis Stamelos, Royce Walker和Sami Zahran。
感谢Martin Kyle给我们提供了有用的建议：用平白的语言书写。我们感谢John Nosek对合作编程的见解和对本书的贡献。我们非常高兴有Angappa Gunasekaran的支持。我们感谢Lai Shan Sit用很多有趣的漫画来解释我们的观点。感谢我们的朋友和同事Jun Wang，Zheng Li，Polly Leung，Fei Dong，Ka Wing Wong，Whitney Lesch和Rosalyn Farkas的协助。
最后，我们尤其感谢两个人。感谢Kent Beck启发了我们在软件开发韵律方面的研究。Kent向我们建议了应该集中在哪些选题上，他还审查了整个手稿。感谢Paul Petralia，我们的编辑，他告诉我们从最开始他就喜欢这本书的概念。他说这本书将促进人们用新方法思考老问题，没有他的鼓励就没有这本书。我们全都相信软件开发韵律是一个强大的解决方案和有效的管理工具，这不是巧合。韵律不是方法，它更像元方法，是一种开发新软件方法的方法！
KIM MAN LUI
KEITH C. C. CHAN
2008年1月于中国香港
译者序
这是一本关于推荐、推广、推崇敏捷软件开发的教材。2008年初识此书，几章读下来，思维方式受到了巨大冲击。这不仅是一本指导软件开发实践的参考书，更是转变软件开发思维的工具书。后来有了本书其他译者的加入：具有丰富专业知识和经验的丁大江、倪祎昭和杨军，软件开发爱好者王天骄和张靖。在本书翻译的多次讨论中，我们都感觉到由这本书带来的思维方式的冲击是深刻的，不只影响了软件开发思维，甚至拓宽了学习、工作的思维方法。本书主要介绍软件开发韵律，是一种开发软件的新思维，一种软件工程管理上的革命！
我国有最好的程序员，他们勤奋、好学，不厌其烦地一遍遍书写并修改代码，而软件的管理水平却亟待提高。随着几十年软件开发的发展，软件管理也面临着从粗放到集约的转变，除了编写软件外，我们开始关心如何做好、做出易管理的、低耗而高效的软件产品，这些都是我们未来软件管理的核心发展方向。
这本书中谈到技术与管理的关系，将人的因素加入软件工程管理范畴，与我在交通心理学中进行的研究不谋而合，也因此引起了我极大的兴趣。人作为整个系统的核心因素，却常常被遗忘在技术的背后。本书综合考虑软件工程中的各个环节，将其作为一项系统工程，而非单纯的日程表和编码。作者通过借用大量心理学范围的理论和实例阐释了程序员的因素对软件开发的影响，从而有力地说明：一种先进的软件开发及管理方法必须对人的因素进行细致而彻底的研究。
与其他程序设计教材相比，本书更注重用事实说话，以典型案例为根基，以分析为支柱，建设敏捷软件开发的殿堂。作者依靠详实的案例和丰富的软件开发管理经验对采用敏捷软件开发的原因、环境和原则进行了独到的分析与阐释。作为一本面向程序开发团队的管理教材，作者的目的在于向团队的管理层推荐敏捷软件开发的概念、推广敏捷组队等团队形式，以及推崇软件开发韵律这一崭新的理念。所有的方法论变革看似突然、巧妙，仔细回味却又觉得按部就班、理所当然，让人觉得水到渠成又感到无所适从。到底应该用什么样的方法解决问题？如何面对内外部环境的变化？在这本书里面，频繁出现的一个词给了我们启迪，这个词就是“韵律”。
作者以提高软件质量为目的，针对敏捷开发，从易于理解的、创新的视角向读者阐述了软件开发的“韵律”，即“在敏捷实践的基础上，如何采用其中一种开发方式并使它与另一种开发方式相结合，以实现一种协同作用，从而使它们在协同工作方式下所发挥的效用比它们单独使用更加强大”。
书中有众多工业上经典精彩的实例，加上语言上幽默精辟的分析，让每个结论都显得扎实、饱满、让人信服。以译者揣摩，作者更倾向于向团队管理人物销售软件开发韵律的理念，而非手把手地指导敏捷软件开发的流程。相较于其他程序设计书籍丰富详实的编程实例，此书对编程代码方面仅是点到即止。
作者的行文方式令人印象深刻。比起普通程序设计教材生硬刻板的论述，此书常以软件开发实践中的点滴作为出发点展开论题。如此行文，亲切自然，更另诸多非程序员（比如团队的管理者、组织者）能够轻易地了解作者的意图，书中虽然涉及了目前软件管理中的大部分先进概念，但并不晦涩难懂。作者绕开软件开发的种种术语，旨在给读者介绍更高层的管理理念。本书附有大量生动的图表，采用一种轻松活泼的风格写成；书中还包含许多有趣的小故事以及来自实际生产的案例分析，使读者身临其境、易于理解。比如，心理学理论往往是比较抽象的，而本书的作者却用平实朴素的语言，加以大量有趣的测试和实例解释了编程心理学的相关知识。更独到的是，这本书创造性地用五线谱来描述软件开发的韵律，通过五线谱把两个以上的软件实践和谐地掌控起来，使读者能更深刻地感受，去探索软件开发的节奏和韵律。
本书共有9章，涵盖了软件开发韵律学的理念、应用、实例及其注意事项的方方面面。其中第1章和第4章由丁大江翻译，第5章和第7章由倪祎昭翻译，第6章和第8章由王天骄翻译，第3章和第9章由杨军翻译，第2章由张靖翻译，全部译稿的统编和校对由杨艳完成。所有的翻译和校对工作历时大半年，在此，我要感谢为本书的出版付出辛勤汗水的电子工业出版社博文视点公司的编辑，他们严谨认真的工作使该译本可读性更高，她们高涨的工作热情深深感染着我努力将最好的版本奉献给读者。希望这本书除介绍给读者有用的知识外，也能带给您阅读的享受。
希望本书的中文版能够促进读者们之间的交流。同时，翻译之中的不妥和疏漏之处，还敬请读者批评指正。
杨艳
2010年3月3日于英国
目  录
第一部分：基本概念
第1章  程序员不死
1.1  开发软件与修建隧道相比
1.1.1  美好的旧时光 
1.1.2  情况越变化，他们越相同 
1.1.3  软件产品的背后 
1.1.4  成交或不成交 
1.2  哆来咪哆来咪
1.2.1  迭代模型
1.2.2  编码后修复模型
1.2.3  混沌 
1.2.4  重要的方法
1.3  软件开发韵律
1.3.1  五线谱示例
1.3.2  博弈理论 
1.3.3  启动－结束示图（In-Out Diagram）
1.3.4  精通－培训示图
1.3.5  不用数学
1.3.6  去哪里探索韵律
参考文献  
第2章  了解程序员 
2.1  个性及智力
2.1.1  编程高手 
2.1.2  了解你的团队
2.1.3  招募程序员 
2.2  外包程序员  
2.2.1  本土化的程序员
2.2.2  程序员，文化及团队 
2.3  经验式管理 
2.3.1  对待因果关系不严谨 
2.3.2  谨慎借用经验
2.3.3  从现在做起 
参考文献 
第3章  从开源做起 
3.1  流程和实践 
3.1.1  项目的四个P 
3.1.2  敏捷的价值  
3.1.3  零起点合作 
3.2  开源软件开发
3.2.1  软件克隆
3.2.2  软件质量
3.2.3  启动流程
3.2.4  开源开发团体
3.2.5  用户程序员 
3.2.6  参与者角色
3.2.7  快速发布
3.2.8  黑盒编程 
3.2.9  OSS实践 
3.3  类OSS开发
3.3.1  敏捷实践 
3.3.2  近邻交流
3.3.3  松耦合和紧耦合
3.3.4  同一地点的软件开发
3.4  结论  
参考文献
第二部分：韵律
第4章  抄袭编程 
4.1  抄袭 
4.1.1  已有的代码
4.1.2  社交网络分析  
4.1.3  被抄袭  
4.1.4  让人人成为程序员
4.1.5  模式语言  
4.1.6  软件团队能力
4.1.7  粗线条设计
4.1.8  培训不是解决方案   
4.2  抄袭最快 
4.2.1  不道德
4.2.2  无先例的代码 
4.2.3  人际关系网 
4.2.4  抄袭的韵律
4.2.5  工作中抄袭
4.3  抄袭的生意与韵律  
4.3.1  15分钟的商业报告
4.3.2  市场调研
4.3.3  聊天机器人
4.3.4  老歌新唱
参考文献
第5章  结对编程 
5.1  艺术与科学 
5.1.1  最佳搭档 
5.1.2  喧闹的程序设计  
5.1.3  仅仅是培训  
5.1.4  付费给观众
5.2  两个世界 
5.2.1  没钱的世界
5.2.2  金钱引导的世界
5.2.3  经济学
5.2.4  虚构的质量——时间关系
5.2.5  加速运行时间
5.2.6  关键路径法 
5.2.7  为什么是两个结对而不是三个：反组织现象
5.2.8  软件的需求是个拼图
5.3  程序设计任务需求
5.3.1  2+4=6 
5.3.2  2+4=4
5.3.3  2+4=3 
5.3.4  2+4≥2  
5.3.5  2+4=?
5.4  结对编程不仅仅是程序设计
5.4.1  用代码设计
5.4.2  结对设计
5.4.3  韵律结对编程
5.5  结对编程团队指导
参考文献  
第6章  重复编程   
6.1  结对编程的争议
6.1.1  编程是一项特殊的工作吗 
6.1.2  三个脑袋是否比两个好
6.1.3  不可重复的实验
6.2  重复编程
6.2.1  相反的结果
6.2.2  原理
6.2.3  三人一组编程的效率不高
6.3  旋律：结对-单独-结对-单独 
6.3.1  持续性
6.3.2  联系
6.3.3  动机
6.4  证明布鲁克斯法则的一个特例 
6.4.1  士气低落
6.4.2  沟通的成本 
6.4.3  适用于延误项目的旋律
参考文献  
第7章  敏捷组队  
7.1  项目团队 
7.1.1  自组织团队
7.1.2  团队中的团队
7.1.3  项目团队的组成 
7.1.4  团队生命周期与学习曲线
7.2  生产力 
7.2.1  生产力的错觉
7.2.2  集体代码所有权
7.2.3  责任、职责和透明度
7.3  问题与出问题的人
7.3.1  旋律：困难——重组
7.3.2  组队原则 
7.4  拯救即将失败的项目 
7.4.1  项目红绿灯报告
7.4.2  一个商业案例
7.4.3  指导委员会会议 
7.4.4  敏捷组队发挥作用 
7.5  提防Iago（埃古）
参考文献 
第8章  增量设计
8.1  建模和计划
8.1.1  敏捷计划 
8.1.2  使用功能性模块进行设计 
8.1.3  简洁设计
8.1.4  总体成本的概念
8.2  返工还是复用
8.2.1  无法避免的返工 
8.2.2  即兴创作
8.2.3  预先设计
8.3  即时的软件开发
8.3.1  CMM的旋律
8.3.2  一次工厂参观
8.3.3  走来走去的工人 
8.3.4  即时软件开发 
8.3.5  增量式设计
8.4  需求复杂性
8.4.1  遗漏的需求 
8.4.2  冲突的需求 
8.4.3  迅速改变的需求 
8.4.4  需求和设计
8.5  重构 
8.5.1  重构活动
8.5.2  通过挑战进行重构 
8.5.3  为了设计模式进行重构
8.5.4  故意制造错误
参考文献 
第9章  测试驱动开发
9.1  逆向瀑布
9.1.1  设计-编码-测试
9.1.2  测试-编码-设计
9.2  测试优先编程
9.2.1  测试和验证
9.2.2  断点测试
9.2.3  支撑实践 
9.3  韵律：测试-编码-重构
9.3.1  简单的案例
9.3.2  自动操作
9.3.3  意识革命 
9.3.4  用来合作的测试案例
9.4  快速的软件过程升级
9.4.1  培训程序
9.4.2  项目规划
9.4.3  项目跟踪
9.4.4  软件质量
9.4.5  软件配置
9.4.6  人员纪律
参考文献
尾声  各种乐声的混合
开发旋律和您
适用于具有更多重复性编程任务的开发旋律
适用于具有挑战性的任务的开发旋律