人月神话

当前位置:首页 > 计算机网络 > 软件工程/开发项目管理 > 人月神话

出版社:清华大学出版社
出版日期:2007-9
ISBN:9787302155676
作者:弗雷德里克.布鲁克斯
页数:315页

后记

我依然记得那种向往和开心的感觉——当我在1944年8月7日读到哈佛大学Mark I型计算机研制成功的报道时——那时候我才13岁。Mark I是电子机械学上的奇迹,哈佛大学的Aiken是它的结构设计师,而IBM的工程师Clair Lake,Benjamin Durfee和FrancisHamilton是它的实现设计师。同样令人向往的是读到Vannevar Bush的1945年4月发表在亚特兰大月刊上的论文“That We May Think”的时候。在这篇论文中,他建议将大量的知识组织成超文本的网络方式,从用户的计算机上,可以跟随已有的链接,也可以跳到新的相关链接,从而实现链接之间的漫游。我对计算机的热情在1952年进一步高涨,因为得到了IBM在纽约恩迪科特的一份暑期工作。正是那次,我有了在IBM 604上编程的实际经验,也了解了如何编制IBM 701(它的第一个存储程序计算机)程序的正式指令;从哈佛大学Aiken和Iverson名下毕业终于让我的职业梦想变成了现实,并且,就这样沉迷了一辈子。感谢上帝,让我成为了为数不多的那些开开心心地做着自己喜欢的工作的人之一。我实在无法想象还有哪种生活会比热爱计算机更加激动人心,自从从真空管发展到晶体管,再到集成电路以来,计算机技术已经飞速发展。我用来工作的第一台计算机,是从哈佛刚刚出炉的IBM 7030Stretch超级计算机,Stretch在1961—1964年间都是世界上运算速度最快的计算机,一共卖出了9台。而我现在用的计算机,MacintoshPowerbook,不但快,还有大容量内存和大容量硬盘,而且便宜了1000倍(如果按定值美元来算,便宜了5000倍)。我们依次看到了计算机革命、电子计算机革命、小型计算机革命和微型计算机革命,这些技术上的革命每一次都带来了计算机数量上的剧增。在计算机技术进步的同时,计算机相关学科知识也在飞速发展。当我在20世纪50年代中期刚从学校毕业的时候,能看完当时所有的期刊和会议报告,掌握所有的潮流动向。而我现在只能对层出不穷的学科分支遗憾地说“再见”,对我所关注的东西也越来越难以全部掌握。兴趣太多,令人兴奋的学习、研究和思考的机会也太多——多么不可思议的矛盾啊!这个神奇的时代远远没有结束,它依然在飞速发展。更多的乐趣,尽在将来。

作者简介

在软件领域,很少能有像《人月神话》一样具有深远影响力和畅销不衰的著作。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年
注解与参考文献

编辑推荐

《人月神话(32周年中文纪念版)》由清华大学出版社出版。

前言

