故事点可不是这么用的!

  • Christopher R. Goldsbury
  • 金毅

2012 年 5 月 13 日

话题:敏捷Scrum语言 & 开发架构文化 & 方法

是不是所有的敏捷团队都真正理解故事点的用途呢?显然不是。Mountain Goat 软件的创始人Mike Cohn近期发表博文,重申了故事点的作用——用来估算完成产品特性所需要的相对工作量,而不是根据功能的复杂度进行排序所得到的排名值。

为了说清楚这两者的区别,Mike 通过买车来举例子。根据功能的复杂度进行排序的团队会先把车按价格排序,价格最低的车给一个点,并且从低到高给每辆车多加一点。如果给 Tata Nano 标一点,那么依次加下去,Bugatti 则是十点。这个例子告诉大家,利用故事点对产品待办事项列表进行排序会导致对成本的理解偏差,要知道,Bugatti 的成本几乎是 Nano 的 960 倍。

但为什么会有这样的问题呢?真的有敏捷团队搞不清楚用故事点是为了估量相对工作量、成本……而不是排序吗?这正是 Tomas V 的疑惑:

我不得不问问:是什么让你想到要写这样的博文的?真有人在这么做吗?

Mike Cohn 很肯定。是的,确实有人在这么做:

嗨,Thomas——是的,怪就怪在,就是有人在这么做。我周六收到的一封电子邮件里就是这么说的,而发件人是个我觉得很不错的伙计,这才促使我写这篇博文。我当时很惊讶。为什么要这样去排序产品待办事项列表呢?我百思不得其解,可它确实就发生了。

亲爱的读者:你们见过团队乱用故事点估算技术的情况吗?你所在的团队是不是也把故事点当做排名值了……而不是用故事点来估算产品待办事项上的功能特性呢?

查看英文原文:That's How You're Using Story Points? No Way.

敏捷Scrum语言 & 开发架构文化 & 方法