《人月神话》读后感

在刚刚进入软件工程学习时，老师总会时不时向我们提起一些关于“软件项目开发的完成与增加人员的问题”这句话听起来通俗易懂，但实现起来却遇到了相当大的困难，这是我在阅读完成《人月神话》时最大的感受，我想这种问题的出现主要是就订单项目而言，因为人员的增加主要是因为客户所要求实现的东西并没有在计划的时间内收到满意的答复和应得的功能与效益。所以项目开发人员不断的增加，本书作者布鲁克斯得出的结论是显而易见的：“向进度落后的项目中增加人手，只会使进度更加落后”。 如果不想加班，不想削减功能，不想推迟发布日期，那么唯一的方法还是只有加人。加足够的人。而且不要逐步加入，一定要一次性加入。要小心的是，新加入的人可能对原来的组织造成冲击，或者对原来的设计有不同意见，特别是我想如果如果有比较强大的设计者时就要当做新组建了一个团队。重新交流，培训新人，就设计达成一致，继续向者目标前进。这也是造成项目延迟的原因之一。

书中主要提到在项目管理方面可以看到项目估算，组织结构和人员角色安排，团队建设和沟通，历史数据积累和建模，软件开发方法论，风险和问题管理等相关的内容；在软件工程方面可以看到架构设计保证概念完整性，整体和部分，空间技能和程序结构的关系，产品集成的方法和消除缺陷的设计思路；在支持过程上我们可以看到文档和流程的建设，软件开发工具对软件开发过程的支持和效率的提升以及工具的选择等相关内容，回过来再看，发现书里面仍然大部分内容涉及到了团队，人和沟通。对于大型的软件工程项目仍然强调了人的重要性，在开篇就在讲开发人员的职业乐趣，后面又通过巴比伦塔讲沟通的重要性，在外科手术队伍中讲团队的组建和分工。这些都涉及到了团队中的人和交互，只有一个有了积极心态和热情的沟通团队，才可能成就一个伟大的团队。从最后的没有银弹，再次肯定了开发工作是一种高智力的脑力工作。

总结一下这本书，讲的主要是软件工程方面的，如何配置人力进行开发 。虽然对于软件编程我们对其了解并不多，但是对于在软件功能的实现，程序设计人员面临的客观性的困难至少我可以站在略懂的角度上去理解他们，对于一个或多个项目来说，公司大多都会搞人海战术，进度没有提前，还整天加班，最后用户不满意，开发人员整天郁闷，结果是用户对公司失去了信任，成了一槌子买卖，开发人员旧人一一辞职，新人天天引进，做法没有改变，情况没有改观，公司没有发展，这就是问题。人月之所以不能成为神话，正是因为增加人手的同时也增加了人与人之间的交流。我们所有的进度都是以“人月”代码产量来衡量的. 而增加"人"并不能缩短"月"的量。这同样是作者的观点，布鲁克斯这个名字在中国知之者不多，但在美国却是大名鼎鼎。因为他在60年代初只有29岁时就主持与领导了被称为人类从原子能时代进入信息时代标志的IBM/360系列计算机的开发工作，取得辉煌成功，在计算机技术的诸多领域中都做出了巨大的贡献。作者在书中提到了他使用了很多年的经验法则：1/3计划1/6编码1/4构件测试和早期系统测试1/4系统测试，虽然布鲁克斯的这本书发表数十年，但他预计的这些问题并没有得到最终的大变革，软工领域仍在面临着多种作则提出的问题，不过令人欣慰的是，大家确实在向这方面改变。在第6章中作者又提到，系统架构师们应该在文档中描述所有外部特性，但是他应该避免干涉具体实现细节，实际上我们动脑想一想解决办法很简单：谁开发、谁决定，对于外部特性的形式化定义不应该扼杀实现人员的创造力。我认为任何事都应当先规划再执行，很多专家和

…… …… 余下全文

读《人月神话》有感

读过《人月神话》，马上就被深深的吸引了。 这确实是一本很值得多次阅读的好书，每次阅读可能都能从中得到一些提示。 因此，把感触比较深的几点记下来。

