下载文档原格式
人月神话第五章读后感这一章里啊，作者大谈特谈关于进度安排的那些事儿。
以前我总觉得，做项目嘛，只要人够多，时间就肯定能缩短。
就像搬砖，人多力量大，砖很快就能搬完呗。
但是这章就像是一盆冷水，直接浇灭了我这种天真的想法。
作者说人月这个概念其实很有欺骗性。
可不是嘛，一个人干一个月的活，和十个人干一个月的活可不一样。
就好比十个人一起做饭，可能光是协调谁切菜、谁煮饭、谁炒菜就得花不少时间，说不定还会因为想法太多，在厨房里打起来呢。
软件项目也是这样，增加人手不一定能让进度加快，反而可能因为沟通成本的增加，让整个项目变得更乱。
书里提到那些被乐观估计的进度安排，简直就像我每次减肥时给自己定的目标一样不切实际。
一开始总是信心满满，觉得每天少吃一顿饭，再加上点运动，一个月就能瘦十斤。
结果呢？三天打鱼两天晒网，还总是忍不住偷吃。
软件项目里那些拍脑袋定下来的乐观进度表，最后往往也是被各种意外情况打得落花流水。
什么需求突然改变啦，技术难题冒出来啦，就像减肥时突然遇到美食的诱惑一样，让人难以招架。
还有那关于里程碑的说法也很有趣。
就像是在漫长的旅途中给自己设几个标记点，告诉自己到这儿了就离目的地更近一步。
但是设里程碑也不是乱设的，不是随便在路上插个小旗就算数。
得是真正能检验项目进展、有实际意义的点才行。
这就好比减肥的时候，不能把每天称一次体重当成唯一的里程碑，而是得看体脂率有没有下降，能不能穿上小一号的衣服之类的。
这一章读完，我算是明白了，软件项目的进度安排就像一场精密的棋局，不是简单地把棋子（人）往棋盘（项目）上一放就了事的。
得考虑到各种因素，小心谨慎地布局，不然就等着被项目这个对手将一军吧。
《人月神话》读后感（五篇范例）第一篇：《人月神话》读后感《人月神话》读后感在软件领域中,很少能有像《人月神话》一样具有深远影响力和畅销不衰的著作。
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字读《人与神话》有感翻开《人月神话》这本书的第一感受，感觉看这本书不像是在看一本和我们学的相关的书，书中用了很多的形象的比喻，来阐述项目管理中的一些问题，让人以很轻松愉悦心态去阅读。
书开始就形象有有趣的把软件危机比作：焦油坑。
史前史中,没有别的场景比巨兽在焦油坑中垂死挣扎的场面更令人震撼。
上帝见证着恐龙、猛犸象、剑齿虎在焦油中挣扎。
它们挣扎...让我感觉到，软件开发过的过程中，会有很多困难，很多的挑战。
看完此书后，我发现人月神话无处不在，其实在我们做软件工程来说，此书已经渗透进去了。
本书作者为人们管理复杂项目提供了颇具洞察力的见解，既有很多发人深省的观点，也有大量的软件工程实践。
大型编程项目深受由于人力划分产生的管理问题的困扰，保持产品本身的概念完整性是一个至关重要的需求。
《人月神话》探索了达成一致性的困难和解决的方法，并探讨了软件工程管理的其他方面。
的在刚刚进入软件工程学习时，老师就和我们说了一些关于“软件项目开发的完成与增加人员的问题”，这句话听起来通俗易懂，道理很简单明了，但实现起来却遇到了相当大的困难，这也是我在阅读完成《人月神话》时最大的感受。
全书的第二章说的就是人月神话的关系。
“一切都将运转良好”在软件工程中是不适用的；完成工作的人数与时间是不能进行简单的互换的，因为沟通需要额外的成本。
我想这种问题的出现主要是就订单项目而言，因为人员的增加主要是因为客户所要求实现的东西并没有在计划的时间内收到满意的答复和应得的功能与效益。
所以项目开发人员不断的增加，本书作者布鲁克斯得出的结论是显而易见的：“向进度落后的项目中增加人手，只会使进度更加落后”。
如果不想加班，不想削减功能，不想推迟发布日期，那么唯一的方法还是只有加人。
加足够的人。
而且不要逐步加入，一定要一次性加入。
要小心的是，新加入的人可能对原来的组织造成冲击，或者对原来的设计有不同意见，特别是我想如果如果有比较强大的设计者时就要当做新组建了一个团队。
人月神话读后感《人月神话》读后感《人月神话》是一本由弗雷德里克·布鲁克斯所著的软件工程领域经典著作。
这本书首次出版于1975年，至今已经被翻译成多种语言并广泛流传。
在这本书中，布鲁克斯提出了许多关于软件开发的观点和原则，对软件工程领域产生了深远的影响。
在读完《人月神话》之后，我深受启发。
这本书不仅仅是一本关于软件开发的著作，更是一部关于团队合作、项目管理和创新思维的指南。
布鲁克斯在书中提出了许多深刻的观点，让我对软件开发这个领域有了更深入的理解。
首先，我深受布鲁克斯关于“人月神话”的观点所感动。
在书中，他指出了一个常见的误区，即认为增加人手就能够加快项目的进度。
然而，布鲁克斯指出，人手的增加并不一定会带来效率的提升，反而可能会导致更多的沟通成本和管理成本。
这一观点让我深刻地意识到，团队的规模并不代表团队的效率，而是需要通过合理的规划和管理来提高项目的执行效率。
其次，布鲁克斯在书中提出了“二次系统效应”的概念。
他指出，当一个软件系统经过一次开发之后，随着需求的变化和新的功能的增加，系统的复杂度会呈指数级增长。
这一观点让我意识到，软件开发并不是一次性的任务，而是需要不断地进行迭代和优化。
只有不断地对系统进行重构和改进，才能够应对不断变化的需求和挑战。
另外，布鲁克斯还在书中提出了许多关于项目管理和团队合作的建议。
他强调了团队的沟通和协作的重要性，以及项目计划和进度的管理。
这些建议无疑对我在实际工作中的团队合作和项目管理产生了积极的影响。
我意识到，一个成功的项目不仅需要技术上的创新，更需要团队之间的有效沟通和协作，以及合理的项目规划和管理。
总的来说，读完《人月神话》之后，我对软件开发这个领域有了更深入的理解。
布鲁克斯在书中提出的观点和原则，让我意识到软件开发不仅仅是技术上的挑战，更是一个需要团队合作、项目管理和创新思维的领域。
我相信，这些观点和原则将对我未来的工作产生深远的影响，帮助我更好地应对软件开发中的各种挑战和问题。
人月神话读后感《人月神话》是软件工程领域的经典之作，作者弗雷德里克·布鲁克斯（Frederick P. Brooks Jr.）通过自己的实践经验，对软件开发过程中的一些误区进行了深入的剖析。
在阅读这本书后，我有以下几点感悟：1. 项目规模与团队规模的关系：布鲁克斯提出了一个著名的“人月神话”，即增加人力并不能缩短项目周期。
这一观点挑战了当时软件开发行业的普遍认识，强调了项目管理的重要性。
在实际工作中，我们应该关注团队的规模和效率，而不是单纯地增加人力。
2. 沟通与协作：书中多次强调了沟通与协作在软件开发过程中的重要性。
一个优秀的团队应该具备良好的沟通能力，能够有效地传递信息、解决问题。
此外，团队成员之间的协作也至关重要，只有大家齐心协力，才能完成高质量的软件项目。
3. 文档的重要性：布鲁克斯认为，编写高质量的文档是软件开发过程中不可或缺的一环。
文档可以帮助团队成员更好地理解项目需求、设计思路和实现细节，从而提高开发效率。
同时，文档也是项目交接和维护的重要依据。
4. 软件质量与测试：书中提到了软件质量的重要性，并强调了测试在保证软件质量中的关键作用。
一个好的软件项目应该注重测试，确保软件在各种情况下都能正常运行。
此外，测试也应该贯穿于软件开发的整个生命周期，从需求分析、设计、编码到维护，都应进行严格的测试。
5. 软件项目的风险管理：布鲁克斯指出，软件开发过程中存在很多不确定性因素，因此需要对项目风险进行有效的管理。
项目经理应该关注项目中可能出现的问题，并采取相应的措施进行预防和应对。
同时，团队成员也应该具备一定的风险意识，及时发现并报告潜在问题。
总之，《人月神话》这本书为我们提供了很多关于软件开发过程的宝贵经验，值得我们认真学习和借鉴。
在实际工作中，我们应该关注项目管理、沟通协作、文档编写、软件质量和风险管理等方面，努力提高软件开发的效率和质量。
《⼈⽉神话》读后感⼀《⼈⽉神话》这本书风⾏已经很久了，写成于1975年，经历这么久的时间，⼜被⽼师提出来让我们去读⼀下，⽼师明明是那种追求新技术的⼈,这让我⾮常的好奇，但是⼀直没有时间读。
直到最近，快开学了，才终于狠下⼼来把他看完。
也不能说看完吧，⼀知半解的，看了看。
觉得有⼀些疑惑，⼜去⽹上找来读后感读了读，虽然没有读懂，但是起码我觉得还好要写⼀点东西。
⼈⽉神话看上去这么浪漫的名字，并不是真的说神话故事，作者阐述的主要观点是在软件开发项⽬上项⽬进度和增加⼈员这两个概念是不能互换。
虽然已经时隔40多年了，这本书依然给我震撼.⼀是让我惊讶的是，美国40年前软件项⽬所⾯临的问题，在我们现在依然如此，糟糕的情况没有改变，⼤家仍旧在焦油坑⾥挣扎，⽽且看上去没有解决办法。
这就⾮常的让⼈绝望：所有的编程⼈员都有乐观主义，总是相信⾃⼰的代码是肯定能运⾏的。
所以在安排项⽬的进度的时候就会是假设在代码能够在正常运⾏时因该花费的时间。
⽽现实往往不是乐观，在项⽬的进展过程中会存在各种不可预知的问题。
在这个时候项⽬经理就会为项⽬增加⼈员，然⽽增加⼈员反⽽导致项⽬进度越来越慢。
因为新增加的⼈员还需要培训，需要时间去了解项⽬的内容和进展情况。
在投⼊了更多的⼈⼒的时候，经理发现项⽬进度反⽽更慢他就会投⼊更多的⼈⼒，这种恶⾏循环导致项⽬的失败。
那种认为⼤项⽬只是增加⾜够的程序员就能顺利完成，已经对于已经推迟的项⽬，只要增加⼈⼿就能按期完成的看法是错误和危险的，因为它假定⼈和⽉是可互换的，⽽其实将⼯作分割给许多⼈、培训和程序员之间的交流都需要额外的⼯作。
Brooks提出这样⼀条定律：给推迟的软件项⽬增加⼈⼿将使得项⽬更加推迟。
看起来这不是我们现在⾯对的问题，但是其实我们的⽼师之前也提出了要换⼈的想法，最后因为时间的原因⽽没有交换，这就是⼈和⽉之间的对⽴与不可交换性。
其实主要还是在于团队的磨合性上，我觉得这个可能会对我将来的⼩组开发作业有很⼤的帮助。
《人月神话》观后感由于自己修的是计算机专业，所以在业余时间读了计算机界的巨著—《人月神话》这本书。
我认为这本书的重要之处在于内容源于作者Brooks在IBM公司任System/360计算机系列以及其庞大的软件系统OS/360项目经理时的实践经验，而不是一位业外人士所写，具有真实性。
另外，IBM是一家全世界著名的公司，因此又具有典型性。
此外《人月神话》探索了达成一致性的困难和解决的方法，并探讨了软件工程管理的其他方面，为每个复杂项目的管理者给出了自己的真知灼见具有很好的借鉴意义，所以这本书风靡一时。
刚开始看到“人月”这两个字，我认为文章的用词一定很优美，其实不然。
看过之后，我认为它是本书的精髓所在，全书都在围绕它们进行创作。
我个人认为“人月”和物理中的“mAh”有相同之处，但又不尽相同。
和其它人类创造出来的事物一样，软件也有成本而”人月“恰恰就代表软件的成本。
衡量软件成本的两个重要因素便是人力和时间，和其它事物不同的是两者是对立的，不是相互促进的，增加人力投入并不能减少开发时间，在某些情况下反而会延长时间，得不偿失。
这部分指出以大量人员和较短的时间，并不能缩短软件的开发进度。
一窝蜂的作业方式不但无助于软件生产，而且会制造麻烦，产生出更差的软件。
向进度落后的项目追加人力，只会使进度更加落后，只会是火上浇油，越添越乱。
因为新进的人员需要时间了解整个项目，而增加额外的沟通消耗。
当有N 个人必须在这群人之中进行沟通时，当N 增加，其输出将抵消其效益，甚至倒退。
而mAh代表电池的容量，增加电流就会减少使用时间，这和人月是一样的。
第一章讲述了焦油坑的故事。
史前时代的焦油坑吞噬了成千上万个力大无穷的巨兽，今天的大型软件项目则令无数庞大的开发团队陷入无从逃脱的窘境。
同生态危机一样，软件开发也有危机，俗称软件危机。
通俗地说，就是软件开发时间，成本超出额定期限。
这给决策者带来巨大的挑战。
同时也可能造成社会人力资源的极大浪费，造成有付出没有收获的凄凉景象。
人月神话(40周年中文纪念版)读后感10篇《人月神话(40周年中文纪念版)》是一本由(美) 布鲁克斯(Brooks, F. P.) 著著作，清华大学出版社出版的平装图书，本书定价：68.00元，页数：392，特精心从网络上整理的一些读者的读后感，希望对大家能有帮助。
《人月神话(40周年中文纪念版)》读后感(一)：懷一個孩子需要九個月，無論你把任務分給多少個女人。
標題背後的意思很明確，就是說程序有著穩定的成熟期，並非人越多所用的時間就能夠越短。
軟件工程基本上可以說是“關係”科學，它的研究對象就是概念之間的關係和人與概念的關係，自有一套難弄的邏輯。
有時你要對付的不是什麼數學問題，而是你的同事或者看不見的同行，因為大家的努力，都用在彼此相容上，或者說，問題的關鍵，在於靈活性和紀律性之間的平衡。
這是一門至今混亂同時也變化多端的科學。
作者如同標題名言之外的另一條名言是“在延期的課題中加入人力只能讓它延遲更多”意即，一個延期的課題，往往比較複雜，修改很多，如果再有新人參與，合作會更加困難，短期之內看不到人力增加的效果，反而會因為配合問題降低效率。
軟件工程不僅會受到人的干預，技術開發還會明顯受市場左右，新技術往往要讓位給利益、技術和商業，往往遵循的是兩套邏輯。
《人月神话(40周年中文纪念版)》读后感(二)：神作！非常好的一本书！五星！神作！扉页上的数字表明，这本书购于2021.6，我足足看了1年3个月。
分了6个晚上，陆陆续续看完了。
一直拖着没看完，实因其中理论较庞杂，且时有妙语，细细品味为佳。
1975年写成的书，在40年后的今天大部分理论仍然适用，且不停被引用到项目管理，软件开发排期，编程语言的选择，组织结构的调整，增量迭代开发(敏捷)，快速验证原型等诸多领域上，Brooks真乃神人也！恰巧今晚看到"程序员那些事儿"推了Brooks的言论"一个程序员一个月完成的编程工作，不要让两个程序员花两个月完成"，可知人月不能互相转换已经达成共识。
人月神话观后感（精选5篇）第一篇：人月神话观后感《人月神话》观后感在软件领域，很少能有像《人月神话》一样具有深远影响力和畅销不衰的著作。
Brooks博士为人们管理复杂项目提供了最具洞察力的见解，既有很多发人深省的观点，又有大量软件工程的实践。
读完本书后，感触颇深，书中通过介绍在软件项目开发过程中遇到的一系列问题，以及解决的方法，向IT从业者讲述软件开发过程中需要注意的问题，以下将按照本书的顺序一一总结。
第一章焦油坑史前时代的焦油坑吞噬了成千上万个力大无穷的巨兽，今天的大型软件项目则令无数庞大的开发团队陷入无从逃脱的窘境。
软件程序按其规模和目标的不同，对开放过程的要求也有极大的不同，这给软件开放这一职业带来无穷乐趣，同时也是这一行业苦恼的根源。
第二章人月神话软件开发项目常以人月来衡量工作量，这种度量暗示着人手和时间是可以互换的。
这种“人多力量大”的想法是一种一厢情愿的虚妄神话，布鲁克斯法则：向滞后的软件项目追加人手会使得进度更迟缓。
自本书第一版以来，这一法则在软件业广为传诵。
第三章外科手术队伍虽然优秀的程序员的工作效率往往数倍于平庸的程序员，但若是缺乏合理的配置，优秀的成员未必能构成优秀的团队。
大型软件开发项目的团队需要和外科手术组一样妥善分工，各司其职协调配合。
第四章贵族专制、民主制和系统设计概念完整性是系统设计中最重要的因素，尤其对于大型软件系统，概念完整性是项目顺利完成的必要保障，为获得概念完整性，架构设计由精简的架构设计小组负责，具体实现则围绕核心概念展开，架构设计和具体实现既相分离，又相辅相成。
以建筑工程为类比，概念完整性也是软件项目通往成功的保证。
第五章画蛇添足人们在第一个系统成功完成后，往往会在开发后续的第二个系统时犯冒进的错误。
第二个系统经常成为过度设计或画蛇添足的牺牲品。
要避免这种错误，必须在第二个系统开发时审慎地考查技术环境的变化，广泛进行交流和沟通，聆听各方面的建议，确立严谨的估算和规划。
《人月神话》读后感5我们公司普通的十个程序员，不过工资最多也就是普通程序员的二倍。
是不是有些不公平呢?我也说不清楚。
因为那些普通程序员也十分的努力。
不过，我觉得，作为公司，应该给最好的人最好的待遇，或者说给比目前更高的待遇。
组建一个团队，最好的就是那种精英团队，大家都是牛人，效率会特别高。
微软就是这种思路吧，把最聪明的人集中在一起，想不成功都难亚。
3，进度落后与增加人力。
记得当年看《C++编程思想》，Bruce 说"十个妇女不能在一个月内生下小孩"(大意)，于我心有戚戚焉。
而本书作者Brooks得出的结论是对我是震撼性的："向进度落后的项目中增加人手，只会使进度更加落后"。
以前，增加人手基本是挽救进度落后项目的主要办法。
这个办法行不通的话，难道只有"加班"一条路了?但长期加班是对个人的摧残，我更愿意利用业余时间去看书，例如看这本"人月神话"。
：) 如果不想加班，不想削减功能，不想推迟发布日期，那么。
唯一的方法还是只有….加人。
加足够的人。
而且不要逐步加入，一定要一次性加入。
要小心的是，新加入的人可能对原来的组织造成冲击，或者对原来的设计有不同意见(特别是加入的人中有比较强大的设计者)。
那么，就当作，新组建了一个团队吧。
交流，培训新人，就设计达成一致，继续向者目标前进。
感触还有很多，以后如果有机会再写。
不过，我决定去买本英文版回来，收藏，以后再多看几次。
<li读后感< a="">上一页 [1] [2]</li读后感<>。
《人月神话》读后感
看完《人月神话》，真的没有太多的感触。
可能是因为成书时间太过于久远，太多的内容实在是老生常谈，很多想法已经成为软件工程领域的一般做法，一些内容也已经为学习编程者所熟知。
另外，由于年代的限制，作者所强调的一些细节也已无关紧要了。
但是，作者对问题的分析思路，他客观的分析方式还是值得学习。
作者并不人云亦云，他反对很多流行的论断，他做出判断的依据通常是基于常识和经验的理性推理。
比如，他非常反对对流程图的推崇，认为流程图既没什么用，也没什么人用，大家在编程后画流程图，多半只为了交差；他反对把GOTO一棒子打死的做法，认为在指定入口的时
候，GOTO是非常有用的；他坚持认为即使改进编程语言，软件工程的生产率在10年内也不能获得数量级上的提高，因为软件工程最大的问题在于解决概念完整性和处理沟通。
不过书中还是确实有很多地方很让我觉得有同感：
在第6章中作者提到，系统架构师们应该在文档中描述所有外部特性，但是他应该避免干涉具体实现细节，这让我联想起以前与同学合作参加编程比赛，为了数据组织形式这种内在特性争论，现在看来，实际上解决办法很简单：谁开发、谁决定，对于外部特性的形式化定义不应该扼杀实现人员的创造力。
在第16章中，作者提到快速原型技术是如何改变了工作的效率，相比于一次开发成功一个大型系统，先开发可用原型再经过迭代得到一个大型系统拥有更高的效率，这不仅仅因为看到一个可用产品的兴奋性会激发较高的生产率，而且是因为一个可用版本的产品能够直接获得改进的反馈和目标的调整，这也确实是个人工作中体会到的。
也许本书适合于在工作中不断重翻，不断去体会。
鉴于本书的每一
章都是一篇相对独立的散文，下面对它的每一章进行总结，即“一句话读后感”。
Chap1. 焦油坑
编程系统产品的成本数倍于编程本身；编程这样一个行业给人以创造、动手与控制的乐趣，但是，对沟通的依赖、对完美的追求也是编程所令人苦恼的一面。
Chap.2 人月神话
“一切都将运转良好”在软件工程中是不适用的；完成工作的人数与时间是不能进行简单的互换的，因为沟通需要额外的成本；Brook法则：向进度落后的项目中添加人手，只会使进度更加落后。
Chap.3 外科手术队伍
程序员在生产率上甚至可以达到数量级的差异；专业的、分工良好的小规模团队的生产率更高，在这种架构下，决策的集中性也保证了概念的一致性。
Chap.4 贵族专制、民主政治和系统设计
概念的完整性最应该被重视，它带来产品的简洁和易懂；因此，系统的体系结构设计应由少数人来完成，即系统设计师专制；但系统设计师应该严守底线，避免干涉外部特征之外的实现细节。
Chap.5 画蛇添足
在第一版设计中，设计师往往能保证精炼简洁；但在第二版设计时，画蛇添足是常见的问题，设计师容易被诱惑着开发过多的功能，这是应该被避免的。
Chap.6 贯彻执行
对产品的文档化规格说明是必要的，它应该用清楚的形式化定义表达；开发人员之间应该定期有不同层次（大会、组例会、电话）的交流，并对交流进行记录、整理和思考；开发人员应坚守手册，尤其在有多重实现时；大型项目中的测试小组对确保用户体验十分重要。
Chap.7 为什么巴别塔会失败
巴别塔有着清晰的目标、充足的人力、材料、技术和时间，但是巴别塔的建造人员缺乏沟通；大型软件工程应有不同层次的沟通，并用项目工作手册规定定义接口与划分以减少交流所需的工作量；软件工程的组织结构应采取树形结构，以保证有效的沟通。
Chap.8 胸有成竹
本章将对生产率的估计，工作量 = 常数×指令数目1.5，本章还总结了一些软件工程中一些对生产率进行估计的技术。
Chap.9 削足适履
程序空间也是与时间一样的成本，程序规模应该为预算所控制；空间与时间可以进行一定的折中，但好的数据处理方式是可以在两方面同时进行优化的。
Chap.10 提纲挈领
软件项目经理应该编写一系列关键的文档，它们反映了对目标、技术特征、进度、预算和组织结构的管理；它们不仅仅是检查列表和控制手段，它也是沟通渠道和汇报材料。
Chap.11 未雨绸缪
第一次开发的系统应该准备好要抛弃，因为变化不可避免，要对此计划好系统与组织架构的变化；缺陷修复会引入新的BUG，而且到了最后必然会不能再进行改进。
Chap.12 干将莫邪
工具的安排：软件将最终在之上运行的目标机和开发辅助机，目标机应该被规划使用，辅助机上应该运行可靠的仿真器、解释器和程序库文档。
Chap.13 整体部分
概念完整性与产品精确定义是关键的；结构化编程是必要的；构件应该进行单独的测试，之后再进行集成测试；修改时应控制变更规模。
Chap.14 祸起萧墙
里程碑应该明确定义以防止产生隐瞒；使用PERT图指示对进取的需要；老板不应与一线经理产生角色冲突，而应使用能了解状态真相的评审机制，计划和控制小组在这一过程中很有价值。
Chap.15 另外一面
用户需要文档来帮助他们使用（目的、环境、IO范围、功能算法、指令、选项、运行时间和精度检验）、验证和修改程序；流程图的使用与维护都很麻烦，已经过时；自文档化技术是一种非常有效的解决方案。
Chap.16 没有银弹
软件开发所不可规避的困难在于复杂度、一致性、可变性和不可见性；尽管高级语言、分时系统、IDE在编码过程中帮了程序员的大忙，但他们无助于解决内在困难；高级编程语言、面向对象技术、人工智能、专家系统、自动编程、图形化编程和更快的工作站都无助于问题的根本部分；有希望缓解根本问题的是：购买软件、快速原型技术、增量开发和卓越的设计人员。
