早就听说过这本书的大名了。在课上的时候老师就推荐我们去看这本书，这可是软件书中的战斗机，但是很惭愧，一直没有去了解这本书，甚至有时候碰到这本书，只是感觉很熟悉的样子，但是还是不知道到里面说的是啥。有一种疑问，老师怎么会推荐我们去看小说呢？人 月 神 话 这不是一些传说吗？直到去了解了这本书的内容之后，才发现根本不是这样的，这是软件开发人员必读书目之一。因为这是一个程序员成长为大牛的必经之路，也是一个好的项目成功完成的必须了解的历程。《人月神话》被评价为，“将技术书写成散文集，把经验教训和经历背景等一一道来”。这本书的名字并不是人类和月球之间的神话故事，而是软件工程的一些迷思，人月是一个人一个月的人力单位。

    通过本书我对进度安排和Brooks提出这个定律特别的感兴趣，因为从未想到过编程竟然是这样的。

    一．软件工程的时间分配

    作者提出软件工程中各个项目的比例应该如下：

    1/3 planning

    1/6 coding

    1/4 component test and early system test

1/4 system test, all components in hand

即关于进度安排，1/3计划、1/6编码、1/4构件测试以及1/4系统测试。

出乎我的意料，本来以为编程时间应该成为软件开发中最耗时的部分，事实上却是相反的，编程时间被分配了最少的时间。软件项目团队被建议，使用三分之一的时间对项目进行各种规划、设计，实际的编程时间并不是主要时间部分，余下一半时间被用来进行各种测试，检测、排除软件中的各种问题。这也许就是现实中软件工程和我们平时小打小闹写程序最大的区别，规范的规划、操作，配套的文档，严谨全面的测试阶段，科学的时间任务管理。即使我们在现实中做不到那么专业，较早学到这些意识也是很好的。

    二．任务落后难道增加劳力不对吗？

    Brooks提出一个定律：

    “给一个进度落后的软件项目团队中增援更多的人力，只会将进度拖后更多”

这个观点完全颠覆了我的观点，在之前我一直认为，对一个项目或者工程来讲，如果落后了我们可以按照建筑上盖房子的方式来完成我们的工程，可以增加一个一小队，从而人多力量大，众人拾材火焰高啊，必定会比原来的人进度快一些。但是看完Brooks这个定律后真的不再这么认为了，因为在项目开始后的一段时间内，这些参与开发的人虽然进程落后但是已经对项目比较熟悉了，如果现在在引入新的人，势必会是老的员工培训新的员工这样会使老员工的时间减少，同时新的员工了解这个项目还得花时间，如果分配给员工任务后，员工还需要在这个基础上再次适应，这样必定会增加开发的时间。

在我读这本书之前从未想到过完成项目的时间分配竟然是这样，编程占得时间是最少的，也从未认识到增加人数并不能使一个进度落后的软件项目按时或者提前完成。在读到这里是真的让我耳目一新，有种豁然开朗的感觉，虽然没有编过大的项目也没有按着上面的时间来安排自己的程序，但是，深度思考确实让我对这个话题深感兴趣。