人月神话(40周年中文纪念版)

(美) 布鲁克斯(Brooks, F. P.) 著

出版时间

2015-03-31

ISBN

9787302392644

评分

★★★★★
书籍介绍
在软件领域,很少能有像《人月神话》一样具有深远影响力和畅销不衰的著作。Brooks博士为人们管理复杂项目提供了最具洞察力的见解,既有很多发人深省的观点,又有大量软件工程的实践。本书内容来自Brooks博士在IBM公司SYSTEM/360家族和OS/360中的项目管理经验,该项目堪称软件开发项目管理的典范。该书英文原版一经面世,即引起业内人士的强烈反响,后又译为德、法、日、俄、中、韩等多种文字,全球销售数百万册。确立了其在行业内的经典地位。 在本书第一次出版40年后的今天,我们重新整理了Brooks博士的经典内容,并将国内软件开发领域先行者们对《人月神话》中的实践及系统理论的使用经验和心得集结成册免费赠与大家共享,更使本书成为国内从业者的必读经典之一。 本书读者包括:软件开发人员、软件项目经理、系统分析师等IT从业者。
AI导读
核心看点
  • 揭示向落后项目加人只会更落后的反直觉规律
  • 强调概念完整性,主张由少数人主导系统设计
  • 提出外科手术式团队模式,优化沟通与协作效率
适合谁读
  • 软件项目经理及系统分析师等IT从业者
  • 对软件工程历史与经典理论感兴趣的读者
  • 希望提升团队协作与项目管理能力的开发者
读前提醒
  • 部分技术细节已显陈旧,需结合现代语境理解
  • 建议配合《大教堂与集市》对比阅读以获新知
  • 关注管理哲学与人性洞察,而非具体代码实现
读者共识
  • 虽出版四十载,核心管理洞见至今仍具指导意义
  • 部分读者认为翻译质量欠佳,影响阅读体验
  • 非专业人士可能觉得内容晦涩,但仍有启发

本导读基于书籍简介、目录、原文摘录、短评和书评生成,不等同于全文精读。

精彩摘录
  • "乐观主义 所有的编程人员都是乐观主义者。… “这次她肯定会运行的” “我刚刚找到了最后一个错误” 人月 第二个谬误是在估计和进度安排中使用的工作单位﹣人月。暗示着时间和人员可以相互替换。"
  • "系统开发的时间安排 1/3 计划 1/6 编码 1/4 构件测试和早期系统测试 1/4 系统测试,所有构件已完成 需要特别指出的是,不为系统测试安排足够的时间简直就是一场灾难"
  • "简化Brooks的法则:向进度落后的团队增加人手,只会让进度更加落后。"
  • "所有的编程人员都是乐观主义者。可能是这种现代魔术特别吸引那些相信美满结局的人;也可能是成百上千琐碎的挫折赶走了大多数人,只剩下了那些习惯上只关注结果的人;还可能仅仅因为计算机还很年轻,程序员更加年轻,而年轻人总是些乐观主义者棗无论是什么样的程序,结果是勿庸置疑的:“这次它肯定会运行。”或者“我刚刚找出了最后一个错误。” 所以系统编程的进度安排背后的第一个假设是:一切都将运作良好,每一项任务仅花费它所“应该”花费的时间。 ... 正由于介质的易于驾驭,我们期待在实现过程中不会碰到困难,因此造成了乐观主义的弥漫。而我们的构思是有缺陷的,因此总会有bug。也就是说,我们的乐观主义并不应该是理所应当的"
  • "成本的确随开发产品的人数和时间的不同,有着很大的变化,进度却不是如此。因此我认为用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话。它暗示着人员数量和时间是可以相互替换的。 人数和时间的互换仅仅适用于以下情况:某个任务可以分解给参与人员,并且他们之间不需要相互的交流。这在割小麦或收获棉花的工作中是可行的;而在系统编程中近乎不可能。"
  • "因为软件开发本质上是一项系统工作棗错综复杂关系下的一种实践棗沟通、交流的工作量非常大,它很快会消耗任务分解所节省下来的个人时间。从而,添加更多的人手,实际上是延长了,而不是缩短了时间进度。"
  • "简洁和直白来自概念的完整性。每个部分必须反映相同的原理、原则和一致的折衷机制。在语法上,每个部分应使用相同的技巧;在语义上,应具有同样的相似性。因此,易用性实际上需要设计的一致性和概念的完整性。 概念的完整性要求设计必须由一个人,或者非常少数互有默契的人员来实现。 而进度压力却要求很多人员来开发系统。有两种方法可以解决这种矛盾。第一种是仔细地区分设计方法和具体实现。第二种是前一章节讨论的、一种崭新的组件编程开发团队的方法。 对于非常大型的项目,将设计方法、体系结构方面的工作与具体实现相分离是获得概念完整性的强有力方法。 让我们考虑一下树状编程队伍,以及要使它行之有效。每棵子树必须具备的基本要素"
  • "它们挣扎得越猛烈,焦油就纠缠得越紧,没有任何猛兽足够强壮或具有足够的技巧,能够挣脱束缚,它们最后都沉到了坑底。 表面上看起来好像没有任何一个单独的问题会导致困难,每个问题都能获得解决,但是当它们相互纠缠和累积在一起的时候,团队的行动就会变得越来越慢。对问题的麻烦程度,每个人似乎都会感到惊讶,并且很难看清问题的本质。不过,如果我们想解决问题,就必须试图先去了解问题。"
