当前位置：首页 > 实用文档 > 读后感> 「转」人月神话读后感3

「转」人月神话读后感3

时间：2022-05-07 14:06:05 读后感收藏本文下载本文

「转」人月神话读后感3(（通用14篇））由网友“Ageratum”投稿提供，下面是小编帮大家整理后的「转」人月神话读后感3，欢迎阅读，希望大家能够喜欢。

「转」人月神话读后感3

篇1：「转」人月神话读后感3

「转」人月神话读后感3

堵哥哥要我写人月神话的读后感，再找一篇膜拜一下~~~ ――――――――――――――――――――我是分割线―――――――――――――――――――――――― 不同的社会经验，不同的思想状态，对读本书的心得也不一样，我在此说说我的读后感，书中有许多非常好的观点，但我只把我感触最深的写下来。这确实是一本很值得多次阅读的好书，每次阅读可能都能从中得到一些提示。 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%，其他的时间都花在了无关的琐碎事情上。 7.削足适履Ten Pounds in a Five-Pound Sack 主要讲述程序占用的空间等，在70年代比较突出，但现在好多了。 8.提纲擎领The Documentary Hypothesis 说明文档的作用 9.未雨绸缪Plan to Throw One Away 唯一不变的是变化本身。在大型项目中，项目经理需要有两个和三个顶级程序员作为技术轻骑兵，当工作繁忙最密集的时候，他们能急驰飞奔，解决各种问题。讲述技术人员与项目人员的互换是，对我有一定的提示，但图中IBM的两条职位晋升线，不太理解。 10.干将莫邪Sharp Tools 主要讲述项目中管理好各种工具的重要性，项目经理首先要制定一种策略，让各种工具成为公用的工具，这样才能使开发、维护和使用这种工具的开发人员的效率更高，这种工具可能是开发人员开发出来的，也可能是使用现有的，可能是通用的，也可能是专用的或个人偏好的。比如：文档编写工具、开发工具（包括各种不同开发平台）、调试工具、测试工具、数据库工具、版本管理、项目管理工具等。 11.整体部分The Whole and the Parts 一读这一章，就让我感触颇深，特别是这句话BELL实验室监控系统项目的V.A.Vyssotsky提出,关键的工作是产品定义。许许多多的失败完全源于那些产品未精确定义的地方,细致的功能定义，详细的规格说明，规范话的功能描述说明以及这些方法的实施，大大减少了系统中必须查找的BUG数量。虽然这句话的意思只是说明精确定义产品将减少BUG的数量，但我看到了系统分析的最重要的工作――产品定义。现在，许多开发人员嘴里口口声声说也做过需求调研、系统分析、系统设计，但大多数没有涉及到产品定义的深度，严格意义上不能叫做系统分析。这句话对我的以后想从事系统分析工作有很大的帮助。这一章余下的内容，也值得一看，虽然有些地方有些过时，但剔除BUG的设计以及部分测试/调试方法仍值得一看。 12.祸起萧墙Hatching a Catastrophe 这章节说明使项目进度拖后的最大原因不是重要的事件，如新技术、重组等，而是一些琐碎的小事，每件小事只耽误半天或一天时间，但这种小事多以后，将使项目的进度严重拖后。项目对于公司就如程序对测试工程师一样，如果不了解它，它就是一个黑盒子，如果不打开这个黑盒子，你可能永远不知道盒子里面有什么。这部分描写项目经理以及小组主管的一些心理，值得一看。 13.另外一面The other face 本章说明程序的另一面――文档。不了解，就无法真正拥有――歌德，作者引用的歌德的话来描述文档对客户的重要性，提出客户需要什么样的文档以及文档的格式和包含的内容，指出当时存在的大多数文档只描述了树木，形容了树叶，但没有整个森林的图案。想想，这种情况在现在仍然没有改变。于是作者提出了两个观点： 1.流程图：流程图是被吹捧得最过分的一种程序文档。许多程序甚至不需要流程图，很少程序需要一页以上的流程图 2.自文档化（self-documenting）的程序：提出文档与程序合为一体，能很好的解决文档与程序分开造成的文档过时的问题，并说明了在程序中加入文档的一些方法和技巧。，我看到一位网友关于文档与程序合一的文章，当时就觉得是个好方法，没想到70年代，老美已经提出来了。 14.没有银弹-软件工程中的根本和次要问题(No Silver Bullet-Essence and Accident in software Engineering) 这是一篇论文，发表于1986年,我自认为我的.理论水平没有上升到可以对他的论点和论据做出怀疑或质疑的结论，我只是说说我的感想。人狼是传说中的妖怪，只有银弹才能杀死他。作者认为软件项目具有人狼的特性，因为软件项目也可能变成一个怪物，一个落后进度、超出预算、存在大量缺陷的怪物。作者通过软件系统的内在特性复杂性、一致性、可变性和不可见性来分析说明了软件天生就没有银弹。作者试图通过分析软件问题的本质和很多侯选银弹的特征来探究其中的原因。他行动的第一步是将大块的“巨无霸理论”替换成“微生物理论”。这个变化的过程告诉你，进步是逐步取得的，伴随着辛勤的劳动，对规范化过程应进行持续不懈的努力，而这个努力的过程相应的就诞生了软件工程。作者对软件工程诞生的原因做出这样的解释，我觉得符合外国思维的特点，这正是国人所缺乏。记得有一位朋友说过，中国妈妈与德国妈妈的区别，他说，如果手里拿的针掉到地上了，中国妈妈的第一反应是估计针掉下去的范围，然后在这个范围里面找，可能很快就找到了，也可能一直都找不到；但德国妈妈不同，她会拿一根粉笔来，把整个屋子画成一个大圈，接着把大圈分成许许多多的小圈，然后再到每个小圈里找，虽然比较慢，但最终肯定可以找到。仔细想象，大多数情况下，中国妈妈都会找到得比较快，这确实符合大多数中国妈妈的思维习惯，每个中国妈妈都这样找，这好象是与生俱来的本事，但为什么德国妈妈没有这个本事呢？是德国妈妈笨吗？为什么中国妈妈也有找不到的情况？而德国妈妈，虽然速度慢了点，却始终能够找得到？如果把这件故事推而广之，多年以后，德国妈妈创建了找针工程，她通过多次找针的实验数据，分析出针掉到整个房间中各个小圈的概率，总结出针在哪个小圈的概率最大，很快就可以找到针，找针速度早已高过中国妈妈，而中国妈妈还在依循与生俱来的本事。你能说德国妈妈笨吗？为什么中国妈妈和德国妈妈会有这么大的区别？是德国妈妈把大块的“巨无霸理论”替换成“微生物理论”吗？我觉得是是，你说呢？作者在后面的论述中用数学和物理的发展为例子也说明了，这种思想的成立。余下的作者把软件工程按“巨无霸理论”替换成“微生物理论”的过程详细的说明，值得看，我关注的不是具体的内容，具体内容可能有些不合适宜，我关注的是作者的思考方式以及处理方法，这是非常重要的。在“以往解决次要困难的一些突破”和“银弹的希望”章节，从概念上讲述了软件的发展，其中讲到“专家系统”时，使我想起一部科幻电影，忘了电影名字了，有个情节大致是这样的，一位非常有经验的主管死后，有一名较优秀的下属接任，但这时出现了一位非常厉害的敌人，这位新主管无论如何也战胜不了敌人，这时想起了以前的主管，心想前主管一定有办法对付这个敌人，而前主管的大脑就存放在系统里，于是新主管调出前主管的大脑，把敌人的各种特征都描述给他听，就好象前主管仍然活着一样，他与前主管的大脑通话后，前主管的大脑告诉了他对付敌人的方法，后来通过这个方法真的把敌人打败了。这是否专家系统的最佳境界呢？还有讲到“自动”编程章节时，使我想起我以前也有过类似的想法，但没想到这些想法竟然早就有人提出过。还有记得“图形化编程”好象也风行过一段日子。 15.再论《没有银弹》No Silver Bullet Refired 看完再论《没有银弹》后，虽然作者说有不少人对他的观点持反对或不同意见，但我始终觉得他的观点是对的――根本和次要问题的划分以及定义。作者认为软件开发困难的部分是概念的结构，如规格化、设计和测试等概念的结构，而不是概念的表述和实现概念，虽然实现概念可能占用了小于90%的时间，就如现今的软件开发一样，系统分析通常占用的整个项目开发时间不超过20%，而80%的时间花在编程上一样

篇2：「转」人月神话读后感

「转」人月神话读后感

堵哥哥要我写人月神话的读后感，先找一篇膜拜一下~~~ ――――――――――――――――――――我是分割线―――――――――――――――――――――――― 《人月神话》这本书风行已经很久了，写成于1975年，经历这么久的时间，在当前又重新流行，让我很惊讶,但是一直没有时间读。今天突然想起自己的机器上有本拷贝别人的电子书，决定读读。我今天只看了两章，即焦油坑和人月神话。人月神话看上去这么浪漫的名字，原来并不是真的说神话故事，作者阐述的主要观点是在软件开发项目上项目进度和增加人员这两个概念是不能互换。虽然已经时隔20多年了，这本书依然给我震撼，一是让我惊讶的是，美国前软件项目所面临的问题，在我们现在依然如此，糟糕的情况没有改变，大家仍旧在焦油坑里挣扎，而且看上去没有解决办法。二是作者对软件项目失败的.总结，每一个问题我们依旧再犯，特别读到“是当意识到进度的偏移时，下意识（以及传统）的反应是增加人力。这就像使用汽油灭火一样，只会使事情更糟。越来越大的火势需要更多的汽油，从而进入了一场注定会导致灾难的循环。“，我对这句话简直是太有感触了，因为我身边这样的悲剧整天都在上演，公司对所有的项目搞得都是人海战术，进度没有提前，还整天加班，最后用户不满意，开发人员整天郁闷，结果是用户对公司失去了信任，成了一槌子买卖，开发人员就像割韭菜，旧人一一辞职，新人天天引进，公司何谈发展和积累，做了n年，涛声依旧，做法没有改变，情况没有改观，公司没有发展，好在中国人多地大，呼悠完一个行业，再呼悠另一个行业。三是作者在那个时候，就根据自己的经验提出了对于软件任务的进度安排，以下是作者使用了很多年的经验法则： 1/3计划 1/6编码 1/4构件测试和早期系统测试 1/4系统测试，所有的构件已完成我们公司是通过cmm3认证的，理论不用我说，大家好像都明白，实际情况呢，有谁真的拿出那么多时间作计划，又有谁拿出那么多时间作测试，不过令人欣慰的是，大家确实在向这方面改变，比如我们公司测试部现在就是一个很大很关键的部门，所有的程序发布都需要测试人员的签字。当然，也许可以找点客观原因，比如现在国内多数客户不成熟，签单子靠关系，一旦签了又恨不得明天就正式运行，但是本着“没有任何借口”的观点，我们该怎样改进呢，我决定读下去，看看能否找到作者所说的银弹呢。

篇3：「转」人月神话读后感2

「转」人月神话读后感2

堵哥哥要我写人月神话的读后感，再找一篇膜拜一下~~~ ――――――――――――――――――――我是分割线―――――――――――――――――――――――― 这本300多页（中文新版）的神书，在经过了20多年的历史之后，仍然畅销不衰，究竟是什么让它有如此的魅力？过去的一个月，一点一滴的阅读之中算是初步的了解到了它的一部分吧。人月神话的核心观点：概念完整性和架构师 Brooks认为，一个整洁、优雅的变成产品必须向它的每位用户提供一个条理分明的概念模型，这个模型描述了应用，实现应用的方法以及用来指明操作和各种参数的用户界面使用策略。概念的完整性是易用性中最重要的因素。而架构师，则是负责保证产品所有方面的概念完整性的，架构师设计的是能够让用户理解产品概念的模型，这包括所有的功能的详细说明以及调用和控制的方法。它就像电影的导演一样。我的理解：这里的概念完整性其实应该说的是这个软件理念上的业务流程的前后连贯，也就是用户在使用产品的过程中，能够按照唯一的一个的最高抽象的思路来使用这整个系统。开发第二个系统的后果――盲目的功能和频率猜测所谓第二个系统，指的是产品的第二个实际发布。开发第一个发布的时候会因为各种原因去消减不必须的功能，所以会简化问题，而在第二个版本的时候则常常想其中添加各种各样的功能（也许源于用户的功能建议）但是，却导致了灾难性的后果。所以，在这种情况下，用户群越大，越不稳定，我们就更加应该明确的定义用户群，以获得概念的完整性。我们必须为整个设计团队定义一个共同的用户图像，记录下用户群的属性： 1. 他们是谁 2. 他们need什么 3. 他们认为自己need什么 4. 他们want什么而另一方面，对于任何产品，任何用户群属性都是一种概率上的分布的，也就是每个属性都有各种可能的值，所以我们能做的是，架构师去猜测（guess）或者假设（postulate）一系列完整的属性和频率值。这里，清晰和错误都将比模糊不清好得多。不同的社会经验，不同的思想状态，对读后的'心得也会不一样.比如： 1. 外科手术队伍The Surgical Team 项目经理在项目的初期必须清楚的估计项目的人月运作模式（时间、人力在项目各阶段的分配），例如什么时候需要出什么样成果，决定了什么时候需要什么样的人加入项目，这是项目经理的责任。 2. 如何才能与实现人员就技术说明的琐碎细节充分沟通，以确保设计被正确地理解，并精确地整合到产品中。 3. 贯彻执行Passing the word 印象比较深刻的是”体系结构设计人员必须为自己描述的任何特性准备一种实现方法，但他不应该支配具体的实现过程。” 4. 胸有成竹Calling the Shot 主要讲述如何计算编程时间，以及提出几个人的经验算法。讲述的各种算法可能都不太适合与现在的高级语言，但Portman的观点仍然适合现在，即编程人员实际的编程时间只有50％，其他的时间都花在了无关的琐碎事情上。 5. 整体部分The Whole and the Parts 一读这一章，就让我感触颇深，特别是这句话”BELL实验室监控系统项目的V.A.Vyssotsky提出，’关键的工作是产品定义。许许多多的失败完全源于那些产品未精确定义的地方’，细致的功能定义，详细的规格说明，规范话的功能描述说明以及这些方法的实施，大大减少了系统中必须查找的BUG数量”。虽然这句话的意思只是说明精确定义产品将减少BUG的数量，但我看到了系统分析的最重要的工作――产品定义。现在，许多开发人员嘴里口口声声说也做过需求调研、系统分析、系统设计，但大多数没有涉及到产品定义的深度，严格意义上不能叫做系统分析。这句话对我的以后想从事系统分析工作有很大的帮助。这一章余下的内容，也值得一看，虽然有些地方有些过时，但剔除BUG的设计以及部分测试/调试方法仍值得一看。

篇4：人月神话读后感

人月神话读后感

、《人月神话》是预言了未来还是扼制了未来?

事实是：我们目前的许多工程知识，――无论是从书上看到的，还是从实践中经验到的――大多未曾脱离《人月神话》之所言。

我在开篇中说《人月神话》“是一本可怕的书”。然而我感受恳挚的可怕之处在于：现今凡是论及工程(且不要让人感受是离经叛道)，那么所解说的定然是Brooks的这么的经验以及由此推出的见解，可能在不违拗这些经验和见解上的一些翔实的实作措施!我们全然不顾书中所言是假象，还是性质的推论，可能只是假象归纳的一个(未必准确的)答案。尽管这些答案大多数时候都好像预期地展目前你的切实工程中：

原文中还有众多相仿的见解、假象和答案，都成为了切实工程中的既存假象。先民们所说的圣人以及通神者，皆因他们多数时候在准确地预言自己的切实。只有当这个“多数时候”变成半点的时候，先民们才会置疑圣人和通神者的力气。其实我们懂得并未曾预言未来的人，大多数时候是两种情形导致的假象：

他做出了准确的推断;

你主观地跟随了他对未来的设定。

后者是风险的。大师们预言了未来也就改换了未来，即便未来未必“该当”好像他所预言的那样。

但万一这种预言的前提不准确，那么未来定然脱离这种波及而回到它该当的事态上去。好像我们看到的另一些事实一样，有许多假象阐明，我们正在归来工程***的道路上摸索前进。我们也觉察，在大多数情形下，先哲们的预言在实践中被检讨着，只是偶尔“不太灵光”。下表则列出一些不同的例子：

注1：我例举了爽利的一些见解，并不阐明我是AP/XP的fans。AP/XP的.问题另论，在这里，我只是解释存在一种不同的信念。

注2：Brooks尔后确认“定然丢弃原型”是一个不太准确的见解。

注3：Brooks在这里未曾犯讹谬，只是他所谈论的是狭义的流程图，而我们例举的时序图则更广义。

我们追忆上一细节，在《人月神话》中的那“31%的答案”的前提――也即便那7%的性质中，如下两项是显明猜忌的(也是重要置疑)：

目标的性质：是大型工程，是系统项目，而不是过程

个体的性质：是私利性的

其实早就有人意识到个体的性质“未必全是私利的”，尊重这些个体就会带来一些收获。例如AP正是因为更尊重开发人员的禀性与力气，以及互相间的配合而获得了效率的晋级。

再进一步地说，既然Brooks设定了“大型工程或系统项目”这么的目标，并给出了一些答案。那么在“小那么一点点的”工程项目中，是不是这些答案就无须定了呢?例如Brooks的众多提倡，对于某些目标――例如你要用为期三个月的工夫开发一个的产品――就并不是很管用;可能大约无法厉行――例如你的群体总共只有6个人，连“外科手术式的群体”都组织不起来。

Brooks的答案对于同样的目标，以及在他所述的“性质”未能发生改换时，还是比拟管用(或有厉行的可能性)。因而上述一些例外，总是在上述的“7%的性质”被抵赖或被改换的情形下获得的。因而我们提出的问题是“如何抵赖或改换”这些难以撼动的性质。然而在我看来，Brooks早曾经在最佳位置上，给出了撬动它们的一个支点：

Brooks感受发生“自力更生小型过程”与“编程系统产品”是不同的问题。

Brooks谈论的编程系统产品的规模究竟有多大呢?我想起码该当是以IBM 360为参看的。不过书中在引用Joel Aron(IBM在马里兰州盖兹堡的系统技巧主管)的例子时说，“大型意味着过程员的数目超过25人，将近30,000行的号召”。而按照《人月神话》的数据：人均效率800号召/人年，则这个“大型项目”该当必需1.5年能力告终。另外，还必需大约一倍的人工，来负责除开代码之外的测验、管教、文档和沟通等工作。

好的，万一你有一个“(起码)50人，开发一年半”的项目，那么你能够先接受Brooks的答案去实践一下：起码你能够有工夫来谈论工程问题，也能够组建那样规模的群体。然而，难道只有这么的“大型工程”才算得工程，而“小那么一点点”的就不算吗?切实是，我们一方面在做着“小那么一点点的”工程项目，另一方面在听着全副业界嘈杂着“为更大规模的工程”而准备的工程理论。我们总在实践Brooks的“答案”可能“预言”，而淡忘这些答案的前提：

Brooks的经验源自对IBM 360等大型项目标实践与分析;

Brooks所述的工程是要获得编程系统产品;

Brooks感受编程系统产品的工作量可能是自力更生小型过程的9倍(在告终大约雷同功能的情形下)。

事实上我们目前的软件工程的进展是被驾驶了，而不是被预言了。从性质上来说，Brooks在《人月神话》中只是谈论了大型工程的厉行，以及相应规模下的群体创立。而我们，便按照这么的设定来摆开了全副软件工作的工程化厉行。

促成这种现状的，并不但仅是一本书的能力，还在于商业的能力。因为只有在这么扩展开来的工作环境中，才可能有商业时机。――即便那些工程顾问与厉行专家历来未曾厉行过“50人，开发一年半”这么的项目，凡是他们能报出Brooks的名字，能谈及某些工具在应付“大型项目”中的获胜经验，他们就曾经获胜了一半了。

为什么“爽利”之初颇受争议?为什么爽利对一些中小型的群体显得管用和可厉行?为什么当这些争议被摆在现在的获胜平息尔后，传统工程的理论家们却不忘恨恨地评上一句：那是一种不能(或难以)利用于大型工程的措施呢?!

因为万一大家都很“爽利”，都只做比这些大型工程“小那么一点点”的工程，那么传统工程的专家们就失业了。反到来，只有把工程做大，大到“爽利”错过了含义，而“宏伟”变成了性质的时候，传统工程就可感受任何失利找到借口：看啊，Brooks就说过“未曾银弹”嘛。

篇5：人月神话读后感

人月神话读后感

当我捧起《人月神话》，马上就被深深的吸引了。书中很多细微之处都对我的思维造成了冲击。上一本给我类似感觉的书是那本四人帮的《设计模式》，已经很久没有看到这么好的书了，郑重推荐。

把感触比较深的几点记下来，顺便整理一下自己的思路，与大家分享。

1，保持设计的概念完整。无论对小软件还是大软件，都必须由一个设计师主导，最多两个人讨论来共同完成软件的整体设计。作为一个软件，一个系统，必须有一个清晰明确的概念模型，大家都在这个框架下工作，所有的创新发展都必须与基本的概念相吻合。具体的实现人员可以细化概念，但只有总设计者才有否定与发展基本概念的权力。需要注意的一点是，即使是总设计师一直是同一个人，他脑海中所认为理所当然的规则或者概念，很可能由于没有明确的文档化，而没有成为所有开发者共同的概念。在其他开发者编码的时候，就可能会生成与概念相抵触的东东（模块，功能，算法），导致整体结构的恶化。这个时候总设计师一定要即时发现，做出更正。

概念的完整性，对于很多小规模软件，由于开发人员不多，开发经理一般都能控制住所有的代码，概念完整性在组织层面就维持住了。但要注意以后的Bug修改，功能扩展的时候，也要时刻留意与最初的设计是否概念上相容。对于大规模的软件系统，则必须通过树状组织结构，层层控制，总设计师还是一到两人，每一层都有对下层的绝对把握能力。我以前参加过一个15人左右的项目组，就是分为两层。感觉整体概念完整性的控制效果还不错。我没有更多人数项目的具体实践经验，希望以后能有机会参与比较大的项目。

2，“一个拿2倍工资的人，生产率可能是其他人的10倍。”我和我的同学，一个小公司的技术总监聊起这个，他也是十分的认同。不知道其他公司的程序员们如何看。我的同事中有一个牛人，做出的贡献特别大，应该相当于我们公司普通的十个程序员，不过工资最多也就是普通程序员的二倍。是不是有些不公平呢？我也说不清楚。因为那些普通程序员也十分的努力。不过，我觉得，作为公司，应该给最好的人最好的待遇，或者说给比目前更高的待遇。

组建一个团队，最好的就是那种精英团队，大家都是牛人，效率会特别高。微软就是这种思路吧，把最聪明的人集中在一起，想不成功都难亚。

3，进度落后与增加人力。记得当年看《C＋＋编程思想》，Bruce说“十个妇女不能在一个月内生下小孩”（大意），于我心有戚戚焉。而本书作者Brooks得出的结论是对我是震撼性的：“向进度落后的项目中增加人手，只会使进度更加落后”。()

以前，增加人手基本是挽救进度落后项目的主要办法。这个办法行不通的话，难道只有“加班”一条路了？但长期加班是对个人的摧残，我更愿意利用业余时间去看书，例如看这本“人月神话”。）

如果不想加班，不想削减功能，不想推迟发布日期，那么……唯一的方法还是只有…加人。加足够的人。而且不要逐步加入，一定要一次性加入。要小心的是，新加入的人可能对原来的组织造成冲击，或者对原来的设计有不同意见（特别是加入的人中有比较强大的设计者）。那么，就当作，新组建了一个团队吧。交流，培训新人，就设计达成一致，继续向者目标前进。

感触还有很多，以后如果有机会再写。不过，我决定去买本英文版回来，收藏，以后再多看几次。

篇6：《人月神话》读后感500字

最近读了一本书《人月神话》，这本书是软件工程类的一本经典著作。阅读这本书的第一感受就是感觉这本书不像是一种和学习相关的书，更像是用很多形象的比喻，阐述项目管理当中的一些问题，让读者能够很轻松，明白的去阅读。

一般在大学学习计算机行业的时候，都会学习一门叫做软件工程的课程，老师也会跟我们讲一些关于“软件项目开发的完成与增加人员的问题”，在读这本书的`时候，这个问题给了我很大的感触。很多人认为，当任务在规定期限内还完成不了的时候，适当的加一些人员进去，可以加快任务的进度，从而能够在规定的时间完成任务。但是这个观点在软件工程当中是不适用的。这也是我在阅读完《人月神话》这本书时最大的感受。

这本书的第二章就讲述了人月神话的关系，完成工作的人数和时间是不能进行简单的互换的。因为新加入的人对原有的项目不了解，需要花时间培训，读后感交流，同时新人也有可能对原有的设计有不同的意见，这些都会导致任务的进度大打折扣。“向进度落后的项目中增加人手，只会使进度更加落后”，是这本书作者布鲁克斯得到的结论。

我觉得开发一个软件，要有合理的时间进度安排，项目开发的人员少而精，团队开发之前要提前交流，开发的时候要持续的沟通，合理的分配任务工作。所有只有在一个团队沟通了解，通力协作和努力下，才能更好的完善项目。

篇7：人月神话读书笔记

人月神话读书笔记

人月神话这本书几年前就听别人说是本很经典的软件开发方面的书，这本书的成功之处在于他思想的前卫性，以至于不只是软件行业的人在读。现在终于找到读他的理由了，可以感受一下大师的杰作。在读之前我已经读过了软件工艺和极限编程，为什么留到最后读人月神话呢？主要是因为我觉得一本能够流传30年还被人们津津乐道的书，肯定是本学要好好细读的书，所以留到了最后。按照前两篇读书笔记的惯例，前面几段是一些我读书时的感受和收获，还有一些对内容的评价。

从这本书的内容来看，对于一个项目经理来说肯定会有更大的收获，这本书主要是针对软件开发管理方面的内容，这主要原因可能是因为作者以前就是项目的管理者，他是站在管理者的角度写的。即便这样，对于一个从来没有参与过真实项目开发，更没有领导过团队的我还是有一定的吸引力，这本书中我最喜欢的就是前四章（焦油坑、人月神话、外科手术队伍、贵族专制、民主政治和系统设计）和没有银弹这章。这本书里面为了论证某一观点，会举出许多实际的项目作为证据，这一点非常好，事实胜于雄辩嘛！这些例子也许对于作者那个年代的人来说很好理解，但是放在30年后来看这些例子又有些陈旧和难懂了。另外，从文中我发现作者非常注重文档，一个优质的文档就是项目成功的保证，这一点与传统的软件工程很相似，但是却与极限编程的观点相悖。下面就是一些读书的总结了。

焦油坑 1. 编程系统产品开发的工作量是供个人使用的、独立开发的构件程序的九倍。

2. 编程行业的一些内在固有苦恼：

l 将做事方式调整到追求完美，是学习编程的最困难部分。

l 由其他人来设定目标，并且必须依靠自己无法控制的事物。

l 真正的权威来自于每次任务的完成。

l 任何创造性活动都伴随着枯燥艰苦的劳动，编程也不例外

l 人们通常期望项目在接近结束时（bug、工作时间）能收敛得快一些，然而软件项目的情况却是越接近完成，收敛得越慢。

l 产品在即将完成时总面临着陈旧过时的威胁。人月神话 1. 缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加起来影响还大。

2. 良好的烹饪需要时间，某些任务无法在不损害结果的情况下加快速度。

3. 我们的构思是有缺陷的，因此总会有bug。

4. 我们围绕成本核算的估计技术，混淆了工作量和项目进展。人月是危险和带有欺骗性的神话，因为它暗示人员数量和时间是可以相互替换的。

5. 在若干人员中分解任务会引发额外的沟通工作量--培训和相互沟通。

6. 关于进度安排，作者的经验是为1/3计划、1/6编码、1/4构件测试以及1/4系统测试。

7. 因为我们对自己的估计技术不确定，所以在管理和客户的压力下，我们常常缺乏坚持的勇气。

8. brook法则：向进度落后的项目中增加人手，只会使进度更加落后。

9. 向软件项目中增派人手从三个方面增加了项目必要的总体工作量：任务重新分配本身和所造成的工作中断；培训新人员；额外的相互沟通。外科手术队伍 1. 同样有两年经验而且在受到同样的培训的情况下，优秀的专业程序员的工作效率是较差程序员的十倍。关于这一条我在极限编程里看到，sackman和humphrey分别做了实验发现优秀程序员工作效率比较差程序员的工作效率最高要高达28倍。

2. 小型、精干队伍是最好的。这一点在软件工艺和极限编程里都得到了充分的体现。

3. 两个人的团队，其中一个项目经理，常常是最佳的人员使用方法。

4. 对于真正意义上的大型系统，小型精干的队伍太慢了。

5. 实际上，绝大多数大型编程系统的经验显示出，一拥而上的`开发方法是高成本、速度缓慢、不充分的，开发出的产品无法进行概念上的集成。

6. 一位首席程序员、类似于外科手术队伍的团队架构提供了一种方法，既能获得由少数头脑产生的产品完整性，又能得到多位协助人员的总体生产率，还彻底地减少了沟通的工作量。图1是10人的程序开发队伍沟通模式。图1 10人程序开发队伍沟通模式

贵族专制、民主政治和系统设计 1. 概念完整性是系统设计中最重要的考虑因素。

2. 为了获得概念完整性，设计必须由一个人或者具有共识的小型团队来完成。

3. 对于非常大型的项目，将设计方法、体系结构方面的工作与具体实现相分离是获得概念完整性的强有力方法。

4. 纪律、规则对行业是有益的。外部的体系结构规定实际上是增强，而不是限制实现小组的创造性。

5. 体系结构、设计实现、物理实现的许多工作可以并发进行。画蛇添足 1. 尽早交流和持续沟通能使结构师有较好的成本意识，以及使开发人员获得对设计的信心，并且不会混淆各自的责任分工。

2. 结构师如何成功地影响实现：

i. 牢记是开发人员承担创造性的实现责任；结构师只能提出建议。

ii. 听取开发人员在体系结构上改进的建议。

3. 第二个系统是人们所设计的最危险的系统，通常的倾向是过分地进行设计。关于这一点也许是正确的，但是这是一个回避不了的问题，如果没有开发第二个系统经验的人，就不可能有开发第三个系统经验的人了。贯彻执行 1. 即使是大型的设计团队，设计结果也必须由一个或两个人来完成，以确保这些决定是一致的。

1 2

2. 必须明确定义体系结构中与先前定义不同的地方，重新定义的详细程度应该与原先的说明一致。

3. 出于精确性的考虑，我们需要形式化的设计定义，同样，我们需要记叙性定义来加深理解。

4. 允许体系结构师对实现人员的询问做出电话应答解释是非常重要的，并且必须进行日志记录和整理发布。

5. 项目经理最好的朋友就是他每天要面对的敌人--独立的产品测试机构/小组。为什么巴比伦塔会失败？ 1. 巴比伦塔项目的失败是因为缺乏交流，以及交流的结果的组织。

2. 因为左手不知道右手在做什么，从而进度灾难、功能的不合理和系统缺陷纷纷出现。由于对其他人的各种假设，团队成员之间的理解开始出现偏差。

3. 团队应该以尽可能多的方式进行相互之间的交流：非正式、常规项目会议，会上进行简要的技术陈述、共享的正式项目工作手册。胸有成竹 1. 仅仅通过对编码部分的估计，然后乘以任务其他部分的相对系数，是无法得出对整项工作的精确估计的。

2. 构建独立小型程序的数据不适用于编程系统项目。

3. 程序开发与程序规模成指数增长趋势。

4. 当使用适当的高级语言时，程序编制的生产率可以提高5倍。削足适履

这一章主要是要解决项目投资与磁盘空间和内存之间的矛盾，但是这个矛盾在电脑硬件发展到现在的层次已经可以忽略掉了。

提纲挈领 1. 软件项目的要求：目标、用户手册、内部文档、进度、预算、组织机构图和工作空间分配。

2. 即使是小型项目，项目经理也应该在项目早期规范化上述的一系列文档。这一章强调文档重要性，但并没有将一些教条主义的道理让你相信文档的重要性，而是给项目经理给出了实实在在的操作步骤。

未雨绸缪 1. 对于大多数项目，第一个开发的系统并不合用。它可能太慢、太大，而且难以使用，或者三者兼而有之。系统的丢弃和重新设计可以一步完成，也可以一块块地实现。这是个必须完成的步骤，如果将开发的第一个系统丢弃原型发布给用户，可以获得时间，但是它的代价很高。对于用户，使用极度痛苦；对于重新开发的人员，分散了精力；对于产品，影响了声誉，即使最好的再设计也难以挽回名声。

2. 用户的实际需要和用户感觉会随着程序的构建、测试和使用而变化。

3. 软件产品易于掌握的特性和不可见性，导致了它的构建人员面临着永恒的需求变更。

4. 目标和开发策略上的一些正常变化无可避免，事先为它们做准备总比假设它们不会出现要好得多。

5. 对于一个广泛使用的程序，其维护总成本通常是开发成本的40％或更多。

6. 维护成本受用户数目的严重影响。用户越多，所发现的错误也越多。

7. campbell指出了一个显示产品生命期中每月bug数的有趣曲线，它先是下降，然后攀升。

8. 缺陷修复总会以（20－50）%的机率引入新的bug。

9. 在每次修复之后，必须重新运行先前所有的测试用例，从而确保系统不会以更隐蔽的方式被破坏。

10. 同样，设计实现的人员越少、接口越少，产生的错误也就越少。

11. 所有修改都倾向于破坏系统的架构，增加了系统的混乱程度。即使是最熟练的软件维护工作，也只是放缓了系统退化到不可修复混乱的进程。干将莫邪

项目经理应该制订一套策略，以及为通用工具的开发分配资源，与此同时，他还必须意识到专业工具的需求。

祸起萧墙 1. 一天一天的进度落后比起重大灾难，更难以识别，更不容易防范和更加难以弥补。

2. 根据一个严格的进度表来控制项目的第一个步骤是制订进度表，进度表由里程碑和日期组成。

3. 里程碑必须是具体的、特定的、可度量的事件，能进行清晰能定义。

4. 如果里程碑定义得非常明确，以致于无法自欺欺人时，程序员很少会就里程碑的进展弄虚作假。另外一面 1. 对于软件编程产品来说，程序向用户所呈现的面貌与提供给机器识别的内容同样重要。

2. 即使对于完全开发给自己使用的程序，描述性文字也是必须的，因为它们会被用户和作者所遗忘。

3. 文档能在整个软件开发的生命周期对程序员克服懒惰和进度的压力起促进激励作用，但向编程人员成功地灌输对待文档的积极态度是一件困难的事情。

4. 为了使文档易于维护，将它们合并至源程序是至关重要的，而不是作为独立文档进行保存。没有银弹

人狼的传说可能有人听过也可能没听过，人狼是一种具有人和狼两种特征的恐怖生物，而银弹是消灭它的一种最有效的子弹，如果看过《吸血鬼传说》也许就能和容易的理解这一点。作者将软件开发比作人狼，而将提高软件开发效率的方法比作银弹。作者预言未来十年，想要试图通过寻找一种有效地银弹将软件开发效率提高一个甚至几个数量级，这种银弹不可能出现。

没有银弹这篇文章里作者列举出了当时一些非常先进的技术或思想理念，例如ada和其他高级编程语言、面向对象编程、人工智能、专家系统、“自动”编程、图形化编程、程序验证、环境和工具、工作站等。虽然这些先进技术在一定程度上提高了软件开发的效率，但是始终没有达到银弹的效果。距离作者的预言已经过去有20多年了，纵观现在的软件开发领域，虽然新技术层出不穷，但是还是没有一种银弹能够让软件开发产生一次革命。

焦油坑依然存在

软件工程的焦油坑在将来很长一段时间内会继续困扰着人们。由于软件系统多变性和错综复杂性，这个行业只能是一步一个台阶的往上爬，而出现银弹的希望在我们可以想象的时间范围内是非常渺茫的。我们将长期与焦油作斗争。

篇8：《人月神话》读书心得

《人月神话》读书心得

本月阅读了该部软件工程巨著中第八章--胸有成竹(Calling the Shot)，该章节讲述了软件开发中如何进行准确的项目预测和估算。

本章的标题是胸有成竹，而在开发中真正要做到成竹在胸就必须在项目计划阶段就要对项目的预测和估算都能准确把握。估算要做到准确就必须通过前期多个历史项目和版本的积累，同时通过历史版本和数据的积累来发现和预测指标Y和相应的估算因子X之间的关系。其实也就是进行开发中的专家经验型估算。这样建立出来的估算模型就可以基本保证我们的估算准确性。

最早用的估算方法是建立需求--设计--编码--测试各个阶段工作量之间的比例关系，然后根据需求的工作量来推导其它各个阶段的工作量或者是根据编码工作量来反推上游各个阶段的工作量。这种方式在项目规模比较稳定的小型项目中是比较适用的，但是它不能简单的类比应用到大型软件项目中，因为随着项目规模的扩大，规模和工作量之间已经不是简单的线性关系了。在进行大型软件项目的开发中，要对整个项目做出准确的估算更显得困难。Microsoft公司的windows开发就出现整体项目的'延期，而Blizzard公司的项目延期就显得更加频繁。

根据Nanus和Farr在System Development Corporation公司所做的研究表明，工作量和规模之间是1.5的指数关系，虽然软件产品规模的扩大工作量会成倍增加。工作量=常数×指令的数量)~1.5 Portman的数据表明，在每天8小时工作制的情况下，我们能够有效利用的工作投入时间在5-6小时甚至更低。因此我们在做估算的时候必须要考虑到开发人员每天的有效工作量的问题。

