《人月神话》这本书风行已经很久了，写成于1975年，经历这么久的时间，又被老师提出来让我们去读一下，老师明明是那种追求新技术的人,这让我非常的好奇，但是一直没有时间读。直到最近，快开学了，才终于狠下心来把他看完。也不能说看完吧，一知半解的，看了看。觉得有一些疑惑，又去网上找来读后感读了读，虽然没有读懂，但是起码我觉得还好要写一点东西。
人月神话看上去这么浪漫的名字，并不是真的说神话故事，作者阐述的主要观点是在软件开发项目上项目进度和增加人员这两个概念是不能互换。虽然已经时隔40多年了，这本书依然给我震撼.一是让我惊讶的是，美国40年前软件项目所面临的问题，在我们现在依然如此，糟糕的情况没有改变，大家仍旧在焦油坑里挣扎，而且看上去没有解决办法。这就非常的让人绝望：所有的编程人员都有乐观主义，总是相信自己的代码是肯定能运行的。所以在安排项目的进度的时候就会是假设在代码能够在正常运行时因该花费的时间。而现实往往不是乐观，在项目的进展过程中会存在各种不可预知的问题。在这个时候项目经理就会为项目增加人员，然而增加人员反而导致项目进度越来越慢。因为新增加的人员还需要培训，需要时间去了解项目的内容和进展情况。在投入了更多的人力的时候，经理发现项目进度反而更慢他就会投入更多的人力，这种恶行循环导致项目的失败。那种认为大项目只是增加足够的程序员就能顺利完成，已经对于已经推迟的项目，只要增加人手就能按期完成的看法是错误和危险的，因为它假定人和月是可互换的，而其实将工作分割给许多人、培训和程序员之间的交流都需要额外的工作。Brooks提出这样一条定律：给推迟的软件项目增加人手将使得项目更加推迟。
看起来这不是我们现在面对的问题，但是其实我们的老师之前也提出了要换人的想法，最后因为时间的原因而没有交换，这就是人和月之间的对立与不可交换性。其实主要还是在于团队的磨合性上，我觉得这个可能会对我将来的小组开发作业有很大的帮助。