编程会有很多的乐趣 。首先是一种创建事物的纯粹快乐。如同小孩在玩泥巴时感到愉快一样，成年人喜欢创建事物，特别是自己进行设计。我想这种快乐是上帝创造世界的折射，一种呈现在每片独特、崭新的树叶和雪花上的喜悦。其次，快乐来自于开发对其他人有用的东西。内心深处，我们期望其他人使用我们的劳动成果，并能对他们有所帮助。从这个方面，这同小孩用粘土为“爸爸办公室”捏制铅笔盒没有本质的区别。第三是整个过程体现出魔术般的力量——将相互啮合的零部件组装在一起，看到它们精妙地运行，得到预先所希望的结果。比起弹珠游戏或点唱机所具有的迷人魅力，程序化的计算机毫不逊色。第四是学习的乐趣，来自于这项工作的非重复特性。人们所面临的问题，在某个或其它方面总有些不同。因而解决问题的人可以从中学习新的事物：有时是实践上的，有时是理论上的，或者兼而有之。最后，乐趣还来自于工作在如此易于驾驭的介质上。程序员，就像诗人一样，几乎仅 仅工作在单纯的思考中。程序员凭空地运用自己的想象，来建造自己的“城堡”。很少有这样的介质——创造的方式如此得灵活，如此得易于精炼和重建，如此得容易实现概念上的设想。

软件任务的进度安排的经验法则。1/3计划、1/6编码、1/4软件测试和早期系统测试、1/4系统测试，所有构件已完成。在许多重要的方面，它与传统的进度安排方法不同： 分配给计划的时间比寻常的多。即便如此，仍不足以产生详细和稳定的计划规格说明，也不足以容纳对全新技术的研究和摸索。对所完成代码的调试和测试，投入近一半的时间，比平常的安排多很多。 容易估计的部分，即编码，仅仅分配了六分之一的时间。 通过对传统项目进度安排的研究，我发现很少项目允许为测试分配一半的时间，但大多数项目的测试实际上是花费了进度中一半的时间。它们中的许多项目，在系统测试之前还能保持进度。或者说，除了系统测试，进度基本能保证

…… …… 余下全文

人月神话读后感

张明

二十九年前(1975)﹐IBM大型电脑之父──Fred Brooks 出版一本书﹕"The Mythical Man-Month"。收集了他在19xx年代领导1000多人共同发展OS/360大型软件系统的心得和经验。该书是论文集﹐其中有一篇文章叫"The Mythical Man-Month"﹐他就以此作为书名。在1956~1965 之间﹐Brooks实际领导IBM 360 大型电脑的开发计划﹐包括硬体结构及庞大的OS/360作业系统在内﹐因之他具有IBM 大型电脑之父的尊称。由于OS/360是多达1000位程式师共同合作的大型软件开发工作﹐让他深刻了解到大型软件开发的技术和管理上所面临的种种困难和挑战。于是﹐他就将其领导开发OS/360软件系统的经验心得收集在这本书里。人们常拿Man-Month （多少人﹐做多少个月）来计算软件的工作量﹐但是Brooks发现软件的开发工作是需要人与人之间密切沟通的﹐使得设计工作不易分割﹐所以Man-Month 为单位的计算方法是有问题的(mythical)。也就得出著名的Brooks法则── 「对于进度已落后的软件开发计划而言﹐若再增加人力﹐只会让其更加落后。」(Adding manpower to a late software project makes it later)这是该书名称的涵义。

看完此书后，我发现人月神话无处不在，其实在我们做软件工程来说，此书已经渗透进去了。本书作者为人们管理复杂项目提供了颇具洞察力的见解，既有很多发人深省的观点，也有大量的软件工程实践。 本书对我触动最大的，一是保持设计的概念完整。无论对小软件还是大软件，都必须由一个设计师主导，最多两个人讨论来共同完成软件的整体设计。作为一个软件，一个系统，必须有一个清晰明确的概念模型，大家都在这个框架下工作，所有的创新发展都必须与基本的概念相吻合。具体的实现人员可以细化概念，但只有总设计者才有否定与发展基本概念的权力。需要注意的一点是，即使是总设计师一直是同一个人，他脑海中所认为理所当然的规则或者概念，很可能由于没有明确的文档化，而没有成为所有开发者共同的概念。概念的完整性，对于很多小规模软件，由于开发人员不多，开发经理一般都能控制住所有的代码，概念完整性在组织层面就维持住了。但要注意以后的Bug修改，功能扩展的时候，也要时刻留意与最初的设计是否概念上相容。对于大规模的软件系统，则必须通过树状组织结构，层层控制，总设计师还是一到两人，每一层都有对下层的绝对把握能力。