Aron的数据表明开发人员直接的交互渠道和交互量直接影响到开发人员的平均生产率，我们强调沟通但是过多无效的沟通会直接影响到我们的效率。当在沟通和问题确认上浪费了我们太多时间的时候，开发的效率将会明显下降。

Harr的数据表明确实存在不同程序类型复杂度完全不同的情况，比如对于控制逻辑程序，编译器程序复杂度远远高于应用软件程序。因此程序类型和复杂度的不同也将直接影响到开发效率。

Corbato的数据得出更进一步的延伸结论：一、对常用编程语句而言，生产率似乎是固定的。这个固定的生产率包括了编程中需要注释，并可能存在错误的情况。二、使用适当的高级语言，编程的生产率可以提高5倍。

发表于@01月04日15：33：00|||

篇9：人月神话：软件任务进度安排

《人月神话》中软件任务进度安排的经验法则：

1/3 计划

1/6 编码

1/4 构件测试和早期系统测试

1/4 系统测试，所有构件已完成

说明：

1、分配给计划的时间占1/3，但仍不足以产生详细和稳定的计划规格说明，也不足以容纳对全新技术的研究和探索；

2、调试和测试占1/2；

3、容易估计的部%

篇10：神话读后感

有一个人人皆知的故事，那就是《大禹治水》。这个故事让我很感动。

