如何优化您的估算过程？

Question

估计任何给定任务将花费多长时间似乎是软件开发中最困难的部分之一。在我目前的商店中，我们估计在迭代开始时以小时为单位的任务，但一旦任务完成，我们就不会用它来帮助我们进行未来的估计。

您如何使用您从过去的估算中收集的信息来优化未来的信息？

Answer 1

到目前为止，我所见过的最有趣的方法之一就是Evidence Based Scheduling，它是FogCreek FogBugz 6.0发行版的一部分。请参阅上面链接Joel的博客文章以获取摘要和一些示例。

Answer 2

如果一个估计被吹掉了，试图确定它是否只是随机的（环境破坏了，有些人一旦掉了一个棘手的bug等），或者有些东西是你没有识别的。

如果一个esimate太大，找出你认为这会花费那么长时间，并找出为什么它没有。

这样做有希望能够帮助开发者进行估算。例如，如果开发人员认为为控制器编写测试需要很长时间，然后最终花费的时间比他想象的要少，那么对于类似范围的控制器所做的下一个估计可以保留心神。

Answer 3

我估计会和我的队友们迭代，直到我们达成共识。当然，我们犯了错误，但我们并没有明确计算“速度”因素，而是在我们的新估计辩论中使用了收集的经验。

Answer 4

我发现到目前为止估算时间会让你满意。与其他任务的干扰，未预见的情况或项目影响将不可避免地改变你的时间框架，如果你不断重新评估，你会浪费很多时间来管理你何时可以开发。

因此，对于我们这里，我们给出了一个基于经验的初步估计，以解决时间问题（我们不使用模型，我没有发现在我们的环境中工作得很好的模型），但不要评估我们的KPI反对它，我们也不保证业务这个最后期限将会受到打击。我们在这里的发展方式在很大程度上是被动的，它似乎很好地满足了我们业务对我们的要求。

Answer 5

估计结束时，几乎总是有一个公然的原因，这导致了一个教训。从内存中最近的：

• 用户界面假定不存在（插入新行，并在GridView内嵌编辑的能力）.NET功能;吸取的教训是在提交估计之前验证所选类别的功能。这个错误花了一个星期。

• ftp进程假定FtpWebRequest可以与银行的安全ftp服务器通话;事实证明，如果ftp服务器为当前目录返回除反斜杠之外的任何其他内容，则该类存在已知的错误;经验教训是谷歌的错误和类问题的'问题'，不只是'教程'和'示例'，以确保没有'陷阱'潜伏。这个错误需要三天时间。

这些教训进入一个项目评估与发展“清单”的文件，所以他们不会忘记为下一个项目