人月神话

[美] 弗雷德里克·布鲁克斯

出版时间

2002-11-01

ISBN

9787302059325

评分

★★★★★
书籍介绍
作者为人们管理复杂项目提供了颇具洞察力的见解,既有很多发人深省的观点,也有大量的软件工程实践。书中的内容来自布鲁克斯在IBM公司System 360家族和OS 360中的项目管理经验。初版的20年后,布鲁克斯重新审视了他原先的观点,增加了一些新的想法和建议。新增加的章节包括:原著中一些核心观点的精华;在经过了一个时代以后,Brooks博士对原先观点新的认识;1986年的经典文章《没有银弹》;对1986年所下论断(在10年内不会出现银弹)现在的认识。
AI导读
核心看点
  • 提出布鲁克斯法则:向落后项目加人只会更慢
  • 强调概念完整性,主张外科手术式团队结构
  • 收录经典文章《没有银弹》,探讨本质困难
适合谁读
  • 软件工程师及项目经理,需具备一定实战经验
  • 对软件工程历史及大型系统开发感兴趣的读者
  • 希望深入理解团队协作与沟通成本的从业者
读前提醒
  • 若无项目管理经验,可能觉得内容抽象难懂
  • 部分观点基于传统大型项目,需结合敏捷思考
  • 注意区分书中设计原则与具体实现技术的差异
读者共识
  • 软件工程领域的必读经典,地位无可撼动
  • 核心观点历经时间考验,至今仍具指导意义
  • 翻译质量参差不齐,建议有基础者阅读

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

精彩摘录
  • "乐观主义 所有的编程人员都是乐观主义者。… “这次她肯定会运行的” “我刚刚找到了最后一个错误” 人月 第二个谬误是在估计和进度安排中使用的工作单位﹣人月。暗示着时间和人员可以相互替换。"
  • "系统开发的时间安排 1/3 计划 1/6 编码 1/4 构件测试和早期系统测试 1/4 系统测试,所有构件已完成 需要特别指出的是,不为系统测试安排足够的时间简直就是一场灾难"
  • "简化Brooks的法则:向进度落后的团队增加人手,只会让进度更加落后。"
  • "所有的编程人员都是乐观主义者。可能是这种现代魔术特别吸引那些相信美满结局的人;也可能是成百上千琐碎的挫折赶走了大多数人,只剩下了那些习惯上只关注结果的人;还可能仅仅因为计算机还很年轻,程序员更加年轻,而年轻人总是些乐观主义者棗无论是什么样的程序,结果是勿庸置疑的:“这次它肯定会运行。”或者“我刚刚找出了最后一个错误。” 所以系统编程的进度安排背后的第一个假设是:一切都将运作良好,每一项任务仅花费它所“应该”花费的时间。 ... 正由于介质的易于驾驭,我们期待在实现过程中不会碰到困难,因此造成了乐观主义的弥漫。而我们的构思是有缺陷的,因此总会有bug。也就是说,我们的乐观主义并不应该是理所应当的"
  • "成本的确随开发产品的人数和时间的不同,有着很大的变化,进度却不是如此。因此我认为用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话。它暗示着人员数量和时间是可以相互替换的。 人数和时间的互换仅仅适用于以下情况:某个任务可以分解给参与人员,并且他们之间不需要相互的交流。这在割小麦或收获棉花的工作中是可行的;而在系统编程中近乎不可能。"
  • "因为软件开发本质上是一项系统工作棗错综复杂关系下的一种实践棗沟通、交流的工作量非常大,它很快会消耗任务分解所节省下来的个人时间。从而,添加更多的人手,实际上是延长了,而不是缩短了时间进度。"
  • "简洁和直白来自概念的完整性。每个部分必须反映相同的原理、原则和一致的折衷机制。在语法上,每个部分应使用相同的技巧;在语义上,应具有同样的相似性。因此,易用性实际上需要设计的一致性和概念的完整性。 概念的完整性要求设计必须由一个人,或者非常少数互有默契的人员来实现。 而进度压力却要求很多人员来开发系统。有两种方法可以解决这种矛盾。第一种是仔细地区分设计方法和具体实现。第二种是前一章节讨论的、一种崭新的组件编程开发团队的方法。 对于非常大型的项目,将设计方法、体系结构方面的工作与具体实现相分离是获得概念完整性的强有力方法。 让我们考虑一下树状编程队伍,以及要使它行之有效。每棵子树必须具备的基本要素"
  • "它们挣扎得越猛烈,焦油就纠缠得越紧,没有任何猛兽足够强壮或具有足够的技巧,能够挣脱束缚,它们最后都沉到了坑底。 表面上看起来好像没有任何一个单独的问题会导致困难,每个问题都能获得解决,但是当它们相互纠缠和累积在一起的时候,团队的行动就会变得越来越慢。对问题的麻烦程度,每个人似乎都会感到惊讶,并且很难看清问题的本质。不过,如果我们想解决问题,就必须试图先去了解问题。"
作者简介
弗雷德里克·布鲁克斯(Frederick P. Brooks, Jr.)是北卡罗莱纳大学Kenan-Flagler商学院的计算机科学教授。他曾荣获图灵奖,美国计算机协会(ACM)称赞他“对计算机体系结构、操作系统和软件工程做出了里程碑式的贡献。” 布鲁克斯被认为是IBM 360系统之父,他曾担任360系统的项目经理、360操作系统项目设计阶段的经理。因在这两个项目中的杰出贡献,布鲁克斯和Bob Evans、Erich Bloch在1985年获得美国国家技术奖(National Medal of Technology)。布鲁克斯早期还曾担任IBM公司Stretch和Harvest计算机的体系结构设计师。布鲁克斯创立了北卡罗莱纳大学的计算机科学系,在1964-1984年期间担任系主任。他还曾任职于美国国家科技局和国防科学技术委员会。他目前的教学和研究方向是计算机体系结构、分子模型绘图和虚拟环境设计。 UMLChina翻译组的成员汪颖(Adams Wang)翻译了这本《人月神话》。UMLChina是中文世界访问量最大的软件工程网站。译者汪颖毕业于华中理工大学,从事软件开发以及流程改进方面的工作。
用户评论
放弃了……
比较久远了,标记一下。
作者提倡外科手术式的团队组织,感觉挺好,但是这在现实还是比较难实现的。因为在中国所有人的想法都是,程序员是青春饭,熬了几年转行或是管理,总之,脱离编码。。
本书自第一版以来,畅销20余年不衰,是软件领域绝无仅有的必读经典。
值得以后没事就翻翻的书。
一般般,名不副实
在飞机上看完了最后几章。虽然很多内容特别旧,但是还是有很多可以借鉴的地方,作为日常工作场景的汇总 1. 文档:通过文档及核心文档有效传达信息和追踪进度。核心文档是项目经理管理进度最好的方式 2. Milestone: 合理及明确的时间线及里程碑式帮助团队向目标前进的最有效的方法。milestone不能模糊,一定是要以所有人不需要过多交流就能align的东西,以防止自欺欺人式的milestone accomplishment 3. 外科手术团队与贯彻执行:核心设计和思想由一两个人控制,这样让整个团队向同一个方向前进 4. 画蛇添足与整体部分:第二个系统会大概率遇到 over design; 在系统上的每一次修补都会有概率造成系统的新问题,也会break 本来的设计与边界
于我的价值是三颗🌟
过来人的经验之谈
早年读过,影响我一生工作。“不误飞机的最好方法是早动身”。
下载
收藏