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