印象里,从谭浩强老师的《BASIC语言》在全国畅销,最终销量超过1200万册时,民族软件产业就承载了国人太多的期待。计算机图书出版者也与读者结下了不解之缘。人们将软件产业看作中华民族腾飞的一次历史性机遇。的确,软件产业是头脑产业,而中华民族最不缺的就是有智慧的人才。几台微机,一本指南,似乎就可以开公司编程赚线,而且可以出口赚美元。然而,20多年转瞬即逝,我们听说过很多软件英雄和编程奇才的故事,却没有产生一个有国际影响的软件品牌或有国际竞争力的民族软件企业。就在我们身边,印度的软件产业却已迅速崛起,产值10年增长了10倍,数十家企业通过了CMM5级认证,印度已经成为世界第二大软件出口国。目前,中国经济发展水平可能要领先印度10年,但中国软件产业却落后印度将近10年,原因何在?几乎所有的人都认为,软件开发是年轻人的职业。程序员们一边挥着汗水,辛苦地熬夜写代码,一边又对自己30岁以后的职业发展方向充满惶恐。实际上,我国最缺的是有10年以上经验的软件工程师。金山软件公司总裁雷军曾说过:“在印度,包括在美国,我见到的项目经理都是三四十岁的人,他们‘越老越值钱’,有些人甚至拥有超过20年的行业经验。”为什么中国的程序员总是在不断学习新的开发工具、钻研程序代码,而不能逐步提升自己的视野、思维和经验?作为出版者,我们一直关注着中国软件产业的发展,也时刻检讨着自己的责任。长期以来,在各大城市书城和计算机专业书店的书架上,很难找到几本软件管理和软件工程的图书,更多的书店里甚至根本没有软件工程图书的分类。同样在印度,软件管理的图书比比皆是,数量远远超过编程指南的图书。在全球最大的网上书店亚马逊网站上,软件管理和软件工程方面的图书也是门类清晰,为数众多。对这种强烈反差长期的漠视,也许正是我们出版者的责任。于是,在2001年的秋季,我们在一个月的时间内,走访了软件行业中的各大专业媒体、网站、院校和企业,与50多位业界专家进行了交流和沟通,最终确定了引进出版一套国外软件管理和软件工程经典图书的设想,希望借此能将国外成熟先进的软件管理思想和管理经验系统引进到国内,从而推动中国的软件产业的发展,对广大软件工程师的成长和素质提升有所帮助。我们相信,中国软件产业的繁荣和发展,不仅有赖于国家产业政策的支持,还有赖于从业者管理理念的突破和管理思想的普及,更有赖于软件产业中有人文精神的优秀人才的涌现和具有核心竞争力的优秀企业的诞生。经过将近一年的努力,在业界许多专家的支持下,我们抱着宁缺毋滥的想法,将国外软件管理和软件工程的经典图书完整地筛选了一遍后,选定了几本精品,其中的每一本均是相关领域中最经典或最具代表性的作品,有的书曾在国外屡获大奖;有的书已经出版20年,却仍然畅销不衰,而这本《人月神话》在其出版的25年后我们仍然极力推荐,因为它确实是软件管理工程图书中的极品,值得一版再版。在本书引进和出版的过程中,我们得到了《IT经理世界》、《程序员》杂志、UMLcllina网站等机构和众多业界专家学者的真诚理解和大力支持,在此向他们一并致以衷心的感谢。2007年6月

内容概要

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博士目前的教学和研究方向是计算机体系结构、分子模型绘图和虚拟环境设计。

章节摘录

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

图书封面


 人月神话下载 精选章节试读 更多精彩书评



发布书评

 
 


