人月神话读后感（通用五篇）

　　人月神话读后感 篇1

　　最近读了一本书《人月神话》，这本书是软件工程类的一本经典著作。阅读这本书的第一感受就是感觉这本书不像是一种和学习相关的书，更像是用很多形象的比喻，阐述项目管理当中的一些问题，让读者能够很轻松，明白的去阅读。

　　一般在大学学习计算机行业的时候，都会学习一门叫做软件工程的课程，老师也会跟我们讲一些关于“软件项目开发的完成与增加人员的问题”，在读这本书的时候，这个问题给了我很大的感触。很多人认为，当任务在规定期限内还完成不了的时候，适当的加一些人员进去，可以加快任务的进度，从而能够在规定的时间完成任务。但是这个观点在软件工程当中是不适用的。这也是我在阅读完《人月神话》这本书时最大的感受。

　　这本书的第二章就讲述了人月神话的关系，完成工作的人数和时间是不能进行简单的互换的。因为新加入的人对原有的项目不了解，需要花时间培训，读后感交流，同时新人也有可能对原有的设计有不同的意见，这些都会导致任务的进度大打折扣。“向进度落后的项目中增加人手，只会使进度更加落后”，是这本书作者布鲁克斯得到的结论。

　　我觉得开发一个软件，要有合理的时间进度安排，项目开发的人员少而精，团队开发之前要提前交流，开发的时候要持续的沟通，合理的分配任务工作。所有只有在一个团队沟通了解，通力协作和努力下，才能更好的完善项目。

　　人月神话读后感 篇2

　　《人月神话》这本书风行已经很久了，写成于1975年，经历这么久的时间，在当前又重新流行，让我很惊讶,但是一直没有时间读。今天突然想起自己的机器上有本拷贝别人的电子书，决定读读。我今天只看了两章，即焦油坑和人月神话。

　　人月神话看上去这么浪漫的名字，原来并不是真的说神话故事，作者阐述的主要观点是在软件开发项目上项目进度和增加人员这两个概念是不能互换。虽然已经时隔20多年了，这本书依然给我震撼，一是让我惊讶的是，美国20年前软件项目所面临的问题，在我们现在依然如此，糟糕的情况没有改变，大家仍旧在焦油坑里挣扎，而且看上去没有解决办法。二是作者对软件项目失败的总结，每一个问题我们依旧再犯，特别读到“是当意识到进度的偏移时，下意识（以及传统）的反应是增加人力。

　　这就像使用汽油灭火一样，只会使事情更糟。越来越大的火势需要更多的汽油，从而进入了一场注定会导致灾难的循环。“，我对这句话简直是太有感触了，因为我身边这样的悲剧整天都在上演，公司对所有的项目搞得都是人海战术，进度没有提前，还整天加班，最后用户不满意，开发人员整天郁闷，结果是用户对公司失去了信任，成了一槌子买卖，开发人员就像割韭菜，旧人一一辞职，新人天天引进，公司何谈发展和积累，做了n年，涛声依旧，做法没有改变，情况没有改观，公司没有发展，好在中国人多地大，呼悠完一个行业，再呼悠另一个行业。三是作者在那个时候，就根据自己的经验提出了对于软件任务的进度安排，以下是作者使用了很多年的经验法则：1/3计划1/6编码1/4构件测试和早期系统测试1/4系统测试，所有的构件已完成我们公司是通过cmm3认证的，理论不用我说，大家好像都明白，实际情况呢，有谁真的拿出那么多时间作计划，又有谁拿出那么多时间作测试，不过令人欣慰的是，大家确实在向这方面改变，比如我们公司测试部现在就是一个很大很关键的部门，所有的程序发布都需要测试人员的签字。

　　当然，也许可以找点客观原因，比如现在国内多数客户不成熟，签单子靠关系，一旦签了又恨不得明天就正式运行，但是本着“没有任何借口”的观点，我们该怎样改进呢，我决定读下去，看看能否找到作者所说的银弹呢。

　　人月神话读后感 篇3

　　当我捧起《人月神话》，马上就被深深的吸引了。书中很多细微之处都对我的思维造成了冲击。已经很久没有看到这么好的书了，郑重推荐。

　　把感触比较深的几点记下来，顺便整理一下自己的思路，与大家分享。

　　1，保持设计的概念完整。无论对小软件还是大软件，都必须由一个设计师主导，最多两个人讨论来共同完成软件的整体设计。作为一个软件，一个系统，必须有一个清晰明确的概念模型，大家都在这个框架下工作，所有的创新发展都必须与基本的概念相吻合。具体的实现人员可以细化概念，但只有总设计者才有否定与发展基本概念的权力。需要注意的一点是，即使是总设计师一直是同一个人，他脑海中所认为理所当然的规则或者概念，很可能由于没有明确的文档化，而没有成为所有开发者共同的概念。在其他开发者编码的时候，就可能会生成与概念相抵触的东东（模块，功能，算法），导致整体结构的恶化。这个时候总设计师一定要即时发现，做出更正。

