PKM个人知识管理感悟人月神话
《人月神话》读书笔记
《⼈⽉神话》读书笔记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》更为有远见，把我从充实代码的清晰简介升华，拓展到软件开发的高层度，一个周密，准确，明朗的开发需求分析，可行性研究，软件实现是软件开发的完美递进，他们相互辅助，相互促进，如海浪一层的推着前浪奔向远方，而《人月神话》如软件工程开发经济的精华，碧玉。
在《人月神话》面前《设计模式》、《原型设计》、《灵活软件开发》、《面对对象思维》、只不过是冰山一角。
人月神话读后感
人月神话读后感书中的“人月神话”指的是在软件工程过程中，添加更多的人力资源并不意味着可以在更短的时间内完成任务。
布鲁克斯通过丰富的实例和案例，解释了造成这种现象的原因，并提出了一些解决方案。
首先，布鲁克斯强调了人员沟通的重要性。
他认为，软件工程是一个集体创作活动，团队成员之间的沟通是至关重要的。
只有良好的沟通和密切的合作，才能够确保项目的顺利进行。
而人员增加会增加沟通的复杂性，导致信息传递困难，从而拖慢了项目的进度。
其次，布鲁克斯强调了软件工程的复杂性。
他认为，软件工程是一项非常复杂的任务，涉及到许多不确定性因素。
因此，增加人力资源并不能够简单地提高生产效率，相反可能会导致更多的混乱和复杂性。
他提到了“招募人月”这个概念，即增加人力资源可能会在短期内提高生产效率，但在长期内会带来许多问题和挑战。
布鲁克斯还提出了一种解决“人月神话”的方法，即将项目分为独立的模块并分配给小团队进行开发。
这种方法可以减少团队之间的沟通，提高开发效率。
同时，他强调了软件工程师个人技能的重要性。
他认为，卓越的软件工程师往往可以对项目进行正确的判断和决策，并提出高效的解决方案。
因此，公司应该注重培养和发展软件工程师的个人技能和专业素养。
在读完《人月神话》后，我深刻认识到了软件工程的复杂性和团队协作的重要性。
在实际工作中，我也经常遇到类似的问题，尤其是在项目进度紧迫的情况下。
在过去，我一直认为增加人力资源可以提高开发速度，然而事实证明并不是这样。
通过读这本书，我对软件工程项目的管理有了更深入的了解，也掌握了一些实用的解决方法。
首先，我开始更加注重团队内部的沟通和协作。
我意识到在团队中，每个人的意见和建议都非常重要，只有通过充分的沟通和合作，才能够取得最好的工作结果。
因此，我会定期组织团队会议，让大家就项目的进展和问题进行讨论，并共同制定解决方案。
同时，我也更加注重团队成员之间的互相支持和协助，通过合理分配任务，充分发挥每个人的优势，提高整个团队的工作效率。
人月神话读后感
人月神话读后感这学期班主任给我们推荐了一本在软件领域拥有深远影响力和畅销不衰的著作——人月神话。
布鲁克斯博士为为人们管理复杂项目提供了最具洞察力的见解，既有很多发人深省的观点，又有大量软件工程的实践。
本书内容来自Brooks 博士在IBM公司SYSTEM/360家族和OS/360中的项目管理经验，该项目堪称软件工程项目管理的典范。
该书英文原版一经面世，即引起业内人士的强烈反响，后又译为德、法、日、俄、中、韩等多种文字，全球销售数百万册。
确立了其在行业内的经典地位。
其实说实话，现在看人月神话的话对我并没有多大作用（也可能是我觉得没什么作用），因为就自身能力来讲，还没有达到管理这个层次，但是多了解这方面的内容对我是无害的！那么接下来我就讲讲仅仅针对我而言对于这本著作的解读（个人观点）。
所有的编程人员都有乐观主义，总是相信自己的代码是肯定能运行的。
所以在安排项目的进度的时候就会是假设在代码能够在正常运行时因该花费的时间。
而现实往往不是乐观，在项目的进展过程中会存在各种不可预知的问题。
在这个时候项目经理就会为项目增加人员，然而增加人员反而导致项目进度越来越慢。
因为新增加的人员还需要培训，需要时间去了解项目的内容和进展情况。
在投入了更多的人力的时候，经理发现项目进度反而更慢他就会投入更多的人力，这种恶行循环导致项目的失败。
开发一个项目，我们错误的认为用人月这个工作量单位来估计和进行进度安排。
成本的确随开发产品的人数和时间的不同，有着很大的变化，进度却不是如此。
因此我认为用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话。
它暗示着人员数量和时间是可以相互替换的。
人数和时间的互换仅仅适用于以下情况：某个任务可以分解给参与人员，并且他们之间不需要相互的交流，而在系统编程中近乎不可能。
当任务由于次序上的限制不能分解时，人手的添加对进度没有帮助。
调试、测试的次序特性，许多软件都具有这种特征。
因为软件开发本质上是一项系统工作——错综复杂关系下的一种实践——沟通、交流的工作量非常大，它很快会消耗任务分解所节省下来的个人时间。
《人月神话》读后感
《人月神话》读后感
《人月神话》是一本经典的软件开发管理书籍，作者弗雷德里克·布鲁克斯通过讲述自己在IBM的项目经验，对软件开发过程中的一些问题进行了深入的思考和总结。
这本书虽然是在20世纪70年代写的，但其中的观点和原则在今天依然有着很大的启示意义。
其中最重要的观点之一是布鲁克斯提出了“带来人越多，项目越慢”的概念，即在一个软件项目中，添加更多的人力并不能加速项目的进展，反而可能会拖慢整个团队的工作。
这是因为在软件开发中，人力并不是可以无限量放大的资源，每一个新成员要花费一定的时间来适应项目的环境和沟通协调，而且不同成员之间的协作也可能会带来额外的沟通成本。
因此，布鲁克斯提倡在开发中尽量保持稳定的团队规模，并且强调进行好的项目规划和任务分配，以确保开发进展的高效和质量。
此外，布鲁克斯还讨论了关于项目中进度和质量的问题，他指出时间、人员、功能三者之间是有着天然的矛盾的，在面对这种矛盾时，项目管理者需要进行适当的取舍和折中。
他还提倡采取模块化的开发方式，将复杂的软件系统划分为较小的、可独立开发的模块，这样不仅能够更好地管理和控制开发过程，还能够提高开发的灵活性和可维护性。
总的来说，读完《人月神话》我深感布鲁克斯在软件开发管理方面的经验和思考是非常宝贵的。
他对项目管理、团队协作和开发流程的一些观点仍然非常适用，可以帮助我们更加有效地管理和组织软件开发项目。
这本书对于任何从事软件开发和项目管理的人士都是一本必读之作，我相信它会给读者带来很多启发和思考。
人月神话读后感
人月神话读后感《人月神话》是一本由计算机科学家弗雷德里克·布鲁克斯所写的经典著作，书中以自身的亲身经历和观察为基础，探讨了如何管理和开发大型软件项目的一些重要原则和方法。
阅读完《人月神话》，我深深地被书中的观点和思考所震撼，对于软件开发和项目管理的理解有了更深入的认识。
书中，作者首先提到了“人月神话”这一概念，即认为增加人力资源可以缩短项目的进度。
然而实践中，情况却完全相反，项目反而更加拖延。
布鲁克斯通过数个实际案例说明了这个问题的原因，主要是因为沟通成本的增加和人员的组织问题。
他提出了著名的“布鲁克斯法则”，即“人越多，开发时间越长”。
作者还深入探讨了软件开发中的一些重要问题，如程序员的生产率、项目管理、团队组织等。
他认为，一名出色的程序员的价值相当于普通程序员的数十倍，而且编程工作的本质是创造性的工作，并不适合通过时间来衡量。
他提倡合理的工作时间，并强调了程序员的舒适度对于工作效率的影响。
在项目管理方面，作者提倡将项目分解成小的部分进行开发，并强调了需求分析的重要性。
他指出了软件开发中经常发生的需求变更问题，以及如何通过合理的时间规划和团队协作来解决这个问题。
他还对管理者的角色进行了深入的思考，认为管理者应该给团队提供清晰的目标和方向，并保持开放的沟通和透明的决策过程。
在书中，作者还介绍了一些关于人员组织和团队管理的经验和原则。
他认为，团队的成功不仅仅取决于个人的能力，更取决于人员之间的相互合作和协调。
他引用了傲慢者法则和思科系统的成功经验来说明团队合作的重要性。
他主张鼓励团队成员之间的交流和分享，提倡团队精神和集体创造，以实现项目的成功。
阅读完《人月神话》，我深刻地体会到了软件开发和项目管理中的一些重要规律和原则。
我认为，软件开发是一项复杂而创造性的工作，需要合理的时间和资源来完成。
而项目管理则需要合理的规划和组织，以及良好的沟通和协作。
只有通过合理的方法和思考，才能够提高软件开发的效率和质量。
人月神话读后感
人月神话读后感《人月神话》是一本由弗雷德里克·布鲁克斯所著的计算机领域经典著作，它深刻地剖析了软件开发过程中的种种困难和挑战，提出了许多颠覆性的观点和理论。
在读完这本书后，我深受启发，对软件开发这一领域有了更加深入的理解和认识。
首先，我被书中提出的“人月神话”这一概念所震撼。
在书中，布鲁克斯指出，增加人手并不能缩短软件开发的时间，反而可能会延长项目的完成时间。
这一观点颇具启发性，因为在我以往的认知中，增加人手应该可以加快项目的进度。
然而，书中通过实际案例和数据分析，清晰地展现了增加人手可能导致的沟通成本、协调成本和学习成本等问题，从而使得项目的进度反而受到影响。
这一观点对我来说是一种颠覆性的认知，使我对软件开发的管理和组织产生了新的思考。
其次，书中对软件开发过程中的种种挑战和困难进行了深入的剖析。
例如，书中提到了软件开发中的“二次系统效应”，即在开发过程中，随着系统的不断完善和修改，系统的复杂性会呈指数级增长。
这一观点让我对软件开发的复杂性有了更加深刻的认识，也使我意识到在软件开发过程中需要更加注重系统的设计和架构，以避免二次系统效应带来的种种问题。
此外，书中还提到了软件开发中的“饥饿艺术家效应”和“进度不良的现象”，这些都是软件开发过程中常见的问题，通过深入的剖析和分析，使我对这些问题有了更加清晰的认识，也为我今后在软件开发过程中避免这些问题提供了宝贵的经验和教训。
最后，我被书中对软件开发管理和组织的种种建议所深深吸引。
例如，书中提到了“参与式管理”和“集成式管理”等概念，这些管理理念都是为了解决软件开发过程中的种种挑战和困难而提出的。
通过对这些管理理念的深入剖析和分析，使我对软件开发管理和组织有了更加深入的理解，也为我今后在软件开发过程中的管理和组织提供了宝贵的经验和启示。
总之，《人月神话》是一本极具启发性和深度的书籍，它不仅为我对软件开发的认知和理解提供了新的视角，也为我在软件开发过程中遇到的种种挑战和困难提供了宝贵的经验和教训。
人月神话读书笔记
人月神话读书笔记第一篇：人月神话读书笔记人月神话这本书几年前就听别人说是本很经典的软件开发方面的书，这本书的成功之处在于他思想的前卫性，以至于不只是软件行业的人在读。
现在终于找到读他的理由了，可以感受一下大师的杰作。
在读之前我已经读过了软件工艺和极限编程，为什么留到最后读人月神话呢？主要是因为我觉得一本能够流传30年还被人们津津乐道的书，肯定是本学要好好细读的书，所以留到了最后。
按照前两篇读书笔记的惯例，前面几段是一些我读书时的感受和收获，还有一些对内容的评价。
从这本书的内容来看，对于一个项目经理来说肯定会有更大的收获，这本书主要是针对软件开发管理方面的内容，这主要原因可能是因为作者以前就是项目的管理者，他是站在管理者的角度写的。
即便这样，对于一个从来没有参与过真实项目开发，更没有领导过团队的我还是有一定的吸引力，这本书中我最喜欢的就是前四章（焦油坑、人月神话、外科手术队伍、贵族专制、民主政治和系统设计）和没有银弹这章。
这本书里面为了论证某一观点，会举出许多实际的项目作为证据，这一点非常好，事实胜于雄辩嘛！这些例子也许对于作者那个年代的人来说很好理解，但是放在30年后来看这些例子又有些陈旧和难懂了。
另外，从文中我发现作者非常注重文档，一个优质的文档就是项目成功的保证，这一点与传统的软件工程很相似，但是却与极限编程的观点相悖。
下面就是一些读书的总结了。
焦油坑1. 编程系统产品开发的工作量是供个人使用的、独立开发的构件程序的九倍。
2. 编程行业的一些内在固有苦恼：l 将做事方式调整到追求完美，是学习编程的最困难部分。
l 由其他人来设定目标，并且必须依靠自己无法控制的事物。
l 真正的权威来自于每次任务的完成。
l 任何创造性活动都伴随着枯燥艰苦的劳动，编程也不例外l 人们通常期望项目在接近结束时（bug、工作时间）能收敛得快一些，然而软件项目的情况却是越接近完成，收敛得越慢。
l 产品在即将完成时总面临着陈旧过时的威胁。
人月神话读后感
人月神话读后感《人月神话》是软件工程领域的经典之作，作者弗雷德里克·布鲁克斯（Frederick P. Brooks Jr.）通过自己的实践经验，对软件开发过程中的一些误区进行了深入的剖析。
在阅读这本书后，我有以下几点感悟：1. 项目规模与团队规模的关系：布鲁克斯提出了一个著名的“人月神话”，即增加人力并不能缩短项目周期。
这一观点挑战了当时软件开发行业的普遍认识，强调了项目管理的重要性。
在实际工作中，我们应该关注团队的规模和效率，而不是单纯地增加人力。
2. 沟通与协作：书中多次强调了沟通与协作在软件开发过程中的重要性。
一个优秀的团队应该具备良好的沟通能力，能够有效地传递信息、解决问题。
此外，团队成员之间的协作也至关重要，只有大家齐心协力，才能完成高质量的软件项目。
3. 文档的重要性：布鲁克斯认为，编写高质量的文档是软件开发过程中不可或缺的一环。
文档可以帮助团队成员更好地理解项目需求、设计思路和实现细节，从而提高开发效率。
同时，文档也是项目交接和维护的重要依据。
4. 软件质量与测试：书中提到了软件质量的重要性，并强调了测试在保证软件质量中的关键作用。
一个好的软件项目应该注重测试，确保软件在各种情况下都能正常运行。
此外，测试也应该贯穿于软件开发的整个生命周期，从需求分析、设计、编码到维护，都应进行严格的测试。
5. 软件项目的风险管理：布鲁克斯指出，软件开发过程中存在很多不确定性因素，因此需要对项目风险进行有效的管理。
项目经理应该关注项目中可能出现的问题，并采取相应的措施进行预防和应对。
同时，团队成员也应该具备一定的风险意识，及时发现并报告潜在问题。
总之，《人月神话》这本书为我们提供了很多关于软件开发过程的宝贵经验，值得我们认真学习和借鉴。
在实际工作中，我们应该关注项目管理、沟通协作、文档编写、软件质量和风险管理等方面，努力提高软件开发的效率和质量。
人月神话读后感
人月神话读后感这篇文章主要讲了在软件开发工程项目中，时间和人员数量上的转化关系。
表明了在一个项目中增加人员的数量不一定能够缩短项目完成的时间，很多时候还会起到相反的作用。
正如Brooks法则中所说的那样“想进度落后的项目中增加人手，只会使进度更加落后”。
在软件项目中，缺乏合理的时间进度使造成项目滞后的最主要的原因。
造成这个结果主要由于以下几个方面，包括我们对工程的乐观的估计，错误的认为人和月（时间）可以无条件的相互替代，软件经理不合理的估算和缺少对进度的跟踪和监督。
在编程人员中弥漫着乐观主义，他们通常会认为一切都将运作良好，每一项任务仅花费它所应该花费的时间。
但是人员的构思总是会存在某些偏差，导致了idea是很好的，但在实现的过程中出现问题，这种结果会严重的影响到软件工程最终的完成时间。
所以说在做一个项目的时候，人们不应该盲目的乐观。
文章对造成项目滞后的第二个原因进行了详细的论述，为我们否定了一个关于“人月神话”谬论。
“人月神话”的主要内容是人员数量和时间是可以相互替代的。
事实上，人员数量和时间是不可以无条件的相互替代的。
文中也表明了人员数量和时间的互换仅仅适用于以下情况：摸个任务可以分解给参与人员，并且他们之间不需要相互的交流。
只有在这种可分解的任务中人月神话是存在的。
但是在更多的情况下，由于任务常常是不可分解的，而且需要人员之间的大量的相互沟通。
这时候，一味的增加开发人员不会缩短时间的进度，相反还很有可能比没增加人员的时候完成的时间还要晚。
在文中作者也举了一个例子，假定没有在规定的时间内完成任务，达到第一个里程碑，项目经理可以有四种选择的方案。
1，在原来3个人的基础上增加了2个人。
2，将原来的3个人增加到9个人。
3，重新安排进度。
4，削减任务。
作者说明了项目经理往往倾向于选择削减任务来减少后续的成本，也说明了第一种和第二种方案的不可行。
因为增加了人员就要对他们进行培训，这是需要时间的，还有就是会出现重复工作的问题，原先由3个人负责的工作分解到了由5个人来工作，这就导致了某些已经完成的工作必然会丢失，丢失的工作还需要再做一遍，这也导致了时间的浪费和延长。
人月神话读后感
《人月神话》读后感在刚刚进入软件工程学习时，老师总会时不时向我们提起一些关于“软件项目开发的完成与增加人员的问题”这句话听起来通俗易懂，但实现起来却遇到了相当大的困难，这是我在阅读完成《人月神话》时最大的感受，我想这种问题的出现主要是就订单项目而言，因为人员的增加主要是因为客户所要求实现的东西并没有在计划的时间内收到满意的答复和应得的功能与效益。
所以项目开发人员不断的增加，本书作者布鲁克斯得出的结论是显而易见的：“向进度落后的项目中增加人手，只会使进度更加落后”。
如果不想加班，不想削减功能，不想推迟发布日期，那么唯一的方法还是只有加人。
加足够的人。
而且不要逐步加入，一定要一次性加入。
要小心的是，新加入的人可能对原来的组织造成冲击，或者对原来的设计有不同意见，特别是我想如果如果有比较强大的设计者时就要当做新组建了一个团队。
重新交流，培训新人，就设计达成一致，继续向者目标前进。
这也是造成项目延迟的原因之一。
书中主要提到在项目管理方面可以看到项目估算，组织结构和人员角色安排，团队建设和沟通，历史数据积累和建模，软件开发方法论，风险和问题管理等相关的内容；在软件工程方面可以看到架构设计保证概念完整性，整体和部分，空间技能和程序结构的关系，产品集成的方法和消除缺陷的设计思路；在支持过程上我们可以看到文档和流程的建设，软件开发工具对软件开发过程的支持和效率的提升以及工具的选择等相关内容，回过来再看，发现书里面仍然大部分内容涉及到了团队，人和沟通。
对于大型的软件工程项目仍然强调了人的重要性，在开篇就在讲开发人员的职业乐趣，后面又通过巴比伦塔讲沟通的重要性，在外科手术队伍中讲团队的组建和分工。
这些都涉及到了团队中的人和交互，只有一个有了积极心态和热情的沟通团队，才可能成就一个伟大的团队。
从最后的没有银弹，再次肯定了开发工作是一种高智力的脑力工作。
总结一下这本书，讲的主要是软件工程方面的，如何配置人力进行开发。
虽然对于软件编程我们对其了解并不多，但是对于在软件功能的实现，程序设计人员面临的客观性的困难至少我可以站在略懂的角度上去理解他们，对于一个或多个项目来说，公司大多都会搞人海战术，进度没有提前，还整天加班，最后用户不满意，开发人员整天郁闷，结果是用户对公司失去了信任，成了一槌子买卖，开发人员旧人一一辞职，新人天天引进，做法没有改变，情况没有改观，公司没有发展，这就是问题。
人月神话读后感
人月神话读后感《人月神话》是一本经典的软件工程著作，作者是弗雷德里克·布鲁克斯。
这本书首次出版于1975年，至今已经成为软件开发领域的经典之作。
这本书的名字“人月神话”本身就是一个非常有意思的概念，它指的是在软件开发中，增加人手并不能缩短项目的时间，反而可能会增加时间。
这是因为在软件开发中，人力资源并不能直接转化为时间资源，而且增加人手还会导致沟通成本的增加。
在书中，布鲁克斯详细地阐述了软件开发中的各种问题和挑战，以及他对这些问题的看法和解决方案。
他提出了许多软件开发的经典理论和原则，例如“银弹理论”、“二次系统效应”等等。
这些理论和原则不仅在当时引起了广泛的讨论，而且至今仍然对软件开发领域产生着深远的影响。
在阅读《人月神话》这本书的过程中，我深刻地感受到了布鲁克斯对软件开发的深刻理解和独到见解。
他不仅对软件开发中的技术问题有着清晰的认识，而且对人力资源管理、项目管理等方面也有着独到的见解。
他提出的许多理论和原则，不仅在当时引起了广泛的关注和讨论，而且至今仍然被广泛地应用于软件开发实践中。
在书中，布鲁克斯详细地介绍了许多软件开发中的经典案例和故事，这些案例和故事不仅生动地展现了软件开发中的各种问题和挑战，而且通过这些案例和故事，读者可以更加深入地理解和认识软件开发中的种种问题和挑战。
同时，布鲁克斯还通过这些案例和故事向读者传达了许多宝贵的经验和教训，这些经验和教训对于软件开发实践具有非常重要的指导意义。
在我看来，布鲁克斯在《人月神话》这本书中所提出的许多理论和原则，不仅对软件开发领域具有非常重要的意义，而且对于其他领域的项目管理、团队协作等方面也具有非常重要的借鉴意义。
通过阅读这本书，我不仅对软件开发中的种种问题和挑战有了更加深入的理解，而且对于项目管理、团队协作等方面也有了更加清晰的认识。
总的来说，《人月神话》是一本非常有价值的书籍，它不仅对软件开发领域具有非常重要的意义，而且对于其他领域的项目管理、团队协作等方面也具有非常重要的借鉴意义。
人月神话读书笔记
人月神话读书笔记《人月神话》是一本由美国计算机科学家弗雷德里克·布鲁克斯所著的经典著作，该书于1975年首次出版，并在软件开发领域产生了广泛影响。
这本书主要讨论了软件开发中的管理和计划问题，探讨了人力资源与时间的关系，以及如何提高软件开发过程的效率和质量。
本书作者弗雷德里克·布鲁克斯是一位计算机科学家和软件工程师，他曾经是IBM公司系统/360系列计算机操作系统的主要设计师之一。
在这本书中，布鲁克斯通过自己多年的实践经验和对软件开发的深入研究，对软件项目管理提出了许多有价值的见解和原则。
在《人月神话》一书中，布鲁克斯首先提出了“人月神话”的概念，指出在软件开发中，增加人力资源并不能缩短项目的开发时间，因为新加入的人员需要时间来熟悉整个项目的背景和细节，这反而会增加协同工作的复杂性和沟通成本。
换句话说，增加人员只会使项目进度更加拖延，而不会加快开发进度。
布鲁克斯进一步探讨了软件开发过程中的各种难题和挑战，并提出了一些解决这些问题的方法和技巧。
例如，他提出了“拆分”和“增量开发”的概念，认为将一个大型的软件项目分割成多个较小的子项目，并按照优先级进行开发，可以降低复杂性和风险，并提高软件开发过程的透明度和可控性。
此外，本书还讨论了软件项目管理中的人力资源分配和团队建设等问题。
布鲁克斯指出，一个成功的软件开发团队应该由高质量的人员组成，并给予他们足够的自由度和创造空间。
他还提到了软件工程师的培训和职业发展等方面的问题，强调了持续学习和自我提升的重要性。
总的来说，我认为《人月神话》这本书给我留下了深刻的印象。
作者通过丰富的实践经验和理论知识，深入剖析了软件开发中的种种问题和挑战，并提出了很多有价值的见解和解决方案。
我从中学到了很多关于软件项目管理和团队协作的经验和方法，这对我今后的工作和学习将会有很大的帮助。
然而，尽管这本书有很多有价值的观点，但我也认为其中的某些理论在现代软件开发环境中可能并不适用。
人月神话心得体会
人月神话心得体会软件开发是一项复杂而充满挑战性的工作。
在解决实际问题时，开发团队需要面对紧迫的时间限制、预算限制以及资源限制。
在这样的背景下，《人月神话》这本书提出了许多重要的概念和实践原则，以帮助开发团队更好地规划和管理软件项目。
本文将分享我的《人月神话》心得体会。
1. 软件开发是团队协作的过程《人月神话》强调了软件开发是一个多人协作的过程，团队中的每个成员都有自己的角色和责任。
在项目中，彼此之间的沟通和合作至关重要。
只有通过有效的沟通，开发团队才能更好地协调工作、解决问题，并确保项目成功交付。
2. 人月神话的概念人月神话是指在软件项目中添加更多的人力资源并不能保证项目能在更短的时间内完成。
相反，过多的人力资源可能会引起沟通和协调问题，从而导致项目延期。
开发团队需要合理评估项目需求，并根据团队的规模和能力制定合理的时间计划。
3. 软件工程的经验法则人月神话的作者弗雷德里克·布鲁克斯提出了一些软件工程的经验法则，例如“概念上的完整性”和“构建原型”。
这些法则提醒我们在软件开发过程中要注重系统的整体性，并且在进入详细设计和编码阶段之前，先构建一个可工作的原型来验证需求和设计。
4. 正确估计工作量正确估计工作量是软件开发中的一个关键挑战。
在项目启动之初，开发团队需要进行详细的需求分析和任务拆分，并评估每个任务的工作量。
通过合理的工作量评估，开发团队可以更好地控制进度和资源分配，避免项目延期。
5. 不断学习和改进软件开发不是一成不变的过程。
开发技术和需求都在不断演变，因此开发团队需要保持学习的状态，并不断改进工作流程和方法。
只有不断学习和改进，团队才能跟上时代的步伐，提高开发效率和质量。
结语：《人月神话》提供了许多宝贵的经验和原则，对于软件开发团队来说具有重要意义。
在我的实际工作中，我深刻体会到团队协作、正确估计工作量和持续学习的重要性。
通过遵循《人月神话》的原则，我们可以更好地管理软件项目，提高开发效率，实现项目的成功交付。
《人月神话》读书笔记与心得体会
《人月神话》读书笔记与心得体会几年前刚刚步入软件开发行业，第一次接触软件行业的“人月”概念，了解软件行业的体系结构，懵懂的状态中，不经意间打开了传说中的《人月神话》，记忆中无知者无畏可以是最好的心理状态写实。
重温《TheMythicalMan-Month》，令人欣喜的是美好的憧憬与渴望改变一切的冲劲不仅仅停留在记忆里。
2011年至今，也在企业中摸爬滚打了好几年，时间在变化，思想在变化，转变的痛苦时时伴随着挣扎中的自我。
身份角色的转变，不得不让人思考，重温《人月神话》，焦油坑中的挣扎带给我的问题是以下几点。
1.是什么促使我踏入软件开发行业？比较认同的是《人月神话》中的看法，软件行业给予程序员的是一种创造的快感，类似于上帝创造人类，构建世界的成就感。
同时软件开发行业伴随着的是持续性的创新与学习过程，是重复劳动类工作无法营造的喜悦感。
我是如何踏入这个行业的，11年北京一所普通211高校本科毕业，考研失利（个人原因居多），11至13年混迹于大学的计算机实验室，助理教师一枚，实际的实验室管理员，因为本科除原专业外，同时兼修了计算机专业，似乎计算机行业的从业者身份冥冥中自有注定。
直到13年底进入现在的公司，走的是毕业-迷茫的2年-培训-工作的道路。
得益于还算扎实的基本功，第一份软件工作门槛的踏入还算轻松。
2.软件系统开发是否都是痛苦的挣扎之路？《人月神话》的第一章对软件系统开发的进程做了一个形象的比喻是史前文明的焦油坑，不管是猛犸巨兽还是恐龙霸主，都在“坑”中挣扎，读书笔记似乎生机渺茫（从另一个角度也印证了广大程序员们职业生涯的“填坑”之旅）。
将近4年的短暂路程中，13、14年我是属于初级的软件“打杂”人员，接手项目管理主要从14年底开始，可以说是酸苦辣咸“四味混杂”，甜味基本上与舌尖无缘。
无法忘记的是曾今在用户交付现场，面对交付压力以至于几近崩溃的状态。
现在想来，虽然释然已久，但那时的“满腹心酸”也还无法消解干净。
《人月神话》读后感_读后感_
《人月神话》读后感～-7-6 字数：4071不同的社会经验，不同的思想状态，对读本书的心得也不一样，我在此说说我的，书中有许多非常好的观点，但我只把我感触最深的写下来。
这确实是一本很值得多次阅读的好书，每次阅读可能都能从中得到一些提示。
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％，其他的时间都花在了无关的琐碎事情上。
2023年信息时代的个人知识管理心得体会_1
2023年信息时代的个人知识管理心得体会2023年信息时代的个人知识管理心得体会1在信息严重超载的今天，“我们生活在信息的海洋中，但却忍受着知识的饥渴”。
为了寻找一个地址、电话号码或电子信箱而翻箱倒柜;收藏的总是远远超过阅读和学习的数量;看过很多，却往往在需要某些资料的关键时刻无法找到;被每天的繁重例行工作压得透不过气来等等。
顺应时代要求，知识经济和知识管理逐渐成为当前社会的热门话题。
要想获得生存和发展的能力，人们必须成为个人知识的管理者，提高创造和应用知识能力。
个人知识管理(PKM，Personal Knowledge Management)是一种新的知识管理的理念和方法，能将个人拥有的各种资料、随手可得的信息变成更具价值的知识，最终利于自己的工作、生活。
通过对个人知识的管理，人们可以养成良好的学习习惯，增强信息素养，完善自己的专业知识体系，提高自己的能力和竞争力，为实现个人价值和可持续发展打下坚实基础。
一、个人知识管理的概念1、个人知识的分类知识管理的一个基本问题是对知识的分类。
按照应用的角度，经济发展与合作组织(OECD)将知识分为四类：事实知识(Know-what)、原理知识(Know-why)、技能知识(Know-how)和人际知识(Know-who)。
[1]从认知角度出发，知识又可以分为显性知识(Explicit Knowledge)和隐性知识(Tacit Knowledege)。
显性知识可以通过文件、形象或其他精确的沟通过程来传授，但隐性知识的获得却只能依赖于自身的体验、直觉和洞察力。
在OECD对知识的划分中，前两者属于显性知识，后两者属于隐性知识。
显性知识和隐性知识之间可以相互转化，动态循环。
[2]个人可以管理的知识不仅是指书本和文献中的有形内容，而且更是指信息，是从原始材料中组织和系统化的数据。
个人知识管理的重点在于对隐形知识的管理，实现显性知识和隐性知识的共享，提高学习能力、应变能力和创新能力。
《人月神话》读书心得
《人月神话》读书心得本月阅读了该部软件工程巨著中第八章--胸有成竹(Calling the Shot)，该章节讲述了软件开发中如何进展准确的工程预测和估算。
本章的标题是胸有成竹，而在开发中真正要做到成竹在胸就必须在工程方案阶段就要对工程的预测和估算都能准确把握。
估算要做到准确就必须通过前期多个历史工程和版本的积累，同时通过历史版本和数据的积累来发现和预测指标Y和相应的估算因子X之间的关系。
其实也就是进展开发中的专家经历型估算。
这样建立出来的估算模型就可以根本保证我们的估算准确性。
最早用的估算方法是建立需求--设计--编码--测试各个阶段工作量之间的比例关系，然后根据需求的工作量来推导其它各个阶段的工作量或者是根据编码工作量来反推上游各个阶段的工作量。
这种方式在工程规模比较稳定的小型工程中是比较适用的，但是它不能简单的类比应用到大型软件工程中，因为随着工程规模的扩大，规模和工作量之间已经不是简单的线性关系了。
在进展大型软件工程的开发中，要对整个工程做出准确的估算更显得困难。
Microsoft公司的windows开发就出现整体工程的延期，而Blizzard公司的工程延期就显得更加频繁。
根据Nanus和Farr在System Development Corporation公司所做的研究说明，工作量和规模之间是1.5的指数关系，虽然软件产品规模的扩大工作量会成倍增加。
工作量=常数×指令的数量)~1.5 Portman的数据说明，在每天8小时工作制的情况下，我们能够有效利用的工作投入时间在5-6小时甚至更低。
因此我们在做估算的时候必须要考虑到开发人员每天的有效工作量的问题。
Aron的数据说明开发人员直接的交互渠道和交互量直接影响到开发人员的平均生产率，我们强调沟通但是过多无效的沟通会直接影响到我们的效率。
当在沟通和问题确认上浪费了我们太多时间的时候，开发的效率将会明显下降。
Harr的数据说明确实存在不同程序类型复杂度完全不同的情况，比方对于控制逻辑程序，编译器程序复杂度远远高于应用软件程序。
信息时代的个人知识管理心得体会
信息时代的个人知识管理心得体会信息时代的个人知识管理心得体会（通用5篇）有了一些收获以后，有这样的时机，要好好记录下来，这样就可以通过不断总结，丰富我们的思想。
那么心得体会该怎么写？想必这让大家都很苦恼吧，以下是小编整理的信息时代的个人知识管理心得体会，欢迎阅读，希望大家能够喜欢。
信息时代的个人知识管理心得体会篇1今天，我学习了李亦菲教授讲的信息时代的个人知识管理，感想很深。
李教授详细的讲解了知识管理的概念、知识管理现在面临的困难与挑战、知识管理理论概要、组织知识管理的概念、个人知识管理的概念、个人知识管理的任务、知识的分类、知识的转化、知识转化的金字塔模型、基于素材的知识管理模型、知识管理的技能、浏览知识管理系统。
感触最深的是以前把一个文件存到几个地方，站的空间大不说，不好找。
有时在写教案的时候，点击保存然后找不到保存在哪了，还要重写。
就是这样，不会操作，要比别人多干许多次，一天到晚很忙碌，累得很。
现在虽然比以前有进步了，但是还有许多下载的东西没掌握，虽然下载了，但是找不到下载到哪了。
制作一些课件很是费尽。
现在一些简单的幻灯片会制作了，但是要制作很好的课件还是有难度。
人活到老，学到老一点也不假。
我还必须好好的认真学习。
信息时代的个人知识管理心得体会篇2我通过学习明确了加快信息化建设的重要性和必要性，人类已走进以信息技术为核心的知识经济时代，信息资源已成为与材料和能源同等重要的战略资源;信息技术正以其广泛的渗透性、无形值价和无与伦比的先进性与传统产业结合;信息产业已发展为世界范围内的朝阳产业和新的经济增长点;信息化已成为推进企业发展的助力器;信息化水平则成为一个企业综合实力的重要标志。
现在结合本人几年来对信息化建设工作认识浅谈心得体会如下：1、信息技术对教师的重要作用。
在高科技飞速发展的今天，教师不能只停在原有知识的认识上，要不断学习，不断完善自己，不断充实自己。
现在的学生更是聪明，他们不仅能在学校里学习知识，还能通过电视、网络等多种途径学到更多的知识。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
2020/11/3
PKM个人知识管理感悟人月神话
广度和深度
v 沙堆模型 v 先积累广度再向深度发展 v 发展受阻时候回溯广度 v 粘合剂-知识关联依赖
PKM个人知识管理感悟人月神话
横向和纵向
v 目标驱动 v 问题驱动 v 业务驱动 v 以点到面 v 先纵后横
PKM个人知识管理感悟人月神话
3.方法-分类无处不在
PKM个人知识管理感悟人月神话
演讲完毕，谢谢听讲!
再见，see you again
2020/11/3
PKM个人知识管理感悟人月神话
粒度和复用
Q
DR
Q
DR
D
Q
D
D
模式匹配
R R
R
R
R
R R
积累库
PKM个人知识管理感悟人月神话
有为和无为
v 同样的高度，不同的心态 v 为学日益，为道日损，无为而无不为 v 学习知识就是从无到有，再从有到无过程 v 愉悦的过程带来美好的结果
PKM个人知识管理感悟人月神话
增量和迭代
v 一叶障目，不见泰山 v 增量是堆砌，迭代是雕琢 v 学习过程是迭代过程 v 知识体系结构体现迭代 v 自我评估必须迭代 v 时间管理需要迭代
PKM个人知识管理感悟人月神话
路径和回溯
F
G
A
B GooCgle D
E
H
v A到E => 过渡依赖搜索引擎 v 知道要通过B->C->D才能够到达E v 知道有多条路径可以达到E v 知道在什么场景下选择什么模式
PKM个人知识管理感悟人月神话
方法和模式
A
BCΒιβλιοθήκη DE方法论
模式1
模式2
模式N
v 方法论≠模式 => 知识≠经验 v 知识=>技能=>经验=>模式 v 模式 = 特定场景下问题的解决路径 v 形成模式唯有日积月累
PKM个人知识管理感悟人月神话
目标和过程
v 渐修和顿悟 v 量变带来质变 v 由事入理还是由理入事 v 渐是顿的实践，顿是渐的启发 v 顿悟仅仅是开始
PKM个人知识管理感悟人月神话
工具和结果
v 渡河弃筏和上岸拽筏 v 执指为月和弃指求月 v 工欲善其事，必先利其器 v 工具仅仅是加速器 v 不要沉迷于工具而迷失方向
PKM个人知识管理感悟人月神话
时间管理
时间就像海绵里的水，只要愿挤总还是有的! -鲁迅
v 从救火到重要紧急事情 v 提升效率是王道 v 防止他人浪费你时间
PKM个人知识管理感悟人月神话
思维模式
6.深入-背后的背后 5.提升-思维路径
4.任务-发掘事物本质
1.基础-学习积累知识 2.核心-积极思考提问