人月神话的读后感(优质5篇)

在观看完一部作品以后，一定对生活有了新的感悟和看法吧，为此需要好好认真地写读后感。这时候最关键的读后感不能忘了。那要怎么写好读后感呢？以下是小编为大家收集的读后感的范文，仅供参考，大家一起来看看吧。

人月神话的读后感篇一

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

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

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

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

人月神话的读后感篇二

有一个人人皆知的故事，那就是《大禹治水》。这个故事让我很感动。

很久很久以前，黄河发生了一场特大水患。当时的部落联盟立即派鲧来治水，鲧用“堵”的方法治水，结果，用了9年的时间，却劳民伤财，让水灾闹的更严重了。

大禹治水的时候，曾经经过家门三次，可是他任凭儿子哇哇大哭，妻子声声呼唤，都从来都没有回家看一眼儿子和妻子。为什么他会三过家门而不入？是什么让他三过家门而不入？是他那颗爱国的心，是他那颗想把人民群众从水深火热之中解救出来的心，让他三过家门而不入。

大禹是一个公而忘私的人，是一个伟大的人！我们要学习大禹那种公而忘私的品质，作一个对社会有用的人！

人月神话的读后感篇三

本月阅读了该部软件工程巨著中第八章--胸有成竹(callingtheshot)，该章节讲述了软件开发中如何进行准确的项目预测和估算。

本章的标题是胸有成竹，而在开发中真正要做到成竹在胸就必须在项目计划阶段就要对项目的预测和估算都能准确把握。估算要做到准确就必须通过前期多个历史项目和版本的积累，同时通过历史版本和数据的积累来发现和预测指标y和相应的估算因子x之间的关系。其实也就是进行开发中的专家经验型估算。这样建立出来的估算模型就可以基本保证我们的估算准确性。

最早用的估算方法是建立需求--设计--编码--测试各个阶段工作量之间的比例关系，然后根据需求的工作量来推导其它各个阶段的工作量或者是根据编码工作量来反推上游各个阶段的工作量。这种方式在项目规模比较稳定的小型项目中是比较适用的，但是它不能简单的类比应用到大型软件项目中，因为随着项目规模的扩大，规模和工作量之间已经不是简单的线性关系了。在进行大型软件项目的开发中，要对整个项目做出准确的估算更显得困难。microsoft公司的windows开发就出现整体项目的'延期，而blizzard公司的项目延期就显得更加频繁。

根据nanus和farr在systemdevelopmentcorporation公司所做的研究表明，工作量和规模之间是1.5的指数关系，虽然软件产品规模的扩大工作量会成倍增加。工作量=常数×指令的数量)~1.5portman的数据表明，在每天8小时工作制的情况下，我们能够有效利用的工作投入时间在5-6小时甚至更低。因此我们在做估算的时候必须要考虑到开发人员每天的有效工作量的问题。

aron的数据表明开发人员直接的交互渠道和交互量直接影响到开发人员的平均生产率，我们强调沟通但是过多无效的沟通会直接影响到我们的效率。当在沟通和问题确认上浪费了我们太多时间的时候，开发的效率将会明显下降。

harr的数据表明确实存在不同程序类型复杂度完全不同的情况，比如对于控制逻辑程序，编译器程序复杂度远远高于应用软件程序。因此程序类型和复杂度的不同也将直接影响到开发效率。

corbato的数据得出更进一步的延伸结论：一、对常用编程语句而言，生产率似乎是固定的。这个固定的生产率包括了编程中需要注释，并可能存在错误的情况。二、使用适当的高级语言，编程的生产率可以提高5倍。

发表于@01月04日15：33：00|||

人月神话的读后感篇四

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

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

焦油坑1.编程系统产品开发的工作量是供个人使用的、独立开发的构件程序的九倍。

2.编程行业的一些内在固有苦恼：

l将做事方式调整到追求完美，是学习编程的最困难部分。

l由其他人来设定目标，并且必须依靠自己无法控制的事物。

l真正的权威来自于每次任务的完成。

l任何创造性活动都伴随着枯燥艰苦的劳动，编程也不例外

l人们通常期望项目在接近结束时（bug、工作时间）能收敛得快一些，然而软件项目的情况却是越接近完成，收敛得越慢。

