《人月神话》出版于1975年，作为软件工程（或项目管理）领域的经典著作，今日读来已有不少过时的地方，但其中提出并讨论的基本问题仍然是有意义的。在敏捷与精益成为主流的时代，回顾大型软件项目的管理方法，或许能帮助我们更好地理解敏捷与精益的本质。
人月神话
《人月神话》是一本随笔集，没有系统的结构，作者选择以这种形式来表达自己的观点，我想应该也期待作为读者的我们不必正襟危坐，而以一种轻松和开放的姿态来阅读吧。
“人月神话”的意思，是指在软件开发过程中，人们往往以“人月”作为估计工作量的单位，并认为通过增加人手就能以同等比例缩短所需的开发时间，比如说10个人预计10个月的开发工作量，100个人应该可以在一个月内完成。这种想当然的意见往往与事实天差地别，因此被称为“神话”。
“人月神话”不能成立的原因，一是当任务由于次序上的限制不能分解时，人手的添加对进度没有帮助。二是对于可以分解，但子任务之间需要相互沟通和交流的任务，必须在计划工作中考虑沟通的工作量。
理论上说，一对一的情况下，三个人之间的沟通量是两个人之间沟通量的3倍，四个人之间的沟通量是两个人之间沟通量的6倍，考虑到多个人或者多个团队之间开会协商、一起解决问题的需要，增加人手的作用往往要大打折扣，甚至可能起到负面的作用。
以尽量精简的团队完成任务当然是最佳选择。但小团队毕竟无法承担大型软件开发任务，因为软件开发有其时效性，再高的效率，以大型软件的工作量计，也要十数年才能完成开发——这在商业上是没有意义的。
因此，就展开了本书讨论的主题：如何管理大型软件项目开发。
概念完整性
作者提出的核心观点，是保持软件项目的“概念完整性”：
“一个整洁、优雅的编程产品必须向它的每个用户提供一个条理分明的概念模型，这个模型描述了应用、实现应用的方法以及用来指明操作和各种参数的用户界面使用策略。”
为实现“概念完整性”，作者对开发过程中的各个方面都进行了讨论，比如:
- 采用“外科手术”式团队，由一个人负责整体概念，配以各种辅助角色；
- 通过即时更新的必要文档明确定义体系结构与里程碑；
- 以项目手册等正式与非正式的方法促进团队沟通，保证理解一致；
- 产品经理和架构师双重领导；
- 文档源代码化；
- 开发工具的统一管理等。
作者的观点并不总是正确的，比如在原书中，他是反对封装的——以至于在二十周年纪念版中，他特意指出这是错误的。
但就主要思想而言，似乎和我们今天对软件工程的理解并没有太大的出入——只是我们有了许多便捷的工具和经过验证的方法来实践这些思想。考虑到这几十年间计算机与软件行业的巨大发展，书中思想的先见之明让人怎能不佩服呢！
1999年，本书作者布鲁克斯获得图灵奖，评选委员会主席的致辞中说：
“今天我们所看到的计算机体系结构、软件工程，以及三维计算机图形，均受惠于布鲁克斯的开创性工作，是他改变了这些领域的面貌。”
本书作为软件工程领域的经典著作，是不负其名的。
阅读建议
建议看二十周年纪念版，这个版本收录了作者的另一篇经典论文《没有银弹》，也有对本书主要观点的总结和反思。先看前言、目录和后记，人月神话、没有银弹和关于没有银弹的辩护等章节可以细读。其它内容以略读为主，根据个人兴趣和自己的经历体验，应该有各自不同的选择与体会。
欢迎关注本文首发公众号：读书录
网友评论