很久很久以前，黄河发生了一场特大水患。当时的部落联盟立即派鲧来治水，鲧用“堵”的方法治水，结果，用了9年的时间，却劳民伤财，让水灾闹的更严重了。

后来，鲧的儿子禹又奉命去治水，他采用了“疏”的办法，开渠排水，疏通河道，把洪水引到大海中去。他苦干了，终于成功了！由于他每天都泡在水中，所以，他小腿上没了毛，大腿上的皮一块块的泡烂，脚指甲都泡掉了。可是，大禹却一声不吭。看到这里，我不禁感慨万千：我们这些在蜜罐里泡大的小公主，小皇帝，刚划破了一道小口子，就哇哇大叫，想掉金豆豆。可是，如果仔细想想，我们的伤比起大禹的伤，简直不值得一提。我们又有什么资格哭呢？

大禹治水的时候，曾经经过家门三次，可是他任凭儿子哇哇大哭，妻子声声呼唤，都从来都没有回家看一眼儿子和妻子。为什么他会三过家门而不入？是什么让他三过家门而不入？是他那颗爱国的心，是他那颗想把人民群众从水深火热之中解救出来的心，让他三过家门而不入。

大禹是一个公而忘私的人，是一个伟大的人！我们要学习大禹那种公而忘私的品质，作一个对社会有用的人！

