微软项目求生法则 内容简介
本书作者曾著有两本颇受好评的微软经典著作，通过他的亲身经历，现身说法，使您获得"原沐原味"的微软经验与法则，助您攀着巨人肩膀步入巨人行列！
相关图书：《微软团队成功秘诀》 、《微软研发致胜策略》
微软项目求生法则 本书前言
前 言
现在美国差不多有两千万人在开发约三十万件软件项目。三分之一到二分之一的基础上会在完成前超出时间表与预算目标；在预算花费最多的软件项目中，约半数最后会因为失去控制而取消，有更多项目胎死腹中，被完全搁置，或者这些项目的主持人会宣称目标达成了，可是这些项目结束时没有完成新软件，说明他们碰到了麻烦。本书说明如何避免你的基础上陷入上述困境中，无论你是名资深主管、执行经理、软件客户、使用者代表，还是项目主持人，你都能从本书中获益。
软件项目失败的原因有两种因素：负责项目的团队缺乏成功进行项目的知识，或者项目团队缺乏有效进行项目所需的决心，本书对缺乏决心的问题帮不上什么忙，不过却包含许多成功推行一个软件项目所需的知识。
软件项目成功的因素不全是技术上的，有时软件项目生存或失败被当成完全倚赖软件开发者成功施展神奇技术咒文与否的神秘存在。当软件开发人员被问及为何一个组件慢了两个星期才推出，他们会说："我得在我们的OCX接口上写个32-bit thunking layer"面对诸如此类的解释，也难怪缺乏完整专门技术背景的人们会对如何影响一个软件项目的成败感到无能为力了。
本书的要旨是阐明软件项目的成败并不在如thunkinglayer那样完全技术层面的考虑上，而是在更凡俗的问题上，软件项目的成败取决于项目本身是否被小心规划、谨慎执行。绝大部分软件项目都可以以一种几乎保证成功的决定性方式进行。如果一个项目的资金投入者了解决定项目成败的主要轱纱，他们就能确定项目成功完成。带领项目朝着正确方向前进的人可以是名技术主管或个别的软件开发者，也可以是名上层主管、客户、投资者、使用者代表，或任何其他关注项目的团体。
谁该看这本书
这本书是为所有关注软件项目成败的人所写的。
上层主管、客户、投资者、使用者代表
非软件开发人员常担负起管理软件产品开发的责任。这些人中，有些有营销、管理、金融、法律或其他方面的背景，有些则可能对项目没有任何直接的正面影响力，不过他们还是对项目顺利进行负有连带责任，至少这些人期望在项目开始出错时听到警讯。
如果你处于这类人中，本书提供给你一个简短易读的说明，告诉你一件成功的基础上的概貌。它会更进一步给你许多方法来分辨项目是朝向成功还是失败的方向进行着。它也告诉你怎样分辨哪时没消息算好事，哪时好消息其实不好，或是哪时好消息真正代表好消息。
项目主管
许多软件项目主管没经过任何管理软件项目的训练就被推上管理职位。如果你是这样的人，本书会帮你熟悉需求管理，软件项目规划、项目进行、质量保证和变化控制的关键技术管理技巧。
技术主持人、专业开发人员与黑客
如果你是名技术方面的专家，你可能会不太了解项目主持人需关切的项目轮廓为何，在这方面，你可以将本书当成加注过的基础上规划。通过提供一个成功软件项目的概览，本书将帮助你从专业技术人员转型成高效的基础上主持人，你可以将本书中描述的规划方式当成一个可以依照你的特定项目量身修订的规划起点。
本书适用的项目上类型
本书中所述的规划方式适用于商用系统，广泛的软件销售、垂直市场系统、科学应用系统及类似的程序，它是为利用如对象导向设计与程序写作方式等现代化开发方式的桌面型client/server项目所设计的，不过也可以方便地用在以传统开发方式和大型主机进行的基础上上。这个规划方式是为预期在3-18个月以3-25人的团队规模完成的基础上所设计的。这样的基础上可说是个中型项目。如果你的基础上更小些，你可以自行斟酌本书中建议的做法(我在本书从头到尾都会指出哪些做法是你能斟酌选用的)
本书主要是为那些正在规划阶段的基础上所写。如果你才刚开始执行项目，你可以将本书的做法作为项目规划的基础，如果项目已经进行到一半了，第二章中的求生测试和每一章末尾的求生检查会帮你找出项目的成功率。
这本书的规划本身对应付生命与案例要求苛刻的系统还不够正式或严格，它适用于商业应用与事务软件的开发上，而且显著改善了许多目前已经使用的并且以百万美元为成本单位的基础上计划。
给进阶技术读者的说明
本书描述一种有效进行软件项目管理的方法，这方法不是惟一的，而且对任何一个特定项目都可能不是最好的。有独特见解的技术主持人通常能够想出比本书所提到的通用规划方式更好。更完善、更独到的开发计划。不过本书中提到的规划方式总比临时救急或是完全毫无头绪的做法要强多了。尤其当"完全零规划"是最常见的情形时。
本书中所述的规划方式用来针对软件项目中最常面对的那些弱点，大致依据软件工程协会在SEI能力成熟模型第二级中指出的"关键程序"而来，SEI将这些关键程序当成让组织符合时间表、预算、质量与其他目标的关键要素。所有组织有约85%的表现都在第二级之下，这份规划方式会大大改善这些组织的表现。
软件工程协会将第二级的关键过程定义如下：
项目规划
需求管理
项目执行与监督
结构管理
质量确认
分层管理
本书主要是针对分层管理以外的其他项目。
……
微软项目求生法则 本书目录
第一篇 求生心态
第1章 欢迎来到软件项目求生训练中心
求生需求
求生权利
求生检查
第2章 软件项目求生测验
求生测验
求生测验的评分
求生测验的说明
第3章 求生概念
"开发程序"的威力
上下游
第4章 求生技能
规划
软件规划的例子
规划审查
风险管理
项目控制
项目洞悉力
人因工程
使用者参与度
产品简化主义
焦点放在推出软件
第5章 看看成功的项目
思考阶段
项目流程
规划阶段
汇聚人力
程序代码增长曲线
主要完成点与推行点
第二篇 求生准备
第6章 命中移动目标
变动管理程序
变动管制益处
一般变动管制问题
交付变动管制
第7章 初步规划
项目目标前景
主持推动权
项目规模目标
公开规划与进度
风险管理
细节风险管理规划
匿名风险反馈通道
人事策略
时间管理
软件开发规划
第8章 需求开发
需求开发概览
需求开发程序细节
第9章 质量保证
质量为何重要
品管规划
缺陷追踪
技术检查
系统测试
Beta版公开测试
品管规划涵盖的工作成果
支持活动
第10章 构架
缓缓进入构架阶段
良好的构架的特色
如何分辨构架完成与否
软件构架文件
第11章 最后准备
项目预估
阶段性完成规划
持续规划工作
第三篇 逐步迈向成功
第12章 阶段的初步规划
为何要进行阶段规划
阶段性规划概要
阶段里程碑
阶段规划与管理风格
第13章 细节设计
重新检查构架
一个项目需要多少细节设计工作
技术检查
细节设计文件
第一个阶段的特别考虑
第14章 构建过程
源代码质量
软件整合程序
每日整建与冒烟测试
进度追踪
每周更新项目进度追踪
控制变动
保持焦点
这就是构建过程中所有要做的事情
第15章 系统测试
测试哲学
测试小组对每日整建的帮助
第16章 软件开发
严肃看待发行工作
何时发行
发行检查清单
发行认可文件
第17章 阶段完成记录
总结更动会议
估计修正
对项目规划的评估表现
项目文件保存
更新项目记录
第四篇 完成任务
第18章 项目历程
汇集项目资料
软件项目历程文件
准备未来项目使用的项目历程结果
散发软件项目历程的复制文件
第19章 求生小技
NASA的成功检查清单
其他求生资源
参考书
网络资源
尾声
微软项目求生法则 文章节选
多年来，软件工业的高层人士对软件项目的要求总是爱之深。责之切。一个成功的项目应该尽可能满足成本与时间的需求，以追求高质量的产品为目标，不要瞻前顾后。确定了这点，就现阶段的技术还可以控制在百分之十上下的水准。一般的软件项目主管都可以做得到，即使是项目外的其他人，如高阶主管、经理、客户、投资人和使用者代表一样可以发挥相同的影响力。
一名Construx software Builders的首席软件工程师请我去看他们一些失败的案例。在专家眼里，失败的原因通常很明显。中型软件项目的失败(20000-250000行源代码)其实很容易避免。此外我发现软件项目不是不能达到最短时程、最低成本。最佳质量或任何其他目标择一力臻完美。
并非以上所有目标都能同时完成，本书想要告诉大家的是力求在众多目标之间取得平衡，让一个低成本而高质量的产品能如期推出。
求生需求
软件项目求生第一步就是确认生存的基本需要。Abraham maslow观察出人类的需求依照程度由低到高，以自然阶层的形态呈现，最低程度的需求称作"生理需求"。这是人类生存所必需的最低要求。在我们满足上层的需求前，必须先满足图中的虚线以下部分的软低程度需求。所以要先满足对食物、空气、水的生理需求之后，我们才能够追求"归属感"与爱自尊与自我实现的满足。
如同许多软件专家一样，我发现类似的需求阶层也可以套用在软件项目上，软件项目有一组斟酌需求必须先被满足，逐步攀爬到需求金字塔的上层，就可以大幅改善项目的质量与生产力。
项目团队必须满足"一定会完成项目"的最低层次需求，接着再来考虑有关时间和预算目标百分之十上下的问题，而且项目小组必须在有限的预算和时间之内，以现有的技术水准，努力推出预定计划中的最佳软件。
软件项目的需求阶层与制作项目的个人需求大相径庭，举例来说，开发人员会将他们的个人自尊摆在健全的团队动力之前，但就项目而言，健全的团队动力要比开发人员个人自尊更重要。
本书针对软件项目需求中下阶层的部分讨论，只要当上层需求的方向影响下层需求的满足时，才会提到上一阶层的部分。
求生权利
处境艰难的项目威胁到各相关人士的生存需求，客户担心项目到底不能推出，结果会不会太慢或太贵。主管担心客户会不会取消项目导致失败，或者开发人员能不能够完成，开发人员担心他(她)会不会丢掉饭碗，或是被迫牺牲数百上时的休闲时间表示他(她)真的全心投入工作了。每一种情形，每个人都退回到项目需求阶层的最底层部分----担忧是否满足他们个人承诺的安全需求，这样的反应反而让他们放弃追求金字截上层可达成最高质量与生产力的东西。
……
