估计任何特定任务将花费多长时间似乎是软件开发中最困难的部分之一。在我目前的商店，我们在迭代开始时以小时为单位估算任务，但是一旦任务完成，我们就不会在未来的估算中使用它来帮助我们。
您如何使用从过去的估算中收集的信息来改进未来的估算？
答案 0 :(得分：10)
到目前为止，我见过的最实用的调度方法之一是Evidence Based Scheduling，它是FogCreek FogBugz 6.0版本的一部分。请参阅上面链接的Joel的博客文章，以获取概要和一些示例。
答案 1 :(得分：3)
如果估计值已经消失，请尝试确定它是否是随机的（环境破坏，一些一次性的棘手错误等）或者是否有某些您未识别的内容。
如果一个esimate太大了，那就找出你认为需要这么长时间的东西并弄清楚它为什么没有。
这样做足以帮助开发人员做出估计。
例如，如果一个开发人员认为对控制器进行编写测试需要花费很长时间，然后最终花费的时间比他想象的要少，那么您对类似范围的控制器的下一个估计就可以记住
答案 2 :(得分：2)
我与队友迭代地估计，直到我们达成共识。当然，我们犯了错误，但我们没有明确地计算“速度”因素，而是我们在新的估计辩论中使用了经验。
答案 3 :(得分：2)
我发现估计时间会让你到目前为止。与其他任务的争执，不可预见的情况或项目影响将不可避免地改变你的时间框架，如果你经常重新评估，你将浪费很多时间管理你可能正在发展。
因此，对于我们这里，我们根据经验对解决方案进行初步估计（我们不使用模型，我没有找到一个在我们的环境中运行良好的模型），但是不要判断我们的关键绩效指标它，我们也不向业务部门保证这个截止日期将会受到影响。我们的开发方法在很大程度上是被动的，它似乎很好地满足了我们对业务的要求。
答案 4 :(得分：2)
用户界面假定不存在的.NET功能（能够插入新行并在GridView中内联编辑）;学到的经验教训是在提交估算之前验证所选类的功能。这个错误花了一周时间。
ftp进程假设FtpWebRequest可以与银行的安全ftp服务器通信;事实证明，如果ftp服务器返回当前目录的反斜杠以外的任何内容，则此类存在已知错误;所吸取的教训是谷歌搜索“bug”和“问题”与类名，而不只是'教程'和'示例'，以确保没有'陷阱'潜伏。这个错误花了三天时间。
这些课程将进入项目评估和开发“清单”文档，因此不会忘记下一个项目