这段时间阅读了《人月神话》一书的11-15章，在这几章中，作者又整体讲到个体，从前面注重讲团队之间的问题，讲到个人编程需要注意的问题。“祸起萧墙”这一章，让我深感羞愧，我们组在第一阶段就如书中所说，逐步的落后了下来。“项目是怎样延迟了整整一年的时间？…一次一天。”我们也是这样，滚雪球一样的落后了下来。

“但是一天一天的进度落后是难以识别、不容易防范和难以弥补的。昨天，某个关键人

员生病了，无法召开某个会议。今天，由于雷击打坏了公司的供电变压器，所有机器无法启

动。明天，因为工厂磁盘供货延迟了一周，磁盘例程的测试无法进行。下雪、应急任务、私

人问题、同顾客的紧急会议、管理人员检查——这个列表可以不断地延长。每件事都只会将

某项活动延迟半天或者一天，但是整个进度开始落后了，尽管每次只有一点点。”

“千丈之堤以蝼蚁之穴溃，百尺之室以突隙之烟焚。”每天一点点的问题，导致最后的大问题，这看上去几乎无解。作者提出的最简单的办法——“进取”对软件开发队伍，进取是非常必要的。进取提供了缓冲和储备，使开发队伍能够处理常规的异常事件，可以预计和防止小的灾祸。而对任务进行计算和对工作量进行度量，会对进取超前会造成一些消极的影响。这时，人们往往会比较乐观地放缓工作节奏。就这一点来说，它们是令人扫兴的事情。不过，如同我们看到的，必须关心每一天的滞后，它们是大灾祸的基本组成元素。

个人感受：这就是我们面临的问题，对我个人而言，如果这一天我完成了任务，这毫无疑问让我斗志倍增，洋洋得意，第二天也能斗志昂扬，但是如果我耗费了一天时间都没有半点成果，那么第二天我很可能出现“宕机”假死，我、还有很多和我一样的同学，都有这个问题。我们需要的是像书中所说的，我们可以出现和原计划不同的误差，但是这些误差不是我们气馁的原因，我们知道千里之堤毁于蚁穴，但是我们也要有聚沙成塔的信念，时刻保持进取的态势。另外书中还提到了一个方法“使用PERT 图”。即找到关键任务，只要关键任务不落后，我们就不应该有“其他的部分反正会落后”的消极想法，在关键任务时间没到之前，我们都是有机会“翻盘的”。