人月神话这本书几年前就听别人说是本很经典的软件开发方面的书，这本书的成功之处在于他思想的前卫性，以至于不只是软件行业的人在读。现在终于找到读他的理由了，可以感受一下大师的杰作。在读之前我已经读过了软件工艺和极限编程，为什么留到最后读人月神话呢?主要是因为我觉得一本能够流传30年还被人们津津乐道的书，肯定是本学要好好细读的书，所以留到了最后。按照前两篇读书笔记的惯例，前面几段是一些我读书时的感受和收获，还有一些对内容的评价。
从这本书的内容来看，对于一个项目经理来说肯定会有更大的收获，这本书主要是针对软件开发管理方面的内容，这主要原因可能是因为作者以前就是项目的`管理者，他是站在管理者的角度写的。即便这样，对于一个从来没有参与过真实项目开发，更没有领导过团队的我还是有一定的吸引力，这本书中我最喜欢的就是前四章和没有银弹这章。这本书里面为了论证某一观点，会举出许多实际的项目作为证据，这一点非常好，事实胜于雄辩嘛!这些例子也许对于作者那个年代的人来说很好理解，但是放在30年后来看这些例子又有些陈旧和难懂了。另外，从文中我发现作者非常注重文档，一个优质的文档就是项目成功的保证，这一点与传统的软件工程很相似，但是却与极限编程的观点相悖。下面就是一些读书的总结了。
焦油坑 1. 编程系统产品开发的工作量是供个人使用的、独立开发的构件程序的九倍。
2. 编程行业的一些内在固有苦恼：
l 将做事方式调整到追求完美，是学习编程的最困难部分。
l 由其他人来设定目标，并且必须依靠自己无法控制的事物。
l 真正的权威来自于每次任务的完成。
l 任何创造性活动都伴随着枯燥艰苦的劳动，编程也不例外
l 人们通常期望项目在接近结束时能收敛得快一些，然而软件项目的情况却是越接近完成，收敛得越慢。
l 产品在即将完成时总面临着陈旧过时的威胁。 人月神话 1. 缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加起来影响还大。
2. 良好的烹饪需要时间，某些任务无法在不损害结果的情况下加快速度。
3. 我们的构思是有缺陷的，因此总会有bug。
4. 我们围绕成本核算的估计技术，混淆了工作量和项目进展。人月是危险和带有欺骗性的神话，因为它暗示人员数量和时间是可以相互替换的。
5. 在若干人员中分解任务会引发额外的沟通工作量--培训和相互沟通。
6. 关于进度安排，作者的经验是为1/3计划、1/6编码、1/4构件测试以及1/4系统测试。
7. 因为我们对自己的估计技术不确定，所以在管理和客户的压力下，我们常常缺乏坚持的勇气。
8. brook法则：向进度落后的项目中增加人手，只会使进度更加落后。
9. 向软件项目中增派人手从三个方面增加了项目必要的总体工作量：任务重
书香门第
