代码之家  ›  专栏  ›  技术社区  ›  grigy

用户故事的时间估计

  •  5
  • grigy  · 技术社区  · 16 年前

    你如何估计实现用户故事所需的时间?如果这是你在知道需要多长时间之前所做的事情。但如果这对你来说是全新的呢?你为“惊喜”预留了多少时间?

    4 回复  |  直到 16 年前
        1
  •  6
  •   orip    16 年前

    一个很好的技巧是将故事分解为更小的任务,并对其进行估计 相互比较 (而不是绝对)。所以你可以说:

    • 任务A将需要2个单位(任意)
    • 任务B的复杂性大约是任务A的2倍(4个单元)
    • 任务C大约一半复杂(1个单元)

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

    这项技术来自 Agile Estimating and Planning 迈克·科恩,这是一本关于这个主题的好书。

        2
  •  2
  •   Justin Standard    16 年前

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

    诚然,你可能错了,但你会在开发中遇到一个阶段,在几次迭代中,当你的猜测基本正确时,企业/客户很容易得到一个迭代中可以包含多少故事的准确预算。

    在很难估计的早期,一个很好的经验法则是,把最简单的任务之一分配给1。评估彼此的用户故事,并给出最佳猜测。如果某件事太复杂,或者定义不够明确,你将被迫给它一个非常大的数字。

    另一个关键概念是,每次迭代都必须重新评估每个用户故事的时间。随着你的故事被更好地定义,随着你对速度的估计的提高,你会得到更准确的故事时间。

    至于惊喜,这与用户故事的估计无关。..因为你没有用户故事来代表惊喜。

        3
  •  2
  •   philant    16 年前

    史蒂夫·麦康奈尔在“ Software estimation - demystifiying the black art “说得比我好:

    “如果可能的话,数一数。计算何时 你数不过来。仅凭判断 这只是最后的手段。"

    Chapter 7 - Count, Compute, Judge (PDF)。

    (谢谢你提醒我:)

        4
  •  0
  •   anonym0use    16 年前

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

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

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

    推荐文章