人月神话笔记
《人月神话》读书笔记
《⼈⽉神话》读书笔记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. 焦油坑图⽚来源：史前史中，没有别的场景⽐巨兽在焦油坑中垂死挣扎的场⾯更令⼈震撼。
上帝见证着恐龙、猛犸象、剑齿虎在焦油中挣扎。
它们挣扎得越是猛烈，焦油纠缠得越紧，没有任何猛兽⾜够强壮或具有⾜够的技巧，能够挣脱束缚，它们最后都沉到了坑底。
过去⼏⼗年的⼤型系统开发就犹如这样⼀个焦油坑，很多⼤型和强壮的动物在其中剧烈地挣扎。
各种团队，⼤型的和⼩型的，庞杂的和精⼲的，⼀个接⼀个淹没在了焦油坑中。
表⾯上看起来好像没有任何⼀个单独的问题会导致困难，每个都能被解决，但是当它们相互纠缠和累积在⼀起的时候，团队的⾏动就会变得越来越慢。
软件开发的另⼀个难题，是从单⼀程序到软件系统过程中，所造成复杂度的快速上升，期间并需要包含不同的活动与技能，使得软件开发必须⾯对多样性的挑战。
人月神话读书笔记
人月神话读书笔记第一篇：人月神话读书笔记人月神话这本书几年前就听别人说是本很经典的软件开发方面的书，这本书的成功之处在于他思想的前卫性，以至于不只是软件行业的人在读。
现在终于找到读他的理由了，可以感受一下大师的杰作。
在读之前我已经读过了软件工艺和极限编程，为什么留到最后读人月神话呢？主要是因为我觉得一本能够流传30年还被人们津津乐道的书，肯定是本学要好好细读的书，所以留到了最后。
按照前两篇读书笔记的惯例，前面几段是一些我读书时的感受和收获，还有一些对内容的评价。
从这本书的内容来看，对于一个项目经理来说肯定会有更大的收获，这本书主要是针对软件开发管理方面的内容，这主要原因可能是因为作者以前就是项目的管理者，他是站在管理者的角度写的。
即便这样，对于一个从来没有参与过真实项目开发，更没有领导过团队的我还是有一定的吸引力，这本书中我最喜欢的就是前四章（焦油坑、人月神话、外科手术队伍、贵族专制、民主政治和系统设计）和没有银弹这章。
这本书里面为了论证某一观点，会举出许多实际的项目作为证据，这一点非常好，事实胜于雄辩嘛！这些例子也许对于作者那个年代的人来说很好理解，但是放在30年后来看这些例子又有些陈旧和难懂了。
另外，从文中我发现作者非常注重文档，一个优质的文档就是项目成功的保证，这一点与传统的软件工程很相似，但是却与极限编程的观点相悖。
下面就是一些读书的总结了。
焦油坑1. 编程系统产品开发的工作量是供个人使用的、独立开发的构件程序的九倍。
2. 编程行业的一些内在固有苦恼：l 将做事方式调整到追求完美，是学习编程的最困难部分。
l 由其他人来设定目标，并且必须依靠自己无法控制的事物。
l 真正的权威来自于每次任务的完成。
l 任何创造性活动都伴随着枯燥艰苦的劳动，编程也不例外l 人们通常期望项目在接近结束时（bug、工作时间）能收敛得快一些，然而软件项目的情况却是越接近完成，收敛得越慢。
l 产品在即将完成时总面临着陈旧过时的威胁。
《人月神话》读后感
《人月神话》读后感
《人月神话》是一本经典的软件开发管理书籍，作者弗雷德里克·布鲁克斯通过讲述自己在IBM的项目经验，对软件开发过程中的一些问题进行了深入的思考和总结。
这本书虽然是在20世纪70年代写的，但其中的观点和原则在今天依然有着很大的启示意义。
其中最重要的观点之一是布鲁克斯提出了“带来人越多，项目越慢”的概念，即在一个软件项目中，添加更多的人力并不能加速项目的进展，反而可能会拖慢整个团队的工作。
这是因为在软件开发中，人力并不是可以无限量放大的资源，每一个新成员要花费一定的时间来适应项目的环境和沟通协调，而且不同成员之间的协作也可能会带来额外的沟通成本。
因此，布鲁克斯提倡在开发中尽量保持稳定的团队规模，并且强调进行好的项目规划和任务分配，以确保开发进展的高效和质量。
此外，布鲁克斯还讨论了关于项目中进度和质量的问题，他指出时间、人员、功能三者之间是有着天然的矛盾的，在面对这种矛盾时，项目管理者需要进行适当的取舍和折中。
他还提倡采取模块化的开发方式，将复杂的软件系统划分为较小的、可独立开发的模块，这样不仅能够更好地管理和控制开发过程，还能够提高开发的灵活性和可维护性。
总的来说，读完《人月神话》我深感布鲁克斯在软件开发管理方面的经验和思考是非常宝贵的。
他对项目管理、团队协作和开发流程的一些观点仍然非常适用，可以帮助我们更加有效地管理和组织软件开发项目。
这本书对于任何从事软件开发和项目管理的人士都是一本必读之作，我相信它会给读者带来很多启发和思考。
人月神话读书笔记
人月神话读书笔记第一篇：人月神话读书笔记人月神话这本书几年前就听别人说是本很经典的软件开发方面的书，这本书的成功之处在于他思想的前卫性，以至于不只是软件行业的人在读。
现在终于找到读他的理由了，可以感受一下大师的杰作。
在读之前我已经读过了软件工艺和极限编程，为什么留到最后读人月神话呢？主要是因为我觉得一本能够流传30年还被人们津津乐道的书，肯定是本学要好好细读的书，所以留到了最后。
按照前两篇读书笔记的惯例，前面几段是一些我读书时的感受和收获，还有一些对内容的评价。
从这本书的内容来看，对于一个项目经理来说肯定会有更大的收获，这本书主要是针对软件开发管理方面的内容，这主要原因可能是因为作者以前就是项目的管理者，他是站在管理者的角度写的。
即便这样，对于一个从来没有参与过真实项目开发，更没有领导过团队的我还是有一定的吸引力，这本书中我最喜欢的就是前四章（焦油坑、人月神话、外科手术队伍、贵族专制、民主政治和系统设计）和没有银弹这章。
这本书里面为了论证某一观点，会举出许多实际的项目作为证据，这一点非常好，事实胜于雄辩嘛！这些例子也许对于作者那个年代的人来说很好理解，但是放在30年后来看这些例子又有些陈旧和难懂了。
另外，从文中我发现作者非常注重文档，一个优质的文档就是项目成功的保证，这一点与传统的软件工程很相似，但是却与极限编程的观点相悖。
下面就是一些读书的总结了。
焦油坑1. 编程系统产品开发的工作量是供个人使用的、独立开发的构件程序的九倍。
2. 编程行业的一些内在固有苦恼：l 将做事方式调整到追求完美，是学习编程的最困难部分。
l 由其他人来设定目标，并且必须依靠自己无法控制的事物。
l 真正的权威来自于每次任务的完成。
l 任何创造性活动都伴随着枯燥艰苦的劳动，编程也不例外l 人们通常期望项目在接近结束时（bug、工作时间）能收敛得快一些，然而软件项目的情况却是越接近完成，收敛得越慢。
l 产品在即将完成时总面临着陈旧过时的威胁。
人月神话读后感
人月神话读后感《人月神话》是一本由计算机科学家弗雷德里克·布鲁克斯所写的经典著作，书中以自身的亲身经历和观察为基础，探讨了如何管理和开发大型软件项目的一些重要原则和方法。
阅读完《人月神话》，我深深地被书中的观点和思考所震撼，对于软件开发和项目管理的理解有了更深入的认识。
书中，作者首先提到了“人月神话”这一概念，即认为增加人力资源可以缩短项目的进度。
然而实践中，情况却完全相反，项目反而更加拖延。
布鲁克斯通过数个实际案例说明了这个问题的原因，主要是因为沟通成本的增加和人员的组织问题。
他提出了著名的“布鲁克斯法则”，即“人越多，开发时间越长”。
作者还深入探讨了软件开发中的一些重要问题，如程序员的生产率、项目管理、团队组织等。
他认为，一名出色的程序员的价值相当于普通程序员的数十倍，而且编程工作的本质是创造性的工作，并不适合通过时间来衡量。
他提倡合理的工作时间，并强调了程序员的舒适度对于工作效率的影响。
在项目管理方面，作者提倡将项目分解成小的部分进行开发，并强调了需求分析的重要性。
他指出了软件开发中经常发生的需求变更问题，以及如何通过合理的时间规划和团队协作来解决这个问题。
他还对管理者的角色进行了深入的思考，认为管理者应该给团队提供清晰的目标和方向，并保持开放的沟通和透明的决策过程。
在书中，作者还介绍了一些关于人员组织和团队管理的经验和原则。
他认为，团队的成功不仅仅取决于个人的能力，更取决于人员之间的相互合作和协调。
他引用了傲慢者法则和思科系统的成功经验来说明团队合作的重要性。
他主张鼓励团队成员之间的交流和分享，提倡团队精神和集体创造，以实现项目的成功。
阅读完《人月神话》，我深刻地体会到了软件开发和项目管理中的一些重要规律和原则。
我认为，软件开发是一项复杂而创造性的工作，需要合理的时间和资源来完成。
而项目管理则需要合理的规划和组织，以及良好的沟通和协作。
只有通过合理的方法和思考，才能够提高软件开发的效率和质量。
人月神话读后感
人月神话读后感《人月神话》是一本由弗雷德里克·布鲁克斯所著的计算机领域经典著作，它深刻地剖析了软件开发过程中的种种困难和挑战，提出了许多颠覆性的观点和理论。
在读完这本书后，我深受启发，对软件开发这一领域有了更加深入的理解和认识。
首先，我被书中提出的“人月神话”这一概念所震撼。
在书中，布鲁克斯指出，增加人手并不能缩短软件开发的时间，反而可能会延长项目的完成时间。
这一观点颇具启发性，因为在我以往的认知中，增加人手应该可以加快项目的进度。
然而，书中通过实际案例和数据分析，清晰地展现了增加人手可能导致的沟通成本、协调成本和学习成本等问题，从而使得项目的进度反而受到影响。
这一观点对我来说是一种颠覆性的认知，使我对软件开发的管理和组织产生了新的思考。
其次，书中对软件开发过程中的种种挑战和困难进行了深入的剖析。
例如，书中提到了软件开发中的“二次系统效应”，即在开发过程中，随着系统的不断完善和修改，系统的复杂性会呈指数级增长。
这一观点让我对软件开发的复杂性有了更加深刻的认识，也使我意识到在软件开发过程中需要更加注重系统的设计和架构，以避免二次系统效应带来的种种问题。
此外，书中还提到了软件开发中的“饥饿艺术家效应”和“进度不良的现象”，这些都是软件开发过程中常见的问题，通过深入的剖析和分析，使我对这些问题有了更加清晰的认识，也为我今后在软件开发过程中避免这些问题提供了宝贵的经验和教训。
最后，我被书中对软件开发管理和组织的种种建议所深深吸引。
例如，书中提到了“参与式管理”和“集成式管理”等概念，这些管理理念都是为了解决软件开发过程中的种种挑战和困难而提出的。
通过对这些管理理念的深入剖析和分析，使我对软件开发管理和组织有了更加深入的理解，也为我今后在软件开发过程中的管理和组织提供了宝贵的经验和启示。
总之，《人月神话》是一本极具启发性和深度的书籍，它不仅为我对软件开发的认知和理解提供了新的视角，也为我在软件开发过程中遇到的种种挑战和困难提供了宝贵的经验和教训。
人月神话读书笔记doc
人月神话读书笔记人月神话这本书几年前就听别人说是本很经典的软件开发方面的书，这本书的成功之处在于他思想的前卫性，以至于不只是软件行业的人在读。
现在终于找到读他的理由了，可以感受一下大师的杰作。
在读之前我已经读过了软件工艺和极限编程，为什么留到最后读人月神话呢？主要是因为我觉得一本能够流传30年还被人们津津乐道的书，肯定是本学要好好细读的书，所以留到了最后。
按照前两篇读书笔记的惯例，前面几段是一些我读书时的感受和收获，还有一些对内容的评价。
从这本书的内容来看，对于一个项目经理来说肯定会有更大的收获，这本书主要是针对软件开发管理方面的内容，这主要原因可能是因为作者以前就是项目的管理者，他是站在管理者的角度写的。
即便这样，对于一个从来没有参与过真实项目开发，更没有领导过团队的我还是有一定的吸引力，这本书中我最喜欢的就是前四章（焦油坑、人月神话、外科手术队伍、贵族专制、民主政治和系统设计）和没有银弹这章。
这本书里面为了论证某一观点，会举出许多实际的项目作为证据，这一点非常好，事实胜于雄辩嘛！这些例子也许对于作者那个年代的人来说很好理解，但是放在30年后来看这些例子又有些陈旧和难懂了。
另外，从文中我发现作者非常注重文档，一个优质的文档就是项目成功的保证，这一点与传统的软件工程很相似，但是却与极限编程的观点相悖。
下面就是一些读书的总结了。
焦油坑 1。
编程系统产品开发的工作量是供个人使用的、独立开发的构件程序的九倍。
2。
编程行业的一些内在固有苦恼：l 将做事方式调整到追求完美，是学习编程的最困难部分。
l 由其他人来设定目标，并且必须依靠自己无法控制的事物。
l 真正的权威来自于每次任务的完成。
l 任何创造性活动都伴随着枯燥艰苦的劳动，编程也不例外l 人们通常期望项目在接近结束时（bug、工作时间）能收敛得快一些，然而软件项目的情况却是越接近完成，收敛得越慢。
l 产品在即将完成时总面临着陈旧过时的威胁。
人月神话 1。
关于人月神话读书笔记300字：观点相悖
关于人月神话读书笔记300字：观点相悖本文是关于关于人月神话读书笔记300字：观点相悖，仅供参考，希望对您有所帮助，感谢阅读。
《人月神话》内容源于作者brooks在ibm公司任system计算机系列以及其庞大的软件系统os项目经理时的实践经验。
关于人月神话读书笔记300字思路清晰。
关于人月神话读书笔记300字：观点相悖《人月神话》这本书几年前就听别人说是本很经典的软件开发方面的书，这本书的成功之处在于他思想的前卫性，以至于不只是软件行业的人在读。
现在终于找到读他的理由了，可以感受一下大师的杰作。
在读之前我已经读过了软件工艺和极限编程，为什么留到最后读人月神话呢?主要是因为我觉得一本能够流传30年还被人们津津乐道的书，肯定是本学要好好细读的书，所以留到了最后。
按照前两篇读书笔记的惯例，前面几段是一些我读书时的感受和收获，还有一些对内容的评价。
从这本书的内容来看，对于一个项目经理来说肯定会有更大的收获，这本书主要是针对软件开发管理方面的内容，这主要原因可能是因为作者以前就是项目的管理者，他是站在管理者的角度写的。
即便这样，对于一个从来没有参与过真实项目开发，更没有领导过团队的我还是有一定的吸引力，这本书中我最喜欢的就是前四章(焦油坑、人月神话、外科手术队伍、贵族专制、民主政治和系统设计)和没有银弹这章。
这本书里面为了论证某一观点，会举出许多实际的项目作为证据，这一点非常好，事实胜于雄辩嘛!这些例子也许对于作者那个年代的人来说很好理解，但是放在30年后来看这些例子又有些陈旧和难懂了。
另外，从文中我发现作者非常注重文档，一个优质的文档就是项目成功的保证，这一点与传统的软件工程很相似，但是却与极限编程的观点相悖。
关于人月神话读书笔记300字到这里就结束了，你从中得到了什么启发呢？相关推荐：。
《人月神话》读后感----一到三章
《⼈⽉神话》读后感----⼀到三章《⼈⽉神话》这本书是我们⽼师推荐给我们的，同时⽼师还推荐给我们另⼀本书《梦断代码》。
由于时间的原因，我只能先选⼀本书来读。
这本书⾥⾯的好多观点，对于今天的软件⼯程依然适⽤。
如“没有银弹”这个观点，说明了作者对于软件⼯程独到的见解。
⾝为⼀名软件⼯程的学⽣，我应当仔细读完关于软件⼯程的任何⼀本书。
并将观点与想法运⽤到实际之中。
作者在第⼀章中说到，过去⼏⼗年⼤型系统的开发就像焦油坑⼀样，虽然各种各样的团队通过努⼒开发出可运⾏的系统，但是只有少数的项⽬可以开发出满⾜⽬标、时间进度和预算的要求。
作者还谈到编程的乐趣和烦恼。
编程的乐趣主要是能够⾃⼰创造⾃⼰想要的项⽬。
⽽烦恼是总是难以达到完美。
我在读到这本书的第⼆章的时候，就感到作者的见解独到。
Brooks先⽣对⼈⽉转换的观点进⾏了详细的分析，他还指出⾼层次、尖端的⼈才和低⽔平、平庸的⼯作⼈员的⼯作效率⽐会是⼗倍不⽌，所以说⼀个⼩规模的精锐的团队往往要⽐⼤规模的但是有很多平庸的程序员的团队要好得多。
前苹果公司CEO乔布斯先⽣也提出过类似的观点：“在我关注的研发领域，我发现，通常50到100个平均⽔平的⼈才，其贡献才抵得上⼀个最⾼⽔平的⼈才。
”⾼层次的⼈员效率⾼，⼈少带来的交流就少，节省交流时间，进⽽缩短⼯期。
我感觉这道理说的⼗分正确。
⼈⽉神话这⼀章表达的是对⽤⼈⽉这个单位来计量项⽬的价值本⾝是⾮常不正确的。
它看上去好像是⼈⼒和时间是可以交换的，就好⽐远古时期的部落交换东西时的想法⼀样，这种价值观是不正确的。
有时候我觉得盲⽬的增加⼈员数量只会让项⽬落后。
所以我们不要相信⼈⽉神话，⽽是通过合理的分析来制定整个项⽬的进度。
人月神话每一章的读书笔记
人月神话每一章的读书笔记
读第一遍的时候，里面很多的内容我觉得非常晦涩难懂，但还是坚持读了下来。
第一遍读完之后，就开始看书后的读者感言，也在网上找其他人的读后感来看，才真正加深了理解。
如果有跟我一样，在第一次读这本书觉得很难读的，我还是建议您坚持读完，然后去参考其他人的读后感，你也能领会到这本书的精华所在。
“这个领域的知识在于累积”。
这句话是我在读第二遍的时候才从序言里注意到的，我这段时间开始读书，也不断地在寻找着读书的理由，当我再次翻开第一章开头，“前车之履，后车之鉴”瞬间给我空空的脑袋灌了一壶开水：读书的理由，是在于“积累”，“总结”，用前人的知识，来铺设自己的路。
因此我也萌生了写读书笔记的想法，把自己的路真正地铺设起来。
《人月神话》是一本论文集，每一章都可以单独做为一篇论文去阅读和理解，部分章节之间也存在着统一的中心论点，所以在阅读的时候，可以不按顺序选择自己感兴趣的章节进行阅读。
我的笔记是准备读完一章写一篇，希望自己有一个好的开头也能收获一个完美的结尾。
下面就正式开始我对第一章的读书理解吧。
人月神话读书笔记
人月神话读书笔记《人月神话》是一本由美国计算机科学家弗雷德里克·布鲁克斯所著的经典著作，该书于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亿人民币），但出货的时间不断的顺延。
《人月神话》读书笔记与心得体会
《人月神话》读书笔记与心得体会几年前刚刚步入软件开发行业，第一次接触软件行业的“人月”概念，了解软件行业的体系结构，懵懂的状态中，不经意间打开了传说中的《人月神话》，记忆中无知者无畏可以是最好的心理状态写实。
重温《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 产品在即将完成时总面临着陈旧过时的威胁。
阅读笔记《人月神话》1
阅读笔记《⼈⽉神话》1今天这篇阅读笔记主要讨论《⼈⽉神话》中的“⼈⽉神话”以及组建“外科⼿术队伍”。
⾸先介绍⼀下什么是⼈⽉神话。
我以前听⼈⽉神话的时候总是觉得很⽞幻，以为这是⼀个神话故事之类的。
我相信很多刚刚听到这个词汇的⼈都会这么认为，但是经过阅读发现，⼈⽉神话并不是神话故事。
这是⼀种软件开发过程中的度量单位。
估计完成⼀个项⽬⼤概需要多长时间，⽐如需要12⼈⽉，则可以理解为需要3个⼈⼯作4个⽉。
那么怎么⼜称为神话呢？因为使⽤⼈⽉这种度量⽅式，在很多情况下衡量⼀个⼀项⼯作的规模是⼀个危险和带有欺骗性的神话。
因为在以上关于⼈⽉的介绍中，根据这种计算⽅式，似乎⼈和⽉是可以等价互换，互相补充弥补的，但实际情况并不是如此。
并不能⽤增加⼈的数量来减少开发的周期，这是⼀种愚蠢的想法和做法。
⼈们在对项⽬进⾏估计的时候往往是⾮常乐观的，这是我们应该保持的⼀种良好的⼼态，但是我们更要从实际问题出发，遵循客观规律，不能盲⽬的乐观。
当⼈⽉可以互为转化时，这说明这个项⽬的每个模块的关联性很⼩，团队成员之间的交流也不会很多，⽽且交流起来会⾮常简单，只有基于这种情况下，⼈⽉的内涵才能够充分的得到体现，这种度量⽅式才能很好的阐述⼈⽉可以等价互换的理念。
但是事实往往并⾮如此。
每⼀个项⽬，项⽬的各个模块的联系都是⾮常紧密的，⽽且很多模块之间是由时间先后顺序的，这些因素决定了⼈⽉模型并不适合。
当⼈的数量⼤⼤增加时，并不能有效的缩短项⽬的完成时间，相反，还可能会增加项⽬的时间。
试想⼀下，当团队⼈数⽐较少时，每个⼈负责的⼯作量可能会⽐较⼤，但是每个⼈之间的交流会变得相对来说更加简单，⽽且交流的时间会⽐较少，⽽当⼈数⽐较多时，因为各个模块并不是孤⽴的，要考虑到其他的模块的实现⽅式，所以交流会变得困难起来，这样⽆疑就增加了时间开销，⽽且这种事件开销在⼀个项⽬中会占⽤⼤量的时间。
那么关于⼈⽉之间存在的这种⽭盾，我们该如何解决呢？⼀是，开发并推⾏⽣产率图表、缺陷率、估算规则等等，⽽整个组织最终会从这些数据的共享上获益。
人月神话读书笔记
人月神话读书笔记人月神话这本书几年前就听别人说是本很经典的软件开发方面的书，这本书的成功之处在于他思想的前卫性，以至于不只是软件行业的人在读。
现在终于找到读他的理由了，可以感受一下大师的杰作。
在读之前我已经读过了软件工艺和极限编程，为什么留到最后读人月神话呢?主要是因为我觉得一本能够流传30年还被人们津津乐道的书，肯定是本学要好好细读的书，所以留到了最后。
按照前两篇读书笔记的惯例，前面几段是一些我读书时的感受和收获，还有一些对内容的评价。
从这本书的内容来看，对于一个项目经理来说肯定会有更大的收获，这本书主要是针对软件开发管理方面的内容，这主要原因可能是因为作者以前就是项目的`管理者，他是站在管理者的角度写的。
即便这样，对于一个从来没有参与过真实项目开发，更没有领导过团队的我还是有一定的吸引力，这本书中我最喜欢的就是前四章和没有银弹这章。
这本书里面为了论证某一观点，会举出许多实际的项目作为证据，这一点非常好，事实胜于雄辩嘛!这些例子也许对于作者那个年代的人来说很好理解，但是放在30年后来看这些例子又有些陈旧和难懂了。
另外，从文中我发现作者非常注重文档，一个优质的文档就是项目成功的保证，这一点与传统的软件工程很相似，但是却与极限编程的观点相悖。
下面就是一些读书的总结了。
焦油坑 1. 编程系统产品开发的工作量是供个人使用的、独立开发的构件程序的九倍。
2. 编程行业的一些内在固有苦恼：l 将做事方式调整到追求完美，是学习编程的最困难部分。
l 由其他人来设定目标，并且必须依靠自己无法控制的事物。
l 真正的权威来自于每次任务的完成。
l 任何创造性活动都伴随着枯燥艰苦的劳动，编程也不例外l 人们通常期望项目在接近结束时能收敛得快一些，然而软件项目的情况却是越接近完成，收敛得越慢。
l 产品在即将完成时总面临着陈旧过时的威胁。
人月神话 1. 缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加起来影响还大。
人月神话读后感
编程产品（Programming Product）-- 可以被任何人 运行、测试、修复和扩展 的程序。它可以运行在多 种操作系统平台上，供多 套数据使用。3倍的成本。
编程系统产品 （Programming Systems Product）--才是真正有 用的产品，是大多数系 统开发的目标。9倍的 成本。
尽管计算机领域技术日新月异，编程方法和架构层出不穷， 《人月神话》这本书已经发表了40年了，现在读起来有些观 点还是那么鲜活，很有借鉴意义。
观点一
程序（Program）--它 本身是完整的，可以由 作者在所开发的系统平 台上运行，通常是车库 中产出的产品 编程系统（Programming System）--在功能上能相 互协作的程序集合，具有 规范的格式，可以进行交 互，并可以用来组装和搭 建整个系统。3倍的成本。
• 为变更计划系统
变更的阶段化是一种必要的技术。每个产品都应该有数字版本号，每个 版本都应该有自己的日程表和冻结日期，在此之变更计划组织架构
项目经理需要有两三个顶级程序员作为技术轻骑兵，当工作繁忙最密集 的时候，他们能急驰飞奔，解决各种问题。系统变化时，管理结构也需 要调整，管理人员需要参与技术课程，高级技术人才需要管理培训。
报告完毕，谢谢！
不要盲目压缩成本和工时，这样得到的系统很有可能不是真正有用的产 品，后期维护和二次开发成本会更高！
观点二
我认为用人月作为衡量一 项工作的规模是一个危险 和带有欺骗性的神话。 之所以会出现图2.4的情 况，主要原因是增加人员 是会增加培训和互相交流 的负担，尤其是后者。一 对一交流的情况下，三个 人的工作量是两个人的三 倍，四个人则是两个人的 六倍。所增加的用于沟通 的工作量可能会完全抵消 对原有任务分解所产生的 作用。 人月的谬论在当今软件开发时程评估时还经常发生，一个不小心就会造 成“添加更多的人手，实际上是延长了”，一定要引以为戒！
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
人月神话读书笔记(一)第一章焦油坑表面上看起来好像没有任何一个单独的问题会导致困难，每个都能被解决，但是当它们相互纠缠和积累在一起的时候，团队的行动就会变得越来越慢。
对问题的麻烦程度，每个人似乎都会感到惊讶，并且很难看清问题的本质。
不过，如果我们想解决问题，就必须试图先去理解它。
-- 清楚地解释系统开发的困难所在。
这，就是编程。
一个许多人痛苦挣扎的焦油坑以及一种乐趣和苦恼共存的创造性活动。
对于许多人而言，其中的乐趣远大于苦恼。
而本书的剩余部分将试图搭建一些桥梁，为通过这样的焦油坑提供一些指导。
-- 本书的目的第二章人月神话1. 在众多软件项目中，缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加起来的影响还大。
导致灾难的原因是：首先，我们对估算技术缺乏有效的研究。
第二，我们采用的估算技术隐含地假设人和月可以互换，错误地将进度与工作量相互混淆第三，由于对自己的估算缺乏信心，软件经理通常不会有耐心持续地进行估算这项工作。
第四，对进度缺少跟踪和监督。
第五，当意识到进度的偏移时，下意识（以及传统）的反应是增加人力。
2. 系统开发过程中，乐观主义并不应该是理所应当的。
在单个任务中，“一切都将运转正常”的假设在时间进度上具有可实现性。
因为所遇的延迟是一个概率分布曲线，“不会延迟”仅具有有限的概率，所以现实情况可能会像计划安排的那样顺利。
然而大型的编程工作，或多或少包含了很多任务，某些任务间还具有前后的次序，从而一切正常的概率变得非常小，甚至接近于无。
3. 成本的确随开发产品的人数和时间的不同，有着很大的变化，进度却不是如此。
因此我认为用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话。
它暗示着人员数量和时间是可以相互替换的。
因为软件开发本质上是一项系统的工作--错综复杂关系下的一种实践--沟通、交流的工作量非常大，它很快会消耗任务分解所节省下来的个人时间。
从而，添加更多的人手，实际上是延长了，而不是缩短了时间进度。
4. 在时间进度中，顺序限制所造成的影响，没有哪个部分比单元测试和系统测试所受到的牵涉更彻底。
对于任务的进度安排，以下是作者使用了很多年的经验法则：1/3 计划1/6 编码1/4 构件测试和早期系统测试（单元测试）1/4 系统测试5. 如果发现项目的实际进度滞后于预计的进度，项目经理最好的办法是重新安排进度，而不是增加项目人手。
6. 项目的时间依赖于顺序上的限制，人员的数量依赖于单个子任务的数量。
从这两个数值可以推算出进度时间表，该表安排的人员较少，花费的时间较长（唯一的风险是产品可能过时）。
相反，分派较多的人手，计划较短的时间，将无法得到可行的进度表。
总之，在众多软件项目中，缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加起来的影响还要大。
第三章外科手术队伍1.对于效率和概念的完整性来说，最好由少数干练的人员来设计和开发，而对于大型系统，则需要大量的人手，以使产品能在时间上满足要求。
如何调和这两方面的矛盾呢？--本章要解决的问题2. Mills的建议：外科医生（首席程序员）：定义功能和性能技术说明书，设计程序，编制源代码，测试以及书写技术文档。
副手：主要作用是作为设计的思考者、讨论者和评估人员。
管理员：控制财务、人员、工作地点安排和机器，充当组织中其他管理机构的接口。
编辑：根据外科医生的草稿或者口述的手稿，进行分析和重新组织，提供各种参考信息和书目，对多个版本进行维护以及监督文档生成的机制。
两个秘书程序职员：维护编程产品库中所有团队的技术记录。
工具维护人员：保证所有基本服务的可靠性，以及承担团队成员所需要的特殊工具（特别是交互式计算机服务）的构建、维护和升级责任。
测试人员：各个功能设计系统测试用例的对头，同时也是日常调试设计测试数据的助手。
负责计划测试的步骤和为测试搭建测试平台。
语言专家：寻找一种简洁、有效的使用语言的方法来解决复杂、晦涩或者棘手的问题。
3.当进行大系统开发时：要有一个系统结构师从上至下地进行所有的设计。
要使工作易于管理，必须清晰地划分体系结构设计和实现之间的界线，系统结构师必须一丝不苟地专注于体系结构。
第四章贵族专制、民主政治和系统设计1.概念一致性在系统设计中，概念完整性应该是最重要的考虑因素。
也就是说为了反映一系列连贯的设计思路，宁可省略一些不规则的特性和改进，也不提倡独立和无法整合的系统，哪怕它们其实包含着许多很好的设计。
2.功能与理解上复杂程度的比值才是系统设计的最终测试标准。
但是功能本身或者易于使用都无法成为一个好的设计评判标准。
3.简洁和直白来自概念的完整性。
每个部分必须反映相同的原理、原则和一致的折衷机制。
在语法上，每个部分应使用相同的技巧；在语义上，应具有同样的相似性。
因此，易用性实际上需要设计的一致性和概念上的完整性。
4.概念的完整性要求设计必须由一个人，或者非常少数互有默契的人员来实现。
5.系统的体系结构(architecture)指的是完整和详细的用户接口说明。
体系结构必须同实现仔细地区分开来。
6.作者不认为只有结构师才有好的创意。
新的概念经常来自实现者或者用户。
然而系统的概念完整性决定了使用的容易程度。
不能与系统基本概念进行整合的良好想法和特色，最好放到一边，不予考虑。
如果出现了很多非常重要但不兼容的构想，就应该抛弃原来的设计，对不同基本概念进行合并，在合并后的系统上重新开始。
7.概念的完整性的确要求系统只反映唯一的设计理念，用户所见的技术说明来自少数人的思想。
实际工作被划分成体系结构、设计实现和物理实现，但这并不意味着该开发模式下的系统需要更长的时间来创建。
经验显示恰恰相反，整个系统将会开发得更快，所需要的测试时间将更少。
同工作的水平分割相比，垂直划分从根本上大大减少了劳动量，结果是使交流彻底地简化，概念完整性得到大幅提高。
第五章画蛇添足1. 本章的目标：结构设计师要避免向系统中添加很多不实际的功能（避免画蛇添足）。
2. 尽早交流和持续沟通能使结构师有较好的成本意识，以及使开发人员获得对设计的信心，并且不会混淆各自的责任分工。
3. 面对估算过高的难题，结构师有两个选择：削减设计或者建议成本更低的实现方法--挑战估算的结果。
后者是固有的主观感性反应。
此时，结构师是在向开发人员的做事方式提出挑战。
想要成功，结构师必须牢记是开发人员承担创造性和发明性的实现责任，所以结构师只能建议，而不能支配；时刻准备着为所指定的说明建议一种实现的方法，同样准备接受其他任何能达到目标的方法；对上述的建议保持低调和平静；准备放弃坚持所作的改进建议。
4. 一个可以开阔结构师眼界的准则是为每个小功能分配一个值：每次改进，功能 x 不超过 m 字节的内存和 n 微秒。
这些值会在一开始作为决策的向导，在物理实现期间指南和对所有人的警示。
5. 项目经理必须坚持至少拥有两个系统以上开发经验的结构师的决定。
同时，保持对特殊诱惑的警觉，他可以不断提出正确的问题，确保原则上的概念和目标在详细设计中得到完整的体现。
第六章贯彻执行1. 问题：项目经理如何确保每个人听从、理解并实现结构师的决策？对于有多个结构师的小组如何保持系统概念上的完整性。
2. 手册、或者书面规格说明，是一个非常必要的工具。
手册是产品的外部规格说明，它描述和规定了用户所见的每一个细节；同样的，它也是结构师主要的工作产物。
手册不但要描述包括所有界面在内的用户可见的一切，它同时还要描述用户看不见的事物。
后者是编程实现人员的工作范畴，而实现人员的设计和创造是不应该被限制的。
体系结构设计人员必须为自己描述的任何特性准备一种实现方法，但是他不应该试图支配具体的实现过程。
规格说明的风格必须清晰、完整和准确。
用户常常会单独提到某个定义，所以每条说明都必须重复所有的基本要素，所以所有文字都要相互一致。
3. 规格说明中，形式化定义是精确的，它们倾向于更加完整；差异得更加明显，可以更快地完成。
但是形式化定义的缺点是不易理解。
记叙性文字则可以显示结构性的原则，描述阶段上或层次上的结构，以及提供例子。
应同时包括形式化和记叙性定义两种方式。
4. 通过会议的方式，开发人员进行沟通和讨论问题。
5. 不同实现之间严格要求相互兼容。
如果起初至少有两种以上的实现，那么定义会更加整洁和规范。
6. 对于存有疑问的实现人员，应鼓励他们打电话询问相应的结构师，而不是一边自行猜测一边工作。
一种有用的机制是由结构师保存电话日志。
日志中，他记录了每一个问题和相应的回答。
每周，对若干结构师的日志进行合并，重新整理，并发布给用户和实现人员。
这种机制很不正式，但非常快捷和易于理解。
7. 在最后的分析中，用户是独立的监督人员。
在残酷的现实使用环境中，每个细微缺陷都将无从遁形。
产品测试小组则是顾客的代理人，专门寻找缺陷。
不时地，细心的产品测试人员总会发现一些没有贯彻执行、设计决策没有正确理解或准确实现的地方。
出于这方面的原因，设立测试小组是使设计决策得以贯彻执行的必要手段，同样也是需要尽早着手，与设计同时实现的重要环节。
第七章为什么巴比伦塔会失败1. 项目人员之间的交流和沟通是项目能否顺利和成功的一个重要因素。
2. 缺乏交流引起进度灾难、功能的不合理和系统缺陷纷纷出现。
随着工作的进行，许多小组慢慢地修改自己程序的功能、规模和速度，他们明确或者隐含地更改了一些有效输入和输出结果用法上的约定。
团队如何进行相互之间的交流沟通：清晰定义小组内部的相互关系和充分利用电话，能鼓励大量的电话沟通，从而达到对所书写文档的共同理解。
常规项目会议。
会议中，团队一个接一个地进行简要的技术陈述。
这种方式非常有用，能澄清成百上千的细小误解。
在项目的开始阶段，应该准备正式的项目工作手册。
3. 项目工作手册不是独立的一篇文档，它是对项目必须产出的一系列文档进行组织的一种结构。
项目所有的文档都必须是该结构的一部分。
这包括目的、外部规格说明、接口说明、技术标准、内部说明和管理备忘录。
4. 使用项目工作手册的原因：技术说明几乎是必不可少的。
如果某人就硬件和软件的某部分，去查看一系列相关的用户手册。
他发现的不仅仅是思路，而且还有能追溯到最早备忘录的许多文字和章节，这些备忘录对产品提出建议或者解释设计。
正确的文档结构非常重要。
事先将项目工作手册设计好，能保证文档的结构本身是规范的。
另外，有了文档结构，后来书写的文字就可以放置在合适的章节中。
控制信息发布，确保信息能到达所有需要它的人的手中。
5. 团队组织的目的是减少不必要的交流和合作的数量。
减少交流的方法是人力划分和限定职责范围。
当使用人力划分和职责限定时，树状管理结构所映出对详细交流的需要会相应减少。
第八章胸有成竹1. 问题：系统编程需要花费多长时间？需要多少工作量？如何进行估计？2. 工作量是规模的幂函数。