6.2 如何更好地预估完成任务的时间？

[GreyZeng]

原文地址

在 6.2 中有

另一个改进是,要在每一个任务中记载我们完成这个任务还需要多少时间。

这个时间是基于开发人员的经验而预估。但是像软件开发这样复杂的工程项目，墨菲定律总是能发挥它的作用，总是有超出开发人员预料的因素导致实际开发时间和预估时间的不一致，而且一旦这种因素产生，往往会极大背离开发人员的预估时间，使得预估时间的统筹作用大大减弱。那么这种预估时间应该怎么预估才能使这个预估时间更有效地发挥作用。

[GreyZeng]

学期初我认为，预估时间是基于开发人员的经验得到，会因为意料之外的情况而与真实时间极大背离。

事实上可能也确实如此，在Alpha开发阶段，我们对任务的预估时间与真实开发时间存在不小的出入，进而导致开发过程出现了前松后紧的情况，这个预估时间也没起到太大的统筹作用。

而可以起到指导作用的预估时间应该怎么得到，我通过阅读这个博客似乎找到了一些线索，它给出了这样一些步骤：

1. 制定技术计划
2. 为每个步骤添加时间估算
3. 增加大量的额外时间
4. 在发布之后对估算进行回顾
5. 一切都是跟沟通有关

回顾Alpha阶段的开发过程，我们做的不好的地方是3和5：对开发流程过于乐观和出现问题时不及时沟通成了阻塞开发顺利进行的重要问题。

而在Beta阶段，我们做了一些改善，一是细化了issue的粒度，使得2的估算更加准确，同时留出缓冲区以满足3；二是指定PM和频繁的线下沟通使得开发过程不会被某个人的某个任务而阻塞。而最后的燃尽图也印证这种方式的可行性。

因此我认为这是一个可以参照的预估方式。

原文地址

[GreyZeng]

A3:对于我个人来说的话，完成任务的时间一般是我预估时间的1.5到2倍左右（从计划、编写、文档报告），但是有时候也会因为别的原因而大于这个范围；而对于团队完成任务的时间按书上来说一般也是预估的大概2到3倍，而且团队完成任务与自己开发不一样，还要考虑各种因素（比如沟通、个人原因问题等），这方面，还需要之后实际体验过才知道。
原文地址：https://bbs.csdn.net/topics/613013703