《人月神话》是一本由弗雷德里克・布鲁克斯著作，中国电力出版社出版的精装(无盘)图书，本书定价：25.0，页数：336，特精心从网络上整理的一些读者的读后感，希望对大家能有帮助。

　　《人月神话》精选点评：

　　●中文翻译太不流畅，太烂了。有空找英文版看。

　　●说中的经典，可惜买的是这本英文原版，基本看不懂。可惜了，准备送人。

　　●起于软件，但不止于软件。 "The MM-M is incidentally about software but primarily about how people in teams make things."

　　●这是我看过的生词量最多的英文原版技术书，好在还是咬牙看了下来且受益非浅。令人惊奇的是，敏捷开发方法中倡导的许多理念，Brooks先生在几十年前就考虑过了。

　　●视野

　　●解决两个核心复杂度

　　●虽然写作手法很新颖，但不太喜欢这种过于“断章取义”的东西。虽然这样容易借重人之眼画“千面黛玉”。不过总觉得一本书里能有几句话对自己有点“影响”或“触动”的话，此书也算是没“太”白读。

　　●比中文更贴近其本质理念。

　　●读了一半 后面有些看不进去了 不过也大致了解了下 以后有需要再看看中文版吧

　　●在学校学崩溃了，学英语时期顺手买的，书的设计挺可爱

　　《人月神话》读后感(一)：重读英文原版

　　其实已经读过汉译版了，不过还是对中文的翻译信不过，还想再读一遍原版。看过这本书让我对软件有了一个全新的认识，颠覆了我以前的很多幼稚的想法，实在是一本好书，我想我会读很多遍的。

　　《人月神话》读后感(二)：有些老，不过很有趣

　　基本的原则都没有错。但有些古老。尤其是对年轻人来说，打孔、batch job、relay...一定是天书了。

　　但真是难得一见的有趣的计算机工程读物。语言幽默、恰切，举重若轻。睡觉之前读，在旅行中读都好。

　　《人月神话》读后感(三)：软件研发方法论经典

　　软件研发，首先是一个创作活动，不是照本宣科的复制或者重复性的劳动；其次软件必须是对现实的抽象和创新，而不是天马行空的恣意想象。这决定了软件研发不是能够按部就班制作出来，注定研发过程不是完全可控的，所以软件应该是演化而来的。

　　既然是创作性活动，影响软件研发的核心要素是人。对于创作的影响，精英和普通选手之间的贡献比是差别很大的。

　　软件研发，复杂度和规模决定了必定是团队创作。团队的目标统一、组织清晰有序、沟通明确顺畅，过程的有序、有效产出，是促进软件研发成功的有效方法，但不是银弹。

　　软件研发的两个核心复杂度：软件对现实的抽象和创新；团队创作目标、组织、沟通、价值统一。

　　《人月神话》读后感(四)：貌似他预言了一切

　　1.关于“人月”的神话，最近的一个大项目验证了这点，为了缩短项目周期zg的项目不断的增加人员，但是周期还是被一拖再拖。从我这个新来者的角度，我来这个新的项目需要学习了解太多东西，这需要一段时间。如果项目组有意识的培训的话，可能会好一些。但是，实际上没有，实际情况也很惨。

　　2.关于“外科手术团队”的组建项目团队的方式，已经被广泛的应用了，但是少量的落后公司还是没有使用它。

　　3.自上而下的整体的架构的方法，也是。这是我最近在思考的问题，看了之后豁然开朗，我们需要一个架构师。并且让他不要被一些琐事羁绊。

　　4.关于沟通，关于文档，如何将架构师的意图传达下去，以及如何将这些反馈反映到架构师那里，这个一直都是很重要的。

　　5.关于潮流，关于构件，关于面向对象的发展的，关于购买软件（SOA不正是它的一个变种么）真是很有洞察力！当然他错误判断了“封装”的重要性。

　　恩最后，最重要的是 不要异想天开，没有银弹。需要我们一点一滴的把软件工程做好。这也许是最郁闷也是最有趣的方面。。。。

　　《人月神话》读后感(五)：人月神话(不朽的软件工程名著)

　　本评论转自我的Blog

　　转载必须包含本声明、保持本文完整。并以超链形式注明作者编程随想和本文原始地址：

　　http://program-think.blogspot.com/2009/03/book-review-mythical-man-month.html

　　对于软件工程而言，我个人认为到目前为止，尚未有哪本书的影响力和深刻程度能够超越《人月神话》（全名是：The Mythical Man-Month -- Essay on Software Engineering）。于是考虑来聊一下鼎鼎大名的《人月神话》。如果你已经熟读此书，并且自认为深刻掌握其精华，本帖子你就不必再看了。

　　★作者及写书的背景