l产品在即将完成时总面临着陈旧过时的威胁。人月神话1.缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加起来影响还大。

2.良好的烹饪需要时间，某些任务无法在不损害结果的情况下加快速度。

3.我们的构思是有缺陷的，因此总会有bug。

4.我们围绕成本核算的估计技术，混淆了工作量和项目进展。人月是危险和带有欺骗性的神话，因为它暗示人员数量和时间是可以相互替换的。

5.在若干人员中分解任务会引发额外的沟通工作量--培训和相互沟通。

6.关于进度安排，作者的经验是为1/3计划、1/6编码、1/4构件测试以及1/4系统测试。

7.因为我们对自己的估计技术不确定，所以在管理和客户的压力下，我们常常缺乏坚持的勇气。

8.brook法则：向进度落后的项目中增加人手，只会使进度更加落后。

9.向软件项目中增派人手从三个方面增加了项目必要的总体工作量：任务重新分配本身和所造成的工作中断；培训新人员；额外的相互沟通。外科手术队伍1.同样有两年经验而且在受到同样的培训的情况下，优秀的专业程序员的工作效率是较差程序员的十倍。关于这一条我在极限编程里看到，sackman和humphrey分别做了实验发现优秀程序员工作效率比较差程序员的工作效率最高要高达28倍。

2.小型、精干队伍是最好的。这一点在软件工艺和极限编程里都得到了充分的体现。

3.两个人的团队，其中一个项目经理，常常是最佳的人员使用方法。

4.对于真正意义上的大型系统，小型精干的队伍太慢了。

