6

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

您如何使用从过去估计中收集的信息来改进未来的估计？

4

5 回答 5

10

到目前为止，我见过的最有趣的实际调度方法之一是基于证据的调度，它是 FogCreek FogBugz 6.0 版本的一部分。有关概要和一些示例，请参阅上面链接的 Joel 博客文章。

于 2008-10-09T22:43:45.450 回答
3

如果估算结果超出预期，请尝试确定它是否只是随机的（环境破坏，一些曾经出现过棘手的错误等），或者是否存在您没有识别的东西。

如果估算值太大，请确定您认为会花费这么长时间的原因，并找出为什么没有。

做到这一点有望帮助开发人员进行估算。

例如，如果开发人员认为为控制器编写测试需要很长时间，然后最终花费的时间比他想象的要少，那么您对类似范围的控制器所做的下一次估计可以记住这一点。

于 2008-10-09T22:40:29.780 回答
2

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

于 2008-10-09T22:42:04.707 回答
2

我发现估计时间会让你走这么远。与其他任务、不可预见的情况或项目影响的中断将不可避免地改变你的时间框架，如果你不断地重新评估你会浪费很多时间来管理你可以开发的时间。

所以对我们来说，我们根据经验对时间解决方案进行初步估计（我们不使用模型，我还没有找到在我们的环境中运行得足够好的模型），但不要根据它来判断我们的 KPI，也不我们是否向企业保证这个截止日期会被击中。我们这里的开发方法很大程度上是被动的，它似乎很好地满足了我们的业务需求。

于 2008-10-09T22:43:21.333 回答
2

当估计不正确时，几乎总是有一个明显的原因，这会导致吸取教训。最近记忆中的：

  • 用户界面假定 .NET 功能不存在（插入新行并在 GridView 中内联编辑它的能力）；经验教训是在进行估算之前验证所选类的功能。这个错误花了一周的时间。

  • ftp 进程假设 FtpWebRequest 可以与银行的安全 ftp 服务器通信；事实证明，如果 ftp 服务器返回当前目录的反斜杠以外的任何内容，则此类存在已知错误；吸取的教训是用类名搜索“错误”和“问题”，而不仅仅是“教程”和“示例”，以确保没有“陷阱”潜伏。这个错误花了三天时间。

这些经验教训进入项目评估和开发“清单”文档，因此下一个项目不会忘记它们

于 2008-10-15T15:26:03.527 回答