利用平时坐公交和火车的碎片时间，把这本书看完了，记得刚学编程时，有很多搞IT的朋友都推荐我看看这本书，这也是我读这本书的动机，读完了后也学到了很多软件开发和项目管理的知识，但是没有感受到醍醐灌顶的感觉，有些内容还不是很理解，可能是我相关的项目经验太少的缘故吧，不过既然读完了，就做一下总结吧，也许等若干年后当我再次读这本书时，感觉就完全不一样了。
焦油坑
- 编程系统产品的工作量是独立开发的程序构件的9倍，构件的产品化是原来开发构件的3倍，构件产品整合到系统中又3倍
人月神话
- 时间进度安排的不合理是项目滞后的最主要原因
- 保质保量开发一个软件是需要一定的时间的
- 程序员都是乐观主义者，软件总会有Bug
- 人员数量和时间无法替换，一个项目滞后以后更多的人来“帮忙”只会更加滞后，软件开发过程中培训和沟通交流的时间成本是很高的
- 项目进度安排比例：策划1/3 1/6编码 1/4构件测试 1/4系统测试
外科手术队伍
- 优秀程序员的生产率是一般程序员的10倍
- 小型精干的团队是最好的
- 对于大型的系统，小型精干的团队速度太慢了
- 类似外科手术的团队能很好解决大型系统开发的问题
贵族专制 民主政治和系统设计
- 概念完整性是系统设计中最重要的因素
- 为了保证概念完整性，设计必须由一个人或一个小型的团队
- 软件开发要实现设计和具体实现的分离
- 限制和规则能激发创造性
- 概念统一的系统能更快的开发和测试
画蛇添足
- 不要过分设计
贯彻执行
- 设计必须由一个或两个人负责，确保设计的一致性
- 具体精确的定义系统和功能
为什么巴比伦塔会失败
- 失败的原因：交流
- 团队应该尽可能多的交流
- 制定良好的工作手册
- 每一个团队成员都应该能看到所有材料
- 每个团队两个领导，技术负责人和产品负责人
胸有成竹
- 仅仅靠编码时间乘以系数是无法得到完成时间的
- 小项目的数据不适用于大项目，开发时间随项目大小呈指数增长
- 使用高级语言的效率是使用汇编语言5倍
削足适履
- 控制规模，精简系统功能
- 从系统出发，面向用户
提纲挈领
- 文档的关键，目标，用户手册，内部文档，进度，预算，组织结构图和工作空间分配
- 为每个关键文档提供状态监督和语境机制
- 项目经理的职责是使每个人都朝着同一个方向前进
- 项目经理的日常工作是沟通而不是做决定
未雨绸缪
- 开发人员交付的是用户满意度而不是实际的产品
- 用户的实际需要会不断变化
- 前进两步，后退一步，维护会增加系统的复杂性和引入新的Bug
干将莫邪
- 项目成员要使用通用开发工具
整体部分
- 有时必须推翻顶层，重新开始
祸起萧墙
- 项目进度的落后是潜移默化的，因此必须设置阶段目标
另外一面
- 文档很重要，不论程序员还是用户
- 自文档化技术，文档编写要和源代码结合起来，文档以注释的形式存在
人月神话.png
