利用平时坐公交和火车的碎片时间，把这本书看完了，记得刚学编程时，有很多搞IT的朋友都推荐我看看这本书，这也是我读这本书的动机，读完了后也学到了很多软件开发和项目管理的知识，但是没有感受到醍醐灌顶的感觉，有些内容还不是很理解，可能是我相关的项目经验太少的缘故吧，不过既然读完了，就做一下总结吧，也许等若干年后当我再次读这本书时，感觉就完全不一样了。

焦油坑

• 编程系统产品的工作量是独立开发的程序构件的9倍，构件的产品化是原来开发构件的3倍，构件产品整合到系统中又3倍

人月神话

• 时间进度安排的不合理是项目滞后的最主要原因
• 保质保量开发一个软件是需要一定的时间的
• 程序员都是乐观主义者，软件总会有Bug
• 人员数量和时间无法替换，一个项目滞后以后更多的人来“帮忙”只会更加滞后，软件开发过程中培训和沟通交流的时间成本是很高的
• 项目进度安排比例：策划1/3 1/6编码 1/4构件测试 1/4系统测试

外科手术队伍

• 优秀程序员的生产率是一般程序员的10倍
• 小型精干的团队是最好的
• 对于大型的系统，小型精干的团队速度太慢了
• 类似外科手术的团队能很好解决大型系统开发的问题

贵族专制 民主政治和系统设计

• 概念完整性是系统设计中最重要的因素
• 为了保证概念完整性，设计必须由一个人或一个小型的团队
• 软件开发要实现设计和具体实现的分离
• 限制和规则能激发创造性
• 概念统一的系统能更快的开发和测试

画蛇添足

• 不要过分设计

贯彻执行

• 设计必须由一个或两个人负责，确保设计的一致性
• 具体精确的定义系统和功能

为什么巴比伦塔会失败

• 失败的原因：交流
• 团队应该尽可能多的交流
• 制定良好的工作手册
• 每一个团队成员都应该能看到所有材料
• 每个团队两个领导，技术负责人和产品负责人

胸有成竹

• 仅仅靠编码时间乘以系数是无法得到完成时间的
• 小项目的数据不适用于大项目，开发时间随项目大小呈指数增长
• 使用高级语言的效率是使用汇编语言5倍

削足适履

• 控制规模，精简系统功能
• 从系统出发，面向用户

提纲挈领

• 文档的关键，目标，用户手册，内部文档，进度，预算，组织结构图和工作空间分配
• 为每个关键文档提供状态监督和语境机制
• 项目经理的职责是使每个人都朝着同一个方向前进
• 项目经理的日常工作是沟通而不是做决定

未雨绸缪

• 开发人员交付的是用户满意度而不是实际的产品
• 用户的实际需要会不断变化
• 前进两步，后退一步，维护会增加系统的复杂性和引入新的Bug

干将莫邪

• 项目成员要使用通用开发工具

整体部分

• 有时必须推翻顶层，重新开始

祸起萧墙

• 项目进度的落后是潜移默化的，因此必须设置阶段目标

另外一面

• 文档很重要，不论程序员还是用户
• 自文档化技术，文档编写要和源代码结合起来，文档以注释的形式存在

人月神话.png