　　根据“如何选择IT书籍”里面提到的经验，作者是书籍质量的一个主要保证。所以我先来八卦一下《人月神话》的作者：Frederick Phillips Brooks（以下简称Brooks）。这位老兄最牛X的成就是在60年代（他当时才29岁）主持并完成了一个同样很牛X的IBM 360系统的开发。IBM 360后来被誉为是人类从原子能时代进入信息时代的标志。该项目不光具有历史意义，而且在软件工程方面非常有代表性（因为其规模和复杂度）。为了给大伙儿加深印象，列举该项目的几个数据如下：

　　－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

　　软件人员总数　　2000　四十年后，微软的Windows 2003团队也就5000人

　　软件总费用　　　5亿$　发明第一个原子弹的曼哈顿工程也不过才花20亿$

　　开发周期　　　　4年

　　－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

　　注意，上述仅仅是软件方面的统计。

　　最终，IBM 360项目并没有完成全部的预定目标，但是对于这个史无前例的项目，居然没有中途夭折，本身已经算是奇迹了。后来，Brooks在1975年（距今已30多年）把他所写的一些软件工程方面的随笔（很多都与360项目有关）整理出版，也就是我们今天点评的《人月神话》。

　　★本书的结构

　　前面已经说了，Brooks当年是把他写过的一些随笔整理出书的，所以书中的各个章节相对来说比较独立。因此你不一定按照排版的顺序来阅读。比如我每次重读这本书都只是挑选其中一两个章节来看。

　　★本书的看点

　　虽然本书的每个章节都称得上是经典，但限于篇幅，只把我印象最深刻的几章介绍一下。

　　◇第2章，关于“人月”的误导

　　这是本书最有名气的章节。在本章，Brooks明确反对使用“人月”这个极具欺骗性的度量单位。因为人月这个称谓暗示着“人”和“月”是可以互换的。

　　即使到今天为止，还是有大量的编程人员、测试人员、项目经理和软件公司老板在错误地使用人月来衡量软件开发的工作量，实际上，当某人宣称某工作量是6个人月时，这句话本身是没有太大意义的。一般来说，1个人干6个月的工作，6个人在1个月内几乎很难完成。所以我在沟通工作量时，都会明确地讲清楚，需要几个人干几个月。

　　另外，Brooks根据人月的不可互换推导出一个怪论：向进度落后的项目增加人手会导致项目更加落后。这个怪论是如此出名，以至于后来被称为Brooks法则。每当上级领导企图通过增加人手来赶进度时（往往在项目后期），我都会搬出这个法则来拒绝这种企图。

　　◇第3章，关于团队的组成

　　为了解决前几章中提到的大型团队的种种困难，Brooks提出了一种新的解决方案：把大型团队拆分为若干个类似于外科手术式的小团队。

　　每个小团队有一名主程序员（类似于主刀医生），所有的问题分解和功能定义都通过主程序员来完成，以此来降低沟通成本。并且，每个主程序员配备若干个平庸的人帮他/她打下手，也很符合现实情况（还记得“二八原理系列”中提到的优秀人员和平庸人员的比例吗？）。具体的角色职责我就不细说了，书上都有。

　　◇第16、17章，关于“没有银弹”的大实话

　　实际上第16章“没有银弹”的内容来自于作者在1986年作的报告，后来才加入书中。第17章“再论没有银弹”是20周年版加入的。

　　据作者在本书的“20周年纪念版”中宣称，“没有银弹”是引发最多争议的章节。不过我个人认为：虽然引发最多争议，但是这两章却是全书最重要、最深刻且最有价值的章节。即使你从事的工作和软件工程无关，你也应该认真阅读它。

　　rooks在第16章分析了软件开发的根本性困难（复杂性、非一致性、易变性和不可见性）和次要性困难。分析完根本性困难和次要性困难之后，作者断言：未来十年内，不可能有某种技术突破（银弹）能够彻底解决根本性困难，从而导致软件开发效率有数量级的提高。

　　现在，时间已经过去了远远不止十年。在“没有银弹”发表之后，软件界冒出了数不清的新玩意儿（比如面向对象、组件技术、设计模式、CMM、UML、敏捷开发、RAD、等等），很多新玩意儿的创造者都号称他们发明了银弹。但实际上没有哪个新技术能够经受住时间的考验并真正获得银弹的称号。

　　★我个人的建议

　　啰嗦了这么多，最后来说说我个人的几点建议：

　　如果你从来没有看过本书，那赶紧去找一本来，并全部读一遍（不一定要按顺序看）。

　　如果你以前看的是老版本，那赶紧去找来新版（20周年纪念版），并重点看看增补的4个章节。

　　如果你已经把新版全部看完，今后可以考虑定期（例如每隔一两年）再拿出来翻一翻。