《人月神话》讲了什么
一开始我觉得这本书重点是在软件工程，但后来我觉得更准确的说法是，《人月神话》是讲软件工程中人与团队关系的。
一个由个人完成的“小”程序，和一个由团队完成的“大”程序，有根本性的不同，《人月神话》将讨论的是那些由团队进行开发的大型程序。另外，软件工程的项目管理也和其他类型的项目管理有很大不同，软件工程往往更复杂，存在很多“不可见”的东西。
这本书由于年代久远，部分所讨论的东西已经和现在有较大差异。不过还是有很多重要且并没有过时的道理，我将分章节记录下来。
需要说明：书的【第18章《人月神话》的观点：是与非】，也分章节做了概括性的观点，因此这篇读书笔记将与其类似。不过，这里我将从自己的角度去记录我最关心的内容。
第1章：焦油坑
大型系统开发就像一个焦油坑，很多强壮的动物都在其中挣扎。
如果将一个 “程序” 提升为 “产品”（意味着：通用化、测试、文档、维护）需要3倍的时间；如果将一个 “程序” 提升为 “系统”（意味着：接口、系统集成），需要3倍时间；而如果将一个 “程序” 提升为 “系统产品”，就需要9倍了。
第2章：人月神话
人月是危险和带有欺骗性质的神话，因为它暗示人员数量和时间是可以相互替换的。
沟通所增加的负担由两个部分组成：培训和相互的交流。
在众多软件项目中，缺乏合理的进度安排是造成项目滞后的最主要原因，它比其他所有因素加起来的影响还要大。
第3章：外科手术队伍
2万美元/年的程序员的生产率可能是1万美元/年的程序员的10倍。
小型、精干队伍是最好的——思绪尽可能少。
一位首席程序员、类似于外科手术队伍的团队架构提供了一种方法——既能获得由少数头脑产生的产品完整性，又能得到多位协助人员的总体生产率，还彻底减少了沟通的工作量。