软件研发之道 微软开发团队的经验法则PDF电子书下载

第一部分1995 2

简介 2

有关软件的思考 3

项目的阶段 6

开局阶段 7

组织 7

质保人员是“少数民族”吗 8

到底谁负责产品设计 8

经验法则1建立共同前景 9

经验法则2使大家主动投入 18

经验法则3制定多版本的技术计划 20

经验法则4不要认为别人是笨蛋 25

死亡行军 27

经验法则5搜集情报 30

经验法则6注意团队成员组成的比例 32

经验法则7组建功能小组 33

经验法则8项目经理的重要性 41

团队精神 42

经验法则9做权威，而非掌权者 44

竞争 47

人类学分析 47

软件竞争 49

经验法则10缺乏竞争对手？未必是好事 50

经验法则11与竞争对手不相上下？进行功能竞赛 52

经验法则12落后于竞争对手？更频繁地推出新版本 52

经验法则13领先于竞争对手？绝不放松 55

经验法则14紧跟潮流 55

客户 57

简单的购买模型 59

经验法则15让客户惊喜 60

经验法则16找到靶心 62

经验法则17与客户建立良好的关系，而不只是生意往来 63

经验法则18加快产品周期 65

设计 67

经验法则19追求伟大 67

经验法则20确定主题 68

经验法则21将依赖减至最少 70

经验法则22平息客户的抱怨 71

经验法则23软件的可移植性 71

经验法则24在设计阶段考虑时间因素 71

开发 73

经验法则25拒绝错误指示 75

经验法则26以游戏的心情开发软件 76

中期阶段 79

经验法则27像医生一样 79

经验法则28记住软件开发金三角：功能、资源和时间 82

经验法则29不要不懂装懂 84

经验法则30提交中间产品 87

经验法则31小心“闭门造车型”开发人员 91

经验法则32经常、定期构建软件产品 94

经验法则33始终完全了解产品的状态 97

掌握进度 98

经验法则34利用零缺陷里程碑 99

经验法则35一个也不能少，才算真的到达零缺陷里程碑 100

经验法则36完成每个里程碑后进行事后总结，但不要指责 101

经验法则37把握里程碑的字面意义与精神 101

经验法则38掌握什么是“正常的” 102

经验法则39里程碑的合理数目 107

经验法则40每一个小的里程碑都有专属的意义（故事） 107

经验法则41寻找自然出现的里程碑 109

经验法则42虽落后，别趴下 112

经验法则43不要落后多久就把原定日期延后多久 122

经验法则44延误了这个里程碑，一定要按时到达下一个里程碑 123

经验法则45从延误中学习经验教训 124

经验法则46要有全局观 124

经验法则47与时俱进 125

推出阶段 127

推出阶段：启动 127

推出阶段：移交 129

推出阶段：收尾 129

经验法则48关怀多于要求 130

经验法则49 Beta版不是修改产品的时候 131

经验法则50 利用Beta测试来调整宣传策略 131

经验法则51严格执行类选法 132

经验法则52小心保持软件的稳定 134

发布阶段 135

经验法则53伟大的软件应该有一个伟大的故事 136

经验法则54建立赢家形象 140

结束语 140

附录：聘用和留住人才 142

雇用聪明的人 142

适才适任 144

赛马必须奔跑 144

好高骛远者需要你的推动 145

软件开发领导的一些参考资源 150

第二部分2006 154

新的经验法则 154

经验法则55做完美的老板 154

经验法则56老板就是你最重要的客户 156

一种更好的方式 157

在如何看待老板上的转变 157

经验法则57支付木材税和下阿尔法赌注 159

阿尔法（或阿尔法能量） 160

The Core System V.3.0的元素 163

形成共同前景的4个步骤 164

第1部分：“签到”的元素 164

第2部分：决策过程的元素 166

第3部分：校正的元素 168

第4部分：共同前景的元素 169

The Core Protocols V.3.0 173

核心承诺 173

核心准则 174

放弃/取消放弃 174

签到 174

离开 175

求助 176

准则检查 177

目的检查 177

决策过程 178

解决 180

完美行动 180

个人校正 181

调查 182