用户故事的时间估计

Question

您如何估算实施用户故事所需的时间？如果你知道它需要多长时间，那就是你做过的事情。但是，如果它对你来说是全新的呢？你为“惊喜”预留了多少时间？

Answer 1

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

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

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

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

Answer 2

在敏捷开发的XP学校，他们提倡你不要在实际时间内估算，而是以任意单位估算。 （他们使用“小熊”，但你可以使用任何东西）。您可以为实现该用户故事所需的单位数量分配最佳猜测。

是的，你可能错了，但是当你的猜测大部分是正确的时候，你会在你的开发中经历一个阶段，几次迭代，并且企业/客户很容易获得有关故事的准确预算它们可以包含在迭代中。

在很难估计时，早期的一个好的经验法则是采取最简单的任务之一，并将其​​分配给值1.评估与此相关的用户故事，并给予最好的猜测。如果某些事情太复杂，或者没有明确定义，你将被迫给它一个非常大的数字。

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

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

Answer 3

史蒂夫麦康纳在“Software estimation - demystifiying the black art”中说它比我更好：

  

“尽可能计算。计算何时   你不能指望。单独使用判断   只作为最后的手段。“

Chapter 7 - Count, Compute, Judge（PDF）。

（感谢您提醒我：）

Answer 4

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

对于上述或以下方式的那些价值，请向开发人员或输入人员询问为什么他们认为与平均值相比需要这么长时间。得出团队的一致意见而不是个人意味着每个人都能完成任务。

这是一本关于敏捷技术的书中的一个想法，并且忘记了作者将它归功于它。