本书是特为每个关注项目开发成败的人，特别是那些没有经过正式软件项目管理训练的人而写的一本书。作者利用在研究与工作中获得的经验告诉您项目开发过程中的规划、设计、管理、质量控制、测试与完工所需的策略与观念，并利用大量技巧建立一套精简可靠的框架来成功的管理项目。不论是新手还是老练的项目管理者都将从中获益匪浅。本书将是每个项目人员案头不可或缺的指导书。
本书作者曾著有两本颇受好评的微软经典著作，通过他的亲身经历，现身说法，使您获得“原汁原味”的微软经验与法则，助您攀着巨人肩膀步入巨人行列！
史蒂夫·麦克康奈尔(Steve McConnell) 多家世界知名软件公司（包括微软）的顾问，《IE软件》“最佳实践 ”栏目的编辑，同时是一位活跃的软件开发人员。他的两本微软经典著作—《Code Complete》和《Rapid Development》获得两项Jolt大奖。
现在美国差不多有两千万人在开发约三十万件软件项目。三分之一到二分之一的项目会在完成前超出时间表与预算目标；在预算花费最多的软件项目中，约半数最后会因为失去控制而取消；有更多项目胎死腹中，被完全搁置；或者这些项目的主持人会宣称目标达成了，可是这些项目结束时没有完成新软件，说明他们碰到了麻烦。本书说明如何避免你的项目陷入上述困境中，无论你是名资深主管、执行经理、软件客户、使用者代表，还是项目主持人，你都能从本书中获益。
软件项目失败的原因有两种因素：负责项目的团队缺乏成功进行项目的知识，或者项目团队缺乏有效进行项目所需的决心。本书对缺乏决心的问题帮不上什么忙，不过却包含许多成功推行一个软件项目所需的知识。
软件项目成功的因素不全是技术上的。有时软件项目生存或失败被当成完全倚赖软件开发者成功施展神奇技术咒文与否的神秘存在。当软件开发人员被问及为何一个组件慢了两个星期才推出，他们会说：“我得在我们的OCX接口上写个32-bit thunking layer。”面对诸如此类的解释，也难怪缺乏完整专门技术背景的人们会对如何影响一个软件项目的成败感到无能为力了。
本书的要旨是阐明软件项目的成败并不在如thunking layer那样完全技术层面的考虑上，而是在更凡俗的问题上。软件项目的成败取决于项目本身是否被小心规划、谨慎执行。绝大部分软件项目都可以以一种几乎保证成功的决定性方式进行。如果一个项目的资金投入者了解决定项目成败的主要因素，他们就能确定项目成功完成。带领项目朝着正确方向前进的人可以是名技术主管或个别的软件开发者，也可以是名上层主管、客户、投资者、使用者代表，或任何其他关注项目的团体。
谁该看这本书
这本书是为所有关注软件项目成败的人所写的。
上层主管、客户、投资者、使用者代表
非软件开发人员常担负起管理软件产品开发的责任。这些人中，有些有营销、管理、金融、法律或其他方面的背景，有些则可能对项目没有任何直接的正面影响力，不过他们还是对项目顺利进行负有连带责任。至少这些人期望在项目开始出错时听到警讯。
如果你处于这类人中，本书提供给你一个简短易读的说明，告诉你一件成功的项目的概貌。它会更进一步给你许多方法来分辨项目是朝向成功还是失败的方向进行着。它也告诉你怎样分辨哪时没消息算好事，哪时好消息其实不好，或是哪时好消息真正代表好消息。
项目主管
许多软件项目主管没经过任何管理软件项目的训练就被推上了管理职位。如果你是这样的人，本书会帮你熟悉需求管理、软件项目规划、项目进行、质量保证和变化控制的关键技术管理技巧。
技术主持人、专业开发人员与黑客
如果你是名技术方面的专家，你可能会不太了解项目主持人需关切的项目轮廓为何。在这方面，你可以将本书当成加注过的项目规划。通过提供一个成功软件项目的概览，本书将帮助你从专业技术人员转型成高效的项目主持人。你可以将本书中描述的规划方式当成一个可以依照你的特定项目量身修订的规划起点。
本书适用的项目类型
本书中所述的规划方式适用于商用系统、广泛的软件销售、垂直市场系统、科学应用系统及类似的程序。它是为利用如对象导向设计与程序写作方式等现代化开发方式的桌面型client/server项目所设计的，不过也可以方便地用在以传统开发方式和大型主机进行的项目上。这个规划方式是为预期在3~18个月以3~25人的团队规模完成的项目所设计的。这样的项目可说是个中型项目，如果你的项目更小些，你可以自行斟酌本书中建议的做法（我在本书从头到尾都会指出哪些做法是你能斟酌选用的）。
本书主要是为那些正在规划阶段的项目所写。如果你才刚开始执行项目，你可以将本书的做法作为项目规划的基础。如果项目已经进行到一半了，第二章中的求生测试和每一章末尾的求生检查会帮你找出项目的成功率。
这本书的规划本身对应付生命与安全要求苛刻的系统还不够正式或严格，它适用于商业应用与事务软件的开发上，而且显著改善了许多目前已经使用的并且以百万美元为成本单位的项目计划。
给进阶技术读者的说明
本书描述一种有效进行软件项目管理的方法。这方法不是惟一的，而且对任何一个特定项目都可能不是最好的。有独特见解的技术主持人通常能够想出比本书所提到的通用规划方式更好、更完善、更独到的开发计划。不过本书中提到的规划方式总比临时救急或是完全毫无头绪的做法要强多了，尤其当“完全零规划”是最常见的情形时。
本书中所述的规划方式用来针对软件项目中最常面对的那些弱点，大致依据软件工程协会(Software Engineering Institute，SEI) 在SEI能力成熟模型第二级中指出的“关键程序”而来，SEI将这些关键程序当成让组织符合时间表、预算、质量与其他目标的关键要素。所有组织有约85%的表现都在第二级之下，这份规划方式会大大改善这些组织的表现。
软件工程协会将第二级的关键过程定义如下：
◆ 项目规划
◆ 需求管理
◆ 项目执行与监督
◆ 结构管理
◆ 质量确认
◆ 分层管理
本书主要是针对分层管理以外的其他项目。
本书的参考书
在撰写这本书时，我手边放了三本宝贵的主要参考书。除我所参考的其他书籍之外，我试着将这三本参考书目的内容浓缩，以我所能做到最有用的方式来呈现其中的内容。
第一本参考书籍是软件工程协会(简称SEI)的《Key Practices of the Capability Maturity Model, Version 1.1》。这本书是关于新式软件开发方法的顺序排定方式上难能可贵的金矿山。虽然近五百页的内容有点长，但里面提供的信息还是相当密集。这不是一本教学性质的书，不适于初学者。不过对于书中所描述的方法已经有基本了解的人来说，书中提供的要义与结构都是天赐之物。本书可以免费从网络上的http://www.sei.cmu.edu/ 网站上取得，或是从弗吉尼亚州春田市的美国商业部国家技术服务处取得。
第二本参考书是美国国家航天局（NASA）软件工程实验室（缩写成SEL）的《Recommended Approach to Software Development,》第3版。SEL是最先获得《IEEE Computer Society》杂志颁发的程序成就奖的组织。许多程序成功的关键都记录在这本参考书目中。SEI在第一本书中描述了一组没提到如何在特定项目中应用的做法，第二本书刚好和第一本书的内容形成互补。对有时会怀疑自己的税金哪里去了的美国人来说，这些来自SEI和NASA的最高级软件实务的好书真是一大鼓舞。这本书也可以免费从网络上获得，网址是http://fdd.gsfc.nasa.gov/seltext.html。
我的最后一本参考“书”是我自己的经验。我不是以一名要创作一本完美的理论构架的学者身份在写这本书，而是以一名要创作一本能够让我跟我的客户在各自的工作中获得裨益的、实务参考的实践者身份在写本书。本书中汇集的信息让我更易于推广我的下一个项目，并易于让我对我的客户解释项目成功的关键因素。我希望这本书对你也有相同的帮助。
史蒂夫·麦克康奈尔
华盛顿州，贝尔维尤市
1997年8月
就在1999年4月初，IDC发布对世界各主要国家和地区关于1998年信息社会指数ISI（Information Society Index）所做的研究报告结果。这份报告指出，美国的信息国力仍保持世界第一的地位，而中国的排名则居于世界第53名。
事实上，IDC对于信息国力的评比指针主要分为计算机基础建设、信息／通信基础建设及社会基础建设三大项。换句话说，信息国力的重点不在于一个国家的信息产值有多少，而在于一个国家于信息应用的投入到达何种程度。
比尔·盖茨在其《数字神经系统》一书中，一开始就强调，过去80年代、90年代，企业成功的因素是品质、是企业再造；而展望未来，企业胜出的关键则是“速度”，这一点从它的书名以《与思考等快的明日世界》(Business @ The Speed Of Thought)为副标题即可看出。
数字神经系统并不是一项新的科技架构或是新的软件代号，它所强调的是一种数字基础建设，除了在硬件方面，将个人计算机透过网络连结起来之外，更重要的是利用目前已经成熟的网络技术来建造企业的管理模式。
未来，企业的成长与淘汰都取决于速度，企业中的每一个工作者都要能够适度地“决策”，如果所有的决策都还要经由层层的关卡才能决定，这样的企业岂能取得速度上的优势？因此企业的工作者必须能在正确的时间、正确的位置撷取正确的信息，以帮助他们做出正确及关键的决策。这就是建立数字神经系统的重点所在。
既然企业建立数字神经系统是如此重要，面对21世纪数字时代的来临，企业该如何适应整体经济环境的冲击？企业若仍因循过去的管理经验及技术，在面临未来以信息为管理基础的竞争时，这样的方式将无法满足企业的需求，企业需要的是以未来竞争为根本的数字神经系统。
软件与硬件其实只是实现数字神经系统的材料，真正实现数字神经系统的是企业里的管理团队及信息部门。如何驱动和改变企业内部这些重要成员的动力，发挥其效率将会是数字神经系统能否成功的关键。
除了需要具备信息技术相关知识之外，信息团队的领导者或管理者更需要好的方法与经验。就像企管系的学生在学校中学习管理知识之外，案例研读除了可以帮助学习者更了解这些知识的实质内涵，更可以在未来多变的环境中，拥有更强的应变能力。而这些具典范价值的经验与方法何处可寻呢？在《微软团队：成功秘诀》、《微软研发：致胜策略》以及《微软项目：求生法则》这三本书中，经由微软自己企业发展过程中的经验与法则，可以获得最佳的解答。虽然这些内容是架构在微软软件开发的特质之上，但却都是“放之四海而皆准”的知识与原则。
当你的企业正彷徨于未来信息时代的挑战，而没有胜算的把握时，相信这几本书将会是帮助你前进的最佳材料。
微软中国研究院院长
1999年12月
史蒂夫.麦克康纳尔：暂无简介
余孟学：暂无简介
我想很多信息相关科系毕业的人都念过软件工程，选过软件工程的课。可是当你念完软件工程，带着满腔热血和精通各种软件开发的武艺投入软件开发时，会碰到许多问题：找你去做软件开发的业主或顾客可能连自己的要求是什么都描述不清楚；在规格不明的情形下对你要求很多，想到什么就要你改什么；给你的开发时限和经费都估计太少。如果是跟其他人一起进行软件开发，往往每个人的写作习惯不一，每个人描述事物的方式不一，很少有一个真的让人心悦口服的领导者带领着团队中的每个人去进行软件开发的工作，于是大家各做各的，最后能不能拼凑起来，那就请老天保佑了。
其实在软件开发过程中，技术问题不多（除非你找错人手），真正问题大部分都出在人身上。软件开发人员与管理者和顾客的沟通经常牛头不对马嘴、各讲各的，软件开发人员之间也在相互沟通上耗费了许多精力。另一方面，设计出来的规格不符合使用者需求也是常见的问题，如何规划出一个让开发人员、管理阶层与使用者都满意的规则的确不是一件容易的事情，但却是一件很重要的事情。其实大家或多或少都明白，在沟通与规划不良的情形下开发出来的软件质量好坏简直就是在赌自己的运气，拿使用者当白鼠。
不管你有没有惨痛的软件开发实践经验，不管你是软件开发者、管理者或者一个出钱找人写程序的使用者，你一定不希望软件开发过程中出现一大堆问题，更不知道出了问题后如何解决这些问题。他山之石可以攻玉，这本书就是来告诉你怎样完成一个质量完美的软件开发项目。
不管你是写程序的人或者是叫人写程序的人，希望这本微软进行软件开发多年累积下来的经验结晶对你有所帮助。
感谢我的研究所指导老师给予我充裕的时间译完这本经典之作，谢谢校稿人员和可爱的编辑为这本书忙得头晕，还有谢谢辛苦的爸爸妈妈，在我工作期间尽量避免了让我动手的杂务。
余孟学
1999年仲夏
推荐序 … IV
出版者的话 …VIII
译者序 …X
前言 …XII
第1章 欢迎来到软件项目求生训练中心 …3
求生需求 …5
求生权利 …7
求生检查 …10
第2章 软件项目求生测验 …13
求生测验 …14
求生测验的评分 …18
求生测验的说明 …19
第3章 求生概念 …21
“开发程序”的威力 …22
上下游 …33
第4章 求生技能 …41
规划 …42
软件规划的例子 …43
规划审查 …45
风险管理 …49
项目控制 …50
项目洞悉力 …51
人因工程 …53
使用者参与度 …56
产品简化主义 …59
焦点放在推出软件 …60
第5章 看看成功的项目 …63
思考阶段 …64
项目流程 …65
规划阶段 …70
汇聚人力 …72
程序代码增长曲线 …75
主要完成点与推行点 …77
第6章 命中移动目标 …89
变动管制程序 …90
变动管制益处 …93
一般变动管制问题 …96
交付变动管制 …102
第7章 初步规划 …105
项目目标前景 …106
主持推动权 …109
项目规模目标 …110
公开规划与进度 …113
风险管理 …116
细节风险管理规划 …124
匿名风险反馈通道 …125
人事策略 …126
时间管理 …134
软件开发规划 …138
第8章 需求开发 …141
需求开发概览 …143
需求开发程序细节 …145
第9章 质量保证 …159
质量为何重要 …160
品管规划 …162
缺陷追踪 …164
技术检查 …166
系统测试 …170
Beta版公开测试 …174
品管规划涵盖的工作成果 …177
支持活动 …181
第10章 构架 …185
缓缓进入构架阶段 …187
良好的构架的特色 …187
如何分辨构架完成与否 …196
软件构架文件 …197
第11章 最后准备 …199
项目预估 …200
阶段性完成规划 …208
持续规划工作 …216
更新软件开发规划 …219
第12章 阶段的初步规划 …223
为何要进行阶段规划 …224
阶段性规划概要 …225
阶段里程碑 …232
阶段规划与管理风格 …240
第13章 细节设计 …243
重新检查构架 …244
一个项目需要多少细节设计工作 … 246
技术检查 …249
细节设计文件 …256
第一个阶段的特别考虑 …257
第14章 构建过程 …261
源代码质量 …262
软件整合程序 …266
每日整建与冒烟测试 …269
进度追踪 …275
每周更新项目进度追踪 …276
控制变动 …278
保持焦点 …279
这就是构建过程中所有要做的事情 …280
第15章 系统测试 …283
测试哲学 …284
测试小组对每日整建的帮助 …286
第16章 软件发行 …291
严肃看待发行工作 …292
何时发行 …294
发行检查清单 …304
发行认可文件 …308
第17章 阶段完成记录 …311
总结更动会议 …312
估计修正 …313
对项目规划的评估表现 …316
项目文件保存 …318
更新项目记录 …319
第18章 项目历程 …325
汇集项目资料 …326
软件项目历程文件 …328
准备未来项目使用的项目历程结果 …330
散发软件项目历程的复制文件 …331
第19章 求生小技 …333
NASA的成功检查清单 …334
其他求生资源 …340
参考书 …341
网络资源 …344
尾声 …345
