项目时间的评估从来都不是一件简单的事儿，然而却又有很大的必要性。开发人员对项目的熟悉程度、开发人员的研发能力、需求变更、团队间相关依赖节点是否能按时达成等等都是影响到最终完成时间的因素。到目前为止，在两个版本的开发中已经有三次采用了计划因子乘以理想条件下开发时间的方法来预算开发时间。后两次不是很靠谱，对比前一次时间误差太大，主要表现是评估过于理想。这里做一些总结，后续改进。
任务的分解
整个迭代计划的评估抽象成表格，那么它的第一列就应该是每一项要完成的任务。当这个表格打上程序员所属的标签时，那就往往要抽象到某个部分需要重构、某些功能需要抽象、某些界面需要调整等等。任务的粒度很大程度上影响最后评估时间的结果。
首先你要充分了解需求
强调“充分”是有必要的，沟通本身就是一件存在价值损失的事儿，模棱两可的理解损失就更大。漏掉了或者理解差别引发的返工从而导致的评估误差算是最窝囊的。由于这些并不是需求变更，没办法理直气壮的要求更多的时间资源，所以功课做在前面很重要。
前面的评估中存在漏需求现象，导致版本更新功能缺失，要引以为戒。
任务分解代表着设计思路
你要知道如何做，才能知道要花多少时间，至少要知道努力的方向。新增功能点要知道如何实现，并且决定好使用的模式和方法才好评估时间；不了解的难点要给出充足的了解和攻坚时间；功能优化则要考虑到对原有代码的影响和复用，这时的评估又取决于对老代码的熟悉程度。
说到底还是看个人能力和经验问题，从之前的评估来看，功能优化方向的没有考虑到原有代码的优化和重构时间；新功能的后续设计和最初评估时的想法相比是一个不断优化和重新抽象的过程，这种变化有主动优化的成分同时也有bug逼迫的成分在内，如果是测试驱动开发貌似无可厚非，但是从时间评估的角度讲，就要预算一下重构和优化的时间了。或者说是任务的粒度还是过粗、或者就是设计的能力还是有所欠缺，都是后面评估和设计时需要注意的事情。
至于评估时间预算时需要把实现方式设计到成什么样的程度，我觉得还是取决于任务本身的复杂程度，因为某些任务的分解本身就要依赖于实现方式的设计，这似乎是个死循环，还是要具体情况具体分析。目前存在的问题是，实现的设计思路还是欠考虑，多数时候需要边实现边优化，也就有可能导致原有评估时的任务列表会有所变化，导致最终的时间误差。
时间的评估
这里是指针对每一个分解好的任务单元进行耗时评估，评估的条件是在理想情况完成，所谓理想情况就是无打扰、全投入的情况。我觉得在分解本身不存在问题的前提下、它的准确程度还是要取决于对相关技术点的熟悉程度。而后两次评估误差较大的主要原因在于，评估时间时并不是采用理想情况下。比如说修改一个界面，评估一个0.25h，这个时候想的不是对应的15分钟，而是这里需要的0.25h*4（计划因子）=1个小时么？显然一个小时足够了。这里可能一个两个如此想影响不大，如果全盘都这么个思路最后的偏差会非常大。
时间评估上绕不过的一个心理障碍就是“真的需要这么多时间么”这个问题。假设完成图片资源管理抽象这个功能理想情况下需要1小时，那么评估时间就是4小时，想一想觉得也两小时就足够了，于是1.0就变成了0.5 。结果在实现的过程中并非如此，也许是状态影响也许是调试问题，花了不只两个小时，这是误差就产生了。软件的编写与调试很多时候会碰到莫名其妙的问题，虽然最后大都证明了事必有因，但是探索的过程所需要的时间就要取决于技术经验、搜索引擎是否给力还有一点点运气了。所以结论是评估时间还是要老老实实的按照理想时间来算，真正做事时如果很快搞定节省了预估的时间不要开心的太早、拖延了好久超出了预算也不要太过于揪心，最后能达到一个时间上的平衡才对得起那个计划因子做的乘法。
计划的维护
第一次做迭代计划时间预估的时候还多多少少维护了一下，记录了一下真正任务实现所花的时间、一些设计上变更导致任务的变化等等。后来两次可能是由于任务本身分解的不给力，已经不是很有效的记录这个时间消耗了，因为任务有所变化、或者任务本身跨度大不好统计时间。
计划维护本身的意义在于团队层次上对项目完成程度的把控，对个人来说则在于对之前评估的反思和后续的优化。这一点后面要持续跟进一下。
总结与后续
- 时间评估注意按照理想状态预算；
- 任务分解注意先做好设计；
- 需求要充分理解之后再做事；
