之前的阅读感一是基于整部书的序言部分以及开头的简介写的，而这次的章节就步入了正题“人月神话”。
开篇提到软件实践工程项目的效率问题，那么我就猜测这里的人代指人数，但是月又代表什么呢？难道是月份？这个不得而知，只能继续往下阅读。下面的一大部分在阐述进度和工作量之间的关系，以大部分项目因为缺乏合理的时间分配而滞后为背景，进行了展开分析。在大多数的项目中，一但工程滞后，管理人员的第一反应就是增加人手，但是往往增加人手并不能很好的解决这个问题，因为在软件工程中，每个小分块之间的编写者都是需要沟通才能是整个项目完美完成的，如果只是增加人手，但是这些人对工程项目还不了解，还得与其他人进行沟通，这样反而更加浪费了时间。这就像用汽油灭火一样，只会使事情更加糟糕，越来越大的火势需要更多的汽油，从而进入了一场注定会导致灾难的循环。谈到这里，文章戛然而止，却引出了另一个主题“乐观主义”。
确实，每一个编程者都是乐观主义者。当代程序员都是年轻的程序员，可能因为计算机还很年轻，在他们眼里，无论是什么样的程序，结果都是毋庸置疑的“这次肯定没错，绝对会运行”。虽然乐观是一件好事，但是结果往往事与愿违。所以在实际的软件项目进度安排上，都有一个隐藏的前提——一切都将完美运行。但是每一个项目都有修改bug的步骤，而且时间不确定，这就导致了开篇提到的工程项目滞后的结果。看来这个问题必须要得到足够的重视。
在阐述了第一个谬误后，作者又引出了第二个谬误“人月”。从本书的题目就可以知道，“人月”一定是本书的重中之重。成本的确和开发产品的人数和时间有关，但是进度却不是这样。我现在明白“人月”中的月指的是工程项目中的花费时间。人数和时间的互换仅仅适用于以下情况：某个任务可以分解给参与人员，并且 他们 之间不需要 相 互的交流。 这在割小麦或收获棉花的工作中是可行的；而在系统编程
中近乎不可能。所以说，在系统编程中，人数与时间的互换是一种荒谬的观点。作者举了一个十分浅显易懂的例子——无论多少个母亲，孕育一个生命都需要十个月。以为孕育生命这个进程来说，是绝对不可以分割给别人的。由于测试调试的次序问题，大部分项目都具有这个特点。
就增加人手这个解决方法来看，首先得要解决沟通问题。沟通所增加的负担由两个部分组成，培训和相互的交流。每个成员需要进行技术、项目目标以及总体策略上的培训。这种培训不能分解，因此这部分增加的工作量随人员的数量呈线性变化 。 因为软件开发本质上是一项系统工作——错综复杂关系下的一种实践——沟通、交流的工作量非常大，它很快会消耗任务分解所节省下来的个人时间。从而，添加更多的人手，实际上是延长了，而不是缩短了时间进度。
在这之后，作者根据他多年的经验，列出了他自己在任职时对软件任务的进度安排：1/3 计划 1/6 编码 1/4 构件测试和早期系统测试 1/4 系统测试，所有的构件已完成。从这个安排我们不难看出，在整个任务中测试就占了一半，为什么会出现这种安排呢？我百思不得其解。因此，在早期进度策划时，允许充分的系统测试时间是非常重要的。
未完待续。。。