【读书笔记】人月神话
《人月神话》读书笔记
《⼈⽉神话》读书笔记Photo by Janik Butz from Pexels前⾔：我很庆幸读到了这本书，这本神作。
或许它不能帮我解决我⽬前遇到的任何问题，但是可以帮助我拓宽思维，从前⼈⼤师的视⾓看待软件开发。
⽆需更多的⾔语表达对于这本书的赞美与推崇，这是⼀本软件开发⼈员必须多读的书籍。
摘⾃维基百科介绍：《⼈⽉神话：软件项⽬管理之道》（英语：The Mythical Man-Month: Essays on Software Engineering）是由IBM 系统之⽗所著经典⽂集，全书讲解、相关课题，被誉为软件领域的圣经。
对于⼈⽉的解释：⼈⽉（英语：man-month）指的是“⼀个⼈要花⼏个⽉”才能完成软件开发的单位，⽐如⼀个项⽬ 5个⼈合作开发需要 2个⽉的时间，那么总⼯作量就是 10⼈⽉。
另外，⼈⽉神话这本书的英⽂名是The Mythical Man-Month，有些⼈简称为 MMM注：笔者注记将以这种下划线引⽤添加到正⽂部分，因为本⽂是读书笔记加⼀些反思，⼀些章节只会挑选⼀些重要的、启发性的⽂本加上笔者的概括描述。
原⽂中⽐较重要的段落将以加粗等形式标注。
1. 焦油坑图⽚来源：史前史中，没有别的场景⽐巨兽在焦油坑中垂死挣扎的场⾯更令⼈震撼。
上帝见证着恐龙、猛犸象、剑齿虎在焦油中挣扎。
它们挣扎得越是猛烈，焦油纠缠得越紧，没有任何猛兽⾜够强壮或具有⾜够的技巧，能够挣脱束缚，它们最后都沉到了坑底。
过去⼏⼗年的⼤型系统开发就犹如这样⼀个焦油坑，很多⼤型和强壮的动物在其中剧烈地挣扎。
各种团队，⼤型的和⼩型的，庞杂的和精⼲的，⼀个接⼀个淹没在了焦油坑中。
表⾯上看起来好像没有任何⼀个单独的问题会导致困难，每个都能被解决，但是当它们相互纠缠和累积在⼀起的时候，团队的⾏动就会变得越来越慢。
软件开发的另⼀个难题，是从单⼀程序到软件系统过程中，所造成复杂度的快速上升，期间并需要包含不同的活动与技能，使得软件开发必须⾯对多样性的挑战。
《人月神话》读后感（五篇范例）
《人月神话》读后感（五篇范例）第一篇：《人月神话》读后感《人月神话》读后感在软件领域中,很少能有像《人月神话》一样具有深远影响力和畅销不衰的著作。
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 产品在即将完成时总面临着陈旧过时的威胁。
人月神话读书笔记
人月神话读书笔记第一篇：人月神话读书笔记人月神话这本书几年前就听别人说是本很经典的软件开发方面的书，这本书的成功之处在于他思想的前卫性，以至于不只是软件行业的人在读。
现在终于找到读他的理由了，可以感受一下大师的杰作。
在读之前我已经读过了软件工艺和极限编程，为什么留到最后读人月神话呢？主要是因为我觉得一本能够流传30年还被人们津津乐道的书，肯定是本学要好好细读的书，所以留到了最后。
按照前两篇读书笔记的惯例，前面几段是一些我读书时的感受和收获，还有一些对内容的评价。
从这本书的内容来看，对于一个项目经理来说肯定会有更大的收获，这本书主要是针对软件开发管理方面的内容，这主要原因可能是因为作者以前就是项目的管理者，他是站在管理者的角度写的。
即便这样，对于一个从来没有参与过真实项目开发，更没有领导过团队的我还是有一定的吸引力，这本书中我最喜欢的就是前四章（焦油坑、人月神话、外科手术队伍、贵族专制、民主政治和系统设计）和没有银弹这章。
这本书里面为了论证某一观点，会举出许多实际的项目作为证据，这一点非常好，事实胜于雄辩嘛！这些例子也许对于作者那个年代的人来说很好理解，但是放在30年后来看这些例子又有些陈旧和难懂了。
另外，从文中我发现作者非常注重文档，一个优质的文档就是项目成功的保证，这一点与传统的软件工程很相似，但是却与极限编程的观点相悖。
下面就是一些读书的总结了。
焦油坑1. 编程系统产品开发的工作量是供个人使用的、独立开发的构件程序的九倍。
2. 编程行业的一些内在固有苦恼：l 将做事方式调整到追求完美，是学习编程的最困难部分。
l 由其他人来设定目标，并且必须依靠自己无法控制的事物。
l 真正的权威来自于每次任务的完成。
l 任何创造性活动都伴随着枯燥艰苦的劳动，编程也不例外l 人们通常期望项目在接近结束时（bug、工作时间）能收敛得快一些，然而软件项目的情况却是越接近完成，收敛得越慢。
l 产品在即将完成时总面临着陈旧过时的威胁。
人月神话读后感
人月神话读后感《人月神话》读后感《人月神话》是一本由弗雷德里克·布鲁克斯所著的软件工程领域经典著作。
这本书首次出版于1975年，至今已经被翻译成多种语言并广泛流传。
在这本书中，布鲁克斯提出了许多关于软件开发的观点和原则，对软件工程领域产生了深远的影响。
在读完《人月神话》之后，我深受启发。
这本书不仅仅是一本关于软件开发的著作，更是一部关于团队合作、项目管理和创新思维的指南。
布鲁克斯在书中提出了许多深刻的观点，让我对软件开发这个领域有了更深入的理解。
首先，我深受布鲁克斯关于“人月神话”的观点所感动。
在书中，他指出了一个常见的误区，即认为增加人手就能够加快项目的进度。
然而，布鲁克斯指出，人手的增加并不一定会带来效率的提升，反而可能会导致更多的沟通成本和管理成本。
这一观点让我深刻地意识到，团队的规模并不代表团队的效率，而是需要通过合理的规划和管理来提高项目的执行效率。
其次，布鲁克斯在书中提出了“二次系统效应”的概念。
他指出，当一个软件系统经过一次开发之后，随着需求的变化和新的功能的增加，系统的复杂度会呈指数级增长。
这一观点让我意识到，软件开发并不是一次性的任务，而是需要不断地进行迭代和优化。
只有不断地对系统进行重构和改进，才能够应对不断变化的需求和挑战。
另外，布鲁克斯还在书中提出了许多关于项目管理和团队合作的建议。
他强调了团队的沟通和协作的重要性，以及项目计划和进度的管理。
这些建议无疑对我在实际工作中的团队合作和项目管理产生了积极的影响。
我意识到，一个成功的项目不仅需要技术上的创新，更需要团队之间的有效沟通和协作，以及合理的项目规划和管理。
总的来说，读完《人月神话》之后，我对软件开发这个领域有了更深入的理解。
布鲁克斯在书中提出的观点和原则，让我意识到软件开发不仅仅是技术上的挑战，更是一个需要团队合作、项目管理和创新思维的领域。
我相信，这些观点和原则将对我未来的工作产生深远的影响，帮助我更好地应对软件开发中的各种挑战和问题。
人月神话每一章的读书笔记
人月神话每一章的读书笔记
读第一遍的时候，里面很多的内容我觉得非常晦涩难懂，但还是坚持读了下来。
第一遍读完之后，就开始看书后的读者感言，也在网上找其他人的读后感来看，才真正加深了理解。
如果有跟我一样，在第一次读这本书觉得很难读的，我还是建议您坚持读完，然后去参考其他人的读后感，你也能领会到这本书的精华所在。
“这个领域的知识在于累积”。
这句话是我在读第二遍的时候才从序言里注意到的，我这段时间开始读书，也不断地在寻找着读书的理由，当我再次翻开第一章开头，“前车之履，后车之鉴”瞬间给我空空的脑袋灌了一壶开水：读书的理由，是在于“积累”，“总结”，用前人的知识，来铺设自己的路。
因此我也萌生了写读书笔记的想法，把自己的路真正地铺设起来。
《人月神话》是一本论文集，每一章都可以单独做为一篇论文去阅读和理解，部分章节之间也存在着统一的中心论点，所以在阅读的时候，可以不按顺序选择自己感兴趣的章节进行阅读。
我的笔记是准备读完一章写一篇，希望自己有一个好的开头也能收获一个完美的结尾。
下面就正式开始我对第一章的读书理解吧。
人月神话读书笔记
人月神话读书笔记第一篇：人月神话读书笔记人月神话这本书几年前就听别人说是本很经典的软件开发方面的书，这本书的成功之处在于他思想的前卫性，以至于不只是软件行业的人在读。
现在终于找到读他的理由了，可以感受一下大师的杰作。
在读之前我已经读过了软件工艺和极限编程，为什么留到最后读人月神话呢？主要是因为我觉得一本能够流传30年还被人们津津乐道的书，肯定是本学要好好细读的书，所以留到了最后。
按照前两篇读书笔记的惯例，前面几段是一些我读书时的感受和收获，还有一些对内容的评价。
从这本书的内容来看，对于一个项目经理来说肯定会有更大的收获，这本书主要是针对软件开发管理方面的内容，这主要原因可能是因为作者以前就是项目的管理者，他是站在管理者的角度写的。
即便这样，对于一个从来没有参与过真实项目开发，更没有领导过团队的我还是有一定的吸引力，这本书中我最喜欢的就是前四章（焦油坑、人月神话、外科手术队伍、贵族专制、民主政治和系统设计）和没有银弹这章。
这本书里面为了论证某一观点，会举出许多实际的项目作为证据，这一点非常好，事实胜于雄辩嘛！这些例子也许对于作者那个年代的人来说很好理解，但是放在30年后来看这些例子又有些陈旧和难懂了。
另外，从文中我发现作者非常注重文档，一个优质的文档就是项目成功的保证，这一点与传统的软件工程很相似，但是却与极限编程的观点相悖。
下面就是一些读书的总结了。
焦油坑1. 编程系统产品开发的工作量是供个人使用的、独立开发的构件程序的九倍。
2. 编程行业的一些内在固有苦恼：l 将做事方式调整到追求完美，是学习编程的最困难部分。
l 由其他人来设定目标，并且必须依靠自己无法控制的事物。
l 真正的权威来自于每次任务的完成。
l 任何创造性活动都伴随着枯燥艰苦的劳动，编程也不例外l 人们通常期望项目在接近结束时（bug、工作时间）能收敛得快一些，然而软件项目的情况却是越接近完成，收敛得越慢。
l 产品在即将完成时总面临着陈旧过时的威胁。
《人月神话》读书笔记1
《⼈⽉神话》读书笔记1
《⼈⽉神话》这个名字，初听不像是⼀本关于软件的著作，但是看下去就会发现，整本书使⽤了⼤量像“⼈⽉神话”这样的⽐喻，形象地解释了⼀些⽣晦难懂的东西。
“史前史中，没有别的场景⽐巨兽在焦油坑中垂死挣扎的场⾯更令⼈震撼。
上帝见证着
恐龙、猛犸象、剑齿虎在焦油中挣扎。
它们挣扎得越是猛烈，焦油纠缠得越紧，没有任何猛
兽⾜够强壮或具有⾜够的技巧，能够挣脱束缚，它们最后都沉到了坑底。
”这是作者对于过去⼏⼗年的⼤型系统开发的看法。
仅极少数项⽬满⾜了⽬标、预算和进度的要求。
问题纠缠在⼀起，其⿇烦程度让⼈惊讶，很难看清问题的本质。
⽽之后的部分，就像是对“焦油坑”做出的说明。
“良好的烹饪需要时间，某些任务⽆法在不损害结果的情况下加快速度。
”⼈⽉指⼯作量单位，即⼈⼒(⼈)和时间(⽉)。
⼈⽉是危险和带有欺骗性的神话，因为它暗⽰⼈员数量和时间是可以相互替换的。
它使得项⽬看上去好像⼈⼒和时间是可交换的。
如果时间不够，那么增加⼈⼿就可以加快进度。
但实际上⼈⽉之间的平衡不是线性关系。
这个衡量⽅式忽略了新增加⼈⼿的培训时间、队员之间的沟通时间等等因素，结果就是，盲⽬的增加⼈⼿只会导致项⽬落后。
“向进度落后的项⽬中增加⼈⼿，只会使进度更加落后。
”对此，作者写出了他的进度安排经验：1/3计划、1/6编码、1/4组件测试是和1/4系统集成测试。
人月神话笔记
人月神话读书笔记（一)第一章焦油坑表面上看起来好像没有任何一个单独的问题会导致困难,每个都能被解决，但是当它们相互纠缠和积累在一起的时候,团队的行动就会变得越来越慢。
对问题的麻烦程度，每个人似乎都会感到惊讶，并且很难看清问题的本质。
不过，如果我们想解决问题，就必须试图先去理解它。
-—清楚地解释系统开发的困难所在。
这，就是编程.一个许多人痛苦挣扎的焦油坑以及一种乐趣和苦恼共存的创造性活动.对于许多人而言，其中的乐趣远大于苦恼。
而本书的剩余部分将试图搭建一些桥梁，为通过这样的焦油坑提供一些指导。
-—本书的目的第二章人月神话1。
在众多软件项目中，缺乏合理的时间进度是造成项目滞后的最主要原因,它比其他所有因素加起来的影响还大.导致灾难的原因是：首先,我们对估算技术缺乏有效的研究.第二，我们采用的估算技术隐含地假设人和月可以互换,错误地将进度与工作量相互混淆第三，由于对自己的估算缺乏信心，软件经理通常不会有耐心持续地进行估算这项工作。
第四,对进度缺少跟踪和监督。
第五,当意识到进度的偏移时，下意识(以及传统）的反应是增加人力。
2。
系统开发过程中,乐观主义并不应该是理所应当的。
在单个任务中,“一切都将运转正常”的假设在时间进度上具有可实现性。
因为所遇的延迟是一个概率分布曲线,“不会延迟”仅具有有限的概率，所以现实情况可能会像计划安排的那样顺利。
然而大型的编程工作,或多或少包含了很多任务，某些任务间还具有前后的次序，从而一切正常的概率变得非常小,甚至接近于无。
3. 成本的确随开发产品的人数和时间的不同,有着很大的变化，进度却不是如此。
因此我认为用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话。
它暗示着人员数量和时间是可以相互替换的.因为软件开发本质上是一项系统的工作—-错综复杂关系下的一种实践—-沟通、交流的工作量非常大，它很快会消耗任务分解所节省下来的个人时间。
从而，添加更多的人手，实际上是延长了，而不是缩短了时间进度.4。
人月神话读书笔记
人月神话读书笔记《人月神话》是一本由美国计算机科学家弗雷德里克·布鲁克斯所著的经典著作，该书于1975年首次出版，并在软件开发领域产生了广泛影响。
这本书主要讨论了软件开发中的管理和计划问题，探讨了人力资源与时间的关系，以及如何提高软件开发过程的效率和质量。
本书作者弗雷德里克·布鲁克斯是一位计算机科学家和软件工程师，他曾经是IBM公司系统/360系列计算机操作系统的主要设计师之一。
在这本书中，布鲁克斯通过自己多年的实践经验和对软件开发的深入研究，对软件项目管理提出了许多有价值的见解和原则。
在《人月神话》一书中，布鲁克斯首先提出了“人月神话”的概念，指出在软件开发中，增加人力资源并不能缩短项目的开发时间，因为新加入的人员需要时间来熟悉整个项目的背景和细节，这反而会增加协同工作的复杂性和沟通成本。
换句话说，增加人员只会使项目进度更加拖延，而不会加快开发进度。
布鲁克斯进一步探讨了软件开发过程中的各种难题和挑战，并提出了一些解决这些问题的方法和技巧。
例如，他提出了“拆分”和“增量开发”的概念，认为将一个大型的软件项目分割成多个较小的子项目，并按照优先级进行开发，可以降低复杂性和风险，并提高软件开发过程的透明度和可控性。
此外，本书还讨论了软件项目管理中的人力资源分配和团队建设等问题。
布鲁克斯指出，一个成功的软件开发团队应该由高质量的人员组成，并给予他们足够的自由度和创造空间。
他还提到了软件工程师的培训和职业发展等方面的问题，强调了持续学习和自我提升的重要性。
总的来说，我认为《人月神话》这本书给我留下了深刻的印象。
作者通过丰富的实践经验和理论知识，深入剖析了软件开发中的种种问题和挑战，并提出了很多有价值的见解和解决方案。
我从中学到了很多关于软件项目管理和团队协作的经验和方法，这对我今后的工作和学习将会有很大的帮助。
然而，尽管这本书有很多有价值的观点，但我也认为其中的某些理论在现代软件开发环境中可能并不适用。
《人月神话》读书笔记与心得体会
《人月神话》读书笔记与心得体会几年前刚刚步入软件开发行业，第一次接触软件行业的“人月”概念，了解软件行业的体系结构，懵懂的状态中，不经意间打开了传说中的《人月神话》，记忆中无知者无畏可以是最好的心理状态写实。
重温《TheMythicalMan-Month》，令人欣喜的是美好的憧憬与渴望改变一切的冲劲不仅仅停留在记忆里。
2011年至今，也在企业中摸爬滚打了好几年，时间在变化，思想在变化，转变的痛苦时时伴随着挣扎中的自我。
身份角色的转变，不得不让人思考，重温《人月神话》，焦油坑中的挣扎带给我的问题是以下几点。
1.是什么促使我踏入软件开发行业？比较认同的是《人月神话》中的看法，软件行业给予程序员的是一种创造的快感，类似于上帝创造人类，构建世界的成就感。
同时软件开发行业伴随着的是持续性的创新与学习过程，是重复劳动类工作无法营造的喜悦感。
我是如何踏入这个行业的，11年北京一所普通211高校本科毕业，考研失利（个人原因居多），11至13年混迹于大学的计算机实验室，助理教师一枚，实际的实验室管理员，因为本科除原专业外，同时兼修了计算机专业，似乎计算机行业的从业者身份冥冥中自有注定。
直到13年底进入现在的公司，走的是毕业-迷茫的2年-培训-工作的道路。
得益于还算扎实的基本功，第一份软件工作门槛的踏入还算轻松。
2.软件系统开发是否都是痛苦的挣扎之路？《人月神话》的第一章对软件系统开发的进程做了一个形象的比喻是史前文明的焦油坑，不管是猛犸巨兽还是恐龙霸主，都在“坑”中挣扎，读书笔记似乎生机渺茫（从另一个角度也印证了广大程序员们职业生涯的“填坑”之旅）。
将近4年的短暂路程中，13、14年我是属于初级的软件“打杂”人员，接手项目管理主要从14年底开始，可以说是酸苦辣咸“四味混杂”，甜味基本上与舌尖无缘。
无法忘记的是曾今在用户交付现场，面对交付压力以至于几近崩溃的状态。
现在想来，虽然释然已久，但那时的“满腹心酸”也还无法消解干净。
人月神话读书笔记
人月神话读书笔记第一篇：人月神话读书笔记人月神话这本书几年前就听别人说是本很经典的软件开发方面的书，这本书的成功之处在于他思想的前卫性，以至于不只是软件行业的人在读。
现在终于找到读他的理由了，可以感受一下大师的杰作。
在读之前我已经读过了软件工艺和极限编程，为什么留到最后读人月神话呢？主要是因为我觉得一本能够流传30年还被人们津津乐道的书，肯定是本学要好好细读的书，所以留到了最后。
按照前两篇读书笔记的惯例，前面几段是一些我读书时的感受和收获，还有一些对内容的评价。
从这本书的内容来看，对于一个项目经理来说肯定会有更大的收获，这本书主要是针对软件开发管理方面的内容，这主要原因可能是因为作者以前就是项目的管理者，他是站在管理者的角度写的。
即便这样，对于一个从来没有参与过真实项目开发，更没有领导过团队的我还是有一定的吸引力，这本书中我最喜欢的就是前四章（焦油坑、人月神话、外科手术队伍、贵族专制、民主政治和系统设计）和没有银弹这章。
这本书里面为了论证某一观点，会举出许多实际的项目作为证据，这一点非常好，事实胜于雄辩嘛！这些例子也许对于作者那个年代的人来说很好理解，但是放在30年后来看这些例子又有些陈旧和难懂了。
另外，从文中我发现作者非常注重文档，一个优质的文档就是项目成功的保证，这一点与传统的软件工程很相似，但是却与极限编程的观点相悖。
下面就是一些读书的总结了。
焦油坑1. 编程系统产品开发的工作量是供个人使用的、独立开发的构件程序的九倍。
2. 编程行业的一些内在固有苦恼：l 将做事方式调整到追求完美，是学习编程的最困难部分。
l 由其他人来设定目标，并且必须依靠自己无法控制的事物。
l 真正的权威来自于每次任务的完成。
l 任何创造性活动都伴随着枯燥艰苦的劳动，编程也不例外l 人们通常期望项目在接近结束时（bug、工作时间）能收敛得快一些，然而软件项目的情况却是越接近完成，收敛得越慢。
l 产品在即将完成时总面临着陈旧过时的威胁。
人月神话读书笔记
人月神话读书笔记人月底神话读书笔记软件开发月人能这本书几年前就听他们说是本很经典的神话方面的书，这功能性本书的成功之处在于他思想的前卫性，以至于不只是软件行业的人在读。
从这本书的参考资料来看，对于一个项目经理来说肯定会有更大的收获，这本书主要是针对软件开发管理方面的内容，这主要原因可能是因为作者以前就是项目的管理者，他是站在管理者的角度写的。
即便这样，戏剧化对于一个从来没有应邀参加过真实项目开发，更没有领导过团队我还是有一定的吸引力，这篇文章中我最喜欢的就是前四章(焦油坑、人月神话、外科手术队伍、贵族专制、民主政治和系统设计)和没有银弹这章。
这本书里面为了论证某一观点，会举出许多实际的子项目作为证据，这一点非常好，事实胜于雄辩嘛!这些例子也许对于作者那个年代的人来说很好理解，但是放在30年后来看这些例子又有些陈旧和了。
另外，从文中我发现作者非常注重文档，一个优质的文档就是项目成功的保证，这一点与传统程序设计的软件工程很相似，背道而驰但是却与极限编程的观点相悖。
下面就是一些读书的回顾了。
;焦油坑 1. 编程系统产品开发的工作量是供某项使用程序员的、独立开发的构件程序的九倍。
;2. 编程行业的一些内在固有苦恼：;l 方法将做事方式调整到追求完美，是学习编程的最麻烦部分。
;l 由其他人来设定目标，单靠并且必须依靠自己无法控制的涵义。
;l 真正的权威来自于每次任务的完成。
;l 任何创造性活动都即使伴随着枯燥艰苦的劳动，编程也不例外;l 人们通常期望开打项目在接近结束时(bug、工作时间)能收敛得快一些，然而软件投资项目的情况却是越接近完成，收敛得越慢。
;l 产品在即将完成总面临着陈旧过时的威胁。
人月神话 1.缺乏合理迟滞的时间进度是造成项目滞后的最主要原因，它比其他所有因素加起来影响还小。
;2. 良好的烹饪需要时间，某些任务无法在不损害结果的情况下加快速度。
;3. 我们的构思是有缺陷的，因此总会有bug。
阅读笔记《人月神话》1
阅读笔记《⼈⽉神话》1今天这篇阅读笔记主要讨论《⼈⽉神话》中的“⼈⽉神话”以及组建“外科⼿术队伍”。
⾸先介绍⼀下什么是⼈⽉神话。
我以前听⼈⽉神话的时候总是觉得很⽞幻，以为这是⼀个神话故事之类的。
我相信很多刚刚听到这个词汇的⼈都会这么认为，但是经过阅读发现，⼈⽉神话并不是神话故事。
这是⼀种软件开发过程中的度量单位。
估计完成⼀个项⽬⼤概需要多长时间，⽐如需要12⼈⽉，则可以理解为需要3个⼈⼯作4个⽉。
那么怎么⼜称为神话呢？因为使⽤⼈⽉这种度量⽅式，在很多情况下衡量⼀个⼀项⼯作的规模是⼀个危险和带有欺骗性的神话。
因为在以上关于⼈⽉的介绍中，根据这种计算⽅式，似乎⼈和⽉是可以等价互换，互相补充弥补的，但实际情况并不是如此。
并不能⽤增加⼈的数量来减少开发的周期，这是⼀种愚蠢的想法和做法。
⼈们在对项⽬进⾏估计的时候往往是⾮常乐观的，这是我们应该保持的⼀种良好的⼼态，但是我们更要从实际问题出发，遵循客观规律，不能盲⽬的乐观。
当⼈⽉可以互为转化时，这说明这个项⽬的每个模块的关联性很⼩，团队成员之间的交流也不会很多，⽽且交流起来会⾮常简单，只有基于这种情况下，⼈⽉的内涵才能够充分的得到体现，这种度量⽅式才能很好的阐述⼈⽉可以等价互换的理念。
但是事实往往并⾮如此。
每⼀个项⽬，项⽬的各个模块的联系都是⾮常紧密的，⽽且很多模块之间是由时间先后顺序的，这些因素决定了⼈⽉模型并不适合。
当⼈的数量⼤⼤增加时，并不能有效的缩短项⽬的完成时间，相反，还可能会增加项⽬的时间。
试想⼀下，当团队⼈数⽐较少时，每个⼈负责的⼯作量可能会⽐较⼤，但是每个⼈之间的交流会变得相对来说更加简单，⽽且交流的时间会⽐较少，⽽当⼈数⽐较多时，因为各个模块并不是孤⽴的，要考虑到其他的模块的实现⽅式，所以交流会变得困难起来，这样⽆疑就增加了时间开销，⽽且这种事件开销在⼀个项⽬中会占⽤⼤量的时间。
那么关于⼈⽉之间存在的这种⽭盾，我们该如何解决呢？⼀是，开发并推⾏⽣产率图表、缺陷率、估算规则等等，⽽整个组织最终会从这些数据的共享上获益。
人月神话读后感（通用5篇）
人月神话读后感人月神话读后感（通用5篇）当阅读完一本名著后，相信大家一定领会了不少东西，何不静下心来写写读后感呢？为了让您不再为写读后感头疼，以下是小编为大家收集的人月神话读后感，仅供参考，希望能够帮助到大家。
人月神话读后感篇1最近读了一本书《人月神话》，这本书是软件工程类的一本经典著作。
阅读这本书的第一感受就是感觉这本书不像是一种和学习相关的书，更像是用很多形象的比喻，阐述项目管理当中的一些问题，让读者能够很轻松，明白的去阅读。
一般在大学学习计算机行业的时候，都会学习一门叫做软件工程的课程，老师也会跟我们讲一些关于“软件项目开发的完成与增加人员的问题”，在读这本书的时候，这个问题给了我很大的感触。
很多人认为，当任务在规定期限内还完成不了的时候，适当的加一些人员进去，可以加快任务的进度，从而能够在规定的时间完成任务。
但是这个观点在软件工程当中是不适用的。
这也是我在阅读完《人月神话》这本书时最大的感受。
这本书的第二章就讲述了人月神话的关系，完成工作的人数和时间是不能进行简单的互换的。
因为新加入的人对原有的项目不了解，需要花时间培训，读后感交流，同时新人也有可能对原有的设计有不同的意见，这些都会导致任务的进度大打折扣。
“向进度落后的项目中增加人手，只会使进度更加落后”，是这本书作者布鲁克斯得到的结论。
我觉得开发一个软件，要有合理的时间进度安排，项目开发的人员少而精，团队开发之前要提前交流，开发的时候要持续的沟通，合理的分配任务工作。
所有只有在一个团队沟通了解，通力协作和努力下，才能更好的完善项目。
人月神话读后感篇2《人月神话》这本书风行已经很久了，写成于1975年，经历这么久的时间，在当前又重新流行，让我很惊讶,但是一直没有时间读。
今天突然想起自己的机器上有本拷贝别人的电子书，决定读读。
我今天只看了两章，即焦油坑和人月神话。
人月神话看上去这么浪漫的名字，原来并不是真的说神话故事，作者阐述的主要观点是在软件开发项目上项目进度和增加人员这两个概念是不能互换。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
手册结束 – 时间：进度表 – 资金：预算 – 地点：工作空间分配 – 人员：组织图
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亿人民币），但出货的时间不断的顺延。
15/49
焦油坑之一：进度滞后
“使用人月为单位来衡量一份工作的规模是一个危险和具有欺骗性的神话。它暗 示着人员数量和时间是可以相互替换的。”——brooks
• 人月神话 – 人月：参与开发的程序员数目 * 项目持续的月数 – 为什么说人月是神话？ （1）许多任务是无法拆解的 （2）即使任务可以拆解，人员之间的沟通交流时间随着人手的增加 以(n-1)*n/2的规模递增 20人* 5个月 > 50人* 2个月
18/49
焦油坑之一：进度滞后
• Brooks法则
– 定义："Adding manpower to a late software project makes it later."--Brooks
– 出现原因： 新增的程序员需要进行培训，同时增加了沟通的成本，使得开发 团队增加了更多的开发时间，这个时间超过了新增程序员所做的 贡献。
• 两种可能：
– (1)微软雇佣了5000名不合格的程序员去开发windows NT 5.0 – (2)开发一个大规模的程序系统产品远难于堆砌出单一的程序。
• 作者目的：尽可能地帮助大型系统开发人员走出焦油坑
14/49
焦油坑之一：进度滞后
• 进度滞后的原因
– 乐观主义的盛行（软件开发是纯思维性的活动） – 人月神话 – 各项任务的时间安排不当（特别是测试时间） – 迫于用户压力制定了不合理的进度计划 – brooks法则
23/49
焦油坑之二--缺乏沟通
• 在树状组织架构中进行交流
传统的沟通方式是网状的，n个人之间的交流需要(n-1)*n/2个接口。然而团队的 组织架构总是树状的，可以利用这种树状的组织结构减少沟通成本。需要为每棵 子树定义一些基本要素：
– (1)每棵子树需要完成的任务 – (2)子树的产品负责人（对外沟通） – (3)子树的技术主管（对内技术指导） – (4)进度 – (5)人员的划分 – (6)子树对外接口的定义
周
年 纪
– 收录了作者多年的技术文章
念
版
– 为大型的软件开发提供启示
4/49
软件领域的神话 —— 一本畅销不衰的著作
• 在计算机这个日新月异的领域中，长盛不衰的书籍几乎是凤毛麟角的。 为什么《人月神话》的魅力能不因技术的更替而黯淡，反而能在这多 变的时代中证明自己的价值，乃至有了20年，32年，40年的纪念版 出现呢？
一座带有高塔的城市，这个塔将高耸云霄，也让我们声名远扬。”于
是上帝决定下来看看人们建造的城市和高塔，看了以后，他说：“他
们只是一个种族，使用一种语言，如果他们一开始就能造出城市和高
塔，那以后就没有什么能难得倒他们了。来，让我们在人类的语言里
制造些混淆，让他们相互之间不能听懂。”上帝于是改变并区别开了
对于许多小型的开发团队，加派人手是通常的解决方法？
20/49
焦油坑之二--缺乏沟通
• 巴别塔为什么会失败？
巴别塔：圣经中继“诺亚方舟”后人类第二个大工程，以失败告终
21/49
焦油坑之二--缺乏沟通
• 巴别塔为什么会失败？
......现在整个大地都使用同一种语言。在一次迁徙的过程中，人们发
现了苏美尔地区，并且在那里定居下来。他们说：“来，让我们建造
人类的语言，巴比伦塔不得不停工了。
--旧约 第11章
巴别：在希伯来语中是"变乱"的意思
22/49
焦油坑之二--缺乏沟通
如果大型编程项目中交流不足，很可能面临和巴别塔一样的结局。
• 大型编程项目中的交流方法
– (1)成员之间非正式途径的经常性讨论 – (2)定期召开的项目会议 – (3)项任何一个单独的问题会导致困难，每个都能被
解决，但是当它们相互纠缠和积累在一起的时候，团队的行动就会变 得越来越慢。对问题的麻烦程度，每个人似乎都会感到惊讶，并且很 难看清问题的本质。” ——Brooks
12/49
软件开发中的焦油坑
• Windows NT 5.0(即windows 2000) • 时间：
《人月神话》读书笔记
人月神话
弗雷德里克·布鲁克斯 Frederick P. Brooks, Jr.
人物简介：
• 美国工程院院士
• “IBM 360系统之父”，曾担任 360系统的项目经理，及该项目设 计阶段的经理。凭借在此项目中的 杰出贡献，在1985年获得美国国家 技术奖。
• 1999年荣获美国计算机领域最具声 望的图灵奖 （A.M.TURINGAWARD）桂冠。
2/49
弗雷德里克·布鲁克斯的经典著作——《人月神话》
• 2000年新年伊始，国际计算机协会（ACM）在纽约宣布1999年图 灵奖得住为时年为69岁的Frederick P. Brooks, Jr.。评选委员会主席 在致辞中提到，“今天我们所看到的计算机体系结构、软件工程及三 维计算机图形，均受益于Brooks 的开创性工作，是他改变了这些领 域的面貌。”Brooks确实是一位在计算机科学各方面均作出杰出贡 献的奠基者。
– 结论过于武断？应该附加的前提： (1)项目已经进行了相当长时间的开发 (2)系统比较复杂，新人的学习成本较高
19/49
焦油坑之一：进度滞后
• 对于进度滞后项目的解决方案 – (1)在新的进度安排中分配充分的时间，确保工作能彻 底、认真地完成 – (2)当项目延期所导致的后续成本很高时，往往削减系 统的功能是唯一的解决方法
– 计划开发时间：3年 – 实际开发时间：5年 • 公布数据： – 程序员人数：5,000人 – 代码行数：35,000,000 行代码 – 开发时间：5年 • 每位程序员每年生产多少行代码？
13/49
软件开发中的焦油坑
• 每位程序员每年生产多少行代码？ 以最不幸的情况来估计，每行代码都需要自己编写，得到 结果：35,000,000 行/(5000人*5年) = 1400行/人.年。 这个效率远远低于一名正常程序员的产出量。
– 如何产生自文档化的程序？
(1)在程序源代码里附加尽可能多的信息，例如变量名，函数名等 (2)尽可能使用空格和一致性的格式来提高程序的可读性，表现从属和嵌 套关系 (3)以段落注释的格式，向程序插入必要的记述性文字
27/49
人月神话——精美的烹饪需要时间
美酒的酿造需要年头，美食的烹调需要时间；片刻等待，更多美味，更多享受。 Good Cooking takes time. If you are made to wait, it is to serve you better, and to please you.
• 在《人月神话》中，Brooks博士为人们管理复杂的项目提供了最具洞察 力的见解，既有很多引人深思的观点，又有大量软件工程的实践。
8/49
人月神话
• 人月：软件开发过程中衡量工作量的常用度量单位。 • 而在实际情况中，增加“人”并不能缩短“月”的量
• 为什么说人月是神话？ （1）许多任务是无法拆解的 （2）即使任务可以拆解，人员之间的沟通交流时间随着人手的增加 以(n-1)*n/2的规模递增
• 然而，他最广为认知的功绩则是在软件领域的重要经典著作—— 《人月神话》，可以说正是此书让软件工程学进入了人们的视野。
3/49
弗雷德里克·布鲁克斯的经典著作——《人月神话》
40
《
《
人
人
月
月
神
神
话
话
》
》
20
周
周
年
年
纪
纪
念
念
版
版
《 人
• 书籍简介
月
神 话
– 1975年首次发行
》
32
– 软件工程的经典之作
• 它仍然是计算机书籍中被引用次数最多的书籍，而且即便本书最初出 版于1975年，其内容至今仍未过时。在阅读的时候，每隔几页不说 一句“对极了！”是很难受的。 ——Stee McConnell,Construx公司首席软件工程师