人月神话(精简)剖析
人月神话第五章读后感
人月神话第五章读后感这一章里啊，作者大谈特谈关于进度安排的那些事儿。
以前我总觉得，做项目嘛，只要人够多，时间就肯定能缩短。
就像搬砖，人多力量大，砖很快就能搬完呗。
但是这章就像是一盆冷水，直接浇灭了我这种天真的想法。
作者说人月这个概念其实很有欺骗性。
可不是嘛，一个人干一个月的活，和十个人干一个月的活可不一样。
就好比十个人一起做饭，可能光是协调谁切菜、谁煮饭、谁炒菜就得花不少时间，说不定还会因为想法太多，在厨房里打起来呢。
软件项目也是这样，增加人手不一定能让进度加快，反而可能因为沟通成本的增加，让整个项目变得更乱。
书里提到那些被乐观估计的进度安排，简直就像我每次减肥时给自己定的目标一样不切实际。
一开始总是信心满满，觉得每天少吃一顿饭，再加上点运动，一个月就能瘦十斤。
结果呢？三天打鱼两天晒网，还总是忍不住偷吃。
软件项目里那些拍脑袋定下来的乐观进度表，最后往往也是被各种意外情况打得落花流水。
什么需求突然改变啦，技术难题冒出来啦，就像减肥时突然遇到美食的诱惑一样，让人难以招架。
还有那关于里程碑的说法也很有趣。
就像是在漫长的旅途中给自己设几个标记点，告诉自己到这儿了就离目的地更近一步。
但是设里程碑也不是乱设的，不是随便在路上插个小旗就算数。
得是真正能检验项目进展、有实际意义的点才行。
这就好比减肥的时候，不能把每天称一次体重当成唯一的里程碑，而是得看体脂率有没有下降，能不能穿上小一号的衣服之类的。
这一章读完，我算是明白了，软件项目的进度安排就像一场精密的棋局，不是简单地把棋子（人）往棋盘（项目）上一放就了事的。
得考虑到各种因素，小心谨慎地布局，不然就等着被项目这个对手将一军吧。
《人月神话》读后感（五篇范例）
《人月神话》读后感（五篇范例）第一篇：《人月神话》读后感《人月神话》读后感在软件领域中,很少能有像《人月神话》一样具有深远影响力和畅销不衰的著作。
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年前软件项⽬所⾯临的问题，在我们现在依然如此，糟糕的情况没有改变，⼤家仍旧在焦油坑⾥挣扎，⽽且看上去没有解决办法。
过去⼏⼗年的⼤型系统开发就犹如⼀个焦油坑，很多⼤型企业在其中剧烈地挣扎。
他们中⼤多数开发出了可运⾏的系统。
不过，其中只有⾮常少数的项⽬满⾜了⽬标、时间进度和预算的要求。
各种团队，⼤型的和⼩型的，庞杂的和精⼲的，都⼀个接⼀个淹没在了焦油坑中，被软件危机所带来的灾难覆盖。
表⾯上看起来好像没有任何⼀个单独的问题会导致困难，每个都能被解决，但是当它们相互纠缠和累积在⼀起的时候，团队的⾏动就会变得越来越慢。
对于我们⽽⾔，如果我们想解决问题，就必须试图先去理解它，了解什么是编程系统产品，同时也要找到⾃⼰职业的乐趣，因为只有发现了乐趣，⼯作才会更有积极性。
在第⼆章中，我了解到原来“⼈⽉“是我们项⽬⼯程中估计和进度安排中使⽤的⼯作量单位，⽤⼈⽉作为衡量⼀项⼯作的规模是⼀个危险和带有欺骗性的神话。
它暗⽰着⼈员数量和时间是可以相互替换的但仅适⽤于某个任务可以分解给参与⼈员，并且他们之间不需要相互的交流的情况。
因为软件开发本质上是⼀项系统⼯作——错综复杂关系下的⼀种实践——沟通、交流的⼯作量⾮常⼤，它很快会消耗任务分解所节省下来的个⼈时间。
当任务由于次序上的限制不能分解时，⼈⼿的添加对进度不会有帮助。
虽然我现在只读了前两章，但同样拓宽了⾃⼰的视野，因此我决定继续读下去，继续探索软件⼯程的奥秘。
人月神话读后感
人月神话读后感《人月神话》是一本由计算机科学家弗雷德里克·布鲁克斯所写的经典著作，书中以自身的亲身经历和观察为基础，探讨了如何管理和开发大型软件项目的一些重要原则和方法。
阅读完《人月神话》，我深深地被书中的观点和思考所震撼，对于软件开发和项目管理的理解有了更深入的认识。
书中，作者首先提到了“人月神话”这一概念，即认为增加人力资源可以缩短项目的进度。
然而实践中，情况却完全相反，项目反而更加拖延。
布鲁克斯通过数个实际案例说明了这个问题的原因，主要是因为沟通成本的增加和人员的组织问题。
他提出了著名的“布鲁克斯法则”，即“人越多，开发时间越长”。
作者还深入探讨了软件开发中的一些重要问题，如程序员的生产率、项目管理、团队组织等。
他认为，一名出色的程序员的价值相当于普通程序员的数十倍，而且编程工作的本质是创造性的工作，并不适合通过时间来衡量。
他提倡合理的工作时间，并强调了程序员的舒适度对于工作效率的影响。
在项目管理方面，作者提倡将项目分解成小的部分进行开发，并强调了需求分析的重要性。
他指出了软件开发中经常发生的需求变更问题，以及如何通过合理的时间规划和团队协作来解决这个问题。
他还对管理者的角色进行了深入的思考，认为管理者应该给团队提供清晰的目标和方向，并保持开放的沟通和透明的决策过程。
在书中，作者还介绍了一些关于人员组织和团队管理的经验和原则。
他认为，团队的成功不仅仅取决于个人的能力，更取决于人员之间的相互合作和协调。
他引用了傲慢者法则和思科系统的成功经验来说明团队合作的重要性。
他主张鼓励团队成员之间的交流和分享，提倡团队精神和集体创造，以实现项目的成功。
阅读完《人月神话》，我深刻地体会到了软件开发和项目管理中的一些重要规律和原则。
我认为，软件开发是一项复杂而创造性的工作，需要合理的时间和资源来完成。
而项目管理则需要合理的规划和组织，以及良好的沟通和协作。
只有通过合理的方法和思考，才能够提高软件开发的效率和质量。
人月神话读后感
人月神话读后感《人月神话》是一本由弗雷德里克·布鲁克斯所著的计算机领域经典著作，它深刻地剖析了软件开发过程中的种种困难和挑战，提出了许多颠覆性的观点和理论。
在读完这本书后，我深受启发，对软件开发这一领域有了更加深入的理解和认识。
首先，我被书中提出的“人月神话”这一概念所震撼。
在书中，布鲁克斯指出，增加人手并不能缩短软件开发的时间，反而可能会延长项目的完成时间。
这一观点颇具启发性，因为在我以往的认知中，增加人手应该可以加快项目的进度。
然而，书中通过实际案例和数据分析，清晰地展现了增加人手可能导致的沟通成本、协调成本和学习成本等问题，从而使得项目的进度反而受到影响。
这一观点对我来说是一种颠覆性的认知，使我对软件开发的管理和组织产生了新的思考。
其次，书中对软件开发过程中的种种挑战和困难进行了深入的剖析。
例如，书中提到了软件开发中的“二次系统效应”，即在开发过程中，随着系统的不断完善和修改，系统的复杂性会呈指数级增长。
这一观点让我对软件开发的复杂性有了更加深刻的认识，也使我意识到在软件开发过程中需要更加注重系统的设计和架构，以避免二次系统效应带来的种种问题。
此外，书中还提到了软件开发中的“饥饿艺术家效应”和“进度不良的现象”，这些都是软件开发过程中常见的问题，通过深入的剖析和分析，使我对这些问题有了更加清晰的认识，也为我今后在软件开发过程中避免这些问题提供了宝贵的经验和教训。
最后，我被书中对软件开发管理和组织的种种建议所深深吸引。
例如，书中提到了“参与式管理”和“集成式管理”等概念，这些管理理念都是为了解决软件开发过程中的种种挑战和困难而提出的。
通过对这些管理理念的深入剖析和分析，使我对软件开发管理和组织有了更加深入的理解，也为我今后在软件开发过程中的管理和组织提供了宝贵的经验和启示。
总之，《人月神话》是一本极具启发性和深度的书籍，它不仅为我对软件开发的认知和理解提供了新的视角，也为我在软件开发过程中遇到的种种挑战和困难提供了宝贵的经验和教训。
人月神话(精简)
没有银弹！ --Brooks
• 软件工程的内在特性
– 复杂度：不同于建筑、汽车等产品，软件实体可能比任何由人类 创造的其它实体都要复杂，因为没有任何两个软件部分是相同的 （至少是在语句的级别上）。
• 无规则性：不同于数学、物理等学科，软件工程所控制的 很多复杂度是随心所欲、毫无规则可言的，来自于若干必 须遵循的人为惯例和系统。
• 技术并非《人月神话》的着眼点，它更关注的是软件的创造过程、需 求的变化无常和管理的永恒困境。 • 《人月神话》的中心思想已经超越了具体的时代和技术。
名家谈人月神话
• 这是一本经典著作，与软件开发有关的每一个人都应该不只一遍地读 这本书。 ——Philippe Kruchten Rational 统一过程首席架构师 • 它仍然是计算机书籍中呗引用次数最多的书籍，而且即便本书最初出 版于1975年，其内容至今仍未过时。在阅读的时候，每隔几页不说一 句“对极了！”是很难受的。 ——Stee McConnell,Construx公司首席软件工程师
《人月神话》的由来
• IBM的System/360是第一个特大型软件项目，它催生了《人月神话》
《人月神话》的由来
• System/360的开发过程被视为计算机发展史上最大的一次豪赌，为了 研发System/360这台大型机，IBM决定征召六万多名新员工，创建五 座新工厂，而当时出货的时间不断的顺延。
• 在软件开发中，也许现有的 技术已经可以所向披靡，但 如果整个团队不能进行良好 有效地沟通，项目就有可能 功败垂成。
人月神话——胸有成竹
• 有效的管理和决策是致胜的关键。
• 图为美国历史上最伟大的职 业棒球运动员贝比.鲁斯（ Babe Ruth）在球场上发号施 令。
人月神话读后感
《人月神话》读后感～-7-6 字数：4071不同的社会体会，不同的思想状态，对读本书的心得也不一样，我在此说说我的读后感，书中有许多超级好的观点，但我只把我感触最深的写下来。
这确实是一本很值得多次阅读的好书，每次阅读可能都能从中取得一些提示。
1.外科手术队伍thesurgicalteam项目领导在项目的初期必需清楚的估量项目的人月运作模式（时刻、人力在项目各时期的分派），例如何时需要出什么样功效，决定了何时需要什么样的人加入项目，这是项目领导的责任。
2.贵族～，民主政治aristocracy，democracy，system要取得概念的完整性，设计必需由一个人或具有共识的小组来完成。
有四个问题：1。
如何取得概念的完整性2。
是不是要有一名杰出的精英，或说是结构设计师的贵族～.....3.如何幸免结构设计师产出无法实现或代价昂贵的技术规格说明，使大伙儿陷入窘境。
4。
如何才能与实现人员就技术说明的琐碎细节充分沟通，以确保设计被正确地明白得，并精准地整合到产品中。
对1。
2。
4的回答大体上都能够找到，但第3个似乎找不到。
3.画蛇添足thesecond-systemeffect讲述的大体都是基于ibm360操作系统和编译程序等方面的体会，讲述如何幸免开发第二个系统的风险，作者以为开发第二个系统的设计师设计出来的系统是最危险的，因此要求他们自律。
4.贯彻执行passingtheword印象比较深刻的是＂体系结构设计人员必需为自己描述的任何特性预备一种实现方式，但他不该该支配具体的实现进程。
＂5.什么缘故巴比伦塔会失败whydidthetowerofbabelfail？讲述巴比伦塔会失败的缘故是缺乏交流。
6.胸有成竹callingtheshot要紧讲述如何计算编程时刻，和提出几个人的体会算法。
讲述的各类算法可能都不太适合与此刻的高级语言，但portman的观点仍然适合此刻，即编程人员实际的编程时刻只有50％，其他的时刻都花在了无关的琐碎情形上。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
人月神话——焦油坑
史前 今天
焦油坑
大型软件项目
吞噬
围困
• 图为洛杉矶自然历史博物 馆GeorgeC.Page馆内布拉 雷亚焦油坑的中生代情形 想象图原图
成千上万的巨兽
无数庞大的开发团体
人月神话——人月神话
• 精美的烹饪需要时间
• 软件开发项目常以人月来衡量工 作，这种度量暗示着人手和时间 是可以互换的。这种“人多力量 大”的想法是一种一厢情愿的虚 妄神话。 • Brooks法则：向滞后的软件项目 追加人手会使得进度更迟缓。
• 当时的专案经理Frederick P. Brooks, Jr.事后根据这项计划的开发经 验，写作《人月神话：软件项目管理之道》（The Mythical ManMonth: Essays on Software Engineering）记述人类工程史上一项里 程碑式的大型复杂软件系统开发经验。
• 在《人月神话》中，Brooks博士为人们管理复杂的项目提供了最具洞 察力的见解，既有很多引人深思的观点，又有大量软件工程的实践。
人月神话
• 人月：软件开发过程中衡量工作量的常用度量单位。 • 而在实际情况中，增加“人”并不能缩短“月”的量 • 为什么说人月是神话？ （1）许多任务是无法拆解的 （2）即使任务可以拆解，人员之间的沟通交流时间随着 人手的增加以(n-1)*n/2的规模递增 • 如： 20人* 5个月 > 50人* 2个月
弗雷德里克· 布鲁克斯 Frederick P. Brooks, Jr.
弗雷德里克·布鲁克斯的经典著作——《人月神话》
• 2000年新年伊始，国际计算机协会（ACM）在纽约宣布 1999年图灵奖得住为时年为69岁的Frederick P. Brooks, Jr.。评选委员会主席在致辞中提到，“今天我们所看到的 计算机体系结构、软件工程及三维计算机图形，均受益于 Brooks 的开创性工作，是他改变了这些领域的面貌。 ”Brooks确实是一位在计算机科学各方面均作出杰出贡 献的奠基者。
人月神话
小组成员：
人月神话
人物简介：
• 美国工程院院士 • “IBM 360系统之父”，曾担 任360系统的项目经理，及该 项目设计阶段的经理。凭借在 此项目中的杰出贡献，在1985 年获得美国国家技术奖。 • 1999年荣获美国计算机领域最 具声望的图灵奖（ A.M.TURINGAWARD）桂冠。
• 技术并非《人月神话》的着眼点，它更关注的是软件的创造过程、需 求的变化无常和管理的永恒困境。 • 《人月神话》的中心思想已经超越了具体的时代和技术。
名家谈人月神话
• 这是一本经典著作，与软件开发有关的每一个人都应该不只一遍地读 这本书。 ——Philippe Kruchten Rational 统一过程首席架构师 • 它仍然是计算机书籍中呗引用次数最多的书籍，而且即便本书最初出 版于1975年，其内容至今仍未过时。在阅读的时候，每隔几页不说一 句“对极了！”是很难受的。 ——Stee McConnell,Construx公司首席软件工程师
• 然而，他最广为认知的功绩则是在软件领域的重要经典著 作——《人月神话》，可以说正是此书让软件工程学进入 了人们的视野。
弗雷德里克·布鲁克斯的经典著作——《人月神话》
• 《人月神话》20周年纪念版
• 《人月神话》32周年纪念版
软件领域的神话 —— 一本畅销不衰的著作
• 在计算机这个日新月异的领域中，长盛不衰的书籍几乎是凤毛麟角的 。为什么《人月神话》的魅力能不因技术的更替而黯淡，反而能在这 多变的时代中证明自己的价值，乃至有了20年，32年的纪念版出现呢 ？
《人月神话》的由来
• IBM的System/360是第一个特大型软件项目，它催生了《人月神话》
《人月神话》的由来
• System/360的开发过程被视为计算机发展史上最大的一次豪赌，为了 研发System/360这台大型机，IBM决定征召六万多名新员工，创建五 座新工厂，而当时出货的时间不断的顺延。
• 概念完整性是系统设计中最 重要的因素，尤其对大型软 件系统来说，概念完整性是 项目顺利完成的必要保障。
• 图为Reims大教堂内景，位 于巴黎的Reims是建筑史上 最富盛名的哥特式教堂建筑 之一。
人月神话——画蛇添足
• 设计者往往不肯放弃任何一个 细枝末节的创意，从而堆砌出 不胜繁复的设计，看似完美， 并现实无可行性，往往会成为 头重脚轻的空中楼阁。 • 软件项目的规划必须进行严谨 理性的估算才能为项目的顺利 进展打下牢固的根基，避免不 必要的复杂化风险。
• 图为早年新奥尔良的安东尼奥 法式餐厅的菜单
人月神话——外科Biblioteka 术队伍• 建立一个外科手术团队那样分工明 细、合作有序的开发团队，是高效 率软件开发的重要保障之一。
• 图为合众社发布的帧外科手 术新闻照片
人月神话——贵族专制、民主政治和系统设计
• 自从设计师Jean d’Ordais 制订蓝图以后，继任的8位 建筑师都理解并遵从这一初 始设计的原则，保持了概念 的完整性，最终Reims成为 无与伦比的艺术精品。
《人月神话》目录
• • • • • • • • • • 第1章 焦油坑 第2章 人月神话 第3章 外科手术队伍 第4章 贵族专制、民主政 治和系统设计 第5章 画蛇添足 第6章 贯彻执行 第7章 为什么巴比伦塔会 失败 第8章 胸有成竹 第9章 削足适履 第10章 提纲挈领 • • • • • • 第11章 未雨绸缪 第12章 干将莫邪 第13章 整体部分 第14章 祸起萧墙 第15章 另外一面 第16章 没有银弹-软件 工程中的根本和次要问题 • 第17章 再论“没有银弹” • 第18章 《人月神话》的 观点：是与非 • 第19章 20年后的《人 月神话》
• 我唯一一本读过一遍以上的书，是Fred Brooks的《人月神话》，实 际上我每过一两年就会重读一遍。部分原因是这本书文笔很好，另外 就是书中的忠告很有价值，即使是25年以后。我非常推崇这本书，这 是我唯一能想起来的能从中体会到乐趣和思想的计算机学科书籍。 ——Brian Kernighan ,著名《C程序设计语言》的合著者之一。