人月神话(32周年中文纪念版)(附赠:人月神话.国内实战体验精华册)
基本信息
- 原书名: 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从业者。
在本书第一次出版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博士早期曾.. << 查看详细
Brooks博士是北卡罗莱纳大学KENAN-FLAGLER商学院的计算机科学教授。他被认为是“IBM 360系统之父”,曾担任360系统的项目经理,以及360系统项目设计阶段的经理。凭借在此项目中的杰出贡献,他与BobEvarls和Erich BIocll在1985年荣获了美国国家技术奖(NationalMedal of TecPlnoIogy)。Brooks博士早期曾.. << 查看详细
目录回到顶部↑
第1章 焦油坑
编程系统产品
职业的乐趣
职业的苦恼
第2章 人月神话
乐观主义
人月
系统测试
空泛的估算
重复产生的进度灾难
第3章 外科手术队伍
问题
mills的建议
如何运作
团队的扩建
第4章 贵族专制、民主政治和系统设计
概念的完整性
获得概念的完整性
贵族专制统治和民主政治
在等待时,实现人员应该做什么
编程系统产品
职业的乐趣
职业的苦恼
第2章 人月神话
乐观主义
人月
系统测试
空泛的估算
重复产生的进度灾难
第3章 外科手术队伍
问题
mills的建议
如何运作
团队的扩建
第4章 贵族专制、民主政治和系统设计
概念的完整性
获得概念的完整性
贵族专制统治和民主政治
在等待时,实现人员应该做什么
序言回到顶部↑
这是本书中唯一的一节废话。*
我是个书狂,积习甚深,费尽心机在软件工程、系统工程方面积累了一些书。书,在我看来当分为神品、精品和普通三等,其中神品、精品又分别有一、二和三品之分。我所收集的书中,软件工程书大都属于精品,神品只有两本,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月,于深圳
我是个书狂,积习甚深,费尽心机在软件工程、系统工程方面积累了一些书。书,在我看来当分为神品、精品和普通三等,其中神品、精品又分别有一、二和三品之分。我所收集的书中,软件工程书大都属于精品,神品只有两本,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。
或者
● 写一个大规模的程序系统产品远难于堆砌出单一的程序。
软工经典再启江湖争论
汇集国内软件开发领域先行者们对《人月神话》中的实践及系统理论的使用经验和心得!
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。
或者
● 写一个大规模的程序系统产品远难于堆砌出单一的程序。
书摘回到顶部↑
第2章人月神话
在众多软件项目中,缺乏合理的进度安排是造成项目滞后的最主要原因,它比其他所有因素加起来的影响还要大。导致这种灾难如此普遍的原因是什么呢?
首先,我们对估算技术缺乏有效的研究,更加严肃地说,它反映了一种悄无声息,但并不真实的假设——一切都将运作良好。
第二,我们采用的估算技术隐含地假设人和月可以互换,错误地将进度与工作量相互混淆。
第三,由于对自己的估算缺乏信心,软件经理通常不会有耐心持续地估算这项工作。
第四,对进度缺少跟踪和监督。其他工程领域中,经过验证的跟踪技术和常规监督程序,在软件工程中常常被认为是大胆的革新。
第五,当意识到进度的偏移时,下意识(以及传统)的反应是增加人力。这就像使用汽油灭火一样,只会使事情更糟。越来越大的火势需要更多的汽油,从而进入了一场注定会导致灾难的循环。
进度监督是另一篇论文的主题,而本文中我们将对这一问题的其他方面进行更详细的讨论。
乐观主义
所有的编程人员都是乐观主义者。可能是这种现代魔术特别吸引那些相信美满结局和幻想中的圣母的人;也可能是成百上千琐碎的挫折赶走了大多数人,只剩下了那些习惯上只关注结果的人;还可能仅仅因为计算机还很年轻,程序员更加年轻,而年轻人总是些乐观主义者——无论是什么样的程序,结果是勿庸置疑的:“这次它肯定会运行。”或者“我刚刚找出了最后一个错误。”
……
在众多软件项目中,缺乏合理的进度安排是造成项目滞后的最主要原因,它比其他所有因素加起来的影响还要大。导致这种灾难如此普遍的原因是什么呢?
首先,我们对估算技术缺乏有效的研究,更加严肃地说,它反映了一种悄无声息,但并不真实的假设——一切都将运作良好。
第二,我们采用的估算技术隐含地假设人和月可以互换,错误地将进度与工作量相互混淆。
第三,由于对自己的估算缺乏信心,软件经理通常不会有耐心持续地估算这项工作。
第四,对进度缺少跟踪和监督。其他工程领域中,经过验证的跟踪技术和常规监督程序,在软件工程中常常被认为是大胆的革新。
第五,当意识到进度的偏移时,下意识(以及传统)的反应是增加人力。这就像使用汽油灭火一样,只会使事情更糟。越来越大的火势需要更多的汽油,从而进入了一场注定会导致灾难的循环。
进度监督是另一篇论文的主题,而本文中我们将对这一问题的其他方面进行更详细的讨论。
乐观主义
所有的编程人员都是乐观主义者。可能是这种现代魔术特别吸引那些相信美满结局和幻想中的圣母的人;也可能是成百上千琐碎的挫折赶走了大多数人,只剩下了那些习惯上只关注结果的人;还可能仅仅因为计算机还很年轻,程序员更加年轻,而年轻人总是些乐观主义者——无论是什么样的程序,结果是勿庸置疑的:“这次它肯定会运行。”或者“我刚刚找出了最后一个错误。”
……


点击看大图







加载中...