在进行敏捷管理的学习中，发现时间估算是一个很重要的因素，不同的时间进行综合对比可以查看出很多重要的信息，但是想要真正发挥出这些时间的用途却又不那么容易，就我们在迭代计划中涉及的理想工时估算、实际工时估算、实际完成时间，这小小的三个时间就困惑了我很久，整体概念都清楚，但是实际操作起来，众说纷纭，每个人都有自己的理解，那它们的真实含义以及在我们实际项目管理过程中应该如何操作才能真实反应项目情况，成为有效的“昨日天气”，为下个迭代服务呢？下面主要是自己的一些理解，不一定准确，欢迎展开讨论，寻求最适合我们的“正解”。

      先来第一个，理想工时估算。理想工时，顾名思义，是指该故事在理想状况下消耗的工时。所谓理想状况下，那就包括很多假定，假定你所需要的东西在故事开始时都会准备好、

假定在故事进行过程中不会被打扰、假定正常完成故事并且不会引发bug、假定。。。在所有的假定之后，并且工时不会因为该故事分配给不同的人而变化。

 那么我们如何来估算，这里有两种意见，一由项目经理来估算，二由敏捷小组合作估算。

我个人比较倾向于第二种说法，在故事没有被领取或分配前，小组内的任何人都可能是该故事的执行者，仅由项目经理估算过于片面，小组共同估算才能代表该小组的评估标准（允许同一个故事不同的敏捷小组估算的理想工时不同）；另一方面项目经理的专业能力不可能涵盖到项目中涉及到的所有领域，有些故事的评估应该交由敏捷小组中的其他专家评估更合适更准确。

       我看到过的一个进行共同评估方法，觉得很有趣，采用规划扑克的方式，即在进行一个故事的理想工时估算时，确保小组成员对该故事内容清楚并且无异议，随后每个人在卡片上写下自己的估算工时，大家同时翻转卡片，估算值一定会有差异，针对估值过高和估值过低的人让他们分别说明理由，大家经过讨论后重新进行估算，最终会形成一个合理的估算值。

        第二个，实际工时估算，实际工时与理想工时相比，需排除理想工时的假定，并且还要考虑一些系统开销，比如前期构思、技术准备、与UED、QA的沟通配合、修复bug等因素。

建议的一种做法是将故事拆分成完成这个用户故事需要进行的任务，按任务估算并进行合计。（这个过程只需要心算或者在草稿上简易标注就好）实际工时估算一定会超过理想工时估算，越接近理想工时代表我们预估损耗越小，当然越接近机器，实际情况中这是不可能的，

如果最后体现出的结果是实际完成时间等于甚至小于理想时间，那说明我们的理想时间估算偏大了，下一次迭代需要调整。

       实际工时的估算，普遍认为应该由将要完成该故事的成员进行评估，并且进行迭代计划的故事规划时也以优先级和实际工时估算为准。

       最后一个，实际完成时间，实际完成，这个概念大家应该不会有什么异议，即故事功能完成并且已经通过验证。实际完成时间跟预估工时估算相比，可以很清楚的看出具体成员完成该故事的情况，从而计算出该成员的迭代因子；同时也会指导该成员分析差距原因，在下次进行类似故事评估时更准确。

但是这个时间如何进行填写却是个问题，首先进行该项故事开发的成员，在完成该项故事，并且通过了单元测试和简单的功能测试后，他已经可以认为这个故事是完成的了，这时会有个时间，比如4小时，接着会进行下一个故事。我们不知道QA什么时候会进行这个“完成”故事的验证，并且也不知道验证的结果是否产生了新的bug或者有其他建议性调整。如果验证结果是乐观的，那么这个4小时应该能代表该故事的实际完成时间，但一般情况下我们不会那么幸运，或多或少会引发bug，那么我们用来修复bug的时间算在哪里？

 一种比较合适的说法是，本次迭代能修复的bug花费的时间计算到相关联的故事的实际完成时间里去，挪到下次迭代完成的bug按照新故事估算的方式进行迭代计划安排。

这又涉及到另一个问题，如果修复bug产生了1小时，强调由组员修复bug后自觉将修复的时间1小时加到4小时中即：1+4=5小时，还是由项目经理迭代结束前根据redmine平台上修复bug的情况（bug完成时间-bug开始时间）统一添加到相应故事中。如果采用后一种方式，能否在平台上查看bug时，可以相应查看引发该bug的故事编号呢？