阅读笔记——人月神话（一）

介绍

　　在软件领域，布鲁克斯博士的《人月神话》是一本关于大型项目管理的经典之作。这本书不仅对每一个软件行业的项目经理(PM)来说是一本必读读物，对每个软件行业的参与者(程序员，测试人员或者是创业者)，都是一本不容错过的经典。书中贯穿整个软件开发流程对从业人员都是极有帮助的。虽然这本书讲到的项目是几十年前开发大型服务器相关项目，但是里面对研发工作的创造性思维，到今天还是有指导性意义的。本人在通读之后，得到了不少的启发，想做一点记录，和各位分享。相信以后还会多次精度其中的章节，以期得到不同的感悟。

概述

 

　　书在一开头就提到了软件工程管理中的一个关键问题：人/月。在项目管理过程中，这个指标实际上是有一些误导作用的，给人的感觉是项目取决于两个关键因素，人和时间(月)，而这两个指标仿佛看上去就是一个正比关系，增加人，减少月；减少人，增加月。于是就造成一种简单粗暴的项目管理办法，当项目进展受阻或者进度落后时，直接往项目中增加人手，仿佛这样就可以直接解决问题。而书中直接就针对这个问题指出：

 

• “用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话”
• 并提出Brooks法则："想进度落后的项目中增加人手，只会使进度更加落后。(Adding manpower to a late software project makes it later )"

 

　　这里背后的一个原因是，随着软件开发过程越来越成熟，很多人没有将软件开发当成一种创造性的脑力劳动，而逐步地将软件工程当成了劳动密集型的工程，软件规模和工作量是一种线性增长的模型。

 

　　即使是劳动密集型的工程，也不是一个简单的换算关系，设想建设一栋大楼，100个工人建一年，不是说36500人一天就可以搞定的。更何况对于软件工程这样一件含有大量创造性工作在内的脑力工程。

 

　　章节中提到，我们在进行工作量估算时，往往省略了团队规模扩大之后的一个重要事件成本——沟通成本。而沟通成本由两个部分组成：培训和相互的交流。每个成员需要进行技术、项目目标、总体策略以及工作计划的培训。这种培训是不能分解的，因此这部分增加的工作量随人员的数量呈线性变化。

 

　　上述提到的培训成本是线性的，还是可以接受的。而相互之间的交流成本更麻烦一些。一个大型、复杂的软件项目往往都是相互关联的，为了保证一个目标在团队之间达成一致，最坏情况下是每个部分必须分别于其他部分单独协作，则工作量按照n(n-1)递增。这是一个很可怕的增长。

 

　　也就是说，当团队增长到一定的规模后，新增人员带来的沟通成本会比开发成本都高的多，反而会拖累项目的进度。反过来也要求在软件设计之初做好业务的拆分，做到不需要每个人都需要和其他人员有深度的关联，在代码上也需要做好解耦的设计。当前流行的DDD、微服务、代码上的设计模式都是基于这样一个原则来试图解决问题。