用户故事的时间估计答案

【问题标题】：Time estimation for a user story用户故事的时间估计
【发布时间】：2008-12-05 08:20:58
【问题描述】：

您如何估计实施用户故事所需的时间？如果这是您在知道需要多长时间之前就已经完成的事情。但是，如果它对您来说是全新的呢？你为“惊喜”预留了多少时间？

【问题讨论】：

【解决方案1】：

一个很好的技术是将故事分解成一些更小的任务，并估计它们相互比较（而不是绝对）。所以你可以说：

我们更擅长估计相对复杂性而不是绝对复杂性。然后您实际执行其中一项任务，并计算出实现 1 个单元需要多少“实时”时间 - 现在您可以计算所有任务。您会根据自己的进度不断更新估算值。

这项技术来自 Mike Cohn 的 Agile Estimating and Planning，这是一本关于该主题的好书。

【讨论】：

【解决方案2】：

在敏捷开发的 XP 学派中，他们主张您不要以实际时间进行估算，而是以任意单位进行估算。（他们使用“Gummy Bears”，但你可以使用任何东西）。您对实现该用户故事所需的单元数量进行最佳猜测。

没错，您可能错了，但您会在开发阶段进入一个阶段，进行几次迭代，此时您的猜测大部分是正确的，并且业务/客户很容易获得关于多少故事的准确预算它们可以包含在迭代中。

在难以估计的早期，一个好的经验法则是执行一项最简单的任务，并将其分配为 1。评估与该任务相关的其他用户故事，并尽力而为猜测。如果某件事太复杂，或者定义不够明确，你将不得不给它一个非常大的数字。

另一个关键概念是，您必须在每次迭代时重新评估每个用户故事的时间。随着您的故事得到更好的定义，并且随着您对速度的估计提高，您将获得更准确的故事时间。

至于惊喜，它与用户故事的估计无关......因为您没有用户故事来代表惊喜。

【讨论】：

【解决方案3】：

“Software estimation - demystifiying the black art”中的史蒂夫·麦康奈尔说得比我好：

"尽可能计算。计算何时你数不过来。单独使用判断只能作为最后的手段。”

（谢谢你提醒我这个：）

【讨论】：

【解决方案4】：

在我工作的地方实施的一种技术。对于每个用户故事，把它写在一张带标题的卡片上。让每个人拿一张卡片，并在上面写下他们认为完成所需的小时数。让他们把卡片放在任务上，而不是互相展示。获得所有结果后，查看数字并查看顶部和底部值。通常您会得到非常接近的数字。

对于那些远高于或远低于的值，请询问开发人员或提供输入的人员，为什么他们认为与平均水平相比需要如此长或如此短的时间。提出团队而非个人的共识意味着每个人都能接受任务。

这是我读过的一本关于敏捷技术的书中的一个想法，但忘记了作者的功劳。

【讨论】：