一，“人们通常期望项目在接近结束时，软件项目能收敛的更快一些。然而，情况却是越接近完成，收敛得越慢。”
因为越到最后需要整合的资源越多，需要考虑到的bug越多。
二，“用“人月”来衡量一项工作的规模，是一个危险和带有欺骗性的神话。”
首先，软件的体量很难用数量来衡量，因为会有很多你意想不到的事情发生。
领导当然希望能够按照预期的人月数来开展工作，一是可以根据需要，通过增加人手提高速度（这个问题后续再细说）；二是与不同的人之间可以呼唤（忽略了人员个体的差异）。从哪个角度来看，这样当然都很好很理想，但又是不现实的，所以叫“神话”。
三，在落后的项目中增加人手，只会使进度更加落后。
我认为，加上前后的语境，这句话应该这么理解：“（试图简单的通过）在落后的项目中增加人手的方法（来追赶进度），（通常反而）只会使进度更加落后”。原因很简单，就是临时加入人，培训和沟通需要代价；当然，某些特殊的项目，无需培训，加入的人又超强，自然是另外一回事。之所以领导会有向落后项目增加人手的打算，也是因为认为“人月”中，人和月可以互换，3个人5个月等同与5个人3个月。所以最好是在一开始，对工作的量进行仔细的评估（包括认真分析隐形需求和额外工作量等），对工作量有清晰的认识，对工作时间，取得相关人等的同意，来开展工作。当然，如果一定要提高进度，除了增加人手外又没有别的方法，那么晚加不如早加，虽然不能达到预期追赶和提高进度的目标，长远来看，也会比不加人好，另外，总比项目里中途有成员被调离要好多了吧！
对于我以后的编程工作会有很大的帮助，也解释了许多我以前不知道的问题。