十个孕妇也不能一个月生孩子-----读《梦断代码》有感

 

         在软件工程中，当我们的目标定下来之后，团队要有一个整体的计划，对各步骤时间的把握等，有助于我们整个工程的完成。

       

         可是，软件时间，看上去不起眼的问题，确是最难的问题，也是影响整个软件工程成败的问题。

   

         一个本来以为只要4个小时就能完成的问题，6个月都没能解决，Chandler团队可谓深深的体会到了延误带来的苦果，这个小Bug，在工程刚开始时是万难预计到的，当它被发现时，也没有引起足够的重视，最后产生了致命的后果。软件开发者大都认定每个缺陷都可以被迅速修正，且修正旧缺陷必能减少新缺陷的数量。这种盲目乐观，让工程在一开始时就偏离正轨。

 

         那么，如果已经延误了的工程，我们引起重视，补充能力希望能赶上来，是不是就可以了呢？

 

         答案是： 不!

 

         布鲁克斯法则告诉我们： 往已延误的项目中补充人力，只会使其继续延误。

 

         这种现象是由于软件工程的序列约束造成的，也就是说，完成某项任务是处理其他任务的先决条件，这与人力的投入多少无关。

 

          极好的程序员能在规定时间内完成十倍于普通程序员的工作量，而且完成质量也五倍于普通程序员。

 

          所以说，人多并不能解决问题，我们需要的是高质量，全身心投入的team member，这也给我们的team project敲响了警钟，不应以为这次project人多就轻松了，相反，我们应该引以为戒，千万不能重蹈《梦断代码》中的悲剧。