精彩书评 (总计22条)

  •     文档P169不同的用户需要不同级别的文档1.目的:主要的功能是什么?开发程序的原因是什么?2.环境:程序运行在什么样的机器,硬件配置和操作系统上?3.范围:输入的有效范围是什么?允许显示的合法输出范围是什么?4.实现功能和使用算法。精确地描述它做了什么。5.输入-输出格式。必须是确切和完整的6.操作指令。包括控制台及输出内容中正常和异常结束的行为。7.选项。用户的功能选项有哪些?如何在选项之间进行挑选8.运行时间。在指定的配置下,解决特定规模问题所需要的时间?9.精度和校验。期望结果的精确程度?如何进行精度的检测?
  •     摘抄整理《人月神话》中的一些方法论。一、需求:required document 中要写空间预算、测试用例二、开发:关注质量,生产力自然会提高三、测试:每修复一个bug,就有有20%-50%引入新bug四、组织/管理:1.排期:准确时间 ~ 估算的时间*22. 项目必备要素- 任务需求细分- 产品负责人(主管左右手)- 技术负责人(主管)- 进度表- 分工- 接口定义3. 组织结构与交流结构:组织是树状的,但交流是网状的4. 培养优秀人才的方法- 指派职业导师,负责技术成长和职业生涯规划- 安排学习计划- 提供交流和激励机会5. 建议草案要在会议之前就有,并且发放6. 大型项目排期每两周进行一次计划日期的修订http://hi.baidu.com/xizhicat/blog/item/3f15b6321f8495f515cecb8c.html
  •     概念的完整性的确需要系统只反映唯一的设计理念,用户所见的技术说明来自少数人的思想。外科手术队伍,外科医生和副手了解所有的设计和全部的代码。上下级关系可以达到可观的一致性。让200人去解决问题,仅仅需要协调20个外科医生。人月神话的骗局。开发中人力与时间的关系,他们并不是简单的对等的,而是一个更加复杂的函数。如何避免第二个系统所引起的后果,从而避免画蛇添足?运用特别的自我约束准则,来避免哪些功能上的过于修饰,根据系统基本理念及目的变更,舍弃一些功能。手册的重要性:绝不要携带两个时钟出海,带一个或三个。程序维护中的一个基本问题是缺陷修复总会以固定(20%-50%)的几率引入新的bug。整个过程是前进两步,后退一步。文档的重要性,遇到问题记下来,有记录,分歧才会明朗,矛盾才会突出。概念完整性。一个整洁、优雅的编程产品必须向它的每个用户提供一个条理分明的概念模型,这个模型描述了应用、实现应用的方法以及用来指明操作和各种参数的用户界面使用策略,。用户所感受到的产品概念完整性是易用性中最重要的因素。结构师。结构师负责产品所有方面的概念完整性,这些是用户能实际感受到的。结构师开发用于向用户解释使用的产品概念模型,概念模型包括所有功能的详细说明以及调用和控制的方法。结构师是这些模型的所有者,同时也是用户的代理。在不可避免地对功能、性能、规模、成本和进度进行平衡时,卓有成效地体现用户的利益。这个角色是全职工作,只有在最小的团队中,才能和团队经理的角色合并。结构师就像电影的导演,而经理类似于制片人。将体系结构和设计实现、物理实现相分离。为了使结构师的关键任务更加可行,有必要将用户所感知的产品定义棗体系结构,与它的实现相分离。体系结构和实现的划分在各个设计任务中形成了清晰的边界,边界两边都有大量的工作。人月神话介绍软件工程应该注意的问题,比如团队组织,空间、银弹——开发技术,时间日程表等等。初出茅庐的菜鸟读起来压力很大。

