在软件领域,很少能有像《人月神话》一样具有深远影响力和畅销不衰的著作。Brooks博士为人们管理复杂项目提供了*具洞察力的见解,既有很多发人深省的观点,又有大量软件工程的实践。本书内容来自Brooks博士在IBM公司SYSTEM/360家族和OS/360中的项目管理经验,该项目堪称软件开发项目管理的典范。该书英文原版一经面世,即引起业内人士的强烈反响,后又译为德、法、日、俄、中、韩等多种文字,全球销售数百万册。确立了其在行业内的经典地位。
在本书**次出版32年后的今天,我们重新整理了Brooks博士的经典内容,并将国内软件开发领域先行者们对《人月神话》中的实践及系统理论的使用经验和心得集结成册免费赠与大家共享,更使本书成为国内从业者的必读经典之一。
本书读者包括:软件开发人员、软件项目经理、系统分析师等IT从业者。

第1章 焦油坑
编程系统产品
职业的乐趣
职业的苦恼
第2章 人月神话
乐观主义
人月
系统测试
空泛的估算
重复产生的进度灾难
第3章 外科手术队伍
问题
Mills的建议
如何运作
团队的扩建
第4章 **专制、民主政治和系统设计
概念的完整性
获得概念的完整性
**专制统治和民主政治
在等待时,实现人员应该做什么
第5章 画蛇添足
结构师的交互准则和机制
自律——开发第二个系统所带来的后果
第6章 贯彻执行
文档化的规格说明——手册
形式化定义
直接整合
会议和大会
多重实现
电话日志
产品测试
第7章 为什么巴比伦塔会失败
巴比伦塔的管理教训
大型编程项目中的交流
项目工作手册
大型编程项目的组织架构
第8章 胸有成竹
第9章 削足适履
第10章 提纲挈领
第11章 未雨绸缪
第12章 干将莫邪
第13章 整体部分
第14章 祸起萧墙
第15章 另外一面
第16章 没有银弹
第17章 再论“没有银弹”
第18章 《人月神话》的观点:是与非?
第19章 20年后的《人月神话》
结束语:令人向往、激动人心和充满乐趣的50年
注解与参考文献

