人月神话，那么远，有那么近

《人月神话》

中国科学技术大学软件学院-胡帅-原创作品转载请注明出处

关于软件工程方面的书记可谓是多如牛毛，可是有多少是基于实际开发项目抽象而出的呢？很幸运，《人月神话》就是这样的一本书，真真正正的从实际大型项目中领悟而来，可谓经典二字。《人月神话》一书的内容来自Brooks博士在IBM公司SYSTEM/360家族和OS/360中的项目管理经验，作者为人们管理复杂项目提供了最具洞察力的见解，既有很多发人深省的观点，又有大量软件工程的实践。

最近读完了这本经典，感喟不可不多，无论是从项目的基础，还是到整个项目的框架集成，都有着不同以往的感悟。

《人月神话》提出了2条著名的法则： 1、人月神话：向一个已经延后的项目中投入更多的人力资源只会让它更延后。 2、没有银弹：没有一种策略，技术或者技巧可以极大地提高程序员的生产力。

Brooks在书中根据人月的不可互换推导出一个怪论：向进度落后的项目增加人手会导致项目更加落后。这个法则在如今的大型项目管理过程依然是很重要的，然而到今天为止，还是有大量的编程人员、测试人员、项目经理和软件公司老板在错误地使用人月 来衡量软件开发的工作量。关于人月的真实情况应该是：不能用人力换取时间。它的思想恰到好处地应用于文档项目的管理。有多少次查看文档项目的经理思考通过增加人手缩短时间表？Brooks说，“导致大量软件项目进入失控的原因是时间表的缺漏，这比所有其它因素的组合还多。”他给出了几个原因。首先，Brooks责备可怜的估计技术，它错误的“搞乱了前进中的努力。”因为估计的不确定性，经理们缺少“礼貌的倔强”去支持那些看上去比其它需要更长的时间线的步骤。一旦时间（表）流逝，倾向于加入更多的人力，而这就像“火上浇油”，会导致一个新的灾难生成的循环。当然，一个基本的错误就是假定人力可以严格的和时间交换。Brooks指出，这个公式仅在项目成员不需要和其他人交流的项目中成立，比如：拾棉花。然而，一旦项目中包含连续任务和依赖关系时，可以交换的思想立刻就土崩瓦解了。

那么关于此，什么才是对的。Brooks认为由一个组织，其结构类似于外科团队的，由一些专家设计并完成全部项目的核心工作而由另外的人力在特定的途径上支持他们的努力，来执行产品开发可以治愈上述病症。Brooks说到，这条仅有的路是在一个项目早期完成“概念完整性”的通途。大部分关于这些完整性的重要的表述通过这个规范发生，“那是一本计算机手册加上性能规范……第一批文档中的一篇产生计划中的一个新产品，最后的文档完成它。”文档是关键，这是重要的。

没有银弹，这种说话是不是对的。人狼的传说可能有人听过也可能没听过，人狼是一种具有人和狼两种特征的恐怖生物，而银弹是消灭它的一种最有效的子弹，如果看过《吸血鬼传说》也许就能和容易的理解这一点。作者将软件开发比作人狼，而将提高软件开发效率的方法比作银弹。作者预言未来十年，想要试图通过寻找一种有效地银弹将软件开发效率提高一个甚至几个数量级，这种银弹不可能出现。没有银弹这篇文章里作者列举出了当时一些非常先进的技术或思想理念，例如Ada和其他高级编程语言、面向对象编程、人工智能、专家系统、“自动”编程、图形化编程、程序验证、环境和工具、工作站等。虽然这些先进技术在一定程度上提高了软件开发的效率，但是始终没有达到银弹的效果。距离作者的预言已经过去有20多年了，纵观现在的软件开发领域，虽然新技术层出不穷，但是还是没有一种银弹能够让软件开发产生一次革命。

 

从 实际的效果来看，真正适合读这本书的人应该是哪些管理者，因为作者就是从管理者的角度来系统介绍软件开发生命周期中的大大小小细节。事实大于雄辩，作者以实际的开发的项目经验来阐述相应的理论，深入浅出。作为30年的经典，放在今天来看依然有着不小的用处，但是随着时代的改变，新技术的出现，书中的道理也不是完全的正确。整本书中很注重文档的作用性，作者认为一个优质的文档就是项目成功的保证，这一点与传统的软件工程很相似，但是却与极限编程的观点相悖。所以，也许作者是想传达出这样的一个观点：授人以鱼不如授人以渔。