篇11：神话读后感

最近我看了一本书叫《中国神话故事》，讲我们国家古时候神仙的故事。其中我最佩服妈祖和舜，先来说说妈祖吧。

妈祖又称天妃，天后，是历船工，海员，旅客，商人和渔民共同信奉的神灵。妈祖是福建省莆天县湄州屿良港人，家族是九牧林氏的后裔，在当地是一个望族。妈祖幼年时，就比其他姐妹聪明，八岁时启蒙读书，能过目不忘，而且能理解文字的意思。总是帮助别人，人们都说她助人为乐。后来妈祖被封为神仙。妈祖被封为神仙后依然为民除害。我很钦佩妈祖助人为乐的精神。

再来说说舜，舜出生于有虞氏部落，所以后人也称他为虞舜。舜是个孝顺的人，不管父亲和弟弟对他的态度有多么恶劣，而且还要杀掉舜，舜都真心孝敬父母和弟弟，是个远近闻名的孝子。舜品德高尚，为人谦逊忍让，所以我很欣赏舜尊老爱幼的精神。

我以后一定要学习舜和妈祖他们可贵的精神。

篇12：神话读后感

周六的时候，我看了一本名叫《中国古代神话》的书。

看完之后，我觉得我最喜欢的一篇故事是《盘古开天地》。因为故事里的主人公盘古有舍己为人的精神。在故事里，盘古用他的身体支撑着大地，不让天和地重新合起来，盘古死后的身体还变成了各种花草树木，奔流不息的江河，高山… …盘古创造了美丽的世界，也教会了我们平常也要乐于奉献。

