人月神话读后感
人月神话第五章读后感
人月神话第五章读后感这一章里啊，作者大谈特谈关于进度安排的那些事儿。
以前我总觉得，做项目嘛，只要人够多，时间就肯定能缩短。
就像搬砖，人多力量大，砖很快就能搬完呗。
但是这章就像是一盆冷水，直接浇灭了我这种天真的想法。
作者说人月这个概念其实很有欺骗性。
可不是嘛，一个人干一个月的活，和十个人干一个月的活可不一样。
就好比十个人一起做饭，可能光是协调谁切菜、谁煮饭、谁炒菜就得花不少时间，说不定还会因为想法太多，在厨房里打起来呢。
软件项目也是这样，增加人手不一定能让进度加快，反而可能因为沟通成本的增加，让整个项目变得更乱。
书里提到那些被乐观估计的进度安排，简直就像我每次减肥时给自己定的目标一样不切实际。
一开始总是信心满满，觉得每天少吃一顿饭，再加上点运动，一个月就能瘦十斤。
结果呢？三天打鱼两天晒网，还总是忍不住偷吃。
软件项目里那些拍脑袋定下来的乐观进度表，最后往往也是被各种意外情况打得落花流水。
什么需求突然改变啦，技术难题冒出来啦，就像减肥时突然遇到美食的诱惑一样，让人难以招架。
还有那关于里程碑的说法也很有趣。
就像是在漫长的旅途中给自己设几个标记点，告诉自己到这儿了就离目的地更近一步。
但是设里程碑也不是乱设的，不是随便在路上插个小旗就算数。
得是真正能检验项目进展、有实际意义的点才行。
这就好比减肥的时候，不能把每天称一次体重当成唯一的里程碑，而是得看体脂率有没有下降，能不能穿上小一号的衣服之类的。
这一章读完，我算是明白了，软件项目的进度安排就像一场精密的棋局，不是简单地把棋子（人）往棋盘（项目）上一放就了事的。
得考虑到各种因素，小心谨慎地布局，不然就等着被项目这个对手将一军吧。
《人月神话》读后感（五篇范例）
《人月神话》读后感（五篇范例）第一篇：《人月神话》读后感《人月神话》读后感在软件领域中,很少能有像《人月神话》一样具有深远影响力和畅销不衰的著作。
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》更为有远见，把我从充实代码的清晰简介升华，拓展到软件开发的高层度，一个周密，准确，明朗的开发需求分析，可行性研究，软件实现是软件开发的完美递进，他们相互辅助，相互促进，如海浪一层的推着前浪奔向远方，而《人月神话》如软件工程开发经济的精华，碧玉。
在《人月神话》面前《设计模式》、《原型设计》、《灵活软件开发》、《面对对象思维》、只不过是冰山一角。
人月神话读书笔记
人月神话读书笔记第一篇：人月神话读书笔记人月神话这本书几年前就听别人说是本很经典的软件开发方面的书，这本书的成功之处在于他思想的前卫性，以至于不只是软件行业的人在读。
现在终于找到读他的理由了，可以感受一下大师的杰作。
在读之前我已经读过了软件工艺和极限编程，为什么留到最后读人月神话呢？主要是因为我觉得一本能够流传30年还被人们津津乐道的书，肯定是本学要好好细读的书，所以留到了最后。
按照前两篇读书笔记的惯例，前面几段是一些我读书时的感受和收获，还有一些对内容的评价。
从这本书的内容来看，对于一个项目经理来说肯定会有更大的收获，这本书主要是针对软件开发管理方面的内容，这主要原因可能是因为作者以前就是项目的管理者，他是站在管理者的角度写的。
即便这样，对于一个从来没有参与过真实项目开发，更没有领导过团队的我还是有一定的吸引力，这本书中我最喜欢的就是前四章（焦油坑、人月神话、外科手术队伍、贵族专制、民主政治和系统设计）和没有银弹这章。
这本书里面为了论证某一观点，会举出许多实际的项目作为证据，这一点非常好，事实胜于雄辩嘛！这些例子也许对于作者那个年代的人来说很好理解，但是放在30年后来看这些例子又有些陈旧和难懂了。
另外，从文中我发现作者非常注重文档，一个优质的文档就是项目成功的保证，这一点与传统的软件工程很相似，但是却与极限编程的观点相悖。
下面就是一些读书的总结了。
焦油坑1. 编程系统产品开发的工作量是供个人使用的、独立开发的构件程序的九倍。
2. 编程行业的一些内在固有苦恼：l 将做事方式调整到追求完美，是学习编程的最困难部分。
l 由其他人来设定目标，并且必须依靠自己无法控制的事物。
l 真正的权威来自于每次任务的完成。
l 任何创造性活动都伴随着枯燥艰苦的劳动，编程也不例外l 人们通常期望项目在接近结束时（bug、工作时间）能收敛得快一些，然而软件项目的情况却是越接近完成，收敛得越慢。
l 产品在即将完成时总面临着陈旧过时的威胁。
《人月神话》读后感
《人月神话》读后感
《人月神话》是一本经典的软件开发管理书籍，作者弗雷德里克·布鲁克斯通过讲述自己在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％，其他的时间都花在了无关的琐碎事情上。
人月神话读后感
人月神话读后感《人月神话》是一本由计算机科学家弗雷德里克·布鲁克斯所写的经典著作，书中以自身的亲身经历和观察为基础，探讨了如何管理和开发大型软件项目的一些重要原则和方法。
阅读完《人月神话》，我深深地被书中的观点和思考所震撼，对于软件开发和项目管理的理解有了更深入的认识。
书中，作者首先提到了“人月神话”这一概念，即认为增加人力资源可以缩短项目的进度。
然而实践中，情况却完全相反，项目反而更加拖延。
布鲁克斯通过数个实际案例说明了这个问题的原因，主要是因为沟通成本的增加和人员的组织问题。
他提出了著名的“布鲁克斯法则”，即“人越多，开发时间越长”。
作者还深入探讨了软件开发中的一些重要问题，如程序员的生产率、项目管理、团队组织等。
他认为，一名出色的程序员的价值相当于普通程序员的数十倍，而且编程工作的本质是创造性的工作，并不适合通过时间来衡量。
他提倡合理的工作时间，并强调了程序员的舒适度对于工作效率的影响。
在项目管理方面，作者提倡将项目分解成小的部分进行开发，并强调了需求分析的重要性。
他指出了软件开发中经常发生的需求变更问题，以及如何通过合理的时间规划和团队协作来解决这个问题。
他还对管理者的角色进行了深入的思考，认为管理者应该给团队提供清晰的目标和方向，并保持开放的沟通和透明的决策过程。
在书中，作者还介绍了一些关于人员组织和团队管理的经验和原则。
他认为，团队的成功不仅仅取决于个人的能力，更取决于人员之间的相互合作和协调。
他引用了傲慢者法则和思科系统的成功经验来说明团队合作的重要性。
他主张鼓励团队成员之间的交流和分享，提倡团队精神和集体创造，以实现项目的成功。
阅读完《人月神话》，我深刻地体会到了软件开发和项目管理中的一些重要规律和原则。
我认为，软件开发是一项复杂而创造性的工作，需要合理的时间和资源来完成。
而项目管理则需要合理的规划和组织，以及良好的沟通和协作。
只有通过合理的方法和思考，才能够提高软件开发的效率和质量。
人月神话第五章读后感
人月神话第五章读后感
这一章里，作者把外科手术团队类比软件开发团队，这个比喻可太有趣了。
就像在一个外科手术里，主刀医生那可是绝对的核心人物，其他的护士、麻醉师啥的都围着他转，给他打辅助。
在软件开发里呢，也就应该有这么个灵魂人物，那些个高手程序员就像主刀医生一样，承担着最关键的任务。
这让我一下子就明白了团队里角色分工的重要性。
不能大家都一股脑地去干同一种活儿，得像手术团队那样，各司其职，紧密配合。
不过呢，我也觉得这有点理想状态了。
现实中的软件开发团队啊，有时候就像一群无头苍蝇。
大家都觉得自己是高手，都想当那个“主刀医生”，结果就乱成一锅粥了。
不像人家外科手术团队，经过了那么多的训练，清楚地知道自己该干啥。
我们的开发团队有时候就缺乏这种明确性。
还有啊，这章让我意识到，一个好的团队结构就像一个精密的仪器。
每个部件都得恰到好处地运转。
如果团队里的沟通不畅，就像仪器里的齿轮卡壳了一样，整个项目就会停滞不前。
我就想起我之前参加的一个项目，大家都在埋头写代码，可彼此之间都不咋交流，结果最后拼凑到一起的时候，发现很多地方根本不兼容，就像拿左腿的假肢往右腿上安一样，滑稽又让人头疼。
人月神话读后感
人月神话读后感《人月神话》读后感《人月神话》是一本由弗雷德里克·布鲁克斯所著的软件工程领域经典著作。
这本书首次出版于1975年，至今已经被翻译成多种语言并广泛流传。
在这本书中，布鲁克斯提出了许多关于软件开发的观点和原则，对软件工程领域产生了深远的影响。
在读完《人月神话》之后，我深受启发。
这本书不仅仅是一本关于软件开发的著作，更是一部关于团队合作、项目管理和创新思维的指南。
布鲁克斯在书中提出了许多深刻的观点，让我对软件开发这个领域有了更深入的理解。
首先，我深受布鲁克斯关于“人月神话”的观点所感动。
在书中，他指出了一个常见的误区，即认为增加人手就能够加快项目的进度。
然而，布鲁克斯指出，人手的增加并不一定会带来效率的提升，反而可能会导致更多的沟通成本和管理成本。
这一观点让我深刻地意识到，团队的规模并不代表团队的效率，而是需要通过合理的规划和管理来提高项目的执行效率。
其次，布鲁克斯在书中提出了“二次系统效应”的概念。
他指出，当一个软件系统经过一次开发之后，随着需求的变化和新的功能的增加，系统的复杂度会呈指数级增长。
这一观点让我意识到，软件开发并不是一次性的任务，而是需要不断地进行迭代和优化。
只有不断地对系统进行重构和改进，才能够应对不断变化的需求和挑战。
另外，布鲁克斯还在书中提出了许多关于项目管理和团队合作的建议。
他强调了团队的沟通和协作的重要性，以及项目计划和进度的管理。
这些建议无疑对我在实际工作中的团队合作和项目管理产生了积极的影响。
我意识到，一个成功的项目不仅需要技术上的创新，更需要团队之间的有效沟通和协作，以及合理的项目规划和管理。
总的来说，读完《人月神话》之后，我对软件开发这个领域有了更深入的理解。
布鲁克斯在书中提出的观点和原则，让我意识到软件开发不仅仅是技术上的挑战，更是一个需要团队合作、项目管理和创新思维的领域。
我相信，这些观点和原则将对我未来的工作产生深远的影响，帮助我更好地应对软件开发中的各种挑战和问题。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
人月神话读后感
这学期班主任给我们推荐了一本在软件领域拥有深远影响力和畅销不衰的著作——人月神话。
布鲁克斯博士为为人们管理复杂项目提供了最具洞察力的见解，既有很多发人深省的观点，又有大量软件工程的实践。
本书内容来自Brooks 博士在IBM公司SYSTEM/360家族和OS/360中的项目管理经验，该项目堪称软件工程项目管理的典范。
该书英文原版一经面世，即引起业内人士的强烈反响，后又译为德、法、日、俄、中、韩等多种文字，全球销售数百万册。
确立了其在行业内的经典地位。
其实说实话，现在看人月神话的话对我并没有多大作用（也可能是我觉得没什么作用），因为就自身能力来讲，还没有达到管理这个层次，但是多了解这方面的内容对我是无害的！那么接下来我就讲讲仅仅针对我而言对于这本著作的解读（个人观点）。
所有的编程人员都有乐观主义，总是相信自己的代码是肯定能运行的。
所以在安排项目的进度的时候就会是假设在代码能够在正常运行时因该花费的时间。
而现实往往不是乐观，在项目的进展过程中会存在各种不可预知的问题。
在这个时候项目经理就会为项目增加人员，然而增加人员反而导致项目进度越来越慢。
因为新增加的人员还需要培训，需要时间去了解项目的内容和进展情况。
在投入了更多的人力的时候，经理发现项目进度反而更慢他就会投入更多的人力，这种恶行循环导致项目的失败。
开发一个项目，我们错误的认为用人月这个工作量单位来估计和进行进度安排。
成本的确随开发产品的人数和时间的不同，有着很大的变化，进度却不是如此。
因此我认为用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话。
它暗示着人员数量和时间是可以相互替换的。
人数和时间的互换仅仅适用于以下情况：某个任务可以分解给参与人员，并且他们之间不需要相互的交流，而在系统编程中近乎不可能。
当任务由于次序上的限制不能分解时，人手的添加对进度没有帮助。
调试、测试的次序特性，许多软件都具有这种特征。
因为软件开发本质上是一项系统工作——错综复杂关系下的一种实践——沟通、交流的工作量非常大，它很快会消耗任务分解所节省下来的个人时间。
从而，添加更多的人手，实际上是延长了，而不是缩短了时间进度。
让我印象最深的是巴比伦塔的管理教训里面的一句总结为什么巴比伦塔为什么是一个失败的工程：那为什么项目还会失败呢？他们还缺乏些什么？
两个方面——交流，以及交流的结果——组织。
他们无法相互交谈，从而无法合作。
当合作无法进行时，工作陷入了停顿。
在这次高软的工程实践中我就深刻体会到这句话的重要性。
我们组的项目所有代码都是我一个人写的，我的队友负责帮我优化UI。
我告诉他我需要哪些东西，但是他完全按照他的理解做了一个完全不是我想要的东西。
我以为我和他讲的很清楚，可是还是导致我们的项目在这里浪费了一些时间。
最后总结，我和他交流有问题，还有就是他本身对于我们的项目是不理解的，所以导致他按照他的想法去做的时候就会和我的想法产生误差。
团队如何进行相互之间的交流沟通呢？通过所有可能的途径：非正式途径：清晰定义小组内部的相互关系和充分利用电话，能鼓励大量的电话沟通从而达到对所书写文档的共同理解。
会议：常规项目会议。
会议中，团队一个接一个地进行简要的技术陈述。
这种方式非常有用，能澄清成百上千的细小误解。
工作手册：在项目的开始阶段，应该准备正式的项目工作手册。
其实看完整本书之后，我发现作者一直在强调一个词：文档。
他曾经很勤奋的向软件工程师们讲述文档的必要性以及优秀文档所具有的特点方面的讲座。
但是效果都非常的的不好，他们知道如何来写出优秀的文档，但是他们缺乏热情。
所以作者采用向马车搬收银机的方法向他们展示如何来完成这项工作。
结果显示这种方法的效果还是挺好的。
那我们在开发的过程中需要什么样的文档呢？
不同用户需要不同级别的文档。
某些用户仅仅偶尔使用程序，有些用户必须依赖程序，还有一些用户必须根据环境和目的的变动对程序进行修改。
使用程序。
每个用户都需要一段对程序进行描述的文字。
可是大多数文档只提供了很少的总结性内容，无法达到用户要求，验证程序。
除了程序的使用方法，还必须附带一些程序正确运行的证明，即测试用例。
修改程序。
调整程序或者修复程序需要更多的信息。
显然，这要求了解全部的细节，并且这些细节已经记录在注释良好的列表中。
和一般用户一样，修改者迫切需要一份清晰明了的概述。
另外一个让我印象深刻的观点是：要保证一个项目的进度被大幅度推迟，制定进度表很重要。
进度表由里程碑和完成时间组成。
里程碑必须具体，明确，可界定。
某一里程碑要么到达，要么没有到达，不应该是80%到达的。
而我的经验是，制定进度表非常重要，而且要求制定者有很强的技术背景，这样才能对碰到的问题和可能花掉的时间做出更准确的估计。
通常，开发一个软件我们还会设立规模目标，控制规模，发明一些减少规模的方法——就如同硬件开发人员为减少元器件所做的一样。
规模预算必须与分配的功能相关联；在指明模块大小的同时，确切定义模块的功能。
培养开发人员从系统整体出发、面向用户的态度是软件编程管理人员最重要的职能。
调试，是一种检验程序中的方法。
然而调试是系统编程中很慢和较困难的部分，而漫长的调试周转时间是调试的祸根。
它可以持续一个很长的时间，从而可能影响项目的交付日期。
为了更好的控制进度，我们需要制定一个严格的进度表来控制项目的进度表，进度表由里程碑和日期组成。
里程碑必须是具体的、特定的、可度量的事件，能进行清晰能定义。
进度表有时可以根据进展情况进行适度的修改。
产品测试时每个产品在提交给用户的一道程序。
而这项工作主要由产品测试机构/小组根据规格说明检查机器和程序，充当麻烦的代言人，查明每一个可能的缺陷和相互矛盾的地方。
每个开发机构都需要这样一个独立的技术监督部门，来保证其公正性。
产品－测试小组则是顾客的代理人，专门寻找缺陷。
不时地，细心的产品测试人员总会发现一些没有贯彻执行、设计决策没有正确理解或准确实现的地方。
出于这方面的原因，设立测试小组是使设计决策得以贯彻执行的必要手段，同样也是需要尽早着手，与设计同时实施的重要环节。
昨天我又把书翻了一遍，发现大部分内容都是涉及到团队，人和沟通。
对于大型软件工程项目强调人的重要性。
在开篇讲开发人员的职业乐趣，后面又通过巴比塔的沟通重要性，在外科手术队伍中的组件和分工。
这些都是涉及到团队中人和交互，只有一个有了积极心态和热情的沟通团队，才可能成就一个伟大的团队。
从最后的没有银弹，再次肯定开发工作是一种高智力的脑力工作。