读后有感
读完《人月神话》，首先映入眼帘的就是“人月”这个概念。人月是个什么东西？作为一个和工程管理、合作项目等概念完全没有的学生，这个名词对我就算介绍一遍概念我也很难理解。简单来说就是度量工程进度的一个基本单位，由于软件项目本身很难度量，于是就有了这么一个概念，但这个概念很明显是个忽悠，这就是一个现代的神话。
乐观主义
我们常常对当前形势和风险评估都抱以乐观的态度，这对我们和我们所在做的事都有好处，但如果是要对项目开发的进度预估报以乐观的估算，那就很容易出现问题了。就就是为什么要未雨绸缪的原因。
风险问题与进度伴随，而前者的不可控就会导致后者的不可预知，不对风险进行预估的话在处理风险的时候进度就会被严重拖慢。作者推荐的项目工作量划分是“计划1/3，编码1/6，单元测试和集成测试1/4，系统测试1/4”，计划占了最大头，测试占了剩下的大头。如何缩减了系统分析和总体设计的工作量，则可能带来整个产品结构的不稳定，后果往往是整个产品推倒重来；如果缩减了后期集成和测试的工作量，则不可避免的是导致项目延期。乐观主义者喜欢假设我们开发的是零缺陷的系统，但对复杂的软件系统而言这仅仅是个神话。
人月神话
用人月来衡量一项工作的规模是一个危险和带有欺骗性的神话，因为它暗示了人员数量和时间是可以相互替换的。
假设人月可以互换，则为了缩减周期需要投入更多的人，为了让更多的人都有事可做就需要细分任务，细分任务自然增加了系统分解和后期集成的工作量，细分任务间无法避免的依赖和关联自然增加了沟通的成本和工作量。而且由于任务的细分导致了一项额外的工作，就是沟通工作，项目文档往往在担当重量级的沟通工具时将客户原始的需求给模糊了。
人月不可取的另外原因就是其本身是不可相关联的，人月不能互换的原因，首先是任务能否拆解，及时能够分解任务间是否存在相互的依赖和约束，分解后是否增加会增加相应的沟通，以及由于分解任务而引入的分解和后期集成等额外的工作量。
所以，人月注定只是神话。