人月神话摘要

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

焦油坑

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

人月神话

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

外科手术队伍

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

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

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

多此一举

• 不要过度设计

贯彻执行

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

为何巴比伦塔会失败

• 失败的缘由：交流
• 团队应该尽量多的交流
• 制定良好的工做手册
• 每个团队成员都应该能看到全部材料
• 每一个团队两个领导，技术负责人和产品负责人

成竹在胸

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

削足适履

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

提纲挈领

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

未雨绸缪

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

干将莫邪

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

总体部分

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

祸起萧墙

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

另一面

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

附上电子书连接：连接：http://pan.baidu.com/s/1bBfHk6 密码：cowm