精彩短评 (总计72条)

  •     pass
  •     其实内容还是不错的,毕竟是40年前的书,有些过时在所难免。
  •     用的例子都有点太老了,不过核心的人月不可估算的观点还是值得一看。
  •     今天拿到书,那纸张的感觉像是买了盗版。
  •     多年之前有个故事是这样说的:"如果我被困在一个荒岛上,只能带一本电脑书",他们问,"应该是哪一本?" 这问题很荒谬;答案也简洁明了:The Mythical Man-Month; 作为图灵奖获得者,Brooks博士的这本著作从第一版到今天的32周年纪念版几乎每一版都脱销,并不是因为它多么多么著名,而是它实实在在的描述了软件工程的概念,这种概念放到现在也毫不过失。有人说这是一本普通的IT类Textbook,还有有人说这是一本纪传体式的自传,甚至有人认为这是一本哲学书,我的看法这是一本从概念化,逻辑化,哲学化讲述软件工程的集大成于一体的经典读物,我看过它的英文版,可能有些句义相当晦涩,但不妨碍读者的研究。一言以蔽之,把这本书无责任推荐给所有的软件,IT爱好者和专业人士!
  •     软工实践前于理论;以前做项目对测试不够重视;不是加人就能搞快;现在的工具很丰富。跟很流行的敏捷也不矛盾
  •     为什么没有银弹?
  •     感觉还是有些过时了,虽然系统且稳固但比现在的软件开发节奏要慢。但是想到这本书是在80年代写成,就觉得很了不起了
  •     书里讨论了很多软件工程中的问题,很多事情都很有共鸣,这些问题被大家讨论了几十年,但是为什么现在这么多的团队还是做不好?现在还对书里提到的外科医生团队记忆犹新,希望以后可以有机会尝试。
  •     值得研读,还是原版好些
  •     很好看的故事书
  •     书本质量糊弄人吧 忽悠
  •     在合适的时间读到合适的书是一种幸运,有限的读书经验使我认为很多事情必有实际经历才能产生更深的理解与共鸣。本书中关于项目复杂度、规划的乐观性、沟通重要性、组织的形式和冲突、任务执行的关键、 文档的作用和构成以及其在不同阶段的角色,都深有感触。仅将此书推荐给软件工程的项目管理者实在是浪费,应该给更广泛的复杂系统开发管理者。#原来此书和Project Apollo并没有一毛钱关系,火车上六小时看完#
  •     大作应该不错
  •     在大公司做了一段时间的软件工程,慢慢的也会有很多感触、思考,怎么把这么大的一个项目做好?把上上下下,左左右右的关系处理妥帖?难道我们在学校所理想的,在书本上学到的软件工程就是这样吗?带着很多思考和疑问,读了这本书。应该说它虽然没有回答我所有的疑问,但是给我很多帮助,暗示了未来道路上可能的陷阱。绝对值得一读!远远比很多讲软件工程的书更加实用。
  •     好多年前读过。很经典。
  •     大学时候在工作室读过,很棒的项目管理的理念(一言以蔽之,我们理想的工作状态是有标准的效率,以 人/月 为单位)。人家十几年前就有这样的团队观,反思反思啊。
  •     看过。。无用
  •     从常年的兴趣到不小心踏入IT的项目管理,进入的是全新而陌生的世界。除了交对朋友,我信奉找本好书来辅助我的行业角色导入。希望这一次我没有失望!
  •     我怎么读?
  •     内容应该是比较经典,毋容置疑。买的时候有两本,竟然送了一本。
  •     非常好,以前看的电子版,不太方便。买一本来备着,随时想看随时看。
  •     适合我当前的状态,科普入门用
  •     前面17章读下来感受是有的过时,但考虑到是几十年前的书,还是很佩服!18章之后是多年后的回顾,非常有价值,还顺手推荐了《人件》
  •     翻译得不是很好,但是内容不错的。
  •     圣经
  •     很快翻完了,几个点是颇为经典的。
  •     一方面年代比较古老了,虽然思想上很有指导性,但是有些举例已经不适用了。另一方面,更适合于码农来看,并不适合我……
  •     非常好,虽然有些东西,在当下并不一定适合,但是还是很有借鉴意义
  •     纸质差,第一页“策划人语”就有错别字
  •     站的高,看的远。经验加上学术研究让作者非常有洞见。印象最深的有很多,不过最重要的大概是作者不断强调的——事实上这本书更在意人,而不是技术。这本书的启发性也更多地表现在管理技术上。对他人的以及对自己的。
  •     经典。少一星是因为翻译略有生硬。
  •     和《黑客与画家》一样令人佩服,作者将其他行业的特性与软件行业做对比再说明观点,知识面很广,见解也很深刻
  •     非常经典的一本书,很喜欢
  •     如果你的老板对你说时间不够,我给你加人时,请送这本书给他。一个人在沙漠荒岛上,仅允许带一本计算机书时,首推此书。里面谈及的软件和各类工具是略显陈旧,但其核心内容却是关于人与团队,这在人类社会中却是亘古不变的,软件开发只是顺带提及。必须要看看英文原版。
  •     不太好读,而且年代久远。中途放弃了。
  •     确实经得起时间考验的项目管理书籍,终于知道人月神话的意思了
  •     一本写于上世纪七十年代的著作,在今天仍然能够切实指导你的工程实践,这在发展日新月异的计算机领域是多么令人震撼啊,而《人月神话》就是这样不多的几本书之一。目前我们在开发中遇到的许多问题在该书都进行了深入的分析,给人以很大的启发。而且该书写得很平实,文字也很优美,非常值得大家阅读。
  •     没有银弹啊!
  •     大概浏览了几章,感觉真心没有大家说的那么好,或许是自身实力不够或者说是视野不够,本人毕业半年,从业1年,完全抓不住这本书的头绪,还不如"Joe谈软件"好.
  •     没什么大项目经历,所以也只能体会到一些,但多多少少能从中了解到大工程中遇到的一些问题。
  •     经典~计算机大神之作!~~计算机专业人员必读读物~~
  •     不好理解
  •     我看的是40周年纪念版哦。 交流是很大的开发成本,应该尽量减少且高效; 预估时间的方法,提前计划以及测试做好的比重; 快速模型,增量开发; 软件开发的主要困难在于控制复杂度,没有银弹。
  •     这是管理圣经啊!原来的书丢了
  •     已经40年的书了,但是确实还有很多观点非常的有前瞻性,而且对于项目管理还是有很多可以借鉴的地方。读的时候粗看了很多已经过时的技术描述,可能以后有空会再回来读一遍。
  •     书的质量不太好!纸张很糙很薄
  •     书还没有看,听同事说挺好的
  •     人月是危险和带有欺骗性的神话,因为它暗示人员数量和时间是可以相互替换的。项目进度的偏离通常来自白蚁的肆虐,而不是龙卷风的侵袭。项目进度通常以一种难以察觉,但是残酷无情的方式慢慢落后。//一开始我还以为是人和月亮的神话故事……智障如我……
  •     软件开发中,高质量,高效率沟通非常重要,项目越大,沟通的成本越高。软件架构要有概念完整性,保证整体设计的方向。软件工程的复杂性是主要难题
  •     说到底编码只是通往最终概念的一种实现。所需要完善这个概念所耗费的时间和沟通的精力才是最大的。
  •     this book is good! 还没开始看
  •     每次读都觉得很有收获,非常值得收藏,反复阅读。
  •     有些内容已经过时了,但在今天仍然很有惊醒意义。推荐有一定项目经验后阅读。
  •     回头估计需要再看一遍,现在做大项目的经验太少。
  •     设计和实践不是瀑布式而是增量式。这本书不仅仅是项目管理,更是如何思考实践和思考软件工程的书!如何把一系列程序设计和构建成系统,如何把程序或者系统设计成健壮的、经过测试的、文档化的、可支持的产品,如何维持对大量的复杂性的控制。P176大多数成功的第4代语言是以选项和参数方式系统化某个应用领域的结果。概念完整性。一个整洁、优雅的编程产品必须向它的每个用户提供一个条理分明的概念模型,这个模型描述了应用、实现应用的方法以及用来指明操作和各种参数的用户界面使用策略.化学工程和软件工程的相通之处!
  •     在我看来是神书,讲了很多软件开发及管理方面的建议。 然而我看到的版本太烂了。为自己的英语悲哀!
  •     该书可以告诉你如何估算开发进度
  •     讨论了软件工程的常识,破除了人月互换的主观臆断。明确了软件开发中的主要问题和次要问题,建立了提高效率的方法次序。
  •     重读经典。
  •     管理,芭比他的修建,关系,类比于婚姻关系,上帝对夫妻的规定,预测,了解过去,预知未来,但不能规划。了解need和want。工作目的,实现功能。愿神得荣耀
  •     像盗版,翻译一般 ,纸质不怎么样。体会不到书评中说的滋味
  •     开头那部分看到的一个方形图,右侧和下测的格子是三倍时间,右下角是九倍时间,正赶上之前写的几个开源的库,深深赞同,由于做的不是系统级别的东西,但三倍时间真是保守估算。再想想仅仅在内部使用的项目里写的小功能,一倍时间出来的东西,实在不靠谱。
  •     讲软件工程
  •     经典书籍,值得你看看!
  •     没什么好说的,软件工程领域的经典名著,你值得拥有。
  •     文轩新华书店你出版书的纸张能好点吗,背面的字都可以看得清。。我嘞个去了~~~~这书被这个 出版社坑了~~~
  •     借用序作者的话“书,在我看来当分为神品、精品和普通三等,我所收集的书中,Frederick P. Brooks的这本书就属于神品之列。” 准备通读第二遍,不得不再次承认:IBM—— 一个伟大的公司。 感谢厚坤的推荐,让我接触到更多”程序员的世界“
  •     我想读本书最大的乐趣在于在书中能找到一些想法上的共鸣,理论更深层次的内化最终还是来源于实践。这本书也许对我来说来的太早了,内容太理论,收获不是很大,期待经验更丰富后能理解更多
  •     拿到现在看也还算有点意思。
  •     40年了,这本书值得读的差不多只有一半了
  •     难得还这么有借鉴意义 历经时间而未褪色分毫
 

农业基础科学,时尚,美术/书法,绘画,软件工程/开发项目管理,研究生/本专科,爱情/情感,动漫学堂PDF下载,。 PDF下载网 

PDF下载网 @ 2024