目录回到顶部↑
《软件研发之道:微软开发团队的经验法则》第一部分 1995
简介 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
第二部分
新的经验法则 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
