《人月神话》学习指南

书籍介绍

豆瓣链接

秒懂百科: 一分钟了解人月神话

关于书名

《人月神话》的英文名称是《The Mythical Man-Month》，直译应为不真实的人月。人月（Man-Month）是指一种衡量软件开发工作量的单位，即一个人一个月的工作量。不真实（Mythical）是想表达出人月这种度量的不切实际，即一个人可以十月完成的工作，十个人不一定可以在一个月完成。

内容介绍

在软件领域，很少能有像《人月神话》一样具有深远影响力和畅销不衰的著作。Brooks博士为人们管理复杂项目提供了最具洞察力的见解，既有很多发人深省的观点，又有大量软件工程的实践。本书内容来自Brooks博士在IBM公司SYSTEM／360家族和OS／360中的项目管理经验，该项目堪称软件开发项目管理的典范。该书英文原版一经面世，即引起业内人士的强烈反响，后又译为德、法、日、俄、中、韩等多种文字，全球销售数百万册。确立了其在行业内的经典地位。

在本书第一次出版40年后的今天，我们重新整理了Brooks博士的经典内容，并将国内软件开发领域先行者们对《人月神话》中的实践及系统理论的使用经验和心得集结成册免费赠与大家共享，更使本书成为国内从业者的必读经典之一。

本书读者包括：软件开发人员、软件项目经理、系统分析师等IT从业者。

作者简介

小弗雷德里克•布鲁克斯曾获得美国计算机领域最具声望的图灵奖(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)。

阅读指南

我阅读的版本是《人月神话(40周年中文纪念版)》。这节是我阅读后的一些想法和认知，希望能帮到他人。

正文之前有三篇序，阅读正文前需要先仔细阅读。

软件研发是一个解决复杂问题的系统性过程，其本身也是一个复杂工程。第一章焦油坑就抛出工程复杂度上升后，难以维护的问题。想要解决这个问题，需要程序员对编程本身抱有极大热情，所以第一章最后两节介绍了编程工作的乐趣和痛苦。

在第一版序言中有提到，第2~7章特别包含了本书的中心论点。作者相信由于人员的分工，大型编程项目碰到的管理问题和小项目碰到的管理问题区别很大；关键需要的是维持产品自身的概念完整性。这几章探讨了其中的困难和解决的方法。而后续的章节则探讨了软件工程管理的其他方面。

.第二章人月神话，和书名相同的名字足以显示出这章的重要性。本章讨论了缺乏合理的进度安排造成项目滞后产生的诸多派生问题。

.第三章外科手术队伍和第四章贵族专制、民主政治和系统设计的名字都较为抽象，初学者看到后会摸不着头脑，这两章分别介绍了小团队与大团队的建设。

.第五章画蛇添足的英文原名是The Second-System Effect,本章主要提出了一个观点：第二个系统是人们所设计的最危险的系统，通常的倾向是过分的进行设计。

.第六章贯彻执行介绍了架构师如何将自己的设计确保每个人理解。

我们都知道巴比伦塔的失败是因为上帝给了人类不同的语言导致的沟通失效。那么在大型项目中如何保证沟通的顺畅呢？在第七章为什么巴比伦塔会失败中，作者讨论了如何使得团队之间进行有效沟通。

第八章和第九章的内容放在今天已经过时了。作者在第八章胸有成竹中介绍了一种以代码行数进行工作量量化的方案。由于年代久远，这种方式显然不适合现在基于高级语言的研发工作。第九章削足适履谈论了磁盘空间，内存空间受限情况下，如何控制程序规模。

.第十章提纲挈领再次强调了文档的重要性。文档包含了项目目标、产品的技术说明、时间、资金预算、工作空间的分配和组织结构。对于项目经理来说，文档降低了沟通的负担、让分歧更明朗、便于跟踪项目的进度状态。

唯一不变的是变化本身，第十一章未雨绸缪再次强调了这条朴素真理。软件必然会在修修补补中变得面目全非，最初的设计必须在各种妥协中打上各种丑陋的补丁。无论是多么良好设计的系统，都会走向混乱。因此，好的设计会让这个过程尽可能地慢，让代码尽可能地易于维护。而且，在面对不得不进行的重构时，做好心理准备。

编程需要好的工具，这点毋庸置疑。作者在第十二章干将莫邪中介绍了具体的方法和工具，由于案例年代久远，这章不要看了。

.第十三章整体部分讨论了如何去解决系统论中“1+1>2”的难题。

项目的延期通常是日积月累造成的，第十四章祸起萧墙介绍了“项目里程碑”方法。

.第十八章《人月神话》的观点：是与非，这章整理出了作者的核心概念，方便大家进行思考、判断和讨论。

学习资料

TestOps云层

此处警告：不能因为听了视频，就不看原书。推荐看完一个章节之后，带着问题再听。

【TestOps云层】《人月神话》第一章焦油坑
【TestOps云层】《人月神话》第二章人月神话
【TestOps云层】《人月神话》第三章外科手术队伍
【TestOps云层】《人月神话》第四章贵族专制、民主政治和系统设计
【TestOps云层】《人月神话》第五章画蛇添足
【TestOps云层】《人月神话》第六章贯彻执行
【TestOps云层】《人月神话》第七章为什么巴比伦塔会失败
【TestOps云层】《人月神话》第八章胸有成竹
【TestOps云层】《人月神话》第九章削足适履、第十章提纲挈领
【TestOps云层】《人月神话》第十一章未雨绸缪
【TestOps云层】《人月神话》第十二章干将莫邪
【TestOps云层】《人月神话》第十三章整体部分、第十四章祸起萧墙
【TestOps云层】《人月神话》第十五章另外一面、第十六章没有银弹
【TestOps云层】《人月神话》第十七章再论没有银弹
【TestOps云层】《人月神话》第十八章人月神话的观点:是或非

知乎

《人月神话》就没有一家公司实践过么？

人月神话反过来成立吗？

读《人月神话》——写在华为实习之后

掘金

《人月神话》— 洪荒时代的软件工程