各路英豪品评人月实践
软工经典再启江湖争论
汇集国内软件开发领域先行者们对《人月神话》中的实践及系统理论的使用经验和心得!
Frank Chance
介绍
出版于1975年的《人月神话》是软件开发方面的经典作品。1995年版包括了令人感兴趣的新的几章,但原来的随笔依然是这本书的心脏与灵魂。在这本书中,Brooks解决了如何组织和管理大规模编程项目的问题。这些项目要求成百上千的程序员,产生几百万行代码(想想SAP、Oracle数据库引擎、Windows2000)。这部书由一系列简明的随笔组成。在这篇评论中我将讨论开篇随笔――我的*爱之一。
焦油坑
Brooks将大系统编程作比喻作史前的焦油坑来开始他的**篇随笔:“记忆中,我们看到恐龙、猛犸象、剑齿虎正在挣脱沥青的魔爪。挣扎得越剧烈,陷入的越深,没有哪只野兽足够强壮或熟练,它们*终都沉没了。大系统编程在过去的十年间就像焦油坑,许多大而强有力的野兽在其中已经惨烈地失败了。大部分已实现并在运行的系统,很少有达到目标、时间表和预算的。大和小、厚重和细实,一个接一个的团队卷入了沥青(陷阱)。没有什么事情似乎会导致这个困难――任何特殊的手掌都能被拉出来。但同时并相互作用的因数的相互聚集导致运动越来越慢。每个人似乎都惊讶于问题的难缠,难于面对它的本质。”
记住,这些话写于1975年。今天它们仍然可用吗?考虑一下WindowsNT5.0。**次计划于1997年发布,随后延迟到1998年早期,1998年末,然后是1999年(为此它被重新命名为Windows2000)。这儿是一些公开的估计:
● 5,000程序员。
● 35,000,000行代码。
显然,NT5.0是个大系统编程项目。同样显而易见,Brooks的焦油坑在今天同1975年一样普遍!
让我们继续NT5.0的例子。假设*糟糕的情况,全部35,000,000 行代码都是新编的。有理由假设开发工作大致在1994年开始。所以我们有:
● 5,000 程序员 X 5 年 = 25,000 程序员年
● 35,000,000 行代码/ 25,000 程序员年 = 1,400 行/程序员年。
如果你是个程序员,或者你只接受过编程课程的教育,这个数字(1,400行每年)似乎令人惊异的低。我们当中的大部分人都能在一两天内堆积出接近一千行的代码。什么使得Microsoft的程序员一整年才产出1,400行代码?
两种可能性跃入我们的脑海:
● Microsoft 雇用了5,000名不合格的程序员去开发NT 5.0。
或者
● 写一个大规模的程序系统产品远难于堆砌出单一的程序。
Brooks将讨论认为后一个答案是正确的。他由定义术语开始:
(1) 程序
一个独立的程序是我们两天编程狂欢的结果。它是准备自己运行于我们编程的那台机器上的。如果我们加上文档、通用化代码、编写测**例、使得代码可以由其他无关的编程人员来维护,我们就有了:
(2) 程序产品
另外,如果我们接受我们的程序,并且完整地定义了它的接口使得它达到预定义的规范,并且测试了它和大量的其它组件的交互作用,我们就有:
(3) 程序系统组件
并且如果我们都做了(加上文档、通用化代码、编写测**例、使得代码可维护、定义了接口、测试了交互作用),我们就有:
(4) 程序系统产品组件
Brooks用手边的三倍规则说明在上述每个步骤中的工作要求:
(2) =3倍(1)的人力
(3) =3倍(1)的人力 (4)=9倍(1)的人力
或者,换句话说,开发一个独立的程序仅仅要求开发一个程序系统组件的1/9的人力。
回到Microsoft的例子,如果我们将这个9倍的因子乘以1,400行每程序员年的生产力测量,我们得到12,600行每程序员年(举例来说,假设我们掌握每一程序员,并且使得他们独立工作,堆砌在单一的程序上)。在一篇独立的随笔中,Brooks引用一个发现这点的经理的话说,平均他的每个程序员仅能将他的一半时间用于开发――其它时间由文书工作、会议和各种其它任务所占据。把这些因素考虑到Microsoft的例子中,我们达到了25,200行每程序员年。那么,Microsoft的程序员开始看来非常可敬。另一个测量自1975年来有了很小的改变,Brooks引用的估计是1,000行每程序员年。如果上面引用的1,400行每程序员年是**的,那么,它表现了在1975年到1995年20年间,生产力仅仅提升了1.75%每年。这个结果证实了Brooks的另一个假定——程序员的生产力相对是个常量,它不受开发所用的语言的影响。因此,实际的生产力收获来自于迁移到**语言编程,这些语言每行表达了更多的实际工作。尽管目标是大系统项目,Brooks的解释常常被广泛的应用。例如,这个**篇随笔用标有“手艺的快乐”和“手艺的悲哀”的小节来结束。在悲哀中,他讨论了荒废的问题:
“…这个人们已经工作了很长时间的产品,显然在完成前将被废弃。同事和竞争者已经在热烈地用新的和更好的主意反击。人们的孩童般想法的取代已经不仅仅在构思,而且付诸时间表。这一切总是似乎比它的实际更糟糕。新的和更好的想法通常在完成之前不被应用;它仅仅被谈论。真老虎永远不能和纸老虎相比。”
小结
Brooks的随笔涉及到了大系统编程所固有的多种挑战,但对任何投身于软件开发的人来说读这本书都是有用的。题名的随笔(《人月神话》)讨论了许多编程任务的不可分割性,和为什么增加人力到软件项目中无法产生效用。我的另一篇*爱是“**、民主和系统设计”(概念完整性的讨论)和“计划和投放之路”(在付运前多次交付的明确计划的益处)。一些问题已经因为技术的进步而废弃,例如关于如何在一个大型团队中分发写好的文档。然而,你可能惊讶Brooks面对的许多问题今天如何阻止我们。另外的益处是Brooks简洁、清晰的作品读起来令人愉快。如果你是个程序员,如果你和程序员一起工作,如果你管理程序员,你应该阅读这本书。 “又见人月神话 重温软工经典”
1.软件领域****,32年之后依旧畅销不衰的传奇经典!
2.软件开发人员、软件项目经理、系统分析师必读的一本书!