…… …… 余下全文

人月神话读后感

“人月神话”这个书名乍听起来真像是一部科幻小说或是言情小说的名字，真是很吸引别致，后来经老师提醒才知道这竟是一部在软件行业中享有里程碑地位的名著，一部在软件领域拥有极高声誉，畅销了20多年的必读经典。在这本书中，以我的总结，作者主要详述了包括工程计划，团队组成，文档重要性，项目排错等等的软件工程世纪的方方面面。

而“人月神话”顾名思义让人联想到神话故事，而事实确实作者阐述软件开发项目上项目进度和开发人员这两个概念的不能互换与混淆。

对此书，老实说，可能能力十分有限，对其理解也不是很深刻，在此提出对我影响最深的几点概念： 焦油坑的提出使我想到一个事实，虽然此书出版已20多年，但它所能反映的在软件项目上的问题依然能给软件工作者带来困扰，就如同在焦油坑中挣扎，问题依然没有解决。

人月神话概念的提出，引出Brooks法则：向进度落后的项目增加人手，只会导致进度更加落后。这就是除却了神话色彩的人月。因此缺乏了合理的时间进度是造成项目滞后的最主要原因。

在第三章中，作者有用了一个很好的实例：外科手术队伍。他提出了疑问，如何在有意义的时间进度内创建大型系统呢？要使工作易于管理，他给整个软件团队使用分解的技术，明确了各个工作细则，明确体系架构和实现之间的界限，如系统结构师必须专注于体系结构，其他依然。

为什么软件设计会和贵族专制，民主政治有关呢？因为概念设计必须由一个人或有默契的少数人一起才能进行，概念完整性必须要求系统只反映唯一的设计理念，而用户所见的技术说明来自少数人的思想。 如何避免画蛇添足呢？这告诉我们必须坚持设计拥有两个系统以上开发经验结构师的决定，同时保持对特殊诱惑的警觉，才可以不断提出正确的问题，确保原则上的概念和目标在详细设计中完整体现。 软件设计很重视贯彻执行这一概念，以用户手册为中心，即需求分析，设计人员与实施人缘进行交流，会议，电话记录，电子邮件来沟通，避免理解错误，最终的测试以用户手册为准则进行测试。此时还要注意，不同系统的用户手册是不同的ＧＵＩ的可能是界面说明，程序也可能是借口说明。

…… …… 余下全文

学号：0967020449 姓名：张小波 班级：软件工程专升本3班

《人月神话》读后感

在软件领域中,很少能有像《人月神话》一样具有深远影响力和畅销不衰的著作。Brooks 博士为人们管理复杂项目提供了最具洞察力的见解,既有很多发人深省的观点,又有大量软件工程的实践,影响着一代又一代….

通过阅读《人月神话》，我从中学到了一些东西：

首先，开发一个项目，我们错误的认为用人月这个工作量单位来估计和进行进度安排。成本的确随开发产品的人数和时间的不同，有着很大的变化，进度却不是如此。因此我认为用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话。 它暗示着人员数量和时间是可以相互替换的。人数和时间的互换仅仅适用于以下情况：某个任务可以分解给参与人员，并且他们之间不需要相互的交流，而在系统编程中近乎不可能。当任务由于次序上的限制不能分解时，人手的添加对进度没有帮助。调试、测试的次序特性，许多软件都具有这种特征。因为软件开发本质上是一项系统工作——错综复杂关系下的一种实践——沟通、交流的工作量非常大，它很快会消耗任务分解所节省下来的个人时间。从而，添加更多的人手，实际上是延长了，而不是缩短了时间进度。

对于编程，有其乐趣和苦恼。创建事物的快乐 ，开发对其他人有用的东西的乐趣 ，将可以活动、相互啮合的零部件组装成类似迷宫的东西，这个过程所体现出令人神魂颠倒的魅力 ，面对不重复的任务，不间断学习的乐趣 ，工作在如此易于驾驭的介质上的乐趣——纯粹的思维活动，其存在、移动和运转方式完全不同于实际物体。将做事方式调整到追求完美，是学习编程的最困难部分；由其他人来设定目标，并且必须依靠自己无法控制的事物（特别是程序）；权威不等同于责任实际情况看起来要比这一点好一些；真正的权威来自于每次任务的完成任何创造性活动都伴随着枯燥艰苦的劳动，编程也不例外 人们通常期望项目在接近结束时，（bug、工作时间）能收敛得快一些，然而软件项目的情况却是越接近完成，收敛得越慢产品在即将完成时总面临着陈旧过时的威胁。

