《人月神话》是一本不可多得的软件工程方面的经典著作。作者是被誉为IBM 360之父的Frederick P. Brooks，他在此项目中担任项目经理。他也因此获得美国国家技术奖和计算机领域的“诺贝尔奖”-图灵奖。

我觉得本书语言风趣幽默又不失严肃严谨。尤其是在The Mythical Man-Month和Calling the Shot两章，诙谐的语句间穿插图表和数据，发人深思。

 　　书中给我印象最深的是Brooks提出这样一条定律。“所有的程序员都是乐观主义者，他们倾向于认为事情会如他们想象的那么顺利，而事实上并非如此。”我深刻的意识到，不管是学习中还是生活中，甚至是在工作中（还没经历过真正的工作），我们总是过于乐观。

　　就拿平时的学习，很多人上课不认真听讲，作业不认证完成，不把本节课讲的知识全部弄懂，而等到临近期末突击复习。而这样，往往事与愿违，并没有这么顺利，结果也可想而知。

工作中的例子，我也有一个体会。我曾经做过一个项目集成的兼职，大概一星期后整体验收，而当时车载监控的视频回传出了问题，我认为只是某个插头松了或者流量卡欠费了，一直拖到验收前一天下午才赶过去。弄了一下午，翻了无数遍技术文档，能查的都查了，怀疑设备过热，怀疑流量卡欠费，怀疑联通专线的问题……最后直到晚上10点，才发现上次防火墙配置的NAT没有保存，而前些天停了一次电，他们把ups还关了。

 　　Brooks又提出在软件开发中，软件开发的多少人参与和完成时间不成正比。对于完全可分解的任务，人越多，时间越短。对于无法分解的任务，人数和时间没有关系，此处举了一个很恰当的例子——母亲孕育生命。而软件开发，是错综复杂的任务。人员适当增加，时间减少，人员过多，时间增长。原因就是交流。

　　第七章写到，Why Did the Tower of Babel Fail，原因也是交流和组织。书中说缺乏交流的问题可以通过电话交流、定期的项目会议和一本共享的正式的项目工作报告书解决。有利于交流的组织方式应该是网状的，但是完全的网状结构因为交流量太大，也是不可行的。所以需要设计出特别的组织交流机制以克服结构的不足。

 　　最后，要保证一个项目的进度不被大幅度推迟，制订进度表很重要。进度表由里程碑和完成的时间组成。里程碑必须具体、明确的。某一里程碑要么到达，要么没有到达，不应该是90%到达的。书中说制订进度表非常重要，而且要求制定者有很强的技术背景，能对可能碰到的问题和可能花掉的时间做出准确的估计。而这些，都是通过经验累积起来的。

 　　我要把这些知识和启发，运用的我今后的学习和工作中。

读《人月神话》一书有感