人月神话(32周年中文纪念版) The Mythical Man-Month 有更新!

  Bob

基本信息

  • 原书名:The Mythical Man-Month: The Essays on Software Engineering, 2nd ed
  • 原出版社: Addison-Wesley Professional
  • 作者: (美)弗雷德里克.布鲁克斯   
  • 译者: UMLChian翻译组 汪颖
  • 出版社:清华大学出版社
  • ISBN:9787302155676
  • 上架时间:2007-8-27
  • 出版日期:2007 年9月
  • 开本:16开
  • 页码:315
  • 版次:2-11
  • 所属分类:
    计算机 > 软件工程及软件方法学 > 软件方法/软件工程
     

编辑推荐

“又见人月神话 重温软工经典”.
1.软件领域绝无仅有,32年之后依旧畅销不衰的传奇经典!..
2.软件开发人员、软件项目经理、系统分析师必读的一本书!...

内容简介

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

作译者

Freder ick P.Brooks,Jr.曾荣获美国计算机领域最具声望的图灵奖(A.M.TURINGAWARD)桂冠。美国计算机协会(ACM)称赞他“对计算机体系结构、操作系统和软件工程作出了里程碑式的贡献”。 
  Brooks博士是北卡罗莱纳大学KENAN-FLAGLER商学院的计算机科学教授。他被认为是“IBM 360系统之父”,曾担任360系统的项目经理,以及360系统项目设计阶段的经理。凭借在此项目中的杰出贡献,他与BobEvarls和Erich BIocll在1985年荣获了美国国家技术奖(NationalMedal of TecPlnoIogy)。Brooks博士早期曾担任IBM公司stretcPl和Harvest计算机的体系结构设计师。 
  Brooks博士创立了北卡罗莱纳大学的计算机科学系,并在1964-1984年期间担任系主任。他还曾任职于美国国家科技局和国防科学技术委员会。Brooks博士目前的教学和研究方向是计算机体系结构、分子模型绘图和虚拟环境设计。 

目录

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

序言

  这是本书中唯一的一节废话。* 
  我是个书狂,积习甚深,费尽心机在软件工程、系统工程方面积累了一些书。书,在我看来当分为神品、精品和普通三等,其中神品、精品又分别有一、二和三品之分。我所收集的书中,软件工程书大都属于精品,神品只有两本,Frederick P.Brooks的这本书就属于神品之列。 
  软件作为一个行业,逐步背起了“solving the wrong problem”的名声。问题决定解决方案,这也就是说,我们一直在制造错误解决方案!这方面有大量的证据,其中最著名的是美国政府统计署(GAO)的数据:全球最大的软件消费商—— 美国军方—— 每年要花费数十亿美元购买软件,而在其所购软件中,可直接使用的只占2%,另外3%需要做一些修改,其余95%都成了Rubbish。一句话,不管这些软件是否符合需求规格,但它们显然没有满足客户的需求。面向对象技术并没有给我们带来“神奇的效应”,不管开发商如何吹嘘面向对象OO(Object-Oriented)工具是多么万能,也不管那些OO狂热者是多么毅然地前赴后继,这方面的数据从20世纪80年代以来并没有发生大的改观。 
  这实在是令我们的软件工程专家和从业人员们羞愧,因为它揭示了我们可能一开始就从根本上做错了什么!20世纪90年代中期,当软件工程一代宗师Michael Jackson(非歌坛巨星Michae Jackson)宣布他们的研究结果时,立刻在软件工程界激起了阵阵涟漪。Jackson指出,软件从业人员和方法学大师们只是简单地模仿和照搬其他学科的方法,却将最重要的方面—— 问题域—— 给忽略了。他指出,面向对象方法和结构化方法对问题域的处理没有什么大的区别,却被人们过分地用美好的词汇给美化了: 
  “...You can see the results clearly in many object-oriented modeling descriptions. Often they are accompanied by fine words about modeling the real world. But when you look closely you can see that they are really descriptions of programming objects, pure and simple. Any similarity to real-world objects, living or dead, is purely coincidental...” 
  (……从众多面向对象建模的描述中,你可以很清楚地看到这些恶果。而且它们还经常伴随着有关现实世界建模的非常美好的词汇。然而,仔细看看,你就会发现它们其实是彻头彻尾的编程对象!如果说有任何和现实世界对象相似的地方,不管是死是活,纯属巧合……) 
  回首软件工程近40年的发展,Jackson哀叹软件行业普遍缺乏专业性,充满了业余人员,“手中有个锤子,看到什么都是钉子”,谁都可以开发性命攸关的软件。 
  这就是我们面临的严峻而复杂的现实,也许您会感到震惊!然而在大师Frederick P.Brooks眼里,是那么的平静。因为早在28年前,他就在“The Mythical Man-Month”这本不朽著作中对这些内容作了深入论述。 
  这本小册子行文优美,思想博大精深,字字真言,精读之有不尽的趣味,藏之又是极珍贵的文献,名眼高人,自能鉴之。 
  前些年,一位朋友从印度归来,说此书印度极为普及,我也动起笔来,但惭愧终未成正果。汪颖兄素来勤恳,明知此翻译为“success without applause, diligence without reward”,却兢兢业业,反复琢磨,历经单调、繁琐、艰辛的劳动,终于付梓。钦佩之余随即作序共勉。 
  Dave Wang 
  SE Forum China 
  2002年3月,于深圳 
  

媒体评论

  各路英豪品评人月实践 
  软工经典再启江湖争论 
  汇集国内软件开发领域先行者们对《人月神话》中的实践及系统理论的使用经验和心得! 
  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简洁、清晰的作品读起来令人愉快。如果你是个程序员,如果你和程序员一起工作,如果你管理程序员,你应该阅读这本书。 
 

书摘

  第2章人月神话
   在众多软件项目中,缺乏合理的进度安排是造成项目滞后的最主要原因,它比其他所有因素加起来的影响还要大。导致这种灾难如此普遍的原因是什么呢?
   首先,我们对估算技术缺乏有效的研究,更加严肃地说,它反映了一种悄无声息,但并不真实的假设——一切都将运作良好。
   第二,我们采用的估算技术隐含地假设人和月可以互换,错误地将进度与工作量相互混淆。
   第三,由于对自己的估算缺乏信心,软件经理通常不会有耐心持续地估算这项工作。
   第四,对进度缺少跟踪和监督。其他工程领域中,经过验证的跟踪技术和常规监督程序,在软件工程中常常被认为是大胆的革新。
   第五,当意识到进度的偏移时,下意识(以及传统)的反应是增加人力。这就像使用汽油灭火一样,只会使事情更糟。越来越大的火势需要更多的汽油,从而进入了一场注定会导致灾难的循环。
   进度监督是另一篇论文的主题,而本文中我们将对这一问题的其他方面进行更详细的讨论。
   乐观主义
  所有的编程人员都是乐观主义者。可能是这种现代魔术特别吸引那些相信美满结局和幻想中的圣母的人;也可能是成百上千琐碎的挫折赶走了大多数人,只剩下了那些习惯上只关注结果的人;还可能仅仅因为计算机还很年轻,程序员更加年轻,而年轻人总是些乐观主义者——无论是什么样的程序,结果是勿庸置疑的:“这次它肯定会运行。”或者“我刚刚找出了最后一个错误。”
  …… 
人月神话(32周年中文纪念版).pdf

[人月神话(32周年中文纪念版).pdf]

本资料仅供个人学习参考,请勿用于商业用途,如有能力请尽量购买正版图书,也是对作者的支持。 如需下载加QQ群铂金信息技术交流群 151258054获取访问密码