人月神话
人月神话PPT课件
最糟糕的的情况：导致重复产生进度灾难，耗费大量 人力，物资，却反而使开发出来的产品更差
Brooks 法则：
向进度落后的项目中增加人手，只会使进度更加落后 （Adding manpower to a late software project makes it later）
这就是除去了神话色彩的人月
图形化编程
图形化和可视化编程，计算机图形在 软件设计上的应用
银弹 否?
上述方法均未出现令人激动与信服 的进步
• 程序验证
• 测试和修复BUG
•环境和工具 •
集成数据库的使用
•工作站 •
处理能力和内存容量的稳固和快速提高
Summary
主要内容
• • • • • 人月神话 外科手术队伍 贵族的专制 银弹在哪里？ 没有银弹
Part 3
贵族的专制
丏政与民主
丏政：占统治地位的阶级对敌对阶级实行的强力统治的国家 制度
民主：在一定的阶级范围内，按照平等和少数服从多数原则 来共同管理国家事务的国家制度
•对立
项目管理的制度该如何？
•专政？ •经理 •民主？
•技术
•编码
•管理
•编码 •测试
概念完整性
一个项目，一个建筑，一个品牌想要获得成功，就必须有一 个完整的理念、概念设计，拥有自己的概念DNA
系统测试
• 系统测试进度的安排常常是编程中最不合理的部分，测试 实际需要的时间往往比传统预测的要长很多
•传统
•VS
•作者
除了系统测试，进度基本能保证
然而不为系统测试安排足够的时间简直就 是一场灾难
会付出相当高的商业代价 因此，在早期进度策划时，允许充分的系 统测试时间是非常重要的
《人月神话》读后感（第一二章）
《⼈⽉神话》读后感（第⼀⼆章）初次听闻《⼈⽉神话》这本书，我以为它会是⼀本讲述神话或者浪漫爱情故事的书，但后来在⽼师的⼝中才了解到，这讲述的并不是什么神话、爱情故事，⽽是⼀本有关软件⼯程⽅⾯的经典著作。
经过⽼师的推荐，我抱着试⼀试的想法阅读了这本书，虽然有很多地⽅还不太明⽩，但仍然收获了很多知识。
⽬前我只阅读了前两章，借此来谈⼀谈⾃⼰的收获以及感受。
书的前两章主要讲述了两个问题——焦油坑和⼈⽉神话。
在第⼀章中，作者将软件危机⽐作了焦油坑，谈到美国20年前软件项⽬所⾯临的问题，在我们现在依然如此，糟糕的情况没有改变，⼤家仍旧在焦油坑⾥挣扎，⽽且看上去没有解决办法。
过去⼏⼗年的⼤型系统开发就犹如⼀个焦油坑，很多⼤型企业在其中剧烈地挣扎。
他们中⼤多数开发出了可运⾏的系统。
不过，其中只有⾮常少数的项⽬满⾜了⽬标、时间进度和预算的要求。
各种团队，⼤型的和⼩型的，庞杂的和精⼲的，都⼀个接⼀个淹没在了焦油坑中，被软件危机所带来的灾难覆盖。
表⾯上看起来好像没有任何⼀个单独的问题会导致困难，每个都能被解决，但是当它们相互纠缠和累积在⼀起的时候，团队的⾏动就会变得越来越慢。
对于我们⽽⾔，如果我们想解决问题，就必须试图先去理解它，了解什么是编程系统产品，同时也要找到⾃⼰职业的乐趣，因为只有发现了乐趣，⼯作才会更有积极性。
在第⼆章中，我了解到原来“⼈⽉“是我们项⽬⼯程中估计和进度安排中使⽤的⼯作量单位，⽤⼈⽉作为衡量⼀项⼯作的规模是⼀个危险和带有欺骗性的神话。
它暗⽰着⼈员数量和时间是可以相互替换的但仅适⽤于某个任务可以分解给参与⼈员，并且他们之间不需要相互的交流的情况。
因为软件开发本质上是⼀项系统⼯作——错综复杂关系下的⼀种实践——沟通、交流的⼯作量⾮常⼤，它很快会消耗任务分解所节省下来的个⼈时间。
当任务由于次序上的限制不能分解时，⼈⼿的添加对进度不会有帮助。
虽然我现在只读了前两章，但同样拓宽了⾃⼰的视野，因此我决定继续读下去，继续探索软件⼯程的奥秘。
《人月神话》各章精选
《人月神话》各章精选第1章焦油坑史前史中，没有别的场景比巨兽在焦油坑中垂死挣扎的场面更令人震撼。
上帝见证着恐龙、猛犸象、剑齿虎在焦油中挣扎。
它们挣扎得越是猛烈，焦油纠缠得越紧，没有任何猛兽足够强壮或具有足够的技巧，能够挣脱束缚，它们最后都沉到了坑底。
过去几十年的大型系统开发就犹如这样一个焦油坑，很多大型和强壮的动物在其中剧烈地挣扎。
他们中大多数开发出了可运行的系统——不过，其中只有非常少数的项目满足了目标、时间进度和预算的要求。
各种团队，大型的和小型的，庞杂的和精干的，一个接一个淹没在了焦油坑中。
表面上看起来好像没有任何一个单独的问题会导致困难，每个都能被解决，但是当它们相互纠缠和累积在一起的时候，团队的行动就会变得越来越慢。
对问题的麻烦程度，每个人似乎都会感到惊讶，并且很难看清问题的本质。
不过，如果我们想解决问题，就必须试图先去理解它。
第2章人月神话Brooks法则：向进度落后的项目中增加人手，只会使进度更加落后。
第3章外科手术队伍在计算机领域的会议中，常常听到年轻的软件经理声称他们喜欢由头等人才组成的小型、精干的队伍，而不是那些几百人的大型团队，这里的“人”当然暗指平庸的程序员。
其实我们也经常有相同的看法。
但这种幼稚的观点回避了一个很困难的问题——如何在有意义的时间进度内创建大型的系统？那么就让我们现在来仔细讨论一下这个问题的每一个方面。
第4章贵族专制、民主政治和系统设计法国城市兰斯（Reims）在建筑风格上的一致性和上面所说的大教堂形成了鲜明的对比。
设计的一致性和那些独到之处一样，同样让人们赞叹和喜悦。
如同旅游指南所述，风格的一致和完整性来自8代拥有自我约束和牺牲精神的建筑师们，他们每一个人牺牲了自己的一些创意，以获得纯粹的设计。
同样，这不仅显示了上帝的荣耀，同时也体现了他拯救那些沉醉在自我骄傲中的人们的力量。
第5章画蛇添足在开发第一个系统时，结构师倾向于精炼和简洁。
他知道自己对正在进行的任务不够了解，所以他会谨慎仔细地工作。
《人月神话》读后感
《⼈⽉神话》读后感
这是假期读的第⼆本关于本专业的书，下⾯简单谈⼀下个⼈理解。
⾥⾯运⽤了很多形象的⽐喻，如巨兽在焦油坑⾥垂死挣扎等，这也象征了软件开发⾥遇到的困难，反复地修改等等。
书⾥强调了团队的作⽤，强调⼈和沟通的重要性，个⼈的技术并不能完全决定⼀个项⽬，团队⾥⼈的交互也是很重要的，积极的沟通才能造就伟⼤的团队。
当然，作为学⽣来说，虽然接触不到很⼤的项⽬，但是在学习过程⾥的沟通，交流依然是必不可少的，在探讨的过程⾥，会学的更快，更好，共同做⼀个课题和⽼师布置的作业，这个过程⾥因为思想的交流变得事半功倍，《⼈⽉神话》提到，⼀个⼈做虽然完整性好，但效率低；⽽团队中成员相互协调，效率⾼且完整性也好。
Brooks法则：向进度落后的项⽬中增加⼈⼿，只会使进度更加落后。
还有⽐较值得注意的是时间进度，不能过于拖延。
每完成⼀个部分最好⽤⽂档记录其功能，测试等，⽅便整理时理解，这写⽂档的时间是很必要的，不能节省，不能因为赶进度⽽忽略很多细节。
简单总结⼀下：沟通交流很重要，个⼈技术也得扎实，⽂档是很有⽤的⼯具。
人月神话读书笔记
人月神话读书笔记第一篇：人月神话读书笔记人月神话这本书几年前就听别人说是本很经典的软件开发方面的书，这本书的成功之处在于他思想的前卫性，以至于不只是软件行业的人在读。
现在终于找到读他的理由了，可以感受一下大师的杰作。
在读之前我已经读过了软件工艺和极限编程，为什么留到最后读人月神话呢？主要是因为我觉得一本能够流传30年还被人们津津乐道的书，肯定是本学要好好细读的书，所以留到了最后。
按照前两篇读书笔记的惯例，前面几段是一些我读书时的感受和收获，还有一些对内容的评价。
从这本书的内容来看，对于一个项目经理来说肯定会有更大的收获，这本书主要是针对软件开发管理方面的内容，这主要原因可能是因为作者以前就是项目的管理者，他是站在管理者的角度写的。
即便这样，对于一个从来没有参与过真实项目开发，更没有领导过团队的我还是有一定的吸引力，这本书中我最喜欢的就是前四章（焦油坑、人月神话、外科手术队伍、贵族专制、民主政治和系统设计）和没有银弹这章。
这本书里面为了论证某一观点，会举出许多实际的项目作为证据，这一点非常好，事实胜于雄辩嘛！这些例子也许对于作者那个年代的人来说很好理解，但是放在30年后来看这些例子又有些陈旧和难懂了。
另外，从文中我发现作者非常注重文档，一个优质的文档就是项目成功的保证，这一点与传统的软件工程很相似，但是却与极限编程的观点相悖。
下面就是一些读书的总结了。
焦油坑1. 编程系统产品开发的工作量是供个人使用的、独立开发的构件程序的九倍。
2. 编程行业的一些内在固有苦恼：l 将做事方式调整到追求完美，是学习编程的最困难部分。
l 由其他人来设定目标，并且必须依靠自己无法控制的事物。
l 真正的权威来自于每次任务的完成。
l 任何创造性活动都伴随着枯燥艰苦的劳动，编程也不例外l 人们通常期望项目在接近结束时（bug、工作时间）能收敛得快一些，然而软件项目的情况却是越接近完成，收敛得越慢。
l 产品在即将完成时总面临着陈旧过时的威胁。
人月神话读后感
人月神话读后感这篇文章主要讲了在软件开发工程项目中，时间和人员数量上的转化关系。
表明了在一个项目中增加人员的数量不一定能够缩短项目完成的时间，很多时候还会起到相反的作用。
正如Brooks法则中所说的那样“想进度落后的项目中增加人手，只会使进度更加落后”。
在软件项目中，缺乏合理的时间进度使造成项目滞后的最主要的原因。
造成这个结果主要由于以下几个方面，包括我们对工程的乐观的估计，错误的认为人和月（时间）可以无条件的相互替代，软件经理不合理的估算和缺少对进度的跟踪和监督。
在编程人员中弥漫着乐观主义，他们通常会认为一切都将运作良好，每一项任务仅花费它所应该花费的时间。
但是人员的构思总是会存在某些偏差，导致了idea是很好的，但在实现的过程中出现问题，这种结果会严重的影响到软件工程最终的完成时间。
所以说在做一个项目的时候，人们不应该盲目的乐观。
文章对造成项目滞后的第二个原因进行了详细的论述，为我们否定了一个关于“人月神话”谬论。
“人月神话”的主要内容是人员数量和时间是可以相互替代的。
事实上，人员数量和时间是不可以无条件的相互替代的。
文中也表明了人员数量和时间的互换仅仅适用于以下情况：摸个任务可以分解给参与人员，并且他们之间不需要相互的交流。
只有在这种可分解的任务中人月神话是存在的。
但是在更多的情况下，由于任务常常是不可分解的，而且需要人员之间的大量的相互沟通。
这时候，一味的增加开发人员不会缩短时间的进度，相反还很有可能比没增加人员的时候完成的时间还要晚。
在文中作者也举了一个例子，假定没有在规定的时间内完成任务，达到第一个里程碑，项目经理可以有四种选择的方案。
1，在原来3个人的基础上增加了2个人。
2，将原来的3个人增加到9个人。
3，重新安排进度。
4，削减任务。
作者说明了项目经理往往倾向于选择削减任务来减少后续的成本，也说明了第一种和第二种方案的不可行。
因为增加了人员就要对他们进行培训，这是需要时间的，还有就是会出现重复工作的问题，原先由3个人负责的工作分解到了由5个人来工作，这就导致了某些已经完成的工作必然会丢失，丢失的工作还需要再做一遍，这也导致了时间的浪费和延长。
《人月神话》读书笔记1
《⼈⽉神话》读书笔记1
《⼈⽉神话》这个名字，初听不像是⼀本关于软件的著作，但是看下去就会发现，整本书使⽤了⼤量像“⼈⽉神话”这样的⽐喻，形象地解释了⼀些⽣晦难懂的东西。
“史前史中，没有别的场景⽐巨兽在焦油坑中垂死挣扎的场⾯更令⼈震撼。
上帝见证着
恐龙、猛犸象、剑齿虎在焦油中挣扎。
它们挣扎得越是猛烈，焦油纠缠得越紧，没有任何猛
兽⾜够强壮或具有⾜够的技巧，能够挣脱束缚，它们最后都沉到了坑底。
”这是作者对于过去⼏⼗年的⼤型系统开发的看法。
仅极少数项⽬满⾜了⽬标、预算和进度的要求。
问题纠缠在⼀起，其⿇烦程度让⼈惊讶，很难看清问题的本质。
⽽之后的部分，就像是对“焦油坑”做出的说明。
“良好的烹饪需要时间，某些任务⽆法在不损害结果的情况下加快速度。
”⼈⽉指⼯作量单位，即⼈⼒(⼈)和时间(⽉)。
⼈⽉是危险和带有欺骗性的神话，因为它暗⽰⼈员数量和时间是可以相互替换的。
它使得项⽬看上去好像⼈⼒和时间是可交换的。
如果时间不够，那么增加⼈⼿就可以加快进度。
但实际上⼈⽉之间的平衡不是线性关系。
这个衡量⽅式忽略了新增加⼈⼿的培训时间、队员之间的沟通时间等等因素，结果就是，盲⽬的增加⼈⼿只会导致项⽬落后。
“向进度落后的项⽬中增加⼈⼿，只会使进度更加落后。
”对此，作者写出了他的进度安排经验：1/3计划、1/6编码、1/4组件测试是和1/4系统集成测试。
人月神话读后感
《人月神话》读后感在刚刚进入软件工程学习时，老师总会时不时向我们提起一些关于“软件项目开发的完成与增加人员的问题”这句话听起来通俗易懂，但实现起来却遇到了相当大的困难，这是我在阅读完成《人月神话》时最大的感受，我想这种问题的出现主要是就订单项目而言，因为人员的增加主要是因为客户所要求实现的东西并没有在计划的时间内收到满意的答复和应得的功能与效益。
所以项目开发人员不断的增加，本书作者布鲁克斯得出的结论是显而易见的：“向进度落后的项目中增加人手，只会使进度更加落后”。
如果不想加班，不想削减功能，不想推迟发布日期，那么唯一的方法还是只有加人。
加足够的人。
而且不要逐步加入，一定要一次性加入。
要小心的是，新加入的人可能对原来的组织造成冲击，或者对原来的设计有不同意见，特别是我想如果如果有比较强大的设计者时就要当做新组建了一个团队。
重新交流，培训新人，就设计达成一致，继续向者目标前进。
这也是造成项目延迟的原因之一。
书中主要提到在项目管理方面可以看到项目估算，组织结构和人员角色安排，团队建设和沟通，历史数据积累和建模，软件开发方法论，风险和问题管理等相关的内容；在软件工程方面可以看到架构设计保证概念完整性，整体和部分，空间技能和程序结构的关系，产品集成的方法和消除缺陷的设计思路；在支持过程上我们可以看到文档和流程的建设，软件开发工具对软件开发过程的支持和效率的提升以及工具的选择等相关内容，回过来再看，发现书里面仍然大部分内容涉及到了团队，人和沟通。
对于大型的软件工程项目仍然强调了人的重要性，在开篇就在讲开发人员的职业乐趣，后面又通过巴比伦塔讲沟通的重要性，在外科手术队伍中讲团队的组建和分工。
这些都涉及到了团队中的人和交互，只有一个有了积极心态和热情的沟通团队，才可能成就一个伟大的团队。
从最后的没有银弹，再次肯定了开发工作是一种高智力的脑力工作。
总结一下这本书，讲的主要是软件工程方面的，如何配置人力进行开发。
虽然对于软件编程我们对其了解并不多，但是对于在软件功能的实现，程序设计人员面临的客观性的困难至少我可以站在略懂的角度上去理解他们，对于一个或多个项目来说，公司大多都会搞人海战术，进度没有提前，还整天加班，最后用户不满意，开发人员整天郁闷，结果是用户对公司失去了信任，成了一槌子买卖，开发人员旧人一一辞职，新人天天引进，做法没有改变，情况没有改观，公司没有发展，这就是问题。
人月神话笔记
人月神话读书笔记（一)第一章焦油坑表面上看起来好像没有任何一个单独的问题会导致困难,每个都能被解决，但是当它们相互纠缠和积累在一起的时候,团队的行动就会变得越来越慢。
对问题的麻烦程度，每个人似乎都会感到惊讶，并且很难看清问题的本质。
不过，如果我们想解决问题，就必须试图先去理解它。
-—清楚地解释系统开发的困难所在。
这，就是编程.一个许多人痛苦挣扎的焦油坑以及一种乐趣和苦恼共存的创造性活动.对于许多人而言，其中的乐趣远大于苦恼。
而本书的剩余部分将试图搭建一些桥梁，为通过这样的焦油坑提供一些指导。
-—本书的目的第二章人月神话1。
在众多软件项目中，缺乏合理的时间进度是造成项目滞后的最主要原因,它比其他所有因素加起来的影响还大.导致灾难的原因是：首先,我们对估算技术缺乏有效的研究.第二，我们采用的估算技术隐含地假设人和月可以互换,错误地将进度与工作量相互混淆第三，由于对自己的估算缺乏信心，软件经理通常不会有耐心持续地进行估算这项工作。
第四,对进度缺少跟踪和监督。
第五,当意识到进度的偏移时，下意识(以及传统）的反应是增加人力。
2。
系统开发过程中,乐观主义并不应该是理所应当的。
在单个任务中,“一切都将运转正常”的假设在时间进度上具有可实现性。
因为所遇的延迟是一个概率分布曲线,“不会延迟”仅具有有限的概率，所以现实情况可能会像计划安排的那样顺利。
然而大型的编程工作,或多或少包含了很多任务，某些任务间还具有前后的次序，从而一切正常的概率变得非常小,甚至接近于无。
3. 成本的确随开发产品的人数和时间的不同,有着很大的变化，进度却不是如此。
因此我认为用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话。
它暗示着人员数量和时间是可以相互替换的.因为软件开发本质上是一项系统的工作—-错综复杂关系下的一种实践—-沟通、交流的工作量非常大，它很快会消耗任务分解所节省下来的个人时间。
从而，添加更多的人手，实际上是延长了，而不是缩短了时间进度.4。
人月神话(40周年中文纪念版)
第 19 章是一篇更新的短文。读者应该注意的是，新观点并不像原来 的书一样来自我的亲身经历。我在大学里工作，而不是在工业界，做的 是小规模的项目，而不是大项目。自 1986 年以来，我就只是教授软件工 程，不再做这方面的研究。我现在的研究领域是虚拟环境及其应用。
４０
在这次回顾的准备过程中，我找了一些正在软件工程领域工作的朋
Essays on Software Engineering, Anniversary Edition
神品—— 代序
前些年，一位朋友从印度归来，说此书在印度极为普及，我也动起 笔来，但 惭 愧 终 未 成 正 果。汪颖兄素来勤恳 ，明知此翻译为“success without applause, diligence without reward”(没有掌声的成功，没有回报 的勤勉)，却兢兢业业，反复琢磨，历经单调、繁琐、艰辛的劳动，终于 付梓。钦佩之余随即作序共勉。
* 编注：该序的作者是王计斌(Dave Wang)，清华大学博士，研究方向包括软件工程和集成产 品开发(IPD)，长期从事 IPD/CMM 推行，创办软件工程研究与实践论坛()， 现在华为技术有限公司工作。
Essays on Software Engineering, Anniversary Edition
这就是我们面临的严峻而复杂的现实，也许您会感到震惊！然而在 大师 Frederick P. Brooks 眼里，是那么的平静。因为早在 28 年前，他就 在《人月神话》(The Mythical Man-Month)这本不朽著作中对这些内容做 了深入论述。
这本小册子行文优美，思想博大精深，字字真言，精读之有不尽的 趣味，藏之又是极珍贵的文献，名眼高人，自能鉴之。
印 张：24.5 字 数：316 千字