…… …… 余下全文

人月神话读后感

这本300多页（中文新版）的神书，在经过了20多年的历史之后，仍然畅销不衰，究竟是什么让它有如此的魅力？过去的一个月，一点一滴的阅读之中算是初步的了解到了它的一部分吧。

人月神话的核心观点：概念完整性和架构师

Brooks认为，一个整洁、优雅的变成产品必须向它的每位用户提供一个条理分明的概念模型，这个模型描述了应用，实现应用的方法以及用来指明操作和各种参数的用户界面使用策略。概念的完整性是易用性中最重要的因素。而架构师，则是负责保证产品所有方面的概念完整性的，架构师设计的是能够让用户理解产品概念的模型，这包括所有的功能的详细说明以及调用和控制的方法。它就像电影的导演一样。

我的理解：这里的概念完整性其实应该说的是这个软件理念上的业务流程的前后连贯，也就是用户在使用产品的过程中，能够按照唯一的一个的最高抽象的思路来使用这整个系统。

开发第二个系统的后果——盲目的功能和频率猜测

所谓第二个系统，指的是产品的第二个实际发布。开发第一个发布的时候会因为各种原因去消减不必须的功能，所以会简化问题，而在第二个版本的时候则常常想其中添加各种各样的功能（也许源于用户的功能建议）但是，却导致了灾难性的后果。

所以，在这种情况下，用户群越大，越不稳定，我们就更加应该明确的定义用户群，以获得概念的完整性。我们必须为整个设计团队定义一个共同的用户图像，记录下用户群的属性：

1. 他们是谁

2. 他们need什么

3. 他们认为自己need什么

4. 他们want什么

而另一方面，对于任何产品，任何用户群属性都是一种概率上的分布的，也就是每个属性都有各种可能的值，所以我们能做的是，架构师去猜测（guess）或者假设（postulate）一系列完整的属性和频率值。这里，清晰和错误都将比模糊不清好得多。

不同的社会经验，不同的思想状态，对读后的心得也会不一样.比如：

…… …… 余下全文

3110402157_ 王森_软件112

《人月神话》读后感

在阅读这本书之前,已经很多次听到关于人月神话这本书以及他的作者Brooks的消息了. 在软件领域, 《人月神话》具有深远影响力而且畅销不衰.这一次,正好老师的作业要求我们阅读这本书,我终于使有机会阅读这本经典之作了.在这过去的几个星期里面,一点一滴的阅读这本书,粗略的了解了这本书.

首先,让我印象深刻的是《人月神话》提出的两条著名的法则：

1、人月神话：向一个已经延后的项目中投入更多的人力资源只会让它更延后。 人月神话看上去这么浪漫的名字，原来并不是真的说神话故事，作者阐述的主要观点是在软件开发项目上项目进度和增加人员这两个概念是不能互换。虽然已经时隔20多年了，这本书依然给我震撼，一是让我惊讶的是，美国20年前软件项目所面临的问题，在我们现在依然如此，糟糕的情况没有改变，大家仍旧在焦油坑里挣扎，而且看上去没有解决办法. 当读到“是当意识到进度的偏移时，下意识（以及传统）的反应是增加人力。这就像使用汽油灭火一样，只会使事情更糟。越来越大的火势需要更多的汽油，从而进入了一场注定会导致灾难的循环。这让我明白了一个重要的道:理项目的进度是不能够光靠人力的增加来推进的.

2、没有银弹:没有任何技术或管理上的进展，能够独立地许诺十年内使生产率、可靠性或简洁性获得数量级上的进步。

3110402157_ 王森_软件112

虽然现在有不少人对他的观点持反对或不同意见，但我始终觉得他的观点是对的——根本和次要问题的划分以及定义。作者认为软件开发困难的部分是概念的结构，如规格化、设计和测试等概念的结构，而不是概念的表述和实现概念，虽然实现概念可能占用了小于90%的时间，就如现今的软件开发一样，系统分析通常占用的整个项目开发时间不超过20%，而80%的时间花在编程上一样。

这两个原则已经在过去的几十年间得到了验证.我相信在未来,它以依旧是成立的.

…… …… 余下全文