　　概念的完整性，对于很多小规模软件，由于开发人员不多，开发经理一般都能控制住所有的代码，概念完整性在组织层面就维持住了。但要注意以后的Bug修改，功能扩展的时候，也要时刻留意与最初的设计是否概念上相容。对于大规模的软件系统，则必须通过树状组织结构，层层控制，总设计师还是一到两人，每一层都有对下层的绝对把握能力。我以前参加过一个15人左右的项目组，就是分为两层。感觉整体概念完整性的控制效果还不错。我没有更多人数项目的具体实践经验，希望以后能有机会参与比较大的项目。

　　2，“一个拿2倍工资的人，生产率可能是其他人的10倍。”我和我的同学，一个小公司的技术总监聊起这个，他也是十分的认同。不知道其他公司的程序员们如何看。我的同事中有一个牛人，做出的贡献特别大，应该相当于我们公司普通的十个程序员，不过工资最多也就是普通程序员的二倍。是不是有些不公平呢？我也说不清楚。因为那些普通程序员也十分的努力。不过，我觉得，作为公司，应该给最好的人最好的待遇，或者说给比目前更高的待遇。

　　组建一个团队，最好的就是那种精英团队，大家都是牛人，效率会特别高。微软就是这种思路吧，把最聪明的人集中在一起，想不都难亚。

　　3，进度落后与增加人力。记得当年看《C＋＋编程思想》，Bruce说“十个妇女不能在一个月内生下小孩”（大意），于我心有戚戚焉。而本书作者Brooks得出的结论是对我是震撼性的：“向进度落后的项目中增加人手，只会使进度更加落后”。

　　以前，增加人手基本是挽救进度落后项目的主要办法。这个办法行不通的话，难道只有“加班”一条路了？但长期加班是对个人的摧残，我更愿意利用业余时间去看书，例如看这本“人月神话”。）

　　如果不想加班，不想削减功能，不想推迟发布日期，那么……唯一的`方法还是只有…加人。加足够的人。而且不要逐步加入，一定要一次性加入。要小心的是，新加入的人可能对原来的组织造成冲击，或者对原来的设计有不同意见（特别是加入的人中有比较强大的设计者）。那么，就当作，新组建了一个团队吧。交流，培训新人，就设计达成一致，继续向者目标前进。

　　感触还有很多，以后如果有机会再写。不过，我决定去买本英文版回来，收藏，以后再多看几次。

　　人月神话读后感 篇4

　　人月神话这本书几年前就听别人说是本很经典的软件开发方面的书，这本书的成功之处在于他思想的前卫性，以至于不只是软件行业的人在读。现在终于找到读他的理由了，可以感受一下大师的杰作。在读之前我已经读过了软件工艺和极限编程，为什么留到最后读人月神话呢？主要是因为我觉得一本能够流传30年还被人们津津乐道的书，肯定是本学要好好细读的书，所以留到了最后。按照前两篇读书笔记的惯例，前面几段是一些我读书时的感受和收获，还有一些对内容的评价。

　　从这本书的内容来看，对于一个项目经理来说肯定会有更大的收获，这本书主要是针对软件开发管理方面的内容，这主要原因可能是因为作者以前就是项目的管理者，他是站在管理者的角度写的。即便这样，对于一个从来没有参与过真实项目开发，更没有领导过团队的我还是有一定的吸引力，这本书中我最喜欢的就是前四章（焦油坑、人月神话、外科手术队伍、贵族专制、民主政治和系统设计）和没有银弹这章。这本书里面为了论证某一观点，会举出许多实际的项目作为证据，这一点非常好，事实胜于雄辩嘛！这些例子也许对于作者那个年代的人来说很好理解，但是放在30年后来看这些例子又有些陈旧和难懂了。另外，从文中我发现作者非常注重文档，一个优质的文档就是项目成功的保证，这一点与传统的软件工程很相似，但是却与极限编程的观点相悖。

　　人月神话读后感 篇5

　　《人月神话》是预言了未来还是扼制了未来?

　　事实是：我们目前的许多工程知识，——无论是从书上看到的，还是从实践中经验到的——大多未曾脱离《人月神话》之所言，人月神话读后感。

　　我在开篇中说《人月神话》“是一本可怕的书”。然而我感受恳挚的可怕之处在于：现今凡是论及工程(且不要让人感受是离经叛道)，那么所解说的定然是Brooks的这么的经验以及由此推出的见解，可能在不违拗这些经验和见解上的一些翔实的实作措施!我们全然不顾书中所言是假象，还是性质的推论，可能只是假象归纳的一个(未必准确的)答案。尽管这些答案大多数时候都好像预期地展目前你的切实工程中：

　　原文中还有众多相仿的见解、假象和答案，都成为了切实工程中的既存假象。先民们所说的圣人以及通神者，皆因他们多数时候在准确地预言自己的切实。只有当这个“多数时候”变成半点的时候，先民们才会置疑圣人和通神者的力气。其实我们懂得并未曾预言未来的人，大多数时候是两种情形导致的假象。