对于软件项目进度的估算往往会根据项目的紧急程度而得出过于乐观的结果，这一方面是因为所有的编程人员都是乐观主义者，我们往往会认为“这次肯定能运行”或者是“我已经找出了最后一个bug”，另一方面则来源于市场的压力，这种情况在国内环境更甚。我们对于进度估算的第一个错误假设就是：一切都将运作良好，每一项任务仅花费它所“应该”花费的时间。而这个假设往往是一厢情愿的，对于创造性工作来说，创造者常常是在实现过程中，才发现在构思设计时候的不完整性和不一致性，从而反馈到的构思设计上，处理这种问题的时间和复杂程度会随着项目的结构以及任务的大小而呈现非线性增加的关系。所以对于大型软件项目来说，“一切都将运作良好”就是一件概率非常小的事情了。
项目的时间依赖于顺序上的限制，人员的最大数量依赖于独立子任务的数量。从这两个数值可以推算出进度表，该表安排的人员较少，花费的时间较长（唯一的风险是产品可能会过时）。相反，分派较多的人手，计划较短的时间，将无法得到可行的进度安排。总之，在众多软件项目中，缺乏合理的进度安排是造成项目滞后的最主要的原因，它比其他所有因素加起来的影响还要大。
总的来说就是对团队应当对要做的事情进行充分的规划，要知道事情并不能按照你预想的那样顺利，你预留的时间可能更本就不够你的真正实现，毕竟一杯茶，一包烟，一个bug改一天。
在第二阶段就出现这种情况，第一阶段登陆部分已经把登陆方面写完了，第二阶段整合一下就好了，结果，我预留的时间不够，整合各种出错，到最后还是到一开始的重加载Fragment上。
由此可知，软件工程永远不要相信你自己的效率，也许一个小bug就能把你的时间全浪费了，所以在将来的编程生活中，一定要预留足够的时间去进行代码的实际操作。