进度问题是IT项目管理最为关注的问题之一，到了第二章人月神话开始讲进度问题。进度的可保证性和可控制性来源于项目计划的科学性，项目计划对进度预测的准确性又来源于估算的准确性，估算是否准确又涉及到项目规模，根据规模可以得到工作量，根据工作量和人力资源的投入和任务依赖约束可以得到最终的进度。当软件产品的规模增加的时候，复杂度成倍增长，从而导致这些要素之间不是单纯的线性关系，这是人月神话的启示之一；同时由于软件项目本身的生命周期模型和工序任务限制，导致对于一定规模的软件产品研发，无论投入多少的资源，都有一个最短工期的限制，在这个最短工期下投入再多的资源也没有用。开篇仍然在谈估算的问题，对于估算假设人月可以互换的问题是可以引入CocomoII估算模型来估算工作量和进度的，对于中小型产品和项目的估算更多仍然需要依靠专家的经验，对于大型项目则需要遵循一定的方法和估算模型。因此大型项目仍然强调的是首先要估算出软件产品的规模，规模结合生产率得到工作量，工作量结合进度安排和相关模型得到项目周期。当按照这种思路的时候我们就会有意识的去积累生产率，评审效率，缺陷密度等原始数据。估算的基础是用户需求，但往往我们就是在用户需求不明确的情况下盲目估算。对于企业信息化相关软件系统，对于全新启动和开发的产品估算往往是最不准确的，因为缺乏相关的历史数据，经验积累，估算参与人员也缺乏对业务和需求的深入理解。对于PSP个体软件过程的推广有利于提升估算能力，因为可以让开发人员更加准确的认识到自我的开发生产率。对于技术架构的完善和技术的积累有利于提高估算水平，因为技术越完善后期的技术研究任务越少，而技术研究往往是具有高度不确定性的任务。开发人员对所属业务领域的深入理解有利于提高估算水平，任何一个需求功能点中对规模和工作量影响最大的是业务规则的复杂性，而不是该需求所涉及到的UI界面和基本流程。我们讲当规模增长的时候，工作量并不是非线性增长，周期也不是非线性缩短。其中工作量的增加前面已经讲了第一个重点增加在了系统分析设计，需要将复杂的系统进行分解；其二在后期集成和测试，需要将分解的各个功能模块集成和组装。对于产品规模增加的时候，对于详细设计和编码阶段工作量可以任务是一种线性的增加，非线性部分指数增加的工作量都体现到了前期的分析设计和后期的集成和测试上面。
在过去的编程道路中我很难掌握好自己的进度，很难估算自己的项目多长时间可以完成，我也并没有做到有很多的代码测试，所以在以后我要尽量改进，争取写更多的代码测试以保证项目的准确性。