标签：
《人月神话》读后感
第一次听到 《人月神话》这本书的名字时看上去带有浓重的神话色彩，我也就认为这是一本神话故事，课打开书后我才知道与我所想象的截然相反，而作者想要表达的意思是在软件开发项目上项目进度和增加人员这两个概念是不能互换的相关原理。
在软件领域，很少能有像《人月神话》一样具有深远影响力和畅销不衰的著作。Brooks博士为人们管理复杂项目提供了最具洞察力的见解，既有很多发人深省的观点，又有大量软件工程的实践。本书内容来自Brooks博士在IBM公司SYSTEM／360家族和OS／360中的项目管理经验，该项目堪称软件开发项目管理的典范，使它确立了其在行业内的经典地位。初版的20年后，布鲁克斯重新审视了他原先的观点，增加了一些新的想法和建议。新增加的章节包括：原著中一些核心观点的精华；在经过了一个时代以后，Brooks博士对原先观点新的认识；1986年的经典文章《没有银弹》；对1986年所下论断（在10年内不会出现银弹）现在的认识。
或许是因为书名的缘故，我对这本书产生了浓厚的兴趣，我想通过度这本书想要知道作者问什么给这本书去这样的名字，我也试着用自己的方法来阐释这本书的名字，我个人认为“人”应该代表软件开发的人群，“月”代表着软件开发所需要的时间，人月之所以不能成为神话，正是因为增加人手的同时也增加了人与人之间的交流，有些是不能明确说出功能列表的; 有些则是没有能力知道开发中可能遇到的障碍点在哪里的; 有些则不知道团队人员的真正能力的; 更有些是集以上之大成的. 在有些时候, 我也是其中的一员说到这里, 要说一下人月神话，我们所有的进度都是以人月代码产量来衡量的，而增加"人"并不能缩短"月"的量。
它之所以能称之为经典是因为本书有其重要的贡献，深深的影响了我们的思维和意识，主要贡献在于对软件开发过程的几个重要关键点，提出了独到的见解：
包括以下几点
（1）提倡外科手术式的团队组织：
在软件开发组织上的过份民主，往往带来的是没有效率和责任，参与其中的人想法太多，层面参差不齐。所以，软件开发的组织，应该借鉴外科手术式的团队方式，有一个主要的负责人，其他人都是分工协作的副手，这样效率最好，结果最好。
（2）软件项目的核心概念要由很少的人来完成，以保证概念的完整性：
少就是多，项目的定位需要和功能多少的权衡。太多的想法，使项目没有焦点，什么都要放进去，结果什么都做不象；
（3）软件开发过程中必要的沟通手段；
软件开发中最大的风险往往不是技术的缺陷，而是缺少沟通；
（4）如何保持适度的文档：
在开发中，保持适度的文档。喜欢过度多的文档的人，忘记了文档不是最终的产品，不是用户需要的，最后以为文档好，就是好的开发，其实完全不是。
（5）在软件开发的过程中，只有适度改进，没有包治百病的银弹。
在软件开发的过程中，重要的不是采用了什么工具，而是不论用何种工具，都要达到项目本身的客户需求。任何方法论之前，先要探求问题的来源，否则，对各种方法论的依赖或滥用，有害无益。
这本书中对我启发最大的就是有关使用专业和高级的工具未必就能提高工作效率和质量，这一点对我有很大的惊醒作用。我往常还是很迷信这些一些好的工具和好的制度，以为有了这些，整个流程，所有工作都可以正规起来。现在想想，实在是没有必要。如果要提高工作质量和效率，正确的方法是逐步解决工作中存在的问题。往往一些小的管理技巧要比复杂的软件和制度来的有效，简单的Word+Excel+PPT用的好了不比高级的管理软件差。
标签：
原文地址：http://www.cnblogs.com/xiangwo/p/4307311.html
