故事点的好处

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

使用故事点来估算产品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点。

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

原文地址:http://www.mountaingoatsoftware.com/blog/the-main-benefit-of-story-points