标题：软件项目成功之道
图书信息
原书名： Ship it! A Practical Guide to Successful Software Projects  封面原出版社： Pragmatic Bookshelf 
作者： (美)Jared R. Richardson    William A. Gwaltney Jr. 
译者： 苏金国 王少轩 
丛书名： 图灵程序设计丛书 
出版社：人民邮电出版社 
ISBN：9787115259653 
出版日期：2011 年8月 
开本：16开 
页码：181
内容简介
作者以精炼、风趣的语言揭开了项目管理过程的神秘面纱。所涵盖的内容涉及工具、使用项目技术、曳光弹开发以及常见问题的解决办法，并提供大量实用建议，且总结出方方面面的“技巧”，帮助读者在阅读过程中快速消化所看内容。
《软件项目成功之道》适合软件研发专业人士阅读，对软件项目管理感兴趣的社会各界人士也能从中获益。
作者介绍
Jared R. Richardson是一名开发人员、演说家、作家和独立顾问，是由开发人员逐步成长为研发经理的。他有着十多年丰富的工作经验，擅长使用非定制技术来解 决疑难问题。他领导着SAS软件研究所的一个开发和测试团队，负责带领整个公司提高了测试自动化的使用。
William A. Gwaltney Jr.有着二十多年软件开发经验，在网络、通信、知识表达及基于网络的计划调度方面都很有造诣。他在SAS软件研究所从事测试自动化方面的工作。
译者序
说来也巧，拿到原书正在翻看时，我所在的一个项目组临时召集开会。这个项目去年就已经启动，甚至单位最高领导亲自动员，其重要性可见一斑。开始时大家确实士气高昂，成效明显，每周例会都会汇报新的进展，可惜第一个演示版本提交后，这种势头就没能再保持下去。大家都忙于处理自己手上其他的繁杂事务，在这个项目上投入的精力越来越少，每周例会也不再召开，已经成为回忆。由于中期检查临近，这才不得不召开“例会”了解目前工作状态，并讨论下一步工作安排。 
会议开始后，一个同事的发言让我觉得似曾相识。他负责的部分需要与外单位开发的4个模块集成，提交演示版本时，只有一个模块能成功集成，另外3个模块一直有问题。这期间改改停停，问题一直不能干净利落地得到解决。最近联系过一次联调，经过几天努力，终于搞定了这3个模块。可是最后一天外单位人员临走时过于匆忙，不小心覆盖了那几天的成果。所以这位同事说，只好再安排一个时间重新联调，不过时间还没有定下来……我心里想：这不正是我刚才在书里偶然看到的情况吗？ 
这时另一位同事也表示出对这个单位合作态度的不满，开始大谈他们的种种不是，大家只能百无聊赖地听着，不好意思打断。接下来话题扯得越来越远，一下午的会议结束后，尽管大家都很是辛苦，甚至头昏脑胀，但还是不清楚目前到底有哪些新的进展，也没有讨论好接下来的具体安排。 
回到自己的办公室，重新拿起这本书，我发现这一切正是书中所说的一个真实场景的再现，当即把它推荐给了我们的项目负责人。现如今，我们的每周例会已经恢复（尽管没有做到书中建议的每日例会），项目在有条不紊地向前推进。 
关于这本书的内容，我不想多讲，只想说：这本小书会带给你实实在在的好处，如果你手上有迟迟无法交付的项目，也许这就是你的曙光！ 
“好风凭借力，送我上青云”！借着大师们的力量，站在巨人的肩上，我们会走得更远！ 
全书主要由苏金国、王少轩翻译，并得到王小振、李璜、刘亮、李新宏的大力协助。若译文有不当之处，敬请读者批评指正。
前言
不论是对你自己还是对你的职业发展，最明智的一项投资就是让你身边有一些“合适”的人——他们会成为你能找到的最好的资源。这些人可能已经做过你打算做或者想学着做的事情。如果你想做一些事情，最好找到那些做过这些工作的人，或者至少找到一些真正睿智的人，能够告诉你该怎样完成这些工作。尽可能和他们多待些时间，通过相互帮助来向他们学习。与这些高水平的人相处，会让你学到很多东西，不论你的工作是什么，这都会让你表现得更出色。 
这是一个很好的想法，但是要想与那些顶尖人物接触可能很困难。像Martin Fowler、Kent Beck和Pragmatic Programmers的作者等大师级人物，并不是我们大多数人有机会见到的，不过我们可以看到他们的书、文章和演示文稿。所以要开始读书。一个月读一本书应该不会太费劲。但是不要就此止步，接下来可以学习一种新的编程语言，或者研究一个不同的开发过程。在学习和读书时，要想办法把这些新思想应用到当前的工作中。这样一来，你不仅能帮助你的公司提升，更重要的是，还可以让你自己得到提高。 
要让自己开放地接受新思想。不要闭塞，应当想办法把这些新思想应用到你现在的工作中。也许你会放弃，并声称某种新思想不适用，这样做当然更轻松，不过我们的目标是学习采用另外一种不同的方式考虑问题。要打破条条框框（或者至少建一个更大的框框）。多学习掌握一些看似不太相关的概念和思想。 
通过对环境和过程进行分析和评判，你可以找出弱点。也许这会帮助你对这个项目或者下一个项目做出改进。但同时你也练习了一种新的思维方式，不论在哪里工作这对你都会有好处。大多数人从来不曾了解这个概念，擅长的人更是少之又少。 
所以，读完这本书的每个实践后，请停下来，花5分钟时间试着想想有没有办法在你今天做的工作中具体运用各个概念。你可能不假思索地回答：无法做到。这种回答当然最不费劲，不过要记住，不能这么懈怠，你应当更加努力！如果你自己找不出一种方法来应用这个概念，可以找一位同事来帮忙。如果仅凭自己的双眼看不到，可以借助别人的视角来了解。不论在什么领域，知道如何利用同事的经验，绝对是高手特有的标志。 
希望你掌握从本书（和整个Pragmatic Starter Kit系列）读到的内容，想办法在工作中应用每一个概念。你会看到读这本书给你带来的直接好处，其中最大的好处就是你会学习如何真正加以应用。 
希望你喜欢！ 
致谢 
首先要感谢Andy和Dave让我们为Pragmatic Bookshelf写一本书。能为你们写一本书真是荣幸。Andy，你做的已经远远超出了你的份内职责，甚至花好几个小时与我们一同修改手稿，给我们上了一堂写作速成课，尽管有时对我们的写作天份……有些发愁（我们确信你肯定失望过）。Dave，我们曾经问过很多关于图书生成系统和标记语言细节的问题，感谢你花那么多时间回答这些邮件。非常感谢你们二位！ 
我们有很多非常棒的审校人员，另外还有很多人做出了贡献，他们详细而且有建设性的反馈确实意义重大。没有你们投入的时间，没有你们丰富的经验，这本书不可能出版。Susan Henshaw和Jim Weiss花了大量时间审校我们粗糙的文字，而且读过不止一遍。谢谢你们。 
还要感谢Mike Clark、David Bock、Ken Pugh、Dominique Plante、Justin McCarthy、Al Chou、Bryan Ewbanks、Graham Brooks、Grant Bremer、Guerry Semones、Joe Fair、Mark Donoghue、Roberto Gianassi、Rob Sartin、Shae Erisson、Stefan Schmiedl和Andy Lester。你们当中很多人曾忍受过这本书很早的版本，最近我们重新读了你们原先读过的版本，对你们曾经遭受的“折磨”我们深表歉意。说真的，所有反馈都很棒，正是有了这些反馈，这本书才得到了如此显著的改进。 
在我们的职业生涯中，曾经与很多人共事过，其中有些人对我们的工作以及这本书产生了直接的影响。我们要特别感谢Jim Weiss、Randy Humes、Graham Wright、Flint O’Brien、Toby Segaran和John Wilbanks。还要感谢我们现在的经理Oita Coleman对我们的鼓励和支持。我们很幸运，能够在SAS这样的世界级公司工作。 
如果没有敏捷开发社区的智慧，没有大家出色的作品，这本书绝无可能问世。我们读过XP、Scrum、Crystal以及很多其他软件领域专家的书和文章。没有你们辛苦而忘我的工作，软件行业可能还在黑暗岁月中挣扎。也许我们还没有完全走出黑暗，不过起码正朝着正确的方向前进。你们孜孜不倦的工作让大家受益匪浅。 
开源社区共同为全世界提供了这么多非凡的工具和想法，同样要向你们表示感谢。正是因为全世界开发人员的无私奉献，我们这里讨论的大多数工具才可以免费使用。在此要特别提到SourceForge团队和Apache 软件基金会。你们提供的服务和工具不仅让我们提高了生产效率，还改变了整个世界。 
最后，也是最重要的，要感谢我们的主，耶稣基督，愿主永得荣耀！ 
Jared Richardson和William Gwaltney 
我的妻子Debra为这本书投入了大量的时间和精力。甚至有好几个星期Debra花在这本书上的时间比Will和我还要多。其余的时间她既做母亲又做父亲，才让我得以安心地完成这本书。我发自内心地相信，如果没有她的帮助和支持，我绝对不可能完成这个工作。谢谢你！ 
我的孩子们，Hannah和Elisabeth，很多个夜晚和周末爸爸都把自己锁在办公室里一心扑在这本书上，感谢你们忍受了这一切。谢谢你们的理解和爱！
序言
你可能已经注意到了，书架上关于软件开发的书并不只有这一本。 
实际上，关于设计和构建软件的书林林总总，多得让人眼花缭乱，不仅如此，它们相互之间还不太一致。遗憾的是，这些方法上的分歧带来的感受往往让人“炙热难当”：作为软件行业的从业人员，我们体会到的不是光明，而是焦头烂额的感觉。另外，我们的项目总是延期。 
我们在不断探寻更好的软件开发方法，希望能找到适合自己和团队的好办法。不过，基于既有的教条，关于各种开发方法孰优孰劣的讨论最终总会演变成激烈的争吵。字典中教条的定义是“一种权威性观点，但并没有充分的依据”。我们经常会看到，各种方法的拥护者们都坚持认为自己的方法才是开发软件唯一正确的方法。我们不断听到一些从业人员这么讲，他们执着地采用某种方式开发软件，即使这种方法明显危害到团队的其他人甚至整个组织，却仍然固执己见。 
事实上，开发软件根本没有所谓“绝对正确的方法”。倒是有很多错误的方法，不过没有哪一种方法、观点、哲学或工具能“以不变应万变”，在所有时间、所有场合对所有项目和所有人都适用。软件是人创建的，不会有两个人完全一样。 
所以对于软件开发实践，我们还是沿用“务实”的观点。我们要强调的是目标：你希望得到一堆签名，还是希望所有人都能理解？你希望匆忙间随便抛出一堆东西来，还是生成一个可以真正帮助别人完成工作的软件？ 
我们想尝试新鲜事物，并对我们的实践不断评价和修正；我们希望找到适用的方法。不过着手这个工作很费功夫：我们要做大量研究，需要耗费大量时间，而大多数参与实际工作的程序员根本没有这么多时间。 
这让我萌生出一个想法：请Jared和Will写这样一本书。这是一本快速入门的指南，你能从中了解开发可靠代码所需的基本、有效的工具和技术。 
Jared和Will是《程序员修炼之道》最早的读者，他们用心领会书中的道理，运用我们的方法和技术，并结合其他流行的敏捷方法实践，形成了一种独特的方法，让他们不论在小的初创公司还是世界上最大的私营软件公司，都能得心应手地开展工作。 
这本书汇集了他们最钟爱的技术和实践。运用这些内容，你将在改善开发过程时如虎添翼，快速入手，当然可能还需要补充Pragmatic Starter Kit系列介绍的其他一些技术细节。随着时间的推移，你可能希望进一步扩展，尝试另外一些实践和技术。毕竟，这正是务实之道——根据当务之急，找到最适用的方法。 
希望这本书对你有帮助，能让你轻轻松松地成功交付系统！ 
Andy Hunt 
The Pragmatic Programmers公司 
2005年4月 
目录
《软件项目成功之道》 
第1 章 
绪论　　1 
1.1 习惯性优秀　　2 
1.2 务实观点　　3 
1.3 路线图　　5 
1.4 继续前进　　7 
1.5 怎样读这本书　　7 
第2 章 工具和基础设施　　11 
1 在沙箱中开发　　15 
2 管理资产　　18 
3 建立构建脚本　　23 
4 自动构建　　27 
5 跟踪问题　　32 
6 跟踪特性　　36 
7 使用自动化测试框架　　39 
8 选择工具　　46 
9 何时结束试验　　48 
第3 章 实用项目技术　　51 
10 按照任务清单工作　　53