在新公司里，不懂软件工程的产品经理经常逼迫研发人员作出很不靠谱的时间估算。常见场景有下面这些：
需求未细化的情况下要求给出时间估算；比如，就一句话描述需要做一个什么样的功能，但是具体页面长什么样，交互是什么都没有定下来的时候，就要求给时间估算；
根据产品发布时间否定研发人员的时间估算；比如，我亲眼见过的，有个功能，五天之后要上线，研发估了7天；产品说，不行，重新估，五天后要发布；研发说，那这个功能七天做不完啊，加班也做不完啊。产品说，不行，那你想办法。于是研发妥协，好吧，估5天。产品很happy, 表示说，早说5天不就行了嘛。于是研发苦逼的去加班。要我说，在这种情况下，还估个P的时间啊，纯粹是浪费时间。
受限于现有代码框架导致花费时间肯定远超产品预期；我相信，很多研发人员都会听过产品的抱怨，不就加个XXXX吗，怎么就要两天，即使研发仔细的解释是由于现有代码框架问题或者之前不合理的设计导致的，多数产品还是觉得接受不了，即使他们完全不懂。
认为时间估算不准是不可接受的，是研发人员的水平问题；诚然，技术水平越好，对现有代码和业务流程越熟悉，越有经验的研发人员能够给出更靠谱的估算。可是，软件开发过程中存在很多不确定因素、需求的变更、需求未足够细化，技术实现和原有技术框架等等，都会影响最后的实际实施时间；更何况，研发人员并不是每天都保证所有的时间都可以花费在实现对应的需求上的。所以我个人是不赞同以时间估算是否靠谱来进行绩效考评的行为的。
bug无法准确估算时间；很简单，大部分修复bug时间是花在定位分析上，而不是花在解决上。能够准确估算的bug一定是已经找到了原因的，所以这个注定有些bug是无法准确估算时间的。
好吧，吐槽完毕，回顾一下我们原来走Scrum的时候是怎么进行时间估算的吧。这里不涉及到修改bug, 只涉及到新需求新功能。当时，我们所有的需求都会拆分成task的级别。
首先，能够拿到Scrum sprint中进行估算的task，其对应的需求一定明确的，经过评审的，研发人员与测试人员达成了共识的。说白了，尽量不要因为需求的变更和不明确影响到Scrum的执行；
其次，能够进入估算流程的task, 一定是经过技术角度或者功能角度的细致拆分的，具有清楚的描述的。Task的粒度越细，估算越准确。要去估算一个产品花费的时间，误差一定大；但是要估算写一个方法或者一个类的时间，相对来说要准确得多。对Task的拆分，很多时候是有架构师和技术经理完成，因为他们对产品的理解，技术上的理解都更深刻，也更熟悉现有的代码，清楚是否有可以复用的代码。
经过前面两步之后，应该到这样一种地步：团队里面的所有人去看这个task的描述的时候，都能够很清楚的知道，这个task做的事情是什么，可能的技术难点是什么，需要哪些交互，是否有现成的代码可以复用或者参考。说白了，这个task的实施好坏一般不会影响到架构的变化，因为在拆分task的时候，一定是先将架构定下来了才做得到。
在具体的估算的时候，我们那个时候是采用通用的扑克牌法。也就是每个人手上会有一些写着数字的牌子。当时好像是1，2，3，4，5，8，13，16，20这些数字；然后每个人根据自己的理解出牌，最后取一个相对平均的值。但是这个时候，如果有的人差异很大，尤其是最可能取这个task的人，估算差异与他人相差很大，那么一般来说，存在理解上的差异；这个时候就要看大家是不是真的理解了这个task了。
还有一点就是，如果最后得出的估算数字特别大，比如说，超过了两天了，那么这个task毫无疑问，还有不明确的地方或者还可以继续拆分的可能；要么继续拆分，要么在Scrum的实施过程中重点关注这些对应的task.
以上基本上就是大致的一个时间估算的流程。这样估算出来的，大部分情况下，是相对靠谱的，会因为团队成员的个人能力与实际的有一定差异，但是往往差别并不大。而且在估算和讨论的过程中，团队成员也能达到知识共享和信息交流的目的，非常有利于团队的成长。
当然，很多时候并没有那么理想化，并不是每个任务都可以做到那样的拆分。那么在这种情况下呢，有时候我们是直接不纳入sprint内部，而是会让部分资深的工程师或者架构师做一些预研的工作，铺铺路，踩踩坑，这个时候，虽然这个任务看上去花的时间还是不确定的，但至少所有人都明白项目的风险在哪里，而低风险的部分应该保证一定可以顺利的交互，完成迭代的目标。
其实，这种方法在具体的实施过程中也会有一些缺点。就我自己的感受而言，主要的缺点可能有下面两点：
1 负责任务拆分的架构师或者负责预研的资深工程师有时候会任务过重；根据上面的描述，往往需要在下一个sprint开始之前，就必须对backlog中的某些不明确任务进行拆分和预研，这个其实是比较费时间的，说白了，有些架构和设计的工作就是在这个时候完成的。而架构师和资深的工程师往往还承担着scrum中很多task的具体实现，如果时间分配不好，导致拆分工作没有做好的话，会成为整个scrum的瓶颈。一种缓解的办法就是，将架构，拆分，设计，预研也单独建立任务，纳入sprint, 容忍对这些估算的不准确性；
2 任务估算发生分歧时的讨论会比较费时；很多情况下，这些讨论是有意义的，但并不意味着对参与估算的每个人都很有意义。尤其是在团队构成还达不到Scrum所要求的“自组织”以及“互相可替代”的情况下。一些可以做的改进就是，允许任务无关人员放弃估算，投弃权票；另外就是，尽量不要拿时间估算与绩效挂钩。有些team leader会认为没有在估算的时间内完成是绩效不好，给出估算时间超过别人的时间是绩效不好，等等，这种其实都会影响到客观的估算。要相信团队成员会尽量给出客观的估算，也要鼓励团队成员做出客观的估算。如果不能做到对团队成员足够信任，或者leader认为团队成员不值得这种信任，那么就不要走Scrum, 也不要逼着团队成员给出估算，你都不信任自己的团队了，那还不如自己根据上司的意思随便填个数字就好了。
此外，还有一点就是，在Scrum的实施过程中，允许调整某些任务的估算，这个其实通过burn down图也很容易反映的。因为很多细节问题是在实施过程中才会发现的；调整估算能够更准确的反映当前项目的实际情况和风险。
在sprint的review meeting上，对估算的review也应该是很重要的一环。这有助于后续的sprint流程中做出更精确的估算，帮助项目更可控。例如，我们第一个sprint做完，就发现大家在估算的时候都漏掉了code review的时间：）