5.实际上，绝大多数大型编程系统的经验显示出，一拥而上的`开发方法是高成本、速度缓慢、不充分的，开发出的产品无法进行概念上的集成。

贵族专制、民主政治和系统设计1.概念完整性是系统设计中最重要的考虑因素。

2.为了获得概念完整性，设计必须由一个人或者具有共识的小型团队来完成。

3.对于非常大型的项目，将设计方法、体系结构方面的工作与具体实现相分离是获得概念完整性的强有力方法。

4.纪律、规则对行业是有益的。外部的体系结构规定实际上是增强，而不是限制实现小组的创造性。

5.体系结构、设计实现、物理实现的许多工作可以并发进行。画蛇添足1.尽早交流和持续沟通能使结构师有较好的成本意识，以及使开发人员获得对设计的信心，并且不会混淆各自的责任分工。

2.结构师如何成功地影响实现：

i.牢记是开发人员承担创造性的实现责任；结构师只能提出建议。

ii.听取开发人员在体系结构上改进的建议。

3.第二个系统是人们所设计的最危险的系统，通常的倾向是过分地进行设计。关于这一点也许是正确的，但是这是一个回避不了的问题，如果没有开发第二个系统经验的人，就不可能有开发第三个系统经验的人了。贯彻执行1.即使是大型的设计团队，设计结果也必须由一个或两个人来完成，以确保这些决定是一致的。

2.必须明确定义体系结构中与先前定义不同的地方，重新定义的详细程度应该与原先的说明一致。

3.出于精确性的考虑，我们需要形式化的设计定义，同样，我们需要记叙性定义来加深理解。

4.允许体系结构师对实现人员的询问做出电话应答解释是非常重要的，并且必须进行日志记录和整理发布。

5.项目经理最好的朋友就是他每天要面对的敌人--独立的产品测试机构/小组。为什么巴比伦塔会失败？1.巴比伦塔项目的失败是因为缺乏交流，以及交流的结果的组织。

2.因为左手不知道右手在做什么，从而进度灾难、功能的不合理和系统缺陷纷纷出现。由于对其他人的各种假设，团队成员之间的理解开始出现偏差。

3.团队应该以尽可能多的方式进行相互之间的交流：非正式、常规项目会议，会上进行简要的技术陈述、共享的正式项目工作手册。胸有成竹1.仅仅通过对编码部分的估计，然后乘以任务其他部分的相对系数，是无法得出对整项工作的精确估计的。

2.构建独立小型程序的数据不适用于编程系统项目。

3.程序开发与程序规模成指数增长趋势。

4.当使用适当的高级语言时，程序编制的生产率可以提高5倍。削足适履

这一章主要是要解决项目投资与磁盘空间和内存之间的矛盾，但是这个矛盾在电脑硬件发展到现在的层次已经可以忽略掉了。

提纲挈领1.软件项目的要求：目标、用户手册、内部文档、进度、预算、组织机构图和工作空间分配。

2.即使是小型项目，项目经理也应该在项目早期规范化上述的一系列文档。这一章强调文档重要性，但并没有将一些教条主义的道理让你相信文档的重要性，而是给项目经理给出了实实在在的操作步骤。

未雨绸缪1.对于大多数项目，第一个开发的系统并不合用。它可能太慢、太大，而且难以使用，或者三者兼而有之。系统的丢弃和重新设计可以一步完成，也可以一块块地实现。这是个必须完成的步骤，如果将开发的第一个系统丢弃原型发布给用户，可以获得时间，但是它的代价很高。对于用户，使用极度痛苦；对于重新开发的人员，分散了精力；对于产品，影响了声誉，即使最好的再设计也难以挽回名声。

2.用户的实际需要和用户感觉会随着程序的构建、测试和使用而变化。

3.软件产品易于掌握的特性和不可见性，导致了它的构建人员面临着永恒的需求变更。

4.目标和开发策略上的一些正常变化无可避免，事先为它们做准备总比假设它们不会出现要好得多。

5.对于一个广泛使用的程序，其维护总成本通常是开发成本的40％或更多。

6.维护成本受用户数目的严重影响。用户越多，所发现的错误也越多。

7.campbell指出了一个显示产品生命期中每月bug数的有趣曲线，它先是下降，然后攀升。

8.缺陷修复总会以（20－50）%的机率引入新的bug。

9.在每次修复之后，必须重新运行先前所有的测试用例，从而确保系统不会以更隐蔽的方式被破坏。

10.同样，设计实现的人员越少、接口越少，产生的错误也就越少。

项目经理应该制订一套策略，以及为通用工具的开发分配资源，与此同时，他还必须意识到专业工具的需求。

祸起萧墙1.一天一天的进度落后比起重大灾难，更难以识别，更不容易防范和更加难以弥补。

2.根据一个严格的进度表来控制项目的第一个步骤是制订进度表，进度表由里程碑和日期组成。

3.里程碑必须是具体的、特定的、可度量的事件，能进行清晰能定义。

4.如果里程碑定义得非常明确，以致于无法自欺欺人时，程序员很少会就里程碑的进展弄虚作假。另外一面1.对于软件编程产品来说，程序向用户所呈现的面貌与提供给机器识别的内容同样重要。

2.即使对于完全开发给自己使用的程序，描述性文字也是必须的，因为它们会被用户和作者所遗忘。

3.文档能在整个软件开发的生命周期对程序员克服懒惰和进度的压力起促进激励作用，但向编程人员成功地灌输对待文档的积极态度是一件困难的事情。

人狼的传说可能有人听过也可能没听过，人狼是一种具有人和狼两种特征的恐怖生物，而银弹是消灭它的一种最有效的子弹，如果看过《吸血鬼传说》也许就能和容易的理解这一点。作者将软件开发比作人狼，而将提高软件开发效率的方法比作银弹。作者预言未来十年，想要试图通过寻找一种有效地银弹将软件开发效率提高一个甚至几个数量级，这种银弹不可能出现。

没有银弹这篇文章里作者列举出了当时一些非常先进的技术或思想理念，例如ada和其他高级编程语言、面向对象编程、人工智能、专家系统、“自动”编程、图形化编程、程序验证、环境和工具、工作站等。虽然这些先进技术在一定程度上提高了软件开发的效率，但是始终没有达到银弹的效果。距离作者的预言已经过去有20多年了，纵观现在的软件开发领域，虽然新技术层出不穷，但是还是没有一种银弹能够让软件开发产生一次革命。

焦油坑依然存在

软件工程的焦油坑在将来很长一段时间内会继续困扰着人们。由于软件系统多变性和错综复杂性，这个行业只能是一步一个台阶的往上爬，而出现银弹的希望在我们可以想象的时间范围内是非常渺茫的。我们将长期与焦油作斗争。

人月神话的读后感篇五

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

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

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