作者简介
小弗雷德里克•布鲁克斯曾获得美国计算机领域最具声望的图灵奖(A. M. Turing Award)。美国计算机协会(ACM)称赞他“对计算机体系结构、操作系统和软件工程做出了里程碑式的贡献”。 布鲁克斯博士1956年开始任职于IBM公司,早期担任Stretch 和Harvest计算机的体系建构师。他被认为是“IBM 360系统之父”,曾担任360系统的项目经理。凭借在此项目中的杰出贡献,他与Bob Evans和Erich Bloch在1985年获得了美国国家技术奖(National Medal of Technology)。 布鲁克斯博士创立了北卡罗来纳大学的计算机科学系,并于1965-1985年担任系主任。他还曾任职于美国国家科技局和国防科学技术委员会。目前其仍活跃于从事虚拟环境和科学可视化等方面的研究工作,2010年获得虚拟现实事业奖(IEEE Virtual Reality Career Award)。
目录
第1章 焦油坑 1
编程系统产品 4
职业的乐趣 6
职业的苦恼 8
第2章 人月神话 11

显示全部
用户评论
3.5星,有点啰嗦了
1
配合《大教堂与集市》阅读。
本书说明了一个软件工程领域的一个道理,人员投入和时间人月不一定成线性关系,虽然其中有些内容已经过时,但很多内容在当今软件开发领域仍然有指导意义。
巴别塔寓言:组织/合作,是交流的结果;即人力(人)和时间(月)之间的平衡远不是线性关系,使用人月作为生产率的衡量标准实际是一个神话。
读完没有太多的共鸣和感触,可能是自己功力还不够,没有管理大型项目的经验。几年后再拿出来读,可能会有更深的体会。
书中很多观点都逐渐演变成了本世纪软件开发的各个要点,老爷子当年的思考很有前瞻性,不过这书里例子大多是微机时代的,不具有参考性,整体读下来感觉离现在很远&翻译稀烂。备忘:1. 向项目单纯地增加人力不能线性提高团队工作效率,反而可能因为引入了更高的沟通成本导致效率的降低;2. 体系结构设计和实现分开进行(现在常说的面向接口编程);3. 软件系统演进是熵增的过程,终有一天系统需要推到重来,各种优化手段只是延缓了这一天的到来;4. 软件开发更像早期化学这种经验科学而非物理数学这类精密科学; 5. 软件开发复杂度来源于主要方面(对实体世界建模的思考过程,DDD的目标)和次要方面(将思考具化为可执行代码的过程,高级语言、设计模式、重用代码库等),「没有银弹」指的是没有解决主要方面的灵丹妙药,而非次要方面
简洁经典
我们现在面临的实际问题在几十年前已经被发现、定性、分析,书中的一些例子是以操作系统开发为背景的,不太好理解。在敏捷时代,跟在几十年前软件开发面临的都是同样的问题,即规模、效率、质量。不知道是因为经典书籍语言过于简练,还是翻译的问题,正文读起来很费劲。前七章比较好理解,第十八章总结很重要,附录部分感觉更接地气。
软件入门必读,确实是神书。项目上模糊的不爽感在书里好像都发现了答案。
下载
收藏