![人月神话（英文版） - [美] Frederick P. Brooks, Jr.](https://static.book345.com/covers/s/9787115232687.jpg)
书籍介绍
这不是一本教你如何排期、分派任务、填表的软件工程手册，而是一本让无数项目经理在踩坑后拍腿叹息的反思录。作者Brooks用System/360的惨痛教训换来的核心洞见至今锋利：向进度落后的团队加人，只会让它更慢；
作者简介
Frederick P. Brooks, Jr. 1931年4月19日出生于美国北卡罗来纳州Durham，1953年毕业于杜克大学，1956年获得哈佛大学应用数学博士学位，同年加入IBM公司。他领导了IBM System/360及其操作系统OS/360的开发，被誉为“IBM 360系统之父”，“计算机体系结构”一词即由他首先提出。1964年他离开IBM，创建了北卡罗来纳大学计算机科学系，担任系主任长达20年。1975年，他出版了著名的《人月神话》，探讨软件工程的管理问题。1986年，他发表了经典论文《没有银弹》（本书已收录）。1994年被选为ACM院士。
AI导读
核心看点
- 本书核心揭露了‘人月神话’的谬误，即人员与时间不可互换。作者基于IBM System/360项目经验指出，软件开发涉及复杂沟通，增加人手反而因交流成本激增导致进度更慢。这一观点颠覆了传统管理直觉，强调了任务分解与独立性的极限，是理解软件工程本质的基石。
- 书中提出‘外科手术式团队’概念，强调系统设计的概念完整性至关重要。作者主张由少数默契人员负责核心设计，严格区分设计与实现，以对抗进度压力带来的混乱。同时警告‘第二系统效应’，即开发者易在首个系统成功后过度设计，导致项目失控，需保持克制与简洁。
- 作者深刻剖析了软件开发的‘焦油坑’困境，指出追求完美、外部目标设定及技术过时是主要痛苦来源。书中强调无‘银弹’可彻底解决软件本质复杂性，但提倡通过计划、原型迭代及严格里程碑管理来应对。这些关于项目管理、沟通障碍及伦理责任的论述，至今仍具极高警示价值。
读者共识
- 读者普遍认为本书是软件工程领域的圣经级著作，其核心观点如‘向落后项目加人只会更慢’已成为行业常识。尽管出版于1975年，但读者反馈其揭示的规律在当下依然完全适用，甚至因现代项目复杂性而更具现实意义。任何从事软件相关工作的人都被强烈推荐阅读，以规避常见管理错误。
- 读者赞赏作者基于真实大型项目经验的深刻洞察，认为其内容非空洞理论，而是血泪教训的总结。书中对人性弱点、沟通障碍及设计风险的剖析令人警醒。尽管部分读者初读时可能觉得内容常识化，但实际项目经历后往往感叹其预见性之强，承认自己曾犯书中所述错误，需反复研读以加深体会。
- 读者指出本书英文版阅读体验良好，但部分章节晦涩，建议配合注释版或中文译本。同时，读者强调不应将书中观点视为僵化教条，而应理解其背后的工程伦理与系统思维。对于初学者，此书可能难以完全消化，但作为职业启蒙读物，其价值不可估量，有助于建立正确的工程观与责任感。
精彩摘录
- "乐观主义 所有的编程人员都是乐观主义者。… “这次她肯定会运行的” “我刚刚找到了最后一个错误” 人月 第二个谬误是在估计和进度安排中使用的工作单位﹣人月。暗示着时间和人员可以相互替换。"
- "系统开发的时间安排 1／3 计划 1／6 编码 1／4 构件测试和早期系统测试 1／4 系统测试，所有构件已完成 需要特别指出的是，不为系统测试安排足够的时间简直就是一场灾难"
- "简化Brooks的法则：向进度落后的团队增加人手，只会让进度更加落后。"
- "所有的编程人员都是乐观主义者。可能是这种现代魔术特别吸引那些相信美满结局的人；也可能是成百上千琐碎的挫折赶走了大多数人，只剩下了那些习惯上只关注结果的人；还可能仅仅因为计算机还很年轻，程序员更加年轻，而年轻人总是些乐观主义者棗无论是什么样的程序，结果是勿庸置疑的：“这次它肯定会运行。”或者“我刚刚找出了最后一个错误。” 所以系统编程的进度安排背后的第一个假设是：一切都将运作良好，每一项任务仅花费它所“应该”花费的时间。 ... 正由于介质的易于驾驭，我们期待在实现过程中不会碰到困难，因此造成了乐观主义的弥漫。而我们的构思是有缺陷的，因此总会有bug。也就是说，我们的乐观主义并不应该是理所应当的"
- "成本的确随开发产品的人数和时间的不同，有着很大的变化，进度却不是如此。因此我认为用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话。它暗示着人员数量和时间是可以相互替换的。 人数和时间的互换仅仅适用于以下情况：某个任务可以分解给参与人员，并且他们之间不需要相互的交流。这在割小麦或收获棉花的工作中是可行的；而在系统编程中近乎不可能。"
- "因为软件开发本质上是一项系统工作棗错综复杂关系下的一种实践棗沟通、交流的工作量非常大，它很快会消耗任务分解所节省下来的个人时间。从而，添加更多的人手，实际上是延长了，而不是缩短了时间进度。"
- "简洁和直白来自概念的完整性。每个部分必须反映相同的原理、原则和一致的折衷机制。在语法上，每个部分应使用相同的技巧；在语义上，应具有同样的相似性。因此，易用性实际上需要设计的一致性和概念的完整性。 概念的完整性要求设计必须由一个人，或者非常少数互有默契的人员来实现。 而进度压力却要求很多人员来开发系统。有两种方法可以解决这种矛盾。第一种是仔细地区分设计方法和具体实现。第二种是前一章节讨论的、一种崭新的组件编程开发团队的方法。 对于非常大型的项目，将设计方法、体系结构方面的工作与具体实现相分离是获得概念完整性的强有力方法。 让我们考虑一下树状编程队伍，以及要使它行之有效。每棵子树必须具备的基本要素"
- "它们挣扎得越猛烈，焦油就纠缠得越紧，没有任何猛兽足够强壮或具有足够的技巧，能够挣脱束缚，它们最后都沉到了坑底。 表面上看起来好像没有任何一个单独的问题会导致困难，每个问题都能获得解决，但是当它们相互纠缠和累积在一起的时候，团队的行动就会变得越来越慢。对问题的麻烦程度，每个人似乎都会感到惊讶，并且很难看清问题的本质。不过，如果我们想解决问题，就必须试图先去了解问题。"
目录
Chapter 1 The Tar Pit 3
Chapter 2 The Mythical Man-Month 13
Chapter 3 The Surgical Team 29
Chapter 4 Aristocracy, Democracy, and System Design 41
Chapter 5 The Second-System Effect 53
显示全部
用户评论
虽然没有银弹，但是我们还是可以努力寻找效率最高的解决方案。
程序员，没做过项目管理，但是普遍能够体会到项目管理的拖延性质，书中讨论了软件项目开发的相关，但我造诣不深，很多东西并没有亲身的思考和体会，因此也不会有太多感触，还有待进一步修炼。被众多人捧为经典，说明书中必定有很多精髓还没能悟到，且等下一次在细心品味吧。
1975年出版的书，比C++语言的发明还早四年，却把当今软件工程和软件项目管理的规律揭示得淋漓尽致。2022年我亲身体会，书中所说的规律仍然成立，不是一个两个，而是书中提到的所有规律。我倒不认为这是作者有多么牛逼，他也只是总结他当时那个年代的规律而已，根本还是在于软件行业从上世纪50年代到现在，其实没有什么大的变革。未来的可能性还多得很。
Conceptual integrity, surgical team , communication and organization , document and more .
软件确实是工程
开工，有启发。未读之前还以为是讲登月工程。
单手可持，暖色调书页配清晰舒适的印刷体，适合读者有空慢慢读。词汇通俗易懂，但我选择了人民邮电出版社的注释版辅助。
英文
其实我看的是中文版
求书
收藏