故事点的主要好处

本文转自：Scrum 中文网

如果说故事点是对正在做的事情的时间（工作量）进行估计，那为什么不直接估算出要多少个小时或多少天呢？为什么要使用故事点呢？

使用故事点来估算产品 backlog 条目的原因有很多，我在敏捷估算和计划课程的视频中已经很充分地探讨过，但是，我今天想说的是，故事点本身就自带一个令人信服的理由。

这里得先说说国王亨利一世（公元 1100 年到 1135 年在位）。在他继位之前，“一码”这个计量单位是从一个人的鼻子到他伸出的大拇指间的距离。想象一下，每个人的这个距离都是不同的，这该有多混乱啊？

亨利一世最终确定“一码”就等于国王的鼻子到伸出的拇指之间的距离。这样，就有了一个标准的计量单位，即方便了国王自己，也方便了所有人。

你可能知道，一码比自己自己的胳膊要长点或短点。我也是。但还好，我们有一个共同的计量单位。

故事点数可以用这个故事进行类比。就像英国的度量单位“码”一样，它允许不同技术水准的团队成员能在沟通后得到一个估算值。比如你和我决定出去跑步。我喜欢跑步，但是我跑得很慢。而你，相反跑得很快。你指着一条跑步路线说：我们跑这条路吧，这大概要花 30 分钟。

这条路我很熟，但是作为一个比你跑的慢的人，我心里清楚这要花我 60 分钟。所以，我告诉你，我和你一起跑这条路，但是需要 60 分钟。

所以我们争执起来 30,60,30,60.

我们争执半天没有结果。也许我们可以妥协一下，需要 45 分钟?但是这也许是最坏的结果。因为我们虽然有了一个估算结果，但是，这个结果对大家都没什么好处。

所以，我们继续争论。30,60,30,60.

最终，你跟我说：Mike，这段路大概 5 英里，我能在 30 分钟内跑完它。

我说：我同意这段路程是 5 英里。但它要花我 60 分钟。

问题是我们两个都是对的。你真的能在 30 分钟内跑完，我也真的需要 60 分钟。当我们为这段路程加上时间估算，我们发现不能这样做，因为大家工作（跑步）的速率不同。

但是，当我们使用了一个抽象的度量衡这个例子里是英里我们就能达成一致。你和我都同意这段路程是 5 英里。我们仅仅在它要花费我们多长时间上意见不同。

故事点跟这差不多。它能使不同技术水平和工作速度的人在估算结果上保持一致。当然，这里的主角是具有不同产出率的程序员，而不是本例中跑得快的人和跑得慢的人。

就像这两个跑步的人，两个程序员也许同意一个用户故事是 5 个点（而不是 5 英里）。快一点的程序员可能觉得这很容易，1 天就能完成。那个慢点的程序员可能觉得需要 2 天才能搞定。但是他们能在 5 个故事点这一点上达成一致。因为把第一个用户故事定成 5 个故事点是不需要什么依据的。

不过，最重要的是，一旦他们同意第一个故事是 5 点，这两个程序员就可以达成后续的估计。如果快速程序员认为一个新的用户故事将需要两天（两倍于他估计为 5 点的故事），他将评估新的故事为 10 点。而另一个程序员也会这样做，当她需要四个工作日（两倍于她估计为 5 点的故事），她将评估新的故事为 10 点。

综上，就像定义了国王亨利的鼻子到他的拇指的距离，故事点的定义就能使不同速度的程序员在估算时能达成一致。