project-planning - 用户故事的时间估计

Question

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

Answer 1

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

• 任务 A 将占用 2 个单元（任意）
• 任务 B 大约是任务 A 的 2 倍（4 个单元）
• 任务 C 大约有一半复杂（1 个单元）

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

这项技术来自Mike Cohn的敏捷估计和规划，这是一本关于该主题的好书。

Answer 2

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

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

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

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

至于惊喜，它并不真正影响用户故事的估计......因为你没有用户故事来代表惊喜。

Answer 3

史蒂夫·麦康奈尔在“软件评估 - 揭开魔法的神秘面纱”中说得比我好：

“尽可能数数。当你不能数数时计算。仅将判断作为最后的手段。”

第 7 章 - 计数、计算、判断(PDF)。

（感谢您提醒我这一点：）

Answer 4

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

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

这是我读过的一本关于敏捷技术的书中的一个想法，忘记了作者将其归功于他们。