关于人月神话的“人月” 的思考

老实地说对于《人月神话：软件项目管理之道》这本书我没有深入的思考，因为对于我这个处于入门和基础之间人来说，那种理论性的书还是不要去深入了解比较好。
为什么要看这本书呢？主要是我觉得在看代码的过程被一些代码的语法以及使用或者IDE(集成开发工具)的运用的问题“折磨”的????所以闲暇之余看看这种“大师著作”，好感觉提升一下自己的格调。其实一开始我是被标题《人月神话》吸引的读了部分感觉这本书其实写的关于 “人月”的也不多，可能是本书的核心内容是吧。
好吧，开始正题。
首先我先谈一下“人月”吧。作者佛瑞德·布鲁克斯（Frederick P. Brooks, Jr.） 谈到了“人月”这个概念，这个是用来描述工作量的。譬如100人月可以说成50个人在2个月内完成工作，也可以说成5个人在20个月内完成工作。然而这只是个理想，正常情况下前者一般可以做到，而后者几乎不可能！ “第二个谬误的思考方式是在估计和进度安排中使用的工作量单位：人月。成本的确随开发产品的人数和时间的不同，有着很大的变化，进度却不是如此。因此我认为用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话。它暗示着人员数量和时间是可以相互替换的。” 原文有段话就是如此，事实上人数不能实质上的替代是时间，但那是分情况的。
（1）人数和时间的互换仅仅适用于以下情况：某个任务可以分解给参与人员，并且他们之间不需要相互的交流（如下图）。这在做小项目或者普通的农活倒是未尝不可，如在割小麦或收获棉花的工作中是可行的；而在系统编程中近乎不可能。

(2)当任务由于次序上的限制不能分解时，人手的添加对进度没有帮助（如下图）。无论如何，小孩子学会走路前必须得学会爬。由于调试、测试的次序特性，许多软件都具有这种特征。

(3）对于可以分解，但子任务之间需要相互沟通和交流的任务，必须在计划工作中考虑沟通的工作量。因此，相同人月的前提下，采用增加人手来减少时间得到的最好情况，也比未调整前要差一些（如下图）。

其实还有一些问题在人月过程里（个人认为)，比如说人们的乐观主义，如果发生在编码人员或者测试人员间，那就是个伤脑经的问题。他们可能觉得系统的运行环境以及硬件介质等是良好的就忽略了自己的编码问题，单方面乐观地认为这是最后一个bug，原来自己少写了一个"逗号"之类的。其实许多人员这么认为，那么人月的可行性就更难保证了。