《人月神话》国内评论集之二
UMLChina 收集整理
以下文字均摘自网络，原文中的错字不作修改。
我女朋友是做外贸的，一天晚上她一直捧着我书架上的一本书在看，很投入的样子，后来她叫住我很认真的说：“这本书写的很好，我明天可以带到办公室接着看么？”那本书是《人月神话》。
关于我们的思考——“项目开发”及读《人月神话》有感
项目开发终于结束了，按项目流程，我应该写一份《项目开发总结报告》。拿来“GB856T——88”标准文档，有框架指导我该写些什么，但是怎么能让这些框架协束缚了自由的思想呢？于是决定换一种形式。
项目开发接近尾声的时候，也是最关键的时候，有人送来一本《人月神话》。我很幸运能在这个时候读这本书，因为会有很多思考，关于项目，关于团队，关于我们……
……
四、完美与放弃
在《人月神话》中有一段被截取，称为“程序员的苦与乐”，在网上广为流传。Brooks大师用简短的篇幅，描绘出整个程序世界的苦与乐。在这次项目开发中，有两个苦恼体现的比较明显。
一是追求完美。“因为计算机是以这样的方式来变戏法的：如果口语中的一个字符、一个停顿，没有与正确的形式一致，魔术就不会出现（现实中，很少的人类活动要求完美，所以人类对它本来就不习惯）。实际上，我认为，学习编程最困难的部分，是将做事的方式向追求完美的方向调整。”
看来我再次做出了正确的选择，我是个追求完美的人，而且我也一直认为程序员就应该有这种本性。在写程序的时候，甚至对一个变量名我都要反复斟酌，直到选择一个我认为可以表达这个变量的意义的。我并不认为这是在浪费时间：一是有助于对程序的理解和维护，好的程序本身就是注释；二是减少错误发生的可能。这次开发因为时间短，我尝试采用设计->编码->编译的方式来写程序，经常把一个几千行代码的模块写完之后才开始调试。效果不错，因为对设计考虑的比较充分，基本上都是一些拼写上的错误。不过有一个错误却另我苦恼了很久。因为一个结构的成员变量名与函数参数的变量名一样，而这个参数又在多处使用，写的时候，也可能是拷贝代码的时候，很容易把结构名给忘记或多加了一个结构名，而这时又不会有语法上的错误。吸取了这次教训，我把整个程序检查了一遍，并做了一些修改。这段程序我参考的一位大师的原型，令我欣慰的是，他的下一个版本和我的程序做出了同样的一些修改。
另一个“苦恼来自设定目标、供给资源、提供信息。编程人员很少能控制工作环境和工作目标。”后面章节又提到“结构师获得了所有的创造发明的快乐，剥夺了实现人员的创造力”。“实现同样是一项高级的创造性活动。具体实现中创造和发明的机会，产东会因为指定了外部技术说明而大为减少，相反创造性活动会因为规范化而得到增强，整个产品也一样。”程序员要学会放弃一部分乐趣，整个项目也一样，这是我读《人月神话》感触最深的一点。
设计网络认证的时候，本打算用一种简单的认证方式实现，因为这不是重点。Y提出用证书加自己写的Socket类实现认证的通讯过程。这是一个很好的创意，但VC写出类无法在Delphi里使用，BCB也不行。封装，回调……大家都搞晕了，只剩下两个字：“放弃”。
由于时间比较紧，产品的功能上也放弃了一些认为是很有创意的，但需求中没有提到的部分。后面的开发中也有类似的问题，每个人都按自己的喜好调用和提供接口，可以说是八仙过海，各显神通。问题主要在于交流。
五、善于交流
……
2．交流方式
人月之所以不能成为神话，正是因为增加人手的同时也增加了人与人之间的交流。
我们在项目一开始就通过QQ群组进行沟通，后来又搭建了企业内部协作平台，而且还有不定期的会议。与大师所说的三种交流途径——非正式途径、会议、工作手册——不谋而合。但是，执行的效果却不很理想。是大师说的不对？不是。是我们没有利用好这几种途径。我们很好的利用会议，解决很多细小方面的误解；过多的使用QQ群组，一是在登陆QQ的时候消息太多而没看仔细，二是这种方式针对小的误解是很有效的，但对于一些系统的全面的理解必须通过文档；但是很少使用协作平台，没有仔细的阅读文档的习惯，也没有写出一个完整文档的习惯。
即使在QQ群组的交流中，也没有把问题表述清楚。经常看到：“某某：你那里有问题？”哪里？什么问题？QQ都是通过UDP传输的，这里就不需要发送ACK了，对方不在线可以通过服务器中转，到论坛发一个贴子或直接发送邮件。接着有人回答：“不可能啊？”什么事情都可能发生的，只要能满足条件。域名都会不易而飞，还有什么是不可能的呢？出了问题首先从自身找原因，发现一切的可能。
……
九、结束语
本文只是我在项目开发和读了《人月神话》之后的一点感想，没有谁的对与错，对于本文一些观点的正确于否欢迎与您一起讨论。本文只是按照项目流程，挑主要的部分叙述了在开发中体会到的一些感想。这次开发让我学到太多太多的东西，将使我终身受益。还有很多的想法，如团队建设、整体设计、开发模式……希望以后能与大家多多交流，相互学习。
《人月神话》这本书推荐大家都去读一下。它不是良药，不能为你解决实际工作中的问题，但它可以给你带来很多思考，让你变得更加成熟。软件工程是为开发软件服务的，标准不是目的，只是手段。《人月神话》没讲标准，但它为怎样做好一个项目提供了一些参考。它会增强你的自信心，当有人反驳你的观点的时候，你可以告诉他：“Brooks大师如是说^-^”。
不同的社会经验，不同的思想状态，对读本书的心得也不一样，我在此说说我的读后感，书中有许多非常好的观点，但我只把我感触最深的写下来。这确实是一本很值得多次阅读的好书，每次阅读可能都能从中得到一些提示。
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）的程序：提出文档与程序合为一体，能很好的解决文档与程序分开造成的文档过时的问题，并说明了在程序中加入文档的一些方法和技巧。2002年，我看到一位网友关于文档与程序合一的文章，当时就觉得是个好方法，没想到70年代，老美已经提出来了。
14. 没有银弹-软件工程中的根本和次要问题(No Silver Bullet-Essence and Accident in software Engineering)
这是一篇论文，发表于1986年,我自认为我的理论水平没有上升到可以对他的论点和论据做出怀疑或质疑的结论，我只是说说我的感想。
人狼是传说中的妖怪，只有银弹才能杀死他。作者认为软件项目具有人狼的特性，因为软件项目也可能变成一个怪物，一个落后进度、超出预算、存在大量缺陷的怪物。
作者通过软件系统的内在特性复杂性、一致性、可变性和不可见性来分析说明了软件天生就没有银弹。
作者试图通过分析软件问题的本质和很多侯选银弹的特征来探究其中的原因。他行动的第一步是将大块的“巨无霸理论”替换成“微生物理论”。这个变化的过程告诉你，进步是逐步取得的，伴随着辛勤的劳动，对规范化过程应进行持续不懈的努力，而这个努力的过程相应的就诞生了软件工程。作者对软件工程诞生的原因做出这样的解释，我觉得符合外国思维的特点，这正是国人所缺乏。记得有一位朋友说过，中国妈妈与德国妈妈的区别，他说，如果手里拿的针掉到地上了，中国妈妈的第一反应是估计针掉下去的范围，然后在这个范围里面找，可能很快就找到了，也可能一直都找不到；但德国妈妈不同，她会拿一根粉笔来，把整个屋子画成一个大圈，接着把大圈分成许许多多的小圈，然后再到每个小圈里找，虽然比较慢，但最终肯定可以找到。仔细想象，大多数情况下，中国妈妈都会找到得比较快，这确实符合大多数中国妈妈的思维习惯，每个中国妈妈都这样找，这好象是与生俱来的本事，但为什么德国妈妈没有这个本事呢？是德国妈妈笨吗？为什么中国妈妈也有找不到的情况？而德国妈妈，虽然速度慢了点，却始终能够找得到？如果把这件故事推而广之，多年以后，德国妈妈创建了找针工程，她通过多次找针的实验数据，分析出针掉到整个房间中各个小圈的概率，总结出针在哪个小圈的概率最大，很快就可以找到针，找针速度早已高过中国妈妈，而中国妈妈还在依循与生俱来的本事。你能说德国妈妈笨吗？为什么中国妈妈和德国妈妈会有这么大的区别？是德国妈妈把大块的“巨无霸理论”替换成“微生物理论”吗？我觉得是是，你说呢？作者在后面的论述中用数学和物理的发展为例子也说明了，这种思想的成立。
余下的作者把软件工程按“巨无霸理论”替换成“微生物理论”的过程详细的说明，值得看，我关注的不是具体的内容，具体内容可能有些不合适宜，我关注的是作者的思考方式以及处理方法，这是非常重要的。
在“以往解决次要困难的一些突破”和“银弹的希望”章节，从概念上讲述了软件的发展，其中讲到“专家系统”时，使我想起一部科幻电影，忘了电影名字了，有个情节大致是这样的，一位非常有经验的主管死后，有一名较优 秀的下属接任，但这时出现了一位非常厉害的敌人，这位新主管无论如何也战胜不了敌人，这时想起了以前的主管，心想前主管一定有办法对付这个敌人，而前主管的大脑就存放在系统里，于是新主管调出前主管的大脑，把敌人的各种特征都描述给'他'听，就好象前主管仍然活着一样，他与前主管的大脑通话后，前主管的大脑告诉了他对付敌人的方法，后来通过这个方法真的把敌人打败了。这是否专家系统的最佳境界呢？
还有讲到“自动”编程章节时，使我想起我以前也有过类似的想法，但没想到这些想法竟然早就有人提出过。还有记得“图形化编程”好象也风行过一段日子。
15. 再论《没有银弹》No Silver Bullet Refired
看完再论《没有银弹》后，虽然作者说有不少人对他的观点持反对或不同意见，但我始终觉得他的观点是对的——根本和次要问题的划分以及定义。作者认为软件开发困难的部分是概念的结构，如规格化、设计和测试等概念的结构，而不是概念的表述和实现概念，虽然实现概念可能占用了小于90%的时间，就如现今的软件开发一样，系统分析通常占用的整个项目开发时间不超过20%，而80%的时间花在编程上一样。
好好读书 [::坚持日记::]- 叶 子 @ 18:22:35
呜呼,欢乐无声,幸福是卡片
下午去逛书店,本想选几本适合中学生的读物给我表妹文怡
不想看到了< 人月神话>,好熟悉
看介绍不错,买了
刚才网上查了查批评的声音居多，主要是对译者不满意,大家都更信任ENGLISH VERSION，尽管可能真正看过原版的人寥寥无几，我还没看中文版的,英文版的自然不用说了，看之前已经很好奇了,是炒作还是真的有魅力?
……
第三，对于开发人员的选用，我发现，美国人是非常注重选用优秀的开发人员的。Martin Fowler曾经开玩笑的说，如果给他一批水平不高的开发项目，他会考虑全部解雇，重新招聘。《人月神话》中也说，如果200人开发一个项目，其中25个人最能干，那么会考虑解雇其余的175个人，让项目经理来编程（当然，后面还有一些抉择分析，这里断章取义了）。其结论的基础是基于以下研究结果：优秀的开发人员和差的开发人员，其效率之差可以达到数量级。另外，从管理的角度来说，只有人多了，才会有管理问题，当团队规模控制在一定的范围内时，便不会有太大的管理问题。
……
分工使得每个程序员只关注于自己的工作领域,没有时间也没有精力去关心系统的其他部分,这样就带来了系统开发中的本位主义,更严重的是,系统中存在的错误被详细的分工掩盖了起来,最后往往等到系统测试时才发现错误,这时修改系统已经太晚了,只好在上面进行修补,最后整个系统变得如同泥潭一般,让项目组不能自拔,究其原因,往往是因为分工导致了互不了解,最后大家彼此的工作被相互抵消了,工作的越努力,给其他部分带来的麻烦和缺点越多,这就是软件开发中非常具有讽刺意味的现实.这又往往被理解成为需要更多的沟通,其实不然,因为只有充分了解对方的工作,才能够做到有效的沟通,而分工带来的隔阂使得充分的沟通成为不可能的事情.<<人月神话>>中所谈到的沟通问题,其根本原因就出在分工上面,而作者寄希望于加强沟通来解决问题,我认为也是不现实的.
二.分工导致了对于效率的盲目追求.
由于大家都说:"分工提高了工作效率",于是管理者在此论断的指导下,往往会迫于市场,客户的压力,而盲目要求提高开发的效率.而正是由于分工的存在,每个不同岗位上的程序员都不能意识到这样做的错误性,而反抗这样的决定往往又会背上怠工的罪名,最后大家都听从了.最后,在系统没有明确认识之前,就开始了系统分析,设计,编码,测试.这样做的结果就是"欲速则不达",最后得到的结果往往是,在系统开始时,进行时,似乎都一切正常,等到系统快结束时,问题开始出现,而造成项目一拖再拖. <<人月神话>>中有这样一句话"好的烹饪需要时间."其实软件开发也一样,在对系统充分了解之前开始工作,盲目推进工作,结果就是工作的越多,其中的错误也越多.表面上看提高了效率,实际上是以牺牲软件的质量为代价来追求的速度,而最后当矛盾爆发时,已经太晚了,这就造成了软件危机.究其原因,就是"分工提高了效率"这个似是而非的前提所造成的,正确的说法应该是:"在一定的情况下,分工可以提高开发效率,但在一定的情况下,也有可能降低开发效率."表面上的开发效率提高,并不是真正的开发效率提高,这种表面上的提高往往隐藏了对于系统的不了解,埋下了系统失败的祸根.
我大四之后，考上了本校的研究生……，我本科的同学，毕业第一年的工资税前大约在3000－4000，福利什么的不算，在我读研二的现在，他们的工资已经普遍涨到税前4000－5000左右。 我们在实验室工作的日子，一周6天,每年加班的日子比在公司工作的人多52（每周六）＋7（五一）＋7（十一）－7（我暑假放假的日子）天＝59天，寒假和春节假期相抵。 但是还有一点，那就是我们每天都是从早上8点工作到晚上10点，每天要多工作4 到5个小时。 大家可以算算，我为了这600人民币一个月的工资，一个月要加班多少个小时？写＜人月神话＞的家伙如果到我们实验室转转，估计这本书的下一个版本就会多开一个章节了。
……
这是本栏的第一篇, 也是我最有写作冲动的时候. 人月神话这个题目来自于<<人月神话>>一书, 讲述的内容也来自于人月神话一书. 只不过讲述的内容换成了我所经历的.
编写代码也已经数年了. 说到编写代码的能力, 只怕也不会有一大堆人超越我. 但是, 领导终究是领导, 始终会有没有学过管理或者尝试以流水线理论来主导软件开发的领导. 而且, 在国内, 这样的领导并不少见. 这些领导的共同只处在于: 目标产品是定下期限要完成的, 所有的东西是可以以人手定量的, 而人员配备"按照正常情况足够满足开发进度". 在这一前提下, 形形色色的变种会出现.
有些是不能明确说出功能列表的; 有些则是没有能力知道开发中可能遇到的障碍点在哪里的; 有些则不知道团队人员的真正能力的; ...; 更有些是集以上之大成的. 在有些时候, 我也是其中的一员.
说到这里, 要说一下人月神话. 我们所有的进度都是以 人月 代码产量来衡量的. 而增加"人"并不能缩短"月"的量.
一个目标产品本身能有多大的代码量大致不会和预算的相差很多. 这时我的经验, 当然也有一些连代码量也估算不准的LEADER. 我们通常会最终会将代码量分解到每个模块, 并且根据程序员的工作能力来分配进度要求. 在很多情况下, 遇到进度失衡的时候, 第一反应是增加人手. 但是事实上增加人手的项目不到10%能准时解决. 很多情况下, 增加进去的人手并不能真正进入工作, 因为模块已经无法细分一小块出来给新加入的人手. 又或者新加入人手熟悉现有代码结构的时候已经到达项目终止时间.
而人月代码产量本身就不是一个固定的值. 我的最高写作时刻可以达到1600行/天. 真的就是32000行/月了么? 不! 更多时刻的代码产量在200-300行/天. 也有很多一个算法就花费1天. 变得只有100行/天的情况. 真正比较客观的状况, 根据最近3年的状况, 5000行/3月是比较客观的量. 这是C/C++的速度. 是我的速度, 其他程序员有这样的效率么? 真正能超过的并不多见. 即使是这样的代码效率, 也并不适合将计算进入商业产品的进度考虑.(个人完美产品和商业完美产品将在以后有写作欲的时候写) 因为很多难点并不是因为降低人月代码产量就能够攻克的.
我本人目前比较倾向的时间分配,也是比较真实的时间分配, 没有难点的时间分配
20% 代码编辑
30% DEBUG
30% 文档
20% 保留时间.
这就说明即使在没有已知难点的状况下. 有20%的保留时间仍然有必要. 因为很有可能1个小小的数学逻辑就能让你忙上半天一天. 这并不是不专心, 而是疏忽导致的. 而且从来就没有人能避免疏忽. 而30%文档时间有时并不能完成很漂亮的文档.
了解了这个神话, 我们就可以采取主动行动.
1.首先, 不要低估任何一个产品的难度, 难度估计得高点总是没有错的.(我曾经犯过多次这样的错误) 这样, 在确定任务进度前争取更多的时间.
2.很显然, 既然有可能在任意时刻发生问题, 为什么不提前多干点呢? 很少有人愿意这样. 但是我的经验是一定要提前多干. 在最近的2个项目中, 都是提前很多时候完成了大部分的工作. 90%的东西完成了, 而产品交付时间则剩下1个月. 眼看可以轻松了, 却仍然忙着攻克最后的难点, 到了最后一天才真正完成任务. 险得很. 按照时刻表完成进度的程序员都一定会翻船. 不信! 哼, 随便找一个去看看. 我很自信这点的判断.
<<人月神话中>>有着好的程序员可能效率比糟糕程序员高10倍的可能性.在我的人月神话中确实有着好的程序员比糟糕的程序员速度快上10倍的例证. 当时团队中一天无法完成一个极度简单功能的PROGRAMMER.(不知到此人现在怎么样) 但是在人月理论中, 这样的人也照样要占着进度表的一条...
……
……
“侯捷现象”，真有那 严重吗？前些日子我去书店买《人月神话》，没有遇到一位知道人月是一本计算机书的店员。就算我们在这里吵得热火朝天，社会对此的反应也只是死水微澜而已。其实一个技术作家，即使到Charles Petzold这 地步，对大众的影响力也是非常有限的。
……
……
我们的开发人员结构还需要优化。软件开发团队合理的结构是一般是金字塔形的。为了保证概念的一致性和完整性，大主意必须由一两个人来通盘考虑并做出决定。关于这方面问题，《人月神话》里有非常透彻的描述，包括一些量化的参数。
……
icecloud(冰云)
外国大学一般软件工程课有2本教材，一本就是《人月神话》，一本是那个《软件工程--实践者的研究方法》。可惜啊，中国只讲了一半。
该书非常好，希望能读百遍，别的说了也没用，关键在领悟，实践，其他得都没有用，如果你不能做到这2点，什么书都没有用
这本书挺好的，尤其是作者的基本上所有理论在20多年后仍然很有指导意义，这点在IT领域是不容易的。
而且，这本书不是具体教你怎么做，而更倾向于告诉你为什么这样做。现在很多的人开发软件要写文档、要做计划、要做评审，而却不知道为什么要这么做，从这本书就可以找到很多这样的答案。
当然，这本书算不算经典就不必评价，经典的书未必真好，好的书未必经典。关键是书是否开拓了你的眼界和思维，从这个意义上说，这本书做到了。
我觉得里面有很多东西很有道理。
最近刚碰到这一件事：开发经理把写详细设计书的任务交给我们来写，有模版但是每个人还是写的都不一样，很多人，认为自己发挥的时候到了，刻意写的和别人不同，最后只有开发部经理自己重写了一边，才算完事。
人月神话中就提到文档一般只能由一个人写，如果很多人写会很乱的，每人的思想都不同，到最后拼凑在一起的东西，只能是垃圾。
同意楼上上所说的！我正在看此本书籍，有很多的东西如楼上所说的一样，这本书从1975年已经出来了，能到现在还有很多的读者，应该有它的经典的地方！值的一看！
我觉得挺好，有很多指导意义，其实许多其他同类的书籍如《快速软件开发》中所以写得如此之好就是因为它踩在《人月》巨人的肩膀上。要想《人月》出生于20年前。不过只靠一本《人月》就想有什么质的飞跃是不可能的，还需要借鉴许多其他的经典书籍。
翻译水平最差的一本书
看过了，很有指导作用！
我看那本书没有期待中的那么好，说教的太多，例子又是过时的70年代的东西。对软件工程的阐述不比RUP、XP等书籍清楚、深刻，坦白的说，我看了一半就放下了，我认为这本书的宣传成分很重，且言过其实。当然，也可能是我的水平不够。一家之言...
是真的吗？
我原来就听过这本书，在书店中也见过
但是没有时间看，现在好多书在等着我看
如果好的话，一定要好好研究一下
现在在研究<thinking in c++>，挺有启发的
记住，它是
二十年前
的经典！！！
世事变幻，二十年，许多当时的问题，在现在看来，已经不是问题了。
我有电子档，需要的话留言给我。
简单又有说服力，把我从设计人员带到了管理阶段的门口了
一本就是《人月神话》，一本是那个《软件工程--实践者的研究方法》。我 都拜读过我觉得前者对我更有帮助，后者的高级软件工程课题很值得研究哦，特别是静室软件工程，我认为她代表着一种全新 的质量工程思想，有兴趣的朋友可以去拜读一下MILLS写的《静室软件工程》机械工业出版社有中文版的
买了一本,有不小的收获.不过还没有看完.
我现在只读了3章了,但读到第1章就被吸引着了好久没有看到这种好书了
基本上总结了我们公司大项目失败的原因。
因为之前看过一本<<快速软件开发>>(或者名称类似吧，不太记得了)
感觉比<<人>>好，里面讲得内容都差不多，而且要比后者有趣得多
所以现在看<<人>>电子版，只是随便浏览了一下
一家之言
首先这一是本好书，不容置疑;而且只有项目组长或相关的人员才能找到感觉,一般的程序员收获也不大，更别说才入门的。
就我的经验而言，我以前也做过项目组长，但是不很好，现在在一家新公司里学到很多项目方面的东西，而且也能从书中找到我们公司的影子（我所在的公司在国内或国际的某一个领域站有一席）而且也很成功，（国内很多公司没有这种项目管理的方法）
我建议先看先学，先领悟，对你以后的发展绝对有好处!信不信由你
我也认为《快速软件开发》比《人月神话》好而且有趣，《人月神话》是本好书，但毕竟是20年前的，出版社的大吹大擂是吵作！
我只有电子版的，Adams Wang翻译。
如果时间不多的话，建议看电子版的朋友从后往前看，前边七几年写的东西，确实有很多有价值的论点，经过20多年的实践，已经成为共识，佩服作者的眼光。不过书中的例子实在太老，感觉不太好理解，对论点帮助不大。所以建议先读后面20年后的总结和回顾，有时间再看前边。
《人月神话》是本好书，至少要比我见过的国产的任何关于 软件工程的书要好，要实用。我们不应当来不急去批判它，毕竟我们目前国内的多数软件公司和人家20年前的公司比还要差的远。我们好好学习吧，把有用的留下，没用的丢了，别客气，也不用藐视人家，人家又不比你差
幸亏我没买《人月神话》，我就知道带“神”字的书太玄！！
我只买了《快速软件开发》，但一直竖着耳朵关注《人月神话》，因为我不知道它是讲什么的！
听了楼上二位的解释，这下我就放心了，因为我知道《快速软件开发》是干什么的。
花了三天的时间，一口气读完了它。感觉受益匪浅。
它讲述了软件开发中存在的最最本质的问题。而这些问题，到目前为止也没有得到很好的解决。
虽然，这本书是二十年前所写，其中相当多的例子在如今看来也是不值得一提。但是，它所反映的软件开发的本质，却一点也没有变化。
正如《没有银弹》中所指出的那样，到目前为止，没有一种方法从根本上解决了软件开发的问题，即使在将来相当长的一段时间内，也不会有。
还有，这本书不是一本教材。
花两天实践一口气看完了，有些囫囵吞枣。但还是有些感想，拿出来谈谈：
这本书同时涉及到了编码和管理的经验，确实是一本好书。但作为20年前的这本书，显然其中的有些知识已经陈旧了，翻翻CMM，不得不这样说。回看现在大中专、甚至是大学所教的软件工程课教材，实在是有些不敢恭维。软件工程是一个实实在在的课题，它不单单是技术上的问题，还有管理上的问题。有计划，有规范，有管理，有技术才能把软件做好。我在公司里做事，人家问我能不能做一个好软件，一个大软件，我置之一笑。什么是“好”软件，什么是“大”软件。没有市场的“好”软件、“大”软件意味着什么。做软件的做过市场调研吗，需求分析到位吗？我看现在的软件公司就很难做到这点，更不用说管理了。跳到技术这方面，许多公司都是接到什么订单都做（市场竞争身不由己，原始积累的过程），但对自己的核心竞争力、核心技术却没有一个发展计划。许多在市场上有比较大占有率的软件，其研发公司都具备自己的核心竞争力。所以，做软件在将来也会出现专业化、专业领域的分层，不是讲我使做软件的，而是讲我是做什么方面的软件的。可以看到，软件的开发和管理矛盾重重，不管是UML、CMM或是其它都任重而道远，现在是不过是一个开端而已。
《快速软件开发》(斯蒂芬.迈克康奈尔)和《人月神话》除了都是经典著作，都是讲软件工程范畴的东西外，比较意义真的很强吗？？？
她让你思考。。。。。。
《人月神话》书中对首席程序员、副手、管理员定义如下：
首席程序员。他亲自定义功能和性能技术说明书，设计程序，编制源代码，测试以及书写技术文档。他使用例如PL/I的结构化编程语言，拥有对计算机系统的访问能力；该计算机系统不仅仅能进行测试，还存储程序的各种版本，以允许简单的文件更新，并对他的文档提供文本编辑能力。首席程序员需要极高的天分、十年的经验和应用数学、业务数据处理或其他方面的大量系统和应用知识。
副手。他是首席程序员的后备，能完成任何一部分工作，但是相对具有较少的经验。他的主要作用是作为设计的思考者、讨论者和评估人员。首席程序员和他沟通设计，但不受到他建议的限制。副手经常在与其他团队的功能和接口讨论中代表自己的小组。他需要详细了解所有的代码，研究设计策略的备选方案。显然，他充当外科医生的保险机制。他甚至可能编制代码，但针对代码的任何部分，不承担具体的开发职责。
管理员。首席程序员必须在人员、加薪等方面具有决定权，但他决不能在这些事务上浪费任何时间。因而，他需要一个控制财务、人员、工作地点安排和机器的专业管理人员，该管理员充当与组织中其他管理机构的接口。Baker建议仅在项目具有法律、合同、报表和财务方面的需求时，管理员才具有全职责任。否则，一个管理员可以为两个团队服务。
我的问题是：目前中国的状况是否一般将副手与管理员合一？若是，副手与管理员是否可以合一？这样做的利弊分析？
我的看法：
首先，我们都承认，人约神话中关于这一段的描述是正确的，也就是说这种工作方式是科学的。
其次，在我们这个公司是肯定不可能这样去做的。
第三，除了那些作坊式的开发团队，由于他们本身可能只有一两个人，或者两三个人，否则，我怀疑是否有哪个公司的开发团队或者开发小组真正采用了这种工作方式，似乎大家都是在遵循这书中所说的错误的开发方式，（用一大堆人来解决问题，问题又没有被明确的划分成不同的部分，或者不同的部分之间的接口描述的不清楚）。
第四，作为技术口上的负责人要想对于财务方面（例如人员的薪水和奖金进行控制）在中国好像本身也是个神话吧？更别说让管理员来控制了，当然如果情况比较理想的话，在有些时候，有些企业，或许首席程序员可以对有权利决定人员待遇的领导提出相关的建议，至于听不听，那就是另一回事了。
第五，我个人的看法，如果遵循书中的描述的话，副手和管理员显然是不能合二为一的，因为前者的工作内容是围绕技术管理的，后者这是围绕人员和财务管理的，性质是完全不同的。对于相应人员的技能要求也是完全不同的。
最后声明，因为在下自己也是个没有什么经验的人，同时没有在规模较大的公司待过，所以上面的观点很可能非常的片面或者浅薄，谨代表个人意见，请各位高人指点。