《人月神话》这本书有两个老师都有给我们推荐，第一个老师推荐时不以为然，第二个老师也推荐时，自己感觉应该是挺重要的吧，于是去图书馆借了这本书来看，刚借回来时，总觉得时间不够、作业很多，也没来的及看，就一直搁置在了那里，直到上周，在我们的项目实践开始近三周，但进度却一直赶不上来的情况下，看到了这本书，才拿起来看。目前还没看完，先写一点儿领悟到的东西。
作者从焦油坑，提出项目失败的表现，把过去几十年的大型系统开发比作一个炼焦坑，各种团队一个个地淹没在焦油坑，他们都试图解决面对的问题，但他们都必须去了解问题的本质。
还有著名的Brooks法则——向进度落后的项目中增加人手，只会使进度更加落后，人们常拿人月来计算项目的工作量，但其实开发工作是需要人与人之间密切沟通的，使得设计工作不易分割。一般来说，一件复杂的工作大量的投入人力，会使工作完成的更快，更加出色，但读了《人月神话》的第二章节后，我发现这种观点是不对的，至少在软件开发上不对，当增加人力时，会导致一个可怕的后果，要么工作延迟，要么工作错误百出，从而导致项目的失败。
进度的可保证性和可控制性来源于项目计划的科学性，项目计划对进度预测的准确性又来源于估算的准确性，估算是否准确又涉及到项目规模，根据规模可以得到工作量，根据工作量和人力资源的投入和任务依赖约束可以得到最终的进度。当软件产品的规模增加的时候，复杂度成倍增长，从而导致这些要素之间不是单纯的线性关系，这是人月神话的启示之一；同时由于软件项目本身的生命周期模型和工序任务限制，导致对于一定规模的软件产品研发，无论投入多少的资源，都有一个最短工期的限制，在这个最短工期下投入再多的资源也没有用。
据此，我总结出我们小组进度较慢的原因如下：
1.在项目开始时，未对项目量进行明确的估算；
2.不了解小组人员所掌握的基础知识情况，对小组人员没有明确的分工和定位；
3.知识体系不够完善，做出的东西需要反复修改。
个人感觉，在做每项工作时，都必须要有一个牵头人（可以是除项目经理外的其他人），比如有人对文字撰写比较擅长，就可以让此人来写立项说明书、需求说明书、设计说明书等文档的大概框架，写好框架后按照小组人数将任务分配给每个小组成员，编程能力比较强的可以将项目中所需做的编码工作具体分工，并给编程能力弱的同学提供一个大概的方向，保证每个小组人员都能够按时完成自己的任务，同时，项目经理要保证任务分配的均衡性，并由能力强的带动能力弱的同学，以达到共同学习、共同进步的目的。