在我平常的生活当中也有不少这样的人。一天，下着雨，我拿着雨伞在街道上走着，忽然，我看见了一个小女孩，在大风大雨中，女孩穿着一件红色的外衣，瑟瑟发抖地走在街道上，后面有一个拿着伞的路人。忽然，路人快步地走到了小女孩身边，我不知道这个路人要干什么，于是就看着那边。原来，这个路人是要给那个小女孩挡雨，他把雨伞斜向了小女孩的方向。这一个暖心的举动一瞬间就感动了我，我想着：这个路人真是个乐于助人的好人呀！

读完这本书之后，我觉得神话故事是我们祖先留下的文化瑰宝，我们应该让故事中的精神继续永远流传下去。

篇13：神话读后感

这几天，妈妈又到当当网给我买了“希腊古典神话”，“希腊古典神话”讲的神的故事，因为对希腊人说来，没有神祗的世界那是不可理喻的，《希腊古典神话》读后感300字。

本书是著作，这本书的作者是古斯塔夫・施瓦布，（1792-1850），他所写的书有：《希腊神话故事》、《美好的故事和传说集》、《德国民间话本》。(1809-1814)年在蒂宾根大学攻读神学和哲学，结识乌兰德等著名文学家。

在《希腊古典神话》里，令我印象最深刻的一篇短文题目是：伊娥，这篇文章把伊娥的心理活动、面貌和神态描写的非常生动，把宙斯骗走伊娥时的情景非常简单而又非常清楚的描绘出来了，赫拉对待伊娥的情景实在让人起鸡皮疙瘩，如果换是你是伊娥你肯定会受不了，读后感《希腊古典神话》读后感300字》。

