书籍介绍
在软件项目管理领域中，从来没有一本书能像《人月神话》一样影响深远、弥久不衰。在本书中，Fred Brooks 将软件工程的实践和发人深思的观点融汇一炉，为每个复杂项目的管理者奉上了自己的真知灼见。本书包含的短文来自于他在IBM公司任System/360计算机系列以及其庞大的软件系统OS/360项目经理的经验。在本书第一次出版20周年之际，Brooks重新修订了他最初的观点，并为已经熟悉他作品和刚刚接触本书的广大新老读者添加了新的观点和建议。
本书新增的章节包括：
初版中所有观点的精要浓缩，这其中包括Brooks在本书第一版中的核心观点：大型编程项目和小项目在管理上的不同之处在于人员划分的困难；所以在大项目中，产品的概念完整性至关重要；要达到这样的完整性虽然艰难但也并非全无可能。
Brooks在经过了一个时代之后对上述观点的看法。
Brooks在1986年发表的经典论文“没有银弹”。
Brooks现在对于1986年提出的“在十年内是不可能有银弹出现”的断言的反思。
Frederick P. Brooks, Jr.是1999年美国计算机协会（ACM）图灵奖得主，图灵奖是计算机领域最负盛名的技术奖项。ACM协会特别盛赞了他“在计算机体系结构、操作系统和软件工程领域中里程碑式的贡献”。Brooks博士创立了美国北卡罗莱纳大学的计算机科学系，并在1964~1984年期间担任系主任。他还曾任职于美国国家科技局和国防科学技术委员会。他早期曾担任IBM公司Stretch和Harvest计算机的体系结构设计师，被认为是“IBM 360系统之父”
AI导读
核心看点
- 本书深入剖析了软件工程中‘人月’作为度量单位的谬误，明确指出人员与时间不可简单互换。向进度落后的项目增加人手，只会因沟通成本激增而让进度更加落后，这是项目管理中必须警惕的陷阱。
- 作者基于IBM System/360项目经验，强调概念完整性对系统成功至关重要。即使面临进度压力，也必须坚持由极少数人负责核心设计，以确保系统架构的一致性与简洁性，反对过度民主化的设计决策。
- 书中收录了经典论文《没有银弹》，反思了软件工程本质性困难与偶然性困难的区别。作者指出，尽管技术工具在进步，但软件开发的内在复杂性决定了短期内不可能出现能彻底解决所有问题的‘银弹’。
适合谁读
- 从事软件开发、项目管理或系统架构设计的工程师与技术人员。本书提供的关于团队组织、进度估算及设计原则的深刻见解，是规避大型项目失败风险、提升工程实践水平的必读指南。
- 对软件工程历史、计算机科学发展脉络感兴趣的研究者或学生。作为图灵奖得主的里程碑式著作，本书不仅记录了早期大型系统的开发困境，更奠定了现代软件工程伦理与方法论的基础，具有极高的学术价值。
- 希望提升逻辑思维与复杂系统管理能力的非技术背景管理者。书中关于沟通障碍、目标设定及人性弱点的分析，超越了代码层面，为理解任何复杂协作项目中的组织行为与决策偏差提供了通用视角。
读前提醒
- 请勿将本书视为具体的编程技术手册或敏捷开发教程。其价值在于宏观的项目管理哲学与系统设计伦理，读者应关注作者对人性、沟通及系统复杂性的深刻洞察，而非纠结于过时的具体技术细节。
- 书中部分观点基于上世纪70年代的集中式开发背景，与现代分布式、敏捷开发环境存在差异。建议读者结合当前技术语境批判性阅读，重点理解其底层逻辑而非照搬具体做法，避免陷入教条主义。
- 阅读时请特别注意《没有银弹》及后续反思章节。作者对技术乐观主义的冷静批判极具前瞻性，有助于读者建立对技术局限性的正确认知，避免盲目追求工具革新而忽视工程本质与团队协作的重要性。
读者共识
- 读者普遍认可本书在软件工程领域的经典地位，认为其揭示的项目管理陷阱至今仍具警示意义。尽管部分技术背景已过时，但其关于沟通成本、概念完整性及拒绝‘银弹’的核心思想，被公认为行业基石。
- 许多读者反馈初读时感到晦涩或难以完全共鸣，建议具备一定项目实战经验后再读。随着职业阅历增长，读者往往能更深刻地理解书中关于团队管理、进度估算及设计权衡的残酷现实，从而获得更大启发。
- 尽管有观点认为书中部分建议已不适应现代敏捷开发，但主流共识仍认为其精神内核永不过时。读者强调，本书不仅是技术指南，更是关于诚实、责任与专业精神的哲学读本，值得反复重读以自省。
本导读基于书籍简介、目录、原文摘录、短评和书评生成，不等同于全文精读。
精彩摘录
- "乐观主义 所有的编程人员都是乐观主义者。… “这次她肯定会运行的” “我刚刚找到了最后一个错误” 人月 第二个谬误是在估计和进度安排中使用的工作单位﹣人月。暗示着时间和人员可以相互替换。"
- "系统开发的时间安排 1／3 计划 1／6 编码 1／4 构件测试和早期系统测试 1／4 系统测试，所有构件已完成 需要特别指出的是，不为系统测试安排足够的时间简直就是一场灾难"
- "简化Brooks的法则：向进度落后的团队增加人手，只会让进度更加落后。"
- "所有的编程人员都是乐观主义者。可能是这种现代魔术特别吸引那些相信美满结局的人；也可能是成百上千琐碎的挫折赶走了大多数人，只剩下了那些习惯上只关注结果的人；还可能仅仅因为计算机还很年轻，程序员更加年轻，而年轻人总是些乐观主义者棗无论是什么样的程序，结果是勿庸置疑的：“这次它肯定会运行。”或者“我刚刚找出了最后一个错误。” 所以系统编程的进度安排背后的第一个假设是：一切都将运作良好，每一项任务仅花费它所“应该”花费的时间。 ... 正由于介质的易于驾驭，我们期待在实现过程中不会碰到困难，因此造成了乐观主义的弥漫。而我们的构思是有缺陷的，因此总会有bug。也就是说，我们的乐观主义并不应该是理所应当的"
- "成本的确随开发产品的人数和时间的不同，有着很大的变化，进度却不是如此。因此我认为用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话。它暗示着人员数量和时间是可以相互替换的。 人数和时间的互换仅仅适用于以下情况：某个任务可以分解给参与人员，并且他们之间不需要相互的交流。这在割小麦或收获棉花的工作中是可行的；而在系统编程中近乎不可能。"
- "因为软件开发本质上是一项系统工作棗错综复杂关系下的一种实践棗沟通、交流的工作量非常大，它很快会消耗任务分解所节省下来的个人时间。从而，添加更多的人手，实际上是延长了，而不是缩短了时间进度。"
- "简洁和直白来自概念的完整性。每个部分必须反映相同的原理、原则和一致的折衷机制。在语法上，每个部分应使用相同的技巧；在语义上，应具有同样的相似性。因此，易用性实际上需要设计的一致性和概念的完整性。 概念的完整性要求设计必须由一个人，或者非常少数互有默契的人员来实现。 而进度压力却要求很多人员来开发系统。有两种方法可以解决这种矛盾。第一种是仔细地区分设计方法和具体实现。第二种是前一章节讨论的、一种崭新的组件编程开发团队的方法。 对于非常大型的项目，将设计方法、体系结构方面的工作与具体实现相分离是获得概念完整性的强有力方法。 让我们考虑一下树状编程队伍，以及要使它行之有效。每棵子树必须具备的基本要素"
- "它们挣扎得越猛烈，焦油就纠缠得越紧，没有任何猛兽足够强壮或具有足够的技巧，能够挣脱束缚，它们最后都沉到了坑底。 表面上看起来好像没有任何一个单独的问题会导致困难，每个问题都能获得解决，但是当它们相互纠缠和累积在一起的时候，团队的行动就会变得越来越慢。对问题的麻烦程度，每个人似乎都会感到惊讶，并且很难看清问题的本质。不过，如果我们想解决问题，就必须试图先去了解问题。"
作者简介
Frederick P. Brooks, Jr.是1999年美国计算机协会（ACM）图灵奖得主，图灵奖是计算机领域最负盛名的技术奖项。ACM协会特别盛赞了他“在计算机体系结构、操作系统和软件工程领域中里程碑式的贡献”。Brooks博士创立了美国北卡罗莱纳大学的计算机科学系，并在1964~1984年期间担任系主任。他还曾任职于美国国家科技局和国防科学技术委员会。他早期曾担任IBM公司Stretch和Harvest计算机的体系结构设计师，被认为是“IBM 360系统之父”
目录
用户评论
软件工程里程碑之作
学习项目管理的同时练了自己的英语阅读
非常不错，BROOKS预测了未来还是限制了未来？值得我们思考
读的稀里糊涂的。。。
经典…软件工程必读
First ready is focused on product vs system and product-system.
@2018-03-02 13:55:02
可能过几年再读，收获会更大吧。
兵书
下载
收藏