人月神话读后感2000字
人月神话第五章读后感
人月神话第五章读后感这一章里啊，作者大谈特谈关于进度安排的那些事儿。
以前我总觉得，做项目嘛，只要人够多，时间就肯定能缩短。
就像搬砖，人多力量大，砖很快就能搬完呗。
但是这章就像是一盆冷水，直接浇灭了我这种天真的想法。
作者说人月这个概念其实很有欺骗性。
可不是嘛，一个人干一个月的活，和十个人干一个月的活可不一样。
就好比十个人一起做饭，可能光是协调谁切菜、谁煮饭、谁炒菜就得花不少时间，说不定还会因为想法太多，在厨房里打起来呢。
软件项目也是这样，增加人手不一定能让进度加快，反而可能因为沟通成本的增加，让整个项目变得更乱。
书里提到那些被乐观估计的进度安排，简直就像我每次减肥时给自己定的目标一样不切实际。
一开始总是信心满满，觉得每天少吃一顿饭，再加上点运动，一个月就能瘦十斤。
结果呢？三天打鱼两天晒网，还总是忍不住偷吃。
软件项目里那些拍脑袋定下来的乐观进度表，最后往往也是被各种意外情况打得落花流水。
什么需求突然改变啦，技术难题冒出来啦，就像减肥时突然遇到美食的诱惑一样，让人难以招架。
还有那关于里程碑的说法也很有趣。
就像是在漫长的旅途中给自己设几个标记点，告诉自己到这儿了就离目的地更近一步。
但是设里程碑也不是乱设的，不是随便在路上插个小旗就算数。
得是真正能检验项目进展、有实际意义的点才行。
这就好比减肥的时候，不能把每天称一次体重当成唯一的里程碑，而是得看体脂率有没有下降，能不能穿上小一号的衣服之类的。
这一章读完，我算是明白了，软件项目的进度安排就像一场精密的棋局，不是简单地把棋子（人）往棋盘（项目）上一放就了事的。
得考虑到各种因素，小心谨慎地布局，不然就等着被项目这个对手将一军吧。
《人月神话》读后感（五篇范例）
《人月神话》读后感（五篇范例）第一篇：《人月神话》读后感《人月神话》读后感在软件领域中,很少能有像《人月神话》一样具有深远影响力和畅销不衰的著作。
Brooks 博士为人们管理复杂项目提供了最具洞察力的见解,既有很多发人深省的观点,又有大量软件工程的实践,影响着一代又一代….《人月神话：软件项目管理之道》（英语：The Mythical Man-Month: Essays on Software Engineering）是由IBM System/360系统之父佛瑞德·布鲁克斯所著经典文集，全书讲解软件工程、项目管理相关课题，被誉为软件领域的圣经，内容源于作者布鲁克斯在IBM公司System/360家族和OS/360中的项目管理经验[2]。
该书于1975年首次发行（ISBN 0-201-00650-2），并于1995年重新发行纪念版（ISBN 0-201-83595-9），其中新增了对〈没有银弹〉一文的评论和回应，与4个额外的新章节。
书开始就形象有有趣的把软件危机比作：焦油坑 ========== 史前史中,没有别的场景比巨兽在焦油坑中垂死挣扎的场面更令人震撼。
上帝见证着恐龙、猛犸象、剑齿虎在焦油中挣扎。
它们挣扎...让我感觉到，软件开发过程中所遇到困难是多么的多，开发多么艰难。
当我看完《人月神话》突然感觉到这本书比《The Clean Coder: A Code of Conduct for Professional Programmers 》更完美，是为软件开发经验的天马行空总结。
比《Beautiful code》更为有远见，把我从充实代码的清晰简介升华，拓展到软件开发的高层度，一个周密，准确，明朗的开发需求分析，可行性研究，软件实现是软件开发的完美递进，他们相互辅助，相互促进，如海浪一层的推着前浪奔向远方，而《人月神话》如软件工程开发经济的精华，碧玉。
在《人月神话》面前《设计模式》、《原型设计》、《灵活软件开发》、《面对对象思维》、只不过是冰山一角。
《人月神话》读后感（第一二章）
《⼈⽉神话》读后感（第⼀⼆章）初次听闻《⼈⽉神话》这本书，我以为它会是⼀本讲述神话或者浪漫爱情故事的书，但后来在⽼师的⼝中才了解到，这讲述的并不是什么神话、爱情故事，⽽是⼀本有关软件⼯程⽅⾯的经典著作。
经过⽼师的推荐，我抱着试⼀试的想法阅读了这本书，虽然有很多地⽅还不太明⽩，但仍然收获了很多知识。
⽬前我只阅读了前两章，借此来谈⼀谈⾃⼰的收获以及感受。
书的前两章主要讲述了两个问题——焦油坑和⼈⽉神话。
在第⼀章中，作者将软件危机⽐作了焦油坑，谈到美国20年前软件项⽬所⾯临的问题，在我们现在依然如此，糟糕的情况没有改变，⼤家仍旧在焦油坑⾥挣扎，⽽且看上去没有解决办法。
过去⼏⼗年的⼤型系统开发就犹如⼀个焦油坑，很多⼤型企业在其中剧烈地挣扎。
他们中⼤多数开发出了可运⾏的系统。
不过，其中只有⾮常少数的项⽬满⾜了⽬标、时间进度和预算的要求。
各种团队，⼤型的和⼩型的，庞杂的和精⼲的，都⼀个接⼀个淹没在了焦油坑中，被软件危机所带来的灾难覆盖。
表⾯上看起来好像没有任何⼀个单独的问题会导致困难，每个都能被解决，但是当它们相互纠缠和累积在⼀起的时候，团队的⾏动就会变得越来越慢。
对于我们⽽⾔，如果我们想解决问题，就必须试图先去理解它，了解什么是编程系统产品，同时也要找到⾃⼰职业的乐趣，因为只有发现了乐趣，⼯作才会更有积极性。
在第⼆章中，我了解到原来“⼈⽉“是我们项⽬⼯程中估计和进度安排中使⽤的⼯作量单位，⽤⼈⽉作为衡量⼀项⼯作的规模是⼀个危险和带有欺骗性的神话。
它暗⽰着⼈员数量和时间是可以相互替换的但仅适⽤于某个任务可以分解给参与⼈员，并且他们之间不需要相互的交流的情况。
因为软件开发本质上是⼀项系统⼯作——错综复杂关系下的⼀种实践——沟通、交流的⼯作量⾮常⼤，它很快会消耗任务分解所节省下来的个⼈时间。
当任务由于次序上的限制不能分解时，⼈⼿的添加对进度不会有帮助。
虽然我现在只读了前两章，但同样拓宽了⾃⼰的视野，因此我决定继续读下去，继续探索软件⼯程的奥秘。
《人月神话》读后感
《人月神话》读后感
《人月神话》是一本经典的软件开发管理书籍，作者弗雷德里克·布鲁克斯通过讲述自己在IBM的项目经验，对软件开发过程中的一些问题进行了深入的思考和总结。
这本书虽然是在20世纪70年代写的，但其中的观点和原则在今天依然有着很大的启示意义。
其中最重要的观点之一是布鲁克斯提出了“带来人越多，项目越慢”的概念，即在一个软件项目中，添加更多的人力并不能加速项目的进展，反而可能会拖慢整个团队的工作。
这是因为在软件开发中，人力并不是可以无限量放大的资源，每一个新成员要花费一定的时间来适应项目的环境和沟通协调，而且不同成员之间的协作也可能会带来额外的沟通成本。
因此，布鲁克斯提倡在开发中尽量保持稳定的团队规模，并且强调进行好的项目规划和任务分配，以确保开发进展的高效和质量。
此外，布鲁克斯还讨论了关于项目中进度和质量的问题，他指出时间、人员、功能三者之间是有着天然的矛盾的，在面对这种矛盾时，项目管理者需要进行适当的取舍和折中。
他还提倡采取模块化的开发方式，将复杂的软件系统划分为较小的、可独立开发的模块，这样不仅能够更好地管理和控制开发过程，还能够提高开发的灵活性和可维护性。
总的来说，读完《人月神话》我深感布鲁克斯在软件开发管理方面的经验和思考是非常宝贵的。
他对项目管理、团队协作和开发流程的一些观点仍然非常适用，可以帮助我们更加有效地管理和组织软件开发项目。
这本书对于任何从事软件开发和项目管理的人士都是一本必读之作，我相信它会给读者带来很多启发和思考。
《人月神话》读后感二
《人月神话》读后感二不同的社会经验，不同的思想状态，对读本书的心得也不一样，我在此说说我的读后感，书中有许多非常好的观点，但我只把我感触最深的写下来。
这确实是一本很值得多次阅读的好书，每次阅读可能都能从中得到一些提示。
1.外科手术队伍The Surgical Team 项目经理在项目的初期必须清楚的估计项目的人月运作模式（时间、人力在项目各阶段的分配），例如什么时候需要出什么样成果，决定了什么时候需要什么样的人加入项目，这是项目经理的责任。
2.贵族专制，民主政治Aristocracy，Democracy，System 要获得概念的完整性，设计必须由一个人或具有共识的小组来完成。
有四个问题：1。
如何得到概念的完整性2。
是否要有一位杰出的精英，或者说是结构设计师的贵族专制.....3.如何避免结构设计师产出无法实现或代价高昂的技术规格说明，使大家陷入困境。
4。
如何才能与实现人员就技术说明的琐碎细节充分沟通，以确保设计被正确地理解，并精确地整合到产品中。
对1。
2。
4的回答基本上都可以找到，但第3个似乎找不到。
3.画蛇添足The Second-System Effect 讲述的基本都是基于IBM 360操作系统以及编译程序等方面的经验，讲述如何避免开发第二个系统的风险，作者认为开发第二个系统的设计师设计出来的系统是最危险的，因此要求他们自律。
4.贯彻执行Passing the word 印象比较深刻的是＂体系结构设计人员必须为自己描述的任何特性准备一种实现方法，但他不应该支配具体的实现过程。
＂5.为什么巴比伦塔会失败Why did the Tower of Babel Fail？讲述巴比伦塔会失败的原因是缺乏交流。
6.胸有成竹Calling the Shot 主要讲述如何计算编程时间，以及提出几个人的经验算法。
讲述的各种算法可能都不太适合与现在的高级语言，但Portman的观点仍然适合现在，即编程人员实际的编程时间只有50％，其他的时间都花在了无关的琐碎事情上。
人月神话读后感
人月神话读后感《人月神话》是一本由计算机科学家弗雷德里克·布鲁克斯所写的经典著作，书中以自身的亲身经历和观察为基础，探讨了如何管理和开发大型软件项目的一些重要原则和方法。
阅读完《人月神话》，我深深地被书中的观点和思考所震撼，对于软件开发和项目管理的理解有了更深入的认识。
书中，作者首先提到了“人月神话”这一概念，即认为增加人力资源可以缩短项目的进度。
然而实践中，情况却完全相反，项目反而更加拖延。
布鲁克斯通过数个实际案例说明了这个问题的原因，主要是因为沟通成本的增加和人员的组织问题。
他提出了著名的“布鲁克斯法则”，即“人越多，开发时间越长”。
作者还深入探讨了软件开发中的一些重要问题，如程序员的生产率、项目管理、团队组织等。
他认为，一名出色的程序员的价值相当于普通程序员的数十倍，而且编程工作的本质是创造性的工作，并不适合通过时间来衡量。
他提倡合理的工作时间，并强调了程序员的舒适度对于工作效率的影响。
在项目管理方面，作者提倡将项目分解成小的部分进行开发，并强调了需求分析的重要性。
他指出了软件开发中经常发生的需求变更问题，以及如何通过合理的时间规划和团队协作来解决这个问题。
他还对管理者的角色进行了深入的思考，认为管理者应该给团队提供清晰的目标和方向，并保持开放的沟通和透明的决策过程。
在书中，作者还介绍了一些关于人员组织和团队管理的经验和原则。
他认为，团队的成功不仅仅取决于个人的能力，更取决于人员之间的相互合作和协调。
他引用了傲慢者法则和思科系统的成功经验来说明团队合作的重要性。
他主张鼓励团队成员之间的交流和分享，提倡团队精神和集体创造，以实现项目的成功。
阅读完《人月神话》，我深刻地体会到了软件开发和项目管理中的一些重要规律和原则。
我认为，软件开发是一项复杂而创造性的工作，需要合理的时间和资源来完成。
而项目管理则需要合理的规划和组织，以及良好的沟通和协作。
只有通过合理的方法和思考，才能够提高软件开发的效率和质量。
人月神话读后感
人月神话读后感《人月神话》是一本由弗雷德里克·布鲁克斯所著的计算机领域经典著作，它深刻地剖析了软件开发过程中的种种困难和挑战，提出了许多颠覆性的观点和理论。
在读完这本书后，我深受启发，对软件开发这一领域有了更加深入的理解和认识。
首先，我被书中提出的“人月神话”这一概念所震撼。
在书中，布鲁克斯指出，增加人手并不能缩短软件开发的时间，反而可能会延长项目的完成时间。
这一观点颇具启发性，因为在我以往的认知中，增加人手应该可以加快项目的进度。
然而，书中通过实际案例和数据分析，清晰地展现了增加人手可能导致的沟通成本、协调成本和学习成本等问题，从而使得项目的进度反而受到影响。
这一观点对我来说是一种颠覆性的认知，使我对软件开发的管理和组织产生了新的思考。
其次，书中对软件开发过程中的种种挑战和困难进行了深入的剖析。
例如，书中提到了软件开发中的“二次系统效应”，即在开发过程中，随着系统的不断完善和修改，系统的复杂性会呈指数级增长。
这一观点让我对软件开发的复杂性有了更加深刻的认识，也使我意识到在软件开发过程中需要更加注重系统的设计和架构，以避免二次系统效应带来的种种问题。
此外，书中还提到了软件开发中的“饥饿艺术家效应”和“进度不良的现象”，这些都是软件开发过程中常见的问题，通过深入的剖析和分析，使我对这些问题有了更加清晰的认识，也为我今后在软件开发过程中避免这些问题提供了宝贵的经验和教训。
最后，我被书中对软件开发管理和组织的种种建议所深深吸引。
例如，书中提到了“参与式管理”和“集成式管理”等概念，这些管理理念都是为了解决软件开发过程中的种种挑战和困难而提出的。
通过对这些管理理念的深入剖析和分析，使我对软件开发管理和组织有了更加深入的理解，也为我今后在软件开发过程中的管理和组织提供了宝贵的经验和启示。
总之，《人月神话》是一本极具启发性和深度的书籍，它不仅为我对软件开发的认知和理解提供了新的视角，也为我在软件开发过程中遇到的种种挑战和困难提供了宝贵的经验和教训。
人月神话读后感2000字
人月神话读后感2000字第一篇：人月神话读后感2000字读《人与神话》有感翻开《人月神话》这本书的第一感受，感觉看这本书不像是在看一本和我们学的相关的书，书中用了很多的形象的比喻，来阐述项目管理中的一些问题，让人以很轻松愉悦心态去阅读。
书开始就形象有有趣的把软件危机比作：焦油坑。
史前史中,没有别的场景比巨兽在焦油坑中垂死挣扎的场面更令人震撼。
上帝见证着恐龙、猛犸象、剑齿虎在焦油中挣扎。
它们挣扎...让我感觉到，软件开发过的过程中，会有很多困难，很多的挑战。
看完此书后，我发现人月神话无处不在，其实在我们做软件工程来说，此书已经渗透进去了。
本书作者为人们管理复杂项目提供了颇具洞察力的见解，既有很多发人深省的观点，也有大量的软件工程实践。
大型编程项目深受由于人力划分产生的管理问题的困扰，保持产品本身的概念完整性是一个至关重要的需求。
《人月神话》探索了达成一致性的困难和解决的方法，并探讨了软件工程管理的其他方面。
的在刚刚进入软件工程学习时，老师就和我们说了一些关于“软件项目开发的完成与增加人员的问题”，这句话听起来通俗易懂，道理很简单明了，但实现起来却遇到了相当大的困难，这也是我在阅读完成《人月神话》时最大的感受。
全书的第二章说的就是人月神话的关系。
“一切都将运转良好”在软件工程中是不适用的；完成工作的人数与时间是不能进行简单的互换的，因为沟通需要额外的成本。
我想这种问题的出现主要是就订单项目而言，因为人员的增加主要是因为客户所要求实现的东西并没有在计划的时间内收到满意的答复和应得的功能与效益。
所以项目开发人员不断的增加，本书作者布鲁克斯得出的结论是显而易见的：“向进度落后的项目中增加人手，只会使进度更加落后”。
如果不想加班，不想削减功能，不想推迟发布日期，那么唯一的方法还是只有加人。
加足够的人。
而且不要逐步加入，一定要一次性加入。
要小心的是，新加入的人可能对原来的组织造成冲击，或者对原来的设计有不同意见，特别是我想如果如果有比较强大的设计者时就要当做新组建了一个团队。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
读《人与神话》有感
翻开《人月神话》这本书的第一感受，感觉看这本书不像是在看一本和我们学的相关的书，书中用了很多的形象的比喻，来阐述项目管理中的一些问题，让人以很轻松愉悦心态去阅读。
书开始就形象有有趣的把软件危机比作：焦油坑。
史前史中,没有别的场景比巨兽在焦油坑中垂死挣扎的场面更令人震撼。
上帝见证着恐龙、猛犸象、剑齿虎在焦油中挣扎。
它们挣扎...让我感觉到，软件开发过的过程中，会有很多困难，很多的挑战。
看完此书后，我发现人月神话无处不在，其实在我们做软件工程来说，此书已经渗透进去了。
本书作者为人们管理复杂项目提供了颇具洞察力的见解，既有很多发人深省的观点，也有大量的软件工程实践。
大型编程项目深受由于人力划分产生的管理问题的困扰，保持产品本身的概念完整性是一个至关重要的需求。
《人月神话》探索了达成一致性的困难和解决的方法，并探讨了软件工程管理的其他方面。
的在刚刚进入软件工程学习时，老师就和我们说了一些关于“软件项目开发的完成与增加人员的问题”，这句话听起来通俗易懂，道理很简单明了，但实现起来却遇到了相当大的困难，这也是我在阅读完成《人月神话》时最大的感受。
全书的第二章说的就是人月神话的关系。
“一切都将运转良好”在软件工程中是不适用的；完成工作的人数与时间是不能进行简单的互换的，因为沟通需要额外的成本。
我想这种问题的出现主要是就订单项目而言，因为人员的增加主要是因为客户所要求实现的东西并没有在计划的时间内收到满意的答复和应得的功能与效益。
所以项目开发人员不断的增加，本书作者布鲁克斯得出的结论是显而易见的：“向进度落后的项目中增加人手，只会使进度更加落后”。
如果不想加班，不想削减功能，不想推迟发布日期，那么唯一的方法还是只有加人。
加足够的人。
而且不要逐步加入，一定要一次性加入。
要小心的是，新加入的人可能对原来的组织造成冲击，或者对原来的设计有不同意见，特别是我想如果如果有比较强大的设计者时就要当做新组建了一个团队。
重新交流，培训新人，就设计达成一致，继续向者目标前进。
这也是造成项目延迟的原因之一。
软件开发的多少人参与和完成时间不成正比，过多的人参与并不一定能缩短开发时间。
如战争，部队多，人多并不是关键，更多需要武器的先进，战术，兵多后方便的补给就得多。
如是参与软件开发的人增加，软件的花费将提高，刚参加这需要时间了解项目，给软件管理带来了不协调。
在我们实际进行软件开发的时候，各个成员之间要做好沟通协调，一个人开发软件虽然完整性会很好，但是效率太低；相反，团队开发虽然效率很高速度很快，但是如果各个成员之前没有很好地团结协作，各自为战，那么最后的结果也一定不会尽如人意。
书中主要提到在项目管理方面可以看到项目估算，组织结构和人员角色安排，团队建设和沟通，历史数据积累和建模，软件开发方法论，风险和问题管理等相关的内容；在软件工程方面可以看到架构设计保证概念完整性，整体和部分，空间技能和程序结构的关系，产品集成的方法和消除缺陷的设计思路；在支持过程上我们可以看到文档和流程的建设，软件开发工具对软件开发过程的支持和效率的提升以及工具的选择等相关内容，回过来再看，发现书里面仍然大部分内容
涉及到了团队，人和沟通。
对于大型的软件工程项目仍然强调了人的重要性，在开篇就在讲开发人员的职业乐趣，后面又通过巴比伦塔讲沟通的重要性，在外科手术队伍中讲团队的组建和分工。
这些都涉及到了团队中的人和交互，只有一个有了积极心态和热情的沟通团队，才可能成就一个伟大的团队。
从最后的没有银弹，再次肯定了开发工作是一种高智力的脑力工作。
开发一个软件，我们要有合理的时间进度，开发人员要少而精，概念完整性必须考虑在内，要尽量做到尽早交流和持续沟通。
同时，文档形成了关键的枢纽，每个项目管理的工作都围绕着它们运转，它们是经理们的主要个人工具。
对于计算机硬件开发项目，关键文档是目标、手册、进度、预算、组织机构图、空间分配、以及机器本身的报价、预测和价格；对于大学科系，关键文档类似：目标、课程描述、学位要求、研究报告、课程表和课程的安排、预算、教室分配、教师和研究生助手的分配；对于软件项目，要求是相同的：目标、用户手册、内部文档、进度、预算、组织机构图和工作空间分配。
即使是一个小型项目，我们都会要求书写相关文档，对每个关键文档的维护提供了状态监督和预警机制并且本身就可以作为检查列表或者数据库。
良好的工作手册和组织架构可以开发出更加符合用户的需求。
手册、或者书面规格说明，是一个非常必要的工具，尽管光有文档是不够的。
手册是产品的外部规格说明，它描述和规定了用户所见的每一个细节；同样的，它也是结构师主要的工作产物。
一个软件的好坏不是说是由一个程序员决定的，往往一个很小的功能，其实也需要开发人员的架构设计方面的完善，对其它模块的影响及扩展,以及代码编写工作。
一个小小的bug，也许就需要好几个部门的分工协作。
原著中说，软件系统也是人类创造的错综复杂的事物。
所以只有在一个团队的沟通了解，通力协作和努力之下，才能做出更加完善的软件作品！。