人月神话
出版社:中国电力出版社
出版日期:2003-3-1
ISBN:9787508313030
作者:弗雷德里克・布鲁克斯
页数:336页
作者简介
20余年畅销不衰的经典巨作，软件工程领域的圣经宝典！IBM大型电脑之父Fred Brooks20余年开发经验的汇集，远谋深虑，字字珠玑！技术之巧与人文之美的完美结合！纯正原版影印，真正理解大师的睿智思维，再无译文之歧义困扰！更收录包括《No Silver Bullet》（没有银弹）在内的最新四篇经典论文！
书籍目录
Preface to the Anniversary Edition
Preface to the First Edition
Chapter 1 The Tar Pit
Chapter 2 The Mythical Man-Month
Chapter 3 The Surgical Team
Chapter 4 Aristocracy, Democracy, and System Design
Chapter 5 The Second-System Effect
Chapter 6 Passing the Word
Chapter 7 Why Did the Tower of Babel Fail?
Chapter 8 Calling the Shot
Chapter 9 Ten Pounds in a Five-Pound Sack
Chapter 10 The Documentary Hypothesis
Chapter 11 Plan to Throw One Away
Chapter 12 Sharp Tools
……
内容概要
Frederick P.Brooks Jr.曾荣获美国计算机领域最具声望的图灵奖桂冠。美国计算机协会（ACM）称赞他“对计算机体系结构、操作系统和软件工程做出了里程碑式的贡献”。
Brooks博士是北卡罗莱纳大学Kenan-Flager商学院的计算机科学教授。他被认为是“IBM 360系统之父”，曾担任了360系统的项目经理，以及360操作系统项目设计阶段的经理。凭借在上述项目中的杰出贡献，Brooks博士以及Bob Evans和Erich Bloch在1985年荣获了美国国家技术奖。Brooks博士早期曾担任IBM公司Stretch和Harvest计算机的体系结构设计师。
Brooks博士创立了北卡罗莱纳大学的计算机科学系，并在1964-1984年期间担任系主任。他还曾任职于美国国家科技局和国防科学技术委员会。他目前的教学和研究方向是计算机体系结构、分子模型绘图和虚拟环境设计。
媒体关注与评论
近30年来，《The Mythical MAN-MONTH》（人月神话）被公认为软件工程领域的必读经典。此书已问世将近30年，然而至今畅销不衰，广大的软件开发人员对其仍然推崇备至，是不少人书架中必备的藏书，毫无疑问是软件工程领域的经典之作。书中的许多观点现在在IT行业依然被广泛引用、发展，而业界对书中各种观点的争论也一直从未停息，其中原因也许只有一个，《The Mythical MAN-MONTH》是一本帮助软件工程师思考的著作。如今，《The Mythical MAN-MONTH》在全球热卖了28年后，终于以本来面目来到了中国，中国电力出版社即将推出该书的影印版，以帮助该书的拥戴者和专业人士能零距离接触它睿智生动的文章，从而领悟该书的真实思想。 通过这本书，我们可以跨越20年的软件工程发展历史，领略从传统的工程到面向对象软件工程的思想方法，掌握大量实用的软件工程技术，理解大型项目的开发管理过程，吸收前人之经验以为借鉴，对于我们了解软件工程这一尚且陌生的领域助益颇多。全书由行文精辟的19篇即自成章节而又连续贯通的文章组成，涵盖了软件工程的许多重要方面，可称是字字珠玑，掷地做金石之声，其中不乏使人颇有醍醐灌顶之感的精彩论断。 《The Mythical MAN-MONTH》原来只是被誉为“IBM 360系统之父”的北卡罗莱纳大学Kenan-Flagler商学院的Frederick P. Brooks博士于1975年所著的一部软件工程随笔集。但由于该书拥有在软件工程领域的独特思想和真实范例，同时还兼具技术之妙与人文之美，因此一跃成为软件工程的经典之作。在这部书中，Brooks剖析了许多工程管理的“神话”，这些神话来自他在年轻的软件工业中有意义的实践。他抨击了在项目中增加人手可以促进项目完成的幻想。Brooks用实例、幽默与严密的逻辑，展示了这些神话实际上如何给软件项目带来灾难并导致延迟。 中国电力出版社引进的《The Mythical MAN-MONTH》是1995年出版的20周年纪念版。与20年前的版本相比，增加了《No Silver Bullet》（没有银弹）等几篇文章，并在原有章节中补充了许多新的内容。 弹指20余年，计算机的发展一日千里，层出不穷的新技术瞬间便被抛弃，摩尔定律的时间不断被缩短。然而真正的神话是永恒的，就像《The Mythical MAN-MONTH》，因为思想，只有思想是不会落后的。推荐所有的软件人员都能拥有一本此书，你将会发现，它所带来的帮助将远远超过你的想像。
图书封面
发布书评
精彩书评 (总计6条)
-
基本的原则都没有错。但有些古老。尤其是对年轻人来说，打孔、batch job、relay...一定是天书了。但真是难得一见的有趣的计算机工程读物。语言幽默、恰切，举重若轻。睡觉之前读，在旅行中读都好。 -
1.关于“人月”的神话，最近的一个大项目验证了这点，为了缩短项目周期zg的项目不断的增加人员，但是周期还是被一拖再拖。从我这个新来者的角度，我来这个新的项目需要学习了解太多东西，这需要一段时间。如果项目组有意识的培训的话，可能会好一些。但是，实际上没有，实际情况也很惨。2.关于“外科手术团队”的组建项目团队的方式，已经被广泛的应用了，但是少量的落后公司还是没有使用它。3.自上而下的整体的架构的方法，也是。这是我最近在思考的问题，看了之后豁然开朗，我们需要一个架构师。并且让他不要被一些琐事羁绊。4.关于沟通，关于文档，如何将架构师的意图传达下去，以及如何将这些反馈反映到架构师那里，这个一直都是很重要的。5.关于潮流，关于构件，关于面向对象的发展的，关于购买软件（SOA不正是它的一个变种么）真是很有洞察力！当然他错误判断了“封装”的重要性。恩最后，最重要的是 不要异想天开，没有银弹。需要我们一点一滴的把软件工程做好。这也许是最郁闷也是最有趣的方面。。。。 -
《人月神话》是软件工程方面的一本经典著作，其作者布鲁克斯（Frederick P. Brooks）被誉为“IBM System/360之父”，他曾是这一系统的项目经理，后来在设计期任360操作系统的项目经理。由于这一工作，他与Bob Evans和Erich Bloch 1985年曾获美国国家技术奖。Brooks博士早期曾担任IBM公司Stretch和Harvest计算机的体系结构设计师。1999年，他还荣获美国计算机领域最高奖图灵奖。作者在第一章总结了编程的快乐和烦恼。编程的乐趣主要是创造的乐趣、学习的乐趣。而其烦恼是难以达到完美，必须付出艰苦的劳动，项目似乎总是倾向于推迟完成，最可怕的是产品还未完成就可能已经过时了。所有的程序员都是乐观主义者，他们倾向于认为事情会如他们想象的那么顺利，而事实上并非如此。所有的软件项目都倾向于被推迟完成。那种认为大项目只是增加足够的程序员就能顺利完成，已经对于已经推迟的项目，只要增加人手就能按期完成的看法是错误和危险的，因为它假定人和月是可互换的，而其实将工作分割给许多人、培训和程序员之间的交流都需要额外的工作。Brooks提出这样一条定律：给推迟的软件项目增加人手将使得项目更加推迟。有数据表明：好的程序员与差的程序员的生产力可能相差10倍以上，而且编程经验与编程的优秀度没有直接关联（一名糟糕的程序员不会在编10年程序后就成为优秀的程序员）。所以一个小规模的精锐的团队要比一个大的却有很多平庸的程序员的团队要好得多。一个两人的团队，其中一个作为领导者，通常是最好的使用脑力的方式。书中甚至似乎是玩笑地说：如果准备200人开发一个大项目，如果有25名项目经理，那么让这25人组成开发团队，将其余175解雇掉。但是，对于真正大的系统，小规模的团队开发速度又太慢，难以满足需求。这时，一个主程序员，就像手术团队中只有一名主刀医师的模式是很好的模式。一个团队另外配一名副程序员（与主程序员分享设计，并且代替主程序员于一般程序员、工具制造者、测试人员、语言律师交流）、一名管理员（管理钱、人、机器等）、一名编辑（修改、评价主程序员写的文档），管理员与编辑都配一名秘书。主程序员只与副程序员、管理员和编辑交流，这样就大大减少了主程序员与其他人的交流量。系统设计中最重要的是概念的完整性。应明白概念的完整性而不是功能的多样性是评价系统好坏的标准。概念上统一的系统更容易建造和测试。要保证概念上的完整性，设计应该由一个人或者观念一致的小规模小组完成。这看似具有贵族主义倾向，却是保证系统概念上的完整性的需要。架构师的角色与军队的统帅很类似，虽然独裁，但是却是必须的。分离建构和实施是建造大工程时保证概念完整性的重要手段。这不是创造性和非创造性工作的分离。事实上，实施过程中同样需要大量创造性的工作。要保证项目尽快、低成本地完成，架构师与建造者之间尽早和持续的交流很重要。架构师应如何影响实施呢？首先应记住建造者有创造性实施的责任，架构师只是建议，而不是命令。其次，总是建议一种实施方案，但是永远准备接受其它同样好或者更好的方案。应无声和私人地给予这些建议，同时应准备对别人建议的好的方案给予赞扬和肯定。还有应能听取建造者对于架构的改进意见。第二个系统是一个设计的最危险的系统：最常见的倾向是过度设计。系统可能功能过于丰富，实际上只有半数的功能是常用的。为了避免二次系统效应，可以让一个设计师同时设计二个系统，另外，可以为每一功能付予一个优先值，这样如果时间不允许，可以去掉优先级低的功能。在工程实施过程中，每周有架构师、软件和硬件实施者代表、市场计划者组成的小组例会是非常有用的。总架构师主持会议，如果对于一个问题达不成一致意见，由总架构师决定。会议应有确定的书面的讨论议案。另外，架构师应随时准备回答实施者对于设计的问题。实施者在有疑惑时不应猜测架构师的意图，而应询问清楚。询问的电话记录应集中起来，分发给所有实施者手中。项目经理的最好的朋友是他每天的敌人：独立的产品测试组织。巴别塔项目失败的原因缺乏交流和组织。缺乏交流的问题可以通过电话交流、定期的项目会议和一本共享的正式的项目工作报告书解决。项目工作报告书应该有很好的结构，及时更新，每个人都可以看到。良好的组织可以减少所需的交流量。树状结构是传统的组织方式，它是可行的，但并不一定是最有效的，因为有利于交流的组织方式应该是网状的，但是完全的网状结构因为交流量太大，也是不可行的。所以需要设计出特别的组织交流机制以克服树状结构的不足（通常可以在树状结构中连接一些虚线）。在一个大的项目中，有两个角色是很重要的，一个是生产者（producer），就是管理经理，另一个是技术总监（经理）。管理经理负责组织团队、分配工作、创建日程表等。很多时候，他建立内部交流和报告的模式，但是很多时候负责团队之外的交流。技术经理构造设计，确定模块，保证系统的统一性和概念完整性等。管理经理和技术经理需要的天赋、能力是不同的。同时具有管理天赋和强的技术天赋的人是极其少见的。思想者很少，实干家也很少，有思想家特质的实干家是最少的。只有在3至6人的小项目中，管理经理和技术经理才可以是一个人。在更大的项目中，这两个角色应该由不同人担任，因为两者都需要全身心投入。准备估计一个编程项目的工作总量并制订进度表是很难的，因为很难根据编码时间来估算整个项目需要完成的时间。建造小系统的数据不能应用到大型系统上。据研究，若按基本语句来计算，软件的生产率基本是个常数，其原因是每个人的思考速度基本上是个常数。相比低级语言，使用一种合适的高级语言可以使生产率提高5 倍。程序占用的内存和硬盘空间是另一个要考虑的因素。尤其是对于操作系统软件而言，占用内存大小是要考虑的重要因素。不是说只要是大程序都是不好的，但是不必要的大程序却是。因此软件编写者必须设定软件大小的目标，控制大小，设计减少大小的技巧。软件大小的目标必须包括内存大小目标和占用磁盘大小目标。在设定大小目标的同时必须规定软件要实现的功能，防止程序员以减少功能为代价来减少软件大小。在大的项目中，分小组通常只考虑自己小组的目标的实现，而不顾对用户的影响。因此的实现的整个过程中，系统架构师必须时刻保持警惕，保证系统的完整性。为完成一个完整的系统，保持用户取向的态度是编程经理最重要的功能。另外还有时间-空间权衡的问题，为使空间-时间协调，整个小组要进行编程技巧的培训。但是精巧的快的程序几乎都是由战略上的突破产生的而不是战术上的聪明。通常，这种突破是一种新的算法，更常见的，这种突破来自数据或表的重新表示。表示法是编程的本质。一个计算机产品的主要文档包括目标（需求、需要的东西、限制、优先级）、规范（计算机手册和性能规格）、进度表、财务预算、组织结构图、空间、预测、估算、价格等。正式的文档是非常重要的：首先，将决定写下来是至关重要的，只有当一个人将自己的想法写下来的时候，不确定性、不一致性才可能凸显出来。其次，有了写出来的文档，才可能与别人交流你的决定。最后，经理的文档给他一个数据库和一个检查清单。根据正式的文档，他才会知道自己身在何处。经理每天主要的工作是交流，而不是做决定。文档将计划和已经做出的决定传达给整个团队。作为项目经理，只有一小部分时间，约20%的时间花在从外部获取信息上，所以，市场上呼声很高的的所谓“管理全部信息系统”不是建立在真正的管理实践之上的模型。在绝大多数的项目中，第一个建构的系统几乎不可用：太慢、太大、太不好用或者三者都有。所以准备做一个要扔掉的系统是很好的打算，因为即使最好的计划第一次也不可能保证有效。关键是，管理者是否预先就打算建造一个扔掉的系统。将垃圾扔给顾客当然可以节省时间，但是是以用户的痛苦为代价，设计者在重新设计时将会分心，还有，产品的坏名声将使得好的二次设计的产品没有生存空间。所以，计划扔掉一个，因为无论如何你会扔掉的。另外，应该明白，用户的目标和需求是会改变的，所以在设计时就应该准备改变，而不是假定不变，因为唯一不变的是变化本身。不仅目标和需求会变，开发策略和技术的改变也不可避免，准备扔掉一个的观念就是承受当一个人学习的时候，他改变自己的设计。设计可变化系统的技巧包括模块化，好的子程序，模块之间全面的接口定义以及所有这些的全面文档。组织也应该能应对变化。所有的计划、里程碑和时间表都应该是有弹性的，以应对变化。然而建立一个能应对变化的组织是更难的。老板应该尽量使得管理人员和技术人员在他们的天赋允许的情况下可互换：因此，管理人员应上技术课程，技术人员应进行管理培训。在天赋允许时，高级人员应随时准备自己写代码，技术人员也应乐意进行管理。要保证这一点，不应在管理人员和技术人员中进行高低的划分，管理级别和技术级别应完全等价（Bell实验室即进行了这种实践，它废除了所有的职业头衔）。那种高级的技术人员到最后必须走上管理岗位的观念是错误的。程序维护占据开发代价的约40%。软件的维护与硬件的维护是非常不同的：软件维护通常是修复系统缺陷、增加功能、适应使用环境和配置的变化。维护的费用受用户数量的影响，越多的用户发现越多的漏洞。但是在修补漏洞的时候必须十分小心，因为在修补一个漏洞的时候有20%到50%的概率引入另一个漏洞。在修补任一个漏洞后，应该做所有全部的测试。好的工人使用好的工具。在软件开发过程不仅需要通用的工具，还需要个性化的工具，最核心的问题是交流。使用高级语言编程可以提高生产力和调试速度，一般的反对意见（能干我所干的事、目标代码太大、目标代码太慢）都是难以成立的。交互式编程也可以提高生产力。在没有任何代码之前，编写出的规格说明应该提交给外面的测试组以检查其完全性和简明性。最有破坏性和隐蔽的漏洞是不同模块的建构者的不匹配的假设。 Wirth提出的自上往下、逐步求精的设计方式可以有效避免许多漏洞。组件测试的方法有联机测试、内存拷贝、快照、交互式测试等方法。系统测试往往要比我们期待的要花更多的时间。系统测试也更加艰难。我们应该应该使用各组件能正常工作时再进行系统测试（而不是将许多有Bug的组件组合起来测试，即使这些 Bug是已知的），另外在进行系统测试时一次只加一个组件，如果你一次加多个组件，你将难以判断一个新的Bug的来源。要保证一个项目的进度被大幅度推迟，制订进度表很重要。进度表由里程碑和完成的时间组成。里程碑必须具体、明确、可界定。某一里程碑要么到达，要么没有到达，不应该是80%到达的。一个程序员对于明确的里程碑是很少说谎的，如果里程碑很明显，他不能欺骗自己。长期的计划拖延是士气杀手，如果你错过一个限期，确保你在下一个限期按时完成。对于老板，当然应该把握工程的进度，但是他不应该随意行动。对于经理能够处理的问题，他不应该采取行动。小的计划和控制组可能是一个控制项目进度很好的看门狗。软件的文档是与机器同样重要的，即使是对于极其私人的程序，说明文档也是必须的。不应该由于进度压力等任何原因忽视文档的编写。绝大多数的文档失于概述部分过于简略。程序的概述应包括目的、运行环境、输入输出的范围、函数和应用的算法、输入输出格式、操作指令、选项、运行时间、准确性。修改一段程序也需要有一段概述，应包括流程图或者子程序结构图、详细的算法描述、所有文件的说明、通过结构的概述以及对最初设计进行更改的原因的说明。传统的用流程图说明程序的方式基本已经过时，因为如果流程图超过一页，将变得极其难懂。在源代码中嵌入说明的自说明文档方式是很好的改进。使用自说明文档的方式应注意以下几点：使用程序名和变量名携带更多的文档信息；使用空间和格式来显示子程序、嵌套，增强可读性；插入必要的段落说明，尤其是在模块的开头；另外在多说明使用的原因，而不是仅仅是怎样使用，因为动机是理解的关键。本书是二十周年纪念版在最后加了作者在1986年写的经典文章《没有银弹》。主要观点是：软件实体是一个许多概念交织的建筑：数据集、数据项的关系、算法以及引用函数。其本质是抽象的，概念架构在许多不同的表示方式下是一样的。编写软件最困难的部分是规范、设计和测试这种概念架构，而不是表式他的劳动和测试这一表示的可靠性。现代软件系统存在的内在的不可减少的特性有：复杂性(Complexity)、遵守随机的复杂的规范（Conformity）、易变性（Changeability）和不可见性（Invisibility）。高级语言、分时系统、统一编程环境、面向对象编程、人工智能、专家系统、自动化编程、图形化编程都只是解决了编程偶然的困难，而不能解决编程的内在困难。附注：2007年写的读书笔记，现在把它转帖到Douban来
精彩短评 (总计26条)
-
读了一半 后面有些看不进去了 不过也大致了解了下 以后有需要再看看中文版吧 -
很大，很强大！很经典，很深邃。。。有待于深入的研究。。。 -
比中文更贴近其本质理念。 -
经典图书，一定要好好读读，值得收藏 -
解决两个核心复杂度 -
不过我看的是中文版，英文版的电子书浏览过 -
这是我看过的生词量最多的英文原版技术书，好在还是咬牙看了下来且受益非浅。令人惊奇的是，敏捷开发方法中倡导的许多理念，Brooks先生在几十年前就考虑过了。 -
经典的书
翻翻看
没能仔细读完
有空继续读吧 -
先欣赏优美的文字，后学习软件工程思想 -
软件工程的经典之作 -
内容不错，印刷也可以，不像以前很烂的影印版 -
也许很难会碰到如此复杂的项目，但道理是相通的。书中很多睿智的箴言，值得经常阅读思考 -
文采斐然，百读不厌 -
软工必读！书也便宜，这么经典的书不能不买 -
这本书是作者对软件工程工作的真切心灵感受，做为一个从事软件工程工作数年的从业人员，觉得书中的见解对于自己在软件工程上的工作有着明灯式的指导作用。不过，对于没有从业经验的人员要理解书中的内容，有点难度——正如我说，书中的内容是作者的感受结晶，没有感受的就不能充分理解书中的观点，有被误导的可能。所谓没有从业经验的人员，我觉得至少包括大学学生，对软件工程没有从业感受的从业人员。 -
说中的经典，可惜买的是这本英文原版，基本看不懂。可惜了，准备送人。 -
还是不错的，很多结论到今天还是成立 -
刚毕业的时候看过，现在正重新看一遍，更觉经典，直接看的英文版，看看有没更深体会，最好当散文，小说看吧，毕竟不是工具书，也不是技术书，更多是基于软件开发过程和团队合作的哲学探讨 -
建议多引进一些英文原版经典书籍! -
视野 -
在学校学崩溃了，学英语时期顺手买的，书的设计挺可爱 -
起于软件，但不止于软件。
"The MM-M is incidentally about software but primarily about how people in teams make things." -
虽然写作手法很新颖，但不太喜欢这种过于“断章取义”的东西。虽然这样容易借重人之眼画“千面黛玉”。不过总觉得一本书里能有几句话对自己有点“影响”或“触动”的话，此书也算是没“太”白读。 -
中文翻译太不流畅，太烂了。有空找英文版看。 -
老前辈写的书，一个字，强 -
内容不说了，从行文就可看出作者的老道