十几年前，我还在上大学的时候，专业老师给提推荐的一本经典书籍，至今念念不忘。所以今日抽点时间来分享给大家。
什么叫“人月神话”？
人是程序员，月是时间，，如果1人干10个月如果等同10人干1个月，那就成神话。

1. 先看作者简介：

小弗雷德里克·P.布鲁克斯（Frederick P. Brooks, Jr．1931—2022），图灵奖得主、美国国家科学院院士，对计算机体系结构、操作系统和软件工程做出里程碑式贡献的计算机科学家。
布鲁克斯博士于20世纪60年代初主持与领导了被称为人类从原子能时代进入信息时代的标志的IBM/360系列计算机的开发工作，取得辉煌成功，被认为是“IBM 360系统之父”。
布鲁克斯博士创立了北卡罗来纳大学的计算机科学系，并于1965—1985年担任系主任。他还曾任职于美国国家科技局和国防科学技术委员会。
布鲁克斯博士作为硬件和软件的双重专家和出色的教育家始终活跃在计算机舞台上，因其专业成就和对计算机体系结构的卓越贡献而屡获表彰，包括美国国家技术奖、ACM杰出服务奖、ACM Fellow、ACM Newell奖、IEEE McDowell奖、计算机先驱奖、冯·诺伊曼奖、富兰克林学会鲍尔奖、图灵奖等。
2. 内容简介：

在软件领域，很少能有像《人月神话》一样具有深远影响力和长销不衰的著作。布鲁克斯博士为人们管理复杂项目提供了颇具洞察力的见解，从宏观角度有层次地分析了软件工程的方方面面，不仅逻辑严谨，而且颇具文化底蕴。
容主要来自布鲁克斯博士在IBM公司研发并管理System/360计算机家族和OS/360软件支持包期间的项目管理经验，该项目堪称软件开发项目管理的典范。
《人月神话（纪念典藏版）》英文版一经面世，即引起业内人士的强烈反响，后译为德、法、日、俄、中、韩等多种文字，成为软件开发和管理人员的必读经典。
书中强调了构建“系统产品”与构建“简单程序”的任务不同。研发大型软件系统不是简单程序的堆叠组装。软件开发任务不总是像收割麦子的任务一样可分解，要分析问题性质以及子任务间的依赖关系。
软件研发效能的量化估算不能对“人月”“人周”“人天”做简单加法和乘法，正如不能基于个人百米成绩来推算马拉松成绩一样。新手培训、沟通交互都会引入额外的成本，向延期的软件项目添加新人会使项目拖得更久。
软件开发任务间复杂的依赖关系需要科学管理，避免无效的人力投入。
3. 下面是经典的书摘：
1、过去几十年的大型系统开发就犹如一个焦油坑，很多大型动物在其中剧烈挣扎，他们中大多数开发出了可运行的系统–不过，其中只有非常少数的项目满足了目标、时间进度和预算的要求。
各种团队，大型的和小型的，庞杂的和精干的，一个接一个淹没在了焦油坑中。表面上看起来好像没有任何一个单独的问题会导致困难，每个都能被解决，但是当它们相互纠缠和累积在一起的时候，团队的行动就会变得越来越慢且很难看清问题的本质。
2、Brook法则：向进度落后的项目中增加人手，只会使进度更加落后。
向软件项目中增派人手从三个方面增加了项目必要的总体工作量：
任务重新分配本身和所造成的工作中断；
培训新人员；
额外的相互沟通。
关于进度安排，我的经验是为1/3计划、1/6编码、1/4构件测试以及1/4系统测试。
3、小型、精干队伍是最好的–尽可能的少。
需要协作沟通的人员的数量影响着开发成本，因为成本的主要组成部分是相互的沟通和交流，以及更正沟通不当所引起的不良结果（系统调试）。

总结，无论你踏入程序员这一行，还是已经在软件行业内摸爬滚打了十几年的老兵，《人月神话》都是值得仔细阅读的一本经典著作！
想要电子版，可以关注我右边的公众号:程序员博览，发送：人月神话，即可获得下载链接!