《希腊古典神话》反映了古希腊从公元前11世纪到9世纪被人们习称为“荷马时代”的那段历史中的社会生活面貌，赞颂了古希腊人民的智慧和创造。

篇14：神话读后感

《神话故事》能让童年产生久远的感动，在记忆中留下难以磨灭的痕迹的童话和故事，文字优美，内涵丰富，充满想象力，就像天幕中闪亮的星星，永远闪耀在孩子的心灵里，为它们送上快乐、友善、智慧、诚信、勇敢、坚强、希望……

让我印象最深的就是后羿射日的故事了：有一天，天上出现了十个太阳。十个太阳！不会吧，我还不变成十分熟的烤乳猪啊？！原来，这十个太阳是天帝的儿子，他们住在一棵扶桑树上。这树太神奇了，竟然没被太阳烤干。本来十个太阳轮流出现在天空，可是太阳们觉得很没趣。第二天，他们就一起跑出去了，而且几天没回去。天帝派后羿去除掉吃人的猛兽，吓唬一下儿子们。后羿劝太阳们回去，太阳们却不理他，后羿觉得太阳太过分了，就射掉了九个太阳，只留一个。后羿的箭法真准啊！离太阳那么远都射得中。天帝知道自己九个儿子都被射下，非常愤怒。把后羿变成凡人，夺去了他长生不老的神力。我感觉太阳太过分了，本来一个太阳一个太阳轮流升空的，现在竟然十个太阳一起升到天空，几天没回去，大地都被他们烤干了。读完这个故事我被后羿的精神给打动了，后羿为了拯救人类牺牲了自己的神力，变成了凡人，真伟大，我真想成为后羿一样的英雄。

★ 谈谈“但愿人长久，千里共婵娟”作文300字