篇一 :《人月神话》读后感

《人月神话》读后感

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

《人月神话:软件项目管理之道》(英语:The Mythical Man-Month: Essays on Software Engineering)是由IBM System/360系统之父佛瑞德·布鲁克斯所著经典文集,全书讲解软件工程、项目管理相关课题,被誉为软件领域的圣经,内容源于作者布鲁克斯在IBM公司System/360家族和OS/360中的项目管理经验[2]。该书于19xx年首次发行(ISBN 0-201-00650-2),并于19xx年重新发行纪念版(ISBN 0-201-83595-9),其中新增了对〈没有银弹〉一文的评论和回应,与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)这是该书名称的涵义。

…… …… 余下全文

篇五 :人月神话读后感

人月神话读后感

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

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

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

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

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

…… …… 余下全文

篇六 :《人月神话》读后感

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

《人月神话》读后感

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

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

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

…… …… 余下全文

篇七 :人月神话读后感

人月神话读后感

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

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

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

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

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

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

…… …… 余下全文

篇八 :人月神话读后感

3110402157_ 王森_软件112

《人月神话》读后感

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

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

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

…… …… 余下全文