《人月神话》各章精选
人月神话第五章读后感
人月神话第五章读后感这一章里啊，作者大谈特谈关于进度安排的那些事儿。
以前我总觉得，做项目嘛，只要人够多，时间就肯定能缩短。
就像搬砖，人多力量大，砖很快就能搬完呗。
但是这章就像是一盆冷水，直接浇灭了我这种天真的想法。
作者说人月这个概念其实很有欺骗性。
可不是嘛，一个人干一个月的活，和十个人干一个月的活可不一样。
就好比十个人一起做饭，可能光是协调谁切菜、谁煮饭、谁炒菜就得花不少时间，说不定还会因为想法太多，在厨房里打起来呢。
软件项目也是这样，增加人手不一定能让进度加快，反而可能因为沟通成本的增加，让整个项目变得更乱。
书里提到那些被乐观估计的进度安排，简直就像我每次减肥时给自己定的目标一样不切实际。
一开始总是信心满满，觉得每天少吃一顿饭，再加上点运动，一个月就能瘦十斤。
结果呢？三天打鱼两天晒网，还总是忍不住偷吃。
软件项目里那些拍脑袋定下来的乐观进度表，最后往往也是被各种意外情况打得落花流水。
什么需求突然改变啦，技术难题冒出来啦，就像减肥时突然遇到美食的诱惑一样，让人难以招架。
还有那关于里程碑的说法也很有趣。
就像是在漫长的旅途中给自己设几个标记点，告诉自己到这儿了就离目的地更近一步。
但是设里程碑也不是乱设的，不是随便在路上插个小旗就算数。
得是真正能检验项目进展、有实际意义的点才行。
这就好比减肥的时候，不能把每天称一次体重当成唯一的里程碑，而是得看体脂率有没有下降，能不能穿上小一号的衣服之类的。
这一章读完，我算是明白了，软件项目的进度安排就像一场精密的棋局，不是简单地把棋子（人）往棋盘（项目）上一放就了事的。
得考虑到各种因素，小心谨慎地布局，不然就等着被项目这个对手将一军吧。
《人月神话》读后感（第一二章）
《⼈⽉神话》读后感（第⼀⼆章）初次听闻《⼈⽉神话》这本书，我以为它会是⼀本讲述神话或者浪漫爱情故事的书，但后来在⽼师的⼝中才了解到，这讲述的并不是什么神话、爱情故事，⽽是⼀本有关软件⼯程⽅⾯的经典著作。
经过⽼师的推荐，我抱着试⼀试的想法阅读了这本书，虽然有很多地⽅还不太明⽩，但仍然收获了很多知识。
⽬前我只阅读了前两章，借此来谈⼀谈⾃⼰的收获以及感受。
书的前两章主要讲述了两个问题——焦油坑和⼈⽉神话。
在第⼀章中，作者将软件危机⽐作了焦油坑，谈到美国20年前软件项⽬所⾯临的问题，在我们现在依然如此，糟糕的情况没有改变，⼤家仍旧在焦油坑⾥挣扎，⽽且看上去没有解决办法。
过去⼏⼗年的⼤型系统开发就犹如⼀个焦油坑，很多⼤型企业在其中剧烈地挣扎。
他们中⼤多数开发出了可运⾏的系统。
不过，其中只有⾮常少数的项⽬满⾜了⽬标、时间进度和预算的要求。
各种团队，⼤型的和⼩型的，庞杂的和精⼲的，都⼀个接⼀个淹没在了焦油坑中，被软件危机所带来的灾难覆盖。
表⾯上看起来好像没有任何⼀个单独的问题会导致困难，每个都能被解决，但是当它们相互纠缠和累积在⼀起的时候，团队的⾏动就会变得越来越慢。
对于我们⽽⾔，如果我们想解决问题，就必须试图先去理解它，了解什么是编程系统产品，同时也要找到⾃⼰职业的乐趣，因为只有发现了乐趣，⼯作才会更有积极性。
在第⼆章中，我了解到原来“⼈⽉“是我们项⽬⼯程中估计和进度安排中使⽤的⼯作量单位，⽤⼈⽉作为衡量⼀项⼯作的规模是⼀个危险和带有欺骗性的神话。
它暗⽰着⼈员数量和时间是可以相互替换的但仅适⽤于某个任务可以分解给参与⼈员，并且他们之间不需要相互的交流的情况。
因为软件开发本质上是⼀项系统⼯作——错综复杂关系下的⼀种实践——沟通、交流的⼯作量⾮常⼤，它很快会消耗任务分解所节省下来的个⼈时间。
当任务由于次序上的限制不能分解时，⼈⼿的添加对进度不会有帮助。
虽然我现在只读了前两章，但同样拓宽了⾃⼰的视野，因此我决定继续读下去，继续探索软件⼯程的奥秘。
人月神话第五章读后感
人月神话第五章读后感
这一章里，作者把外科手术团队类比软件开发团队，这个比喻可太有趣了。
就像在一个外科手术里，主刀医生那可是绝对的核心人物，其他的护士、麻醉师啥的都围着他转，给他打辅助。
在软件开发里呢，也就应该有这么个灵魂人物，那些个高手程序员就像主刀医生一样，承担着最关键的任务。
这让我一下子就明白了团队里角色分工的重要性。
不能大家都一股脑地去干同一种活儿，得像手术团队那样，各司其职，紧密配合。
不过呢，我也觉得这有点理想状态了。
现实中的软件开发团队啊，有时候就像一群无头苍蝇。
大家都觉得自己是高手，都想当那个“主刀医生”，结果就乱成一锅粥了。
不像人家外科手术团队，经过了那么多的训练，清楚地知道自己该干啥。
我们的开发团队有时候就缺乏这种明确性。
还有啊，这章让我意识到，一个好的团队结构就像一个精密的仪器。
每个部件都得恰到好处地运转。
如果团队里的沟通不畅，就像仪器里的齿轮卡壳了一样，整个项目就会停滞不前。
我就想起我之前参加的一个项目，大家都在埋头写代码，可彼此之间都不咋交流，结果最后拼凑到一起的时候，发现很多地方根本不兼容，就像拿左腿的假肢往右腿上安一样，滑稽又让人头疼。
《人月神话》各章精选
《人月神话》各章精选第1章焦油坑史前史中，没有别的场景比巨兽在焦油坑中垂死挣扎的场面更令人震撼。
上帝见证着恐龙、猛犸象、剑齿虎在焦油中挣扎。
它们挣扎得越是猛烈，焦油纠缠得越紧，没有任何猛兽足够强壮或具有足够的技巧，能够挣脱束缚，它们最后都沉到了坑底。
过去几十年的大型系统开发就犹如这样一个焦油坑，很多大型和强壮的动物在其中剧烈地挣扎。
他们中大多数开发出了可运行的系统——不过，其中只有非常少数的项目满足了目标、时间进度和预算的要求。
各种团队，大型的和小型的，庞杂的和精干的，一个接一个淹没在了焦油坑中。
表面上看起来好像没有任何一个单独的问题会导致困难，每个都能被解决，但是当它们相互纠缠和累积在一起的时候，团队的行动就会变得越来越慢。
对问题的麻烦程度，每个人似乎都会感到惊讶，并且很难看清问题的本质。
不过，如果我们想解决问题，就必须试图先去理解它。
第2章人月神话Brooks法则：向进度落后的项目中增加人手，只会使进度更加落后。
第3章外科手术队伍在计算机领域的会议中，常常听到年轻的软件经理声称他们喜欢由头等人才组成的小型、精干的队伍，而不是那些几百人的大型团队，这里的“人”当然暗指平庸的程序员。
其实我们也经常有相同的看法。
但这种幼稚的观点回避了一个很困难的问题——如何在有意义的时间进度内创建大型的系统？那么就让我们现在来仔细讨论一下这个问题的每一个方面。
第4章贵族专制、民主政治和系统设计法国城市兰斯（Reims）在建筑风格上的一致性和上面所说的大教堂形成了鲜明的对比。
设计的一致性和那些独到之处一样，同样让人们赞叹和喜悦。
如同旅游指南所述，风格的一致和完整性来自8代拥有自我约束和牺牲精神的建筑师们，他们每一个人牺牲了自己的一些创意，以获得纯粹的设计。
同样，这不仅显示了上帝的荣耀，同时也体现了他拯救那些沉醉在自我骄傲中的人们的力量。
第5章画蛇添足在开发第一个系统时，结构师倾向于精炼和简洁。
他知道自己对正在进行的任务不够了解，所以他会谨慎仔细地工作。
《人月神话》各章精选之欧阳歌谷创编
《人月神话》各章精选欧阳歌谷（2021.02.01）第1章焦油坑史前史中，没有别的场景比巨兽在焦油坑中垂死挣扎的场面更令人震撼。
上帝见证着恐龙、猛犸象、剑齿虎在焦油中挣扎。
它们挣扎得越是猛烈，焦油纠缠得越紧，没有任何猛兽足够强壮或具有足够的技巧，能够挣脱束缚，它们最后都沉到了坑底。
过去几十年的大型系统开发就犹如这样一个焦油坑，很多大型和强壮的动物在其中剧烈地挣扎。
他们中大多数开发出了可运行的系统——不过，其中只有非常少数的项目满足了目标、时间进度和预算的要求。
各种团队，大型的和小型的，庞杂的和精干的，一个接一个淹没在了焦油坑中。
表面上看起来好像没有任何一个单独的问题会导致困难，每个都能被解决，但是当它们相互纠缠和累积在一起的时候，团队的行动就会变得越来越慢。
对问题的麻烦程度，每个人似乎都会感到惊讶，并且很难看清问题的本质。
不过，如果我们想解决问题，就必须试图先去理解它。
第2章人月神话Brooks法则：向进度落后的项目中增加人手，只会使进度更加落后。
第3章外科手术队伍在计算机领域的会议中，常常听到年轻的软件经理声称他们喜欢由头等人才组成的小型、精干的队伍，而不是那些几百人的大型团队，这里的“人”当然暗指平庸的程序员。
其实我们也经常有相同的看法。
但这种幼稚的观点回避了一个很困难的问题——如何在有意义的时间进度内创建大型的系统？那么就让我们现在来仔细讨论一下这个问题的每一个方面。
第4章贵族专制、民主政治和系统设计法国城市兰斯（Reims）在建筑风格上的一致性和上面所说的大教堂形成了鲜明的对比。
设计的一致性和那些独到之处一样，同样让人们赞叹和喜悦。
如同旅游指南所述，风格的一致和完整性来自8代拥有自我约束和牺牲精神的建筑师们，他们每一个人牺牲了自己的一些创意，以获得纯粹的设计。
同样，这不仅显示了上帝的荣耀，同时也体现了他拯救那些沉醉在自我骄傲中的人们的力量。
第5章画蛇添足在开发第一个系统时，结构师倾向于精炼和简洁。
《人月神话》读后感----一到三章
《⼈⽉神话》读后感----⼀到三章《⼈⽉神话》这本书是我们⽼师推荐给我们的，同时⽼师还推荐给我们另⼀本书《梦断代码》。
由于时间的原因，我只能先选⼀本书来读。
这本书⾥⾯的好多观点，对于今天的软件⼯程依然适⽤。
如“没有银弹”这个观点，说明了作者对于软件⼯程独到的见解。
⾝为⼀名软件⼯程的学⽣，我应当仔细读完关于软件⼯程的任何⼀本书。
并将观点与想法运⽤到实际之中。
作者在第⼀章中说到，过去⼏⼗年⼤型系统的开发就像焦油坑⼀样，虽然各种各样的团队通过努⼒开发出可运⾏的系统，但是只有少数的项⽬可以开发出满⾜⽬标、时间进度和预算的要求。
作者还谈到编程的乐趣和烦恼。
编程的乐趣主要是能够⾃⼰创造⾃⼰想要的项⽬。
⽽烦恼是总是难以达到完美。
我在读到这本书的第⼆章的时候，就感到作者的见解独到。
Brooks先⽣对⼈⽉转换的观点进⾏了详细的分析，他还指出⾼层次、尖端的⼈才和低⽔平、平庸的⼯作⼈员的⼯作效率⽐会是⼗倍不⽌，所以说⼀个⼩规模的精锐的团队往往要⽐⼤规模的但是有很多平庸的程序员的团队要好得多。
前苹果公司CEO乔布斯先⽣也提出过类似的观点：“在我关注的研发领域，我发现，通常50到100个平均⽔平的⼈才，其贡献才抵得上⼀个最⾼⽔平的⼈才。
”⾼层次的⼈员效率⾼，⼈少带来的交流就少，节省交流时间，进⽽缩短⼯期。
我感觉这道理说的⼗分正确。
⼈⽉神话这⼀章表达的是对⽤⼈⽉这个单位来计量项⽬的价值本⾝是⾮常不正确的。
它看上去好像是⼈⼒和时间是可以交换的，就好⽐远古时期的部落交换东西时的想法⼀样，这种价值观是不正确的。
有时候我觉得盲⽬的增加⼈员数量只会让项⽬落后。
所以我们不要相信⼈⽉神话，⽽是通过合理的分析来制定整个项⽬的进度。
软件工程--人月神话PPT
小组成员：
人月神话
弗雷德里克·布鲁克斯 Frederick P. Brooks, Jr.
人物简介：
• 美国工程院院士
• “IBM 360系统之父”，曾担 任360系统的项目经理，及该 项目设计阶段的经理。凭借在 此项目中的杰出贡献，在1985 年获得美国国家技术奖。
• 1999年荣获美国计算机领域最 具声望的图灵奖（ A.M.TURINGAWARD）桂冠。
人月神话——祸起萧墙
• 图为1802年A.Canova所作雕 塑：英雄海格力斯（ Herculues）摔死带来死亡之 袍的信使力卡斯（Lycas）。
• 海格力斯是希腊神话中最伟大 的半人半神英雄，一生业绩辉 煌，却因微小的家庭变故摔死 不知情的力卡斯而走向了英雄 末路。
• 潜藏的小祸患看似微不足道， 有朝一日却可能葬送原本看起 来坚不可摧的事物。
• 适合的开发工具、评测技术 能有事半功倍的效果，切合 实用的工具和技术是项目团 队的重要财富。
人月神话——整体部分
• 图为迪士尼公司著名的 米老鼠魔术师形象。
• 作者认为某些泛泛号称自 己能完成庞大软件项目的 业界人士，与旧时以夸张 吹嘘来吸引观众注意的魔 术师一样，其表演的东西 经不起实质追究。
• 如： 20人* 5个月 > 50人* 2个月
《人月神话》目录
• 第1章 焦油坑 • 第2章 人月神话 • 第3章 外科手术队伍 • 第4章 贵族专制、民主政
治和系统设计 • 第5章 画蛇添足 • 第6章 贯彻执行 • 第7章 为什么巴比伦塔会
失败 • 第8章 胸有成竹 • 第9章 削足适履 • 第10章 提纲挈领
人月神话——未雨绸缪
• 在做项目设计和规划时，一定要考 虑到各种不确定的变化因素，灵活 适应多变的环境，否则很可能酿成 悲剧后果。
人月神话每一章的读书笔记
人月神话每一章的读书笔记
读第一遍的时候，里面很多的内容我觉得非常晦涩难懂，但还是坚持读了下来。
第一遍读完之后，就开始看书后的读者感言，也在网上找其他人的读后感来看，才真正加深了理解。
如果有跟我一样，在第一次读这本书觉得很难读的，我还是建议您坚持读完，然后去参考其他人的读后感，你也能领会到这本书的精华所在。
“这个领域的知识在于累积”。
这句话是我在读第二遍的时候才从序言里注意到的，我这段时间开始读书，也不断地在寻找着读书的理由，当我再次翻开第一章开头，“前车之履，后车之鉴”瞬间给我空空的脑袋灌了一壶开水：读书的理由，是在于“积累”，“总结”，用前人的知识，来铺设自己的路。
因此我也萌生了写读书笔记的想法，把自己的路真正地铺设起来。
《人月神话》是一本论文集，每一章都可以单独做为一篇论文去阅读和理解，部分章节之间也存在着统一的中心论点，所以在阅读的时候，可以不按顺序选择自己感兴趣的章节进行阅读。
我的笔记是准备读完一章写一篇，希望自己有一个好的开头也能收获一个完美的结尾。
下面就正式开始我对第一章的读书理解吧。
人月神话培训精品PPT课件
弗雷德里克·布鲁克斯的经典著作——《人月神话》
• 《人月神话》20周年纪念版 • 《人月神话》32周年纪念版
软件领域的神话 —— 一本畅销不衰的著作
• 在计算机这个日新月异的领域中，长盛不衰的书籍几乎是凤毛麟角的 。为什么《人月神话》的魅力能不因技术的更替而黯淡，反而能在这 多变的时代中证明自己的价值，乃至有了20年，32年的纪念版出现呢 ？
• 最大化资源利用率，减少 不必要的资源占用，合理
规划，巧妙的数据结构往
往大幅度地俭省资源耗费 ，提高系统运行的性能。
人月神话—— 提纲挈领
• 图为1897年美国老国会 图书馆内景。
• 作者以汗牛充栋的图书馆形象 地比如软件项目中海量的文档 令人目不暇接。
• 明智地把握好关键的几类文档 ，才能不在浩瀚的信息中迷失 ，才能迅速了解项目，进而准 确地规划下一步工作。
• 它仍然是计算机书籍中呗引用次数最多的书籍，而且即便本书最初出 版于1975年，其内容至今仍未过时。在阅读的时候，每隔几页不说一 句“对极了！”是很难受的。 ——Stee McConnell,Construx公司首席软件工程师
• 我唯一一本读过一遍以上的书，是Fred Brooks的《人月神话》，实 际上我每过一两年就会重读一遍。部分原因是这本书文笔很好，另外 就是书中的忠告很有价值，即使是25年以后。我非常推崇这本书，这 是我唯一能想起来的能从中体会到乐趣和思想的计算机学科书籍。 ——Brian Kernighan ,著名《C程序设计语言》的合著者之一。
《人月神话》的由来
• IBM的System/360是第一个特大型软件项目，它催生了《人月神话》
人月神话
Part 5
针对概念上颇具前途的方法
Outline
• 购买和自行开发 • 需求精炼和快速原型 • 增量开发——增长，而非搭建系统 • 卓越的设计人员
购买和自行开发
• 大众市场——购买比重新开发廉价（可用性、软 件包） 将软件包的通用化方面提高实现可用性： 例：个人定制软件PK购买通用软件包
• 自行开发——通用的数学和统计软件包， 以及一 些简单的编程能力 例：通用软件安装->熟练使用->简单的软件技术 ->软件产品生产
抽象数据类型 层次化类型（类 ） 银弹 否? 他们的出现仅消除了非本质困难 没有促进软件的内在问题
人工智能
AI-1:使用计算机解决以前只能通 过人类智慧解决的问题 AI-2:使用启发式和基干规则的特 定编程技术 银弹 否? 表达的简化仅能提供少量的 促进作用
专家系统
包括归纳推论引擎和规则基础的程 序 推论引擎还包括复杂逻辑或概率数 据和规则 银弹 否?
•没有银弹－软件工程中的根本和次 要问题
SUMMARY
• 贵族与制、民主政治和系统设计的 关系
• 概念完整性是贵族与制的核心
• 概念完整性系统设计的关系
SUMMARY
• 没有银弹－软件工程中的根本和次 要问题
• 银弹在哪里？ 由硬件到软件
• 没有银弹 困难度：复杂度 一致性 可变性 丌可见性
SUMMARY
“自动”编程
从问题的一段陈述说明自动产 生解决问题的程序
银弹 否? 此方法很难普及到更广泛的寻 常软件系统
图形化编程
图形化和可视化编程，计算机图 形在软件设计上的应用 银弹 否? 上述方法均未出现令人激动与 信服的进步
程序验证
测试和修复BUG
人月神话读书笔记
人月神话读书笔记《人月神话》是一本由美国计算机科学家弗雷德里克·布鲁克斯所著的经典著作，该书于1975年首次出版，并在软件开发领域产生了广泛影响。
这本书主要讨论了软件开发中的管理和计划问题，探讨了人力资源与时间的关系，以及如何提高软件开发过程的效率和质量。
本书作者弗雷德里克·布鲁克斯是一位计算机科学家和软件工程师，他曾经是IBM公司系统/360系列计算机操作系统的主要设计师之一。
在这本书中，布鲁克斯通过自己多年的实践经验和对软件开发的深入研究，对软件项目管理提出了许多有价值的见解和原则。
在《人月神话》一书中，布鲁克斯首先提出了“人月神话”的概念，指出在软件开发中，增加人力资源并不能缩短项目的开发时间，因为新加入的人员需要时间来熟悉整个项目的背景和细节，这反而会增加协同工作的复杂性和沟通成本。
换句话说，增加人员只会使项目进度更加拖延，而不会加快开发进度。
布鲁克斯进一步探讨了软件开发过程中的各种难题和挑战，并提出了一些解决这些问题的方法和技巧。
例如，他提出了“拆分”和“增量开发”的概念，认为将一个大型的软件项目分割成多个较小的子项目，并按照优先级进行开发，可以降低复杂性和风险，并提高软件开发过程的透明度和可控性。
此外，本书还讨论了软件项目管理中的人力资源分配和团队建设等问题。
布鲁克斯指出，一个成功的软件开发团队应该由高质量的人员组成，并给予他们足够的自由度和创造空间。
他还提到了软件工程师的培训和职业发展等方面的问题，强调了持续学习和自我提升的重要性。
总的来说，我认为《人月神话》这本书给我留下了深刻的印象。
作者通过丰富的实践经验和理论知识，深入剖析了软件开发中的种种问题和挑战，并提出了很多有价值的见解和解决方案。
我从中学到了很多关于软件项目管理和团队协作的经验和方法，这对我今后的工作和学习将会有很大的帮助。
然而，尽管这本书有很多有价值的观点，但我也认为其中的某些理论在现代软件开发环境中可能并不适用。
【读书笔记】人月神话
手册结束 – 时间：进度表 – 资金：预算 – 地点：工作空间分配 – 人员：组织图
26/49
焦油坑之三--文档问题
自文档化的程序 – 为什么提倡自文档化程序？
数据处理的基本原理告诉我们，试图把信息放在不同文件中，并试图维 护它们的同步是件费力不讨好的事情。在软件开发里，我们却试图维护 一份机器可读的程序，以及一系列包含记述性文字和流程图的文档。
史前
今天
焦油坑
大型软件项目
• 图为洛杉矶自然历史博物馆 George C.Page馆内布拉雷亚 焦油坑的中生代情形想象图原 图
吞噬 成千上万的巨兽
围困 无数庞大的开发团体
11/49
软件开发中的焦油坑
“史前史中，没有别的场景比巨兽在焦油坑中垂死挣扎的场面更令人震 撼。上帝见证着恐龙、剑齿虎在焦油中的挣扎。它们挣扎的越是猛烈， 焦油越是缠的越紧，没有任何猛兽足够强壮或具有足够的技巧，能够 挣脱束缚，它们最后都沉到了坑底。” ——Brooks
• 精美的烹饪需要时间
• 软件开发项目常以人月来衡量工 作，这种度量暗示着人手和时间 是可以互换的。这种“人多力量 大”的想法是一种一厢情愿的虚 妄神话。
• Brooks法则：向滞后的软件项目 追加人手会使得进度更迟缓。
• 图为早年新奥尔良的安东尼奥法式餐厅的菜单
28/49
人月神话——外科手术队伍
6/49
《人月神话》的由来
• IBM的System/360是第一个特大型软件项目，它催生了《人月神话》
7/49
《人月神话》的由来
• System/360的开发过程被视为计算机发展史上最大的一次豪赌，为了 研发System/360这台大型机，IBM决定征召6万多名新员工，创建五5 座新工厂，当时的研发费用超过了50亿美元（相当于现在的340亿美元， 约2200亿人民币），但出货的时间不断的顺延。
人月神话(40周年中文纪念版)读后感10篇
人月神话(40周年中文纪念版)读后感10篇《人月神话(40周年中文纪念版)》是一本由(美) 布鲁克斯(Brooks, F. P.) 著著作，清华大学出版社出版的平装图书，本书定价：68.00元，页数：392，特精心从网络上整理的一些读者的读后感，希望对大家能有帮助。
《人月神话(40周年中文纪念版)》读后感(一)：懷一個孩子需要九個月，無論你把任務分給多少個女人。
標題背後的意思很明確，就是說程序有著穩定的成熟期，並非人越多所用的時間就能夠越短。
軟件工程基本上可以說是“關係”科學，它的研究對象就是概念之間的關係和人與概念的關係，自有一套難弄的邏輯。
有時你要對付的不是什麼數學問題，而是你的同事或者看不見的同行，因為大家的努力，都用在彼此相容上，或者說，問題的關鍵，在於靈活性和紀律性之間的平衡。
這是一門至今混亂同時也變化多端的科學。
作者如同標題名言之外的另一條名言是“在延期的課題中加入人力只能讓它延遲更多”意即，一個延期的課題，往往比較複雜，修改很多，如果再有新人參與，合作會更加困難，短期之內看不到人力增加的效果，反而會因為配合問題降低效率。
軟件工程不僅會受到人的干預，技術開發還會明顯受市場左右，新技術往往要讓位給利益、技術和商業，往往遵循的是兩套邏輯。
《人月神话(40周年中文纪念版)》读后感(二)：神作！非常好的一本书！五星！神作！扉页上的数字表明，这本书购于2021.6，我足足看了1年3个月。
分了6个晚上，陆陆续续看完了。
一直拖着没看完，实因其中理论较庞杂，且时有妙语，细细品味为佳。
1975年写成的书，在40年后的今天大部分理论仍然适用，且不停被引用到项目管理，软件开发排期，编程语言的选择，组织结构的调整，增量迭代开发(敏捷)，快速验证原型等诸多领域上，Brooks真乃神人也！恰巧今晚看到"程序员那些事儿"推了Brooks的言论"一个程序员一个月完成的编程工作，不要让两个程序员花两个月完成"，可知人月不能互相转换已经达成共识。
《人月神话》著名句子
《人月神话》中的著名句子有：
1、祸起萧墙。
2、一天一天的进度落后比起重大灾难，更难以识别，更不容易防范和更加难以弥补。
3、根据一个严格的进度表来控制项目的第一个步骤是制订进度表，进度表由里程碑和日期组成。
4、里程碑必须是具体的、特定的、可度量的事件，能进行清晰能定义。
5、如果里程碑定义得非常明确，以致于无法自欺欺人时，程序员很少会就里程碑的进展弄虚作假。
6、Practice is the best of all instructors.（实践是最好的老师。
）
7、Experience is a dear teacher, but fools will learn at no other.（经验是昂贵的教师，但愚蠢的人从不向他人学习。
）
8、There is nothing in this world constant but inconstancy.（在这个世界上，没有什么比变化更加恒定不变的了。
）。
人月神话读书笔记
人月神话读书笔记第一篇：人月神话读书笔记人月神话这本书几年前就听别人说是本很经典的软件开发方面的书，这本书的成功之处在于他思想的前卫性，以至于不只是软件行业的人在读。
现在终于找到读他的理由了，可以感受一下大师的杰作。
在读之前我已经读过了软件工艺和极限编程，为什么留到最后读人月神话呢？主要是因为我觉得一本能够流传30年还被人们津津乐道的书，肯定是本学要好好细读的书，所以留到了最后。
按照前两篇读书笔记的惯例，前面几段是一些我读书时的感受和收获，还有一些对内容的评价。
从这本书的内容来看，对于一个项目经理来说肯定会有更大的收获，这本书主要是针对软件开发管理方面的内容，这主要原因可能是因为作者以前就是项目的管理者，他是站在管理者的角度写的。
即便这样，对于一个从来没有参与过真实项目开发，更没有领导过团队的我还是有一定的吸引力，这本书中我最喜欢的就是前四章（焦油坑、人月神话、外科手术队伍、贵族专制、民主政治和系统设计）和没有银弹这章。
这本书里面为了论证某一观点，会举出许多实际的项目作为证据，这一点非常好，事实胜于雄辩嘛！这些例子也许对于作者那个年代的人来说很好理解，但是放在30年后来看这些例子又有些陈旧和难懂了。
另外，从文中我发现作者非常注重文档，一个优质的文档就是项目成功的保证，这一点与传统的软件工程很相似，但是却与极限编程的观点相悖。
下面就是一些读书的总结了。
焦油坑1. 编程系统产品开发的工作量是供个人使用的、独立开发的构件程序的九倍。
2. 编程行业的一些内在固有苦恼：l 将做事方式调整到追求完美，是学习编程的最困难部分。
l 由其他人来设定目标，并且必须依靠自己无法控制的事物。
l 真正的权威来自于每次任务的完成。
l 任何创造性活动都伴随着枯燥艰苦的劳动，编程也不例外l 人们通常期望项目在接近结束时（bug、工作时间）能收敛得快一些，然而软件项目的情况却是越接近完成，收敛得越慢。
l 产品在即将完成时总面临着陈旧过时的威胁。
《人月神话》读后感（第七八章）
《⼈⽉神话》读后感（第七⼋章）
第七章——为什么巴别塔会失败：
在这⼀章节开头，作者⾸先写道巴⽐伦塔是⼈类继诺亚⽅⾈之后的第⼆⼤⼯程壮举，但巴⽐伦塔同时也是第⼀个
彻底失败的⼯程。
对于任何⼀个⼯程项⽬，如果想要取得成功，就必须具备以下条件：清晰的⽬标、⼈⼒、材料、⾜
够的时间和⾜够的技术。
在巴别塔项⽬开发过程中，开发者有着清晰的⽬标、充⾜的⼈⼒、材料、技术和时间，那他们为什么会失败呢？原因很简单，因为巴别塔的建造⼈员缺乏沟通，从⽽⽆法合作。
当合作⽆法进⾏时，⼯作就陷⼊了停顿。
，项⽬失败的结果也就可想⽽知了。
⼤型软件⼯程应有不同层次的沟通，并⽤项⽬⼯作⼿册规定定义接⼝与划分以减少交流所需的⼯作量；软件⼯程的组织结构应采取树形结构，以保证有效的沟通。
第⼋章——胸有成⽵：
这⼀章主要讲述了对⽣产率的估计，⼯作量＝（常数）×（指令的数量）1.5，还总结了⼀些软件⼯程中⼀些对⽣产率进⾏估计的技术。
关于人月神话读书笔记300字：观点相悖
三一文库（）/其他范文/读书笔记关于人月神话读书笔记300字：观点相悖《人月神话》内容源于作者brooks在ibm公司任system计算机系列以及其庞大的软件系统os项目经理时的实践经验。
关于人月神话读书笔记300字思路清晰。
关于人月神话读书笔记300字：观点相悖《人月神话》这本书几年前就听别人说是本很经典的软件开发方面的书，这本书的成功之处在于他思想的前卫性，以至于不只是软件行业的人在读。
现在终于找到读他的理由了，可以感受一下大师的杰作。
在读之前我已经读过了软件工艺和极限编程，为什么留到最后读人月神话呢?主要是因为我觉得一本能够流传30年还被人们津津乐道的书，肯定是本学要好好细读的书，所以留到了最后。
按照前两篇读书笔记的惯例，前面几段是一些我读书时的感受和收获，还有一些对内容的评价。
从这本书的内容来看，对于一个项目经理来说肯定会有更大的收获，这本书主要是针对软件开发管理方面的内容，这主要原因可能是因为作者以前就是项目的管理者，他是站在管理者的角度写的。
即便这样，对于一个从来没有参与过真实项目开发，更没有领导过团队的我还是有一定的吸引力，这本书中我最喜欢的就是前四章(焦油坑、人月神话、外科手术队伍、贵族专制、民主政治和系统设计)和没有银弹这章。
这本书里面为了论证某一观点，会举出许多实际的项目作为证据，这一点非常好，事实胜于雄辩嘛!这些例子也许对于作者那个年代的人来说很好理解，但是放在30年后来看这些例子又有些陈旧和难懂了。
另外，从文中我发现作者非常注重文档，一个优质的文档就是项目成功的保证，这一点与传统的软件工程很相似，但是却与极限编程的观点相悖。
关于人月神话读书笔记300字到这里就结束了，你从中得到了什么启发呢？相关推荐：初中生寒假读书笔记范文大全：《假如给我三天光明》高中读书笔记大全老舍《我这一辈子》读书笔记名人传读书笔记800字左右少儿读物《小王子》读书笔记傅雷家书读书笔记300字大全《听听那冷雨》读书笔记《象人》读书笔记1000字范文大卫科波菲尔的读书笔记优秀读书笔记：香草不是笨小孩的读书笔记。
中国神话故事天神帝俊和日月神话快乐读书吧中原文
中国神话故事天神帝俊和日月神话快乐读书吧中原文遥远的东方大洋浩瀚、汹涌的海水中，生长着一棵极为高大而繁茂的扶桑树。
它是一株同根偶生、两干互相依倚交叉在一起的巨树。
它扎根于海水之下的岩礁上，伸出海面达百里之高。
扶桑树的顶端立有一只神奇的玉鸡，它腹部红色，头颈处却像美玉一样是纯白的，并发出宝石般的光泽。
每天夜里它都会准时鸣叫，呼唤、提醒着太阳要准时出发，把光明送给人间。
当它啼叫过五次之后，太阳就会在它的催促之下准时登上扶桑树，准备自己的行程。
太阳神帝俊与月神嫦羲每天和晚上都是从扶桑升起，驾着自己金银的车辆，经过一天的驱驰，最后在西方的大海中缓缓下降，结束他们一天的工作。
在西方大洋——大西洋中同样也有一棵像扶桑一样的高大的巨树，它的名字叫若木，开满了大如车轮的五彩的若花。
每当太阳到达若木之时，若花的色彩变得那么鲜红娇艳，以致于把整个天空都映得红彤彤的;而当月亮到达若木时，若花的色彩则洁白如银，并散发出浓烈的馨香。
在这里，他们通常都会受到海洋之神禺京与专司黄昏与黎明之神的热情欢迎。
帝俊与嫦羲稍事休息之后，再继续他们的行程，经过大地的另一面，重新回到东方的扶桑之地。
每天早晨太阳神回到扶桑，他都会停下车儿，在扶桑下面的海水中尽情畅游、沐浴，洗掉一天的风尘与劳累。
由于太阳神常常在这里洗浴，这里的海水比其他地方都要温暖许多，水汽升腾，云蒸霞蔚，使这儿远望过去犹如一只热汤之锅，所以这里既叫扶桑之国，也叫汤谷;由于这里正是太阳升起的地方，它又被命名为日本，流经这儿沐浴过太阳的温暖海流也被人们称为日本暖流。
帝俊与嫦羲常常沿着同一条线路绕着高远的天空驱驰着他们的车马，日久天长，他们就渐生情愫，爱情的种子在他们的心中萌芽与生长。
爱神云若则用自己的金炬极力促成着这对光明之神的结合。
他们在南方衡山之中一座名为卫丘的小山上建造了一座宏大美丽的琼楼作为他们温馨的家，生下了十二位如同花朵般美丽的女儿。
这十二位女儿正好是在十二个月份里分别出生的，于是他们就决定分别用十二种花朵的名字作为女儿们的爱称。
人月神话(精简)
《人月神话》目录
• • • • • • • • • • 第1章 焦油坑 第2章 人月神话 第3章 外科手术队伍 第4章 贵族专制、民主政 治和系统设计 第5章 画蛇添足 第6章 贯彻执行 第7章 为什么巴比伦塔会 失败 第8章 胸有成竹 第9章 削足适履 第10章 提纲挈领 • • • • • • 第11章 未雨绸缪 第12章 干将莫邪 第13章 整体部分 第14章 祸起萧墙 第15章 另外一面 第16章 没有银弹-软件 工程中的根本和次要问题 • 第17章 再论“没有银弹” • 第18章 《人月神话》的 观点：是与非 • 第19章 20年后的《人 月神话》
• 图为位于英格兰东南部的 巨石阵的想象复原图。
人月神话——祸起萧墙
• 海格力斯是希腊神话中最伟大 的半人半神英雄，一生业绩辉 煌，却因微小的家庭变故摔死 不知情的力卡斯而走向了英雄 末路。 • 潜藏的小祸患看似微不足道， 有朝一日却可能葬送原本看起 来坚不可摧的事物。 • 项目进度的滞后经常源自不易 擦觉的点滴延误的积累。应尽 量明确量化阶段性目标，定期 验收、调整。
• 图为1802年A.Canova所作雕 塑：英雄海格力斯（ Herculues）摔死带来死亡之 袍的信使力卡斯（Lycas）。
人月神话——没有银弹-软件工程中的根本和次要问
题
消灭 银弹 人狼
攻克
软件项目 “焦油坑”危机
• 图为1685年德国线刻板画 的人狼故事
• 是否存在消灭人狼的法宝——银弹？ • 由于软件的复杂性、一致性、变化性和 不可见性，解决软件危机的银弹并不存 在 • 没有任何一种单独的软件工程可以让软 件开发的效率提高一个数量级。
人月神话——焦油坑
史前 今天
焦油坑
大型软件项目
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
《人月神话》各章精选
第1章焦油坑
史前史中，没有别的场景比巨兽在焦油坑中垂死挣扎的场面更令人震撼。
上帝见证着恐龙、猛犸象、剑齿虎在焦油中挣扎。
它们挣扎得越是猛烈，焦油纠缠得越紧，没有任何猛兽足够强壮或具有足够的技巧，能够挣脱束缚，它们最后都沉到了坑底。
过去几十年的大型系统开发就犹如这样一个焦油坑，很多大型和强壮的动物在其中剧烈地挣扎。
他们中大多数开发出了可运行的系统——不过，其中只有非常少数的项目满足了目标、时间进度和预算的要求。
各种团队，大型的和小型的，庞杂的和精干的，一个接一个淹没在了焦油坑中。
表面上看起来好像没有任何一个单独的问题会导致困难，每个都能被解决，但是当它们相互纠缠和累积在一起的时候，团队的行动就会变得越来越慢。
对问题的麻烦程度，每个人似乎都会感到惊讶，并且很难看清问题的本质。
不过，如果我们想解决问题，就必须试图先去理解它。
第2章人月神话
Brooks法则：
向进度落后的项目中增加人手，只会使进度更加落后。
第3章外科手术队伍
在计算机领域的会议中，常常听到年轻的软件经理声称他们喜欢由头等人才组成的小型、精干的队伍，而不是那些几百人的大型团队，这里的“人”当然暗指平庸的程序员。
其实我们也经常有相同的看法。
但这种幼稚的观点回避了一个很困难的问题——如何在有意义的时间进度内创建大型的系统？那么就让我们现在来仔细讨论一下这个问题的每一个方面。
第4章贵族专制、民主政治和系统设计
法国城市兰斯（Reims）在建筑风格上的一致性和上面所说的大教堂形成了鲜明的对比。
设计的一致性和那些独到之处一样，同样让人们赞叹和喜悦。
如同旅游指南所述，风格的一致和完整性来自8代拥有自我约束和牺牲精神的建筑师们，他们每一个人牺牲了自己的一些创意，以获得纯粹的设计。
同样，这不仅显示了上帝的荣耀，同时也体现了他拯救那些沉醉在自我骄傲中的人们的力量。
第5章画蛇添足
在开发第一个系统时，结构师倾向于精炼和简洁。
他知道自己对正在进行的任务不够了解，所以他会谨慎仔细地工作。
在设计第一个项目时，他会面对不断产生的装饰和润色功能。
这些功能都被搁置在一边，作为“下一个”项目的内容。
第一个项目迟早会结束，而此时的结构师，对这类系统充满了十足的信心，熟练掌握了相应的知识，并且时刻准备开发第二个系统。
第二个系统是设计师们所设计的最危险的系统。
第6章贯彻执行
假设一个项目经理已经拥有行事规范的结构师和许多编程实现人员，那么他如何确保每个人听从、理解并实现结构师的决策？对于一个由1000人开发的系统，一个10个结构师的小组如何保持系统概念上的完整性？在System/360硬件设计工作中，我们摸索出来一套实现上述目标的方法，它们对于软件项目同样适用。
第7章为什么巴比伦塔会失败？
那么，既然他们具备了所有的这些条件，为什么项目还会失败呢？他们还缺乏些什么？两个方面——交流，以及交流的结果——组织。
他们无法相互交谈，从而无法合作。
当合作无法进行时，工作陷入了停顿。
通过史书的字里行间，我们推测交流的缺乏导致了争辩、沮丧和群体猜忌。
很快，部落开始分裂——大家选择了孤立，而不是互相争吵。
第8章胸有成竹
系统编程需要花费多长的时间？需要多少的工作量？如何进行估计？
第9章削足适履
创造出自精湛的技艺，精炼、充分和快速的程序也是如此。
技艺改进的结果往往是战略上的突破，而不仅仅是技巧上的提高。
这种战略上突破有时是一种新的算法，如快速傅立叶变换，或者是将比较算法的复杂度从n2降低到n log n。
更普遍的是，战略上突破常来自数据或表的重新表达——这是程序的核心所在。
第10章提纲挈领
我记得曾经有一个项目，在三年的开发周期中，机器指令计数器的设计每六个月变化一次。
在某个阶段，需要好一点的性能时，指令计数器采用触发器来实现；下一个阶段，成本降低是主要的焦点，指令计数器采用内存来实现。
在另一个项目中，我所见过的最好的一个项目经理常常充当一个大型调速轮的角色，他的惯性降低了来自市场和管理人员的起伏波动。
第11章未雨绸缪
因此，管理上的问题不再是“是否构建一个试验性的系统，然后抛弃它？”你必须这样做。
现在的问题是“是否预先计划抛弃原型的开发，或者是否将该原型发布给用户？”从这个角度看待问题，答案更加清晰。
将原型发布给用户，可以获得时间，但是它的代价高昂——对于用户，使用极度痛苦；对于重新开发的人员，分散了精力；对于产品，影响了声誉，即使最好的再设计也难以挽回名声。
因此，为舍弃而计划，无论如何，你一定要这样做。
第12章干将莫邪
就工具而言，即使是现在，很多软件项目仍然像一家五金店。
每个骨干人员都仔细地保管自己工作生涯中搜集的一套工具集，这些工具成为个人技能的直观证明。
正是如此，每个编程人员也保留着编辑器、排序、内存信息转储、磁盘实用程序等工具。
这种方法对软件项目来说是愚蠢的。
第13章整体部分
和古老的神话里一样，现代神话里也总有一些爱吹嘘的人：“我可以编写控制航空货运、拦截弹道导弹、管理银行账户、控制生产线的系统。
”对这些人，回答很简单，“我也可以，任何人都可以，但是其他人成功了吗？”
第14章祸起萧墙
当一线经理发现自己的队伍出现了计划偏离时，他肯定不会马上赶到老板那里去汇报这个令人沮丧的消息。
团队可以弥补进度偏差，他可以想出应对方法或者重新安排进度以解决问题，为什么要去麻烦老板呢？从这个角度来看，好像还不错。
解决这类问题的确是一线经理的职责。
老板已经有很多需要处理的真正的烦心事了，他不想被更多的问题打搅。
因此，所有的污垢都被隐藏在地毯之下。
有两种掀开毯子把污垢展现在老板面前的方法，它们必须都被采用。
一种是减少角色冲突和鼓励状态共享，另一种是猛地拉开地毯。
第15章另外一面
面对那些文档“简约”的程序，我们中的大多数人都不免曾经暗骂那些远在他方的匿名作者。
因此，一些人试图向新人慢慢地灌输文档的重要性：旨在延长软件的生命期、克服惰性和进度的压力。
但是，很多次尝试都失败了，我想很可能是由于我们使用了错误的方法。
第16章没有银弹
在所有恐怖民间传说的妖怪中，最可怕的是人狼，因为它们可以完全出乎意料地从熟悉的面孔变成可怕的怪物。
为了对付人狼，我们在寻找可以消灭它们的银弹。
大家熟悉的软件项目具有一些人狼的特性（至少在非技术经理看来），常常看似简单明了的东西，却有可能变成一个落后进度、超出预算、存在大量缺陷的怪物。
因此，我们听到了近乎绝望的寻求银弹的呼唤，寻求一种可以使软件成本像计算机硬件成本一样降低的尚方宝剑。
但是，我们看看近十年来的情况，没有银弹的踪迹。
没有任何技术或管理上的进展，能够独立地许诺在生产率、可靠性或简洁性上取得数量级的提高。
本章中，我们试图通过分析软件问题的本质和很多候选银弹的特征，来探索其原因。
第17章再论《没有银弹》
《没有银弹》中声称和断定，在近十年内，没有任何单独的软件工程进展可以使软件生产率有数量级的提高（引自1986年的版本）。
现在已经是第九个年头，因此也该看看是否这些预言得到了应验。
《人月神话》一文被大量地引用，很少存在异议；相比之下，《没有银弹》却引发了众多的辩论，编辑收到了很多文章和信件，至今还在延续3。
他们中的大多数攻击其核心论点和我的观点——没有神话般的解决方案，以及将来也不会有。
他们大都同意《没有银弹》一文中的多数观点，但接着断定实际存在着杀死软件怪兽的银弹——由他们所发明的银弹。
今天，当我重新阅读一些早期的反馈，我不禁发现在1986年～1987年期间，曾被强烈推崇的秘方并没有出现所声称的戏剧性效果。
第18章《人月神话》的观点：是或非？
现在我们对软件工程的了解比1975年要多得多。
那么在1975年版本的人月神话中，哪些观点得到了数据和经验的支持？哪些观点被证明是不正确的？又有哪些观点随着世界的变化，显得陈旧过时呢？为了帮助判断，我将1975年书籍中的论断毫无更改地抽取出来，以摘要的形式列举在下面——它们是当年我认为将会是正确的：客观事实和经验中推广的法则。
（你也许会问，“如果这些就是那本书讲的所有东西，为什么要花177页的篇幅来论述？”）方括号中的评论是新增内容。
第19章 20年后的人月神话
为什么《人月神话》得以持续？为什么看上去它仍然和现在的软件实践相关？为什么它还拥有软件工程领域以外的读者群，律师、医生、社会学家、心理学家，和软件人员一样，不断地对这本书提出评论意见，引用它，并和我保持通信？20年前的一本关于30年前软件开发经验的书，如何能够依然和现实情况相关？更不用说有所帮助了。