是不是所有的敏捷团队都真正理解故事点的用途呢？显然不是。Mountain Goat 软件的创始人 Mike Cohn 近期发表博文，重申了故事点的作用——用来估算完成产品特性所需要的相对工作量，而不是根据功能的复杂度进行排序所得到的排名值。
为了说清楚这两者的区别，Mike 通过买车来举例子。根据功能的复杂度进行排序的团队会先把车按价格排序，价格最低的车给一个点，并且从低到高给每辆车多加一点。如果给 Tata Nano 标一点，那么依次加下去，Bugatti 则是十点。这个例子告诉大家，利用故事点对产品待办事项列表进行排序会导致对成本的理解偏差，要知道，Bugatti 的成本几乎是 Nano 的 960 倍。
但为什么会有这样的问题呢？真的有敏捷团队搞不清楚用故事点是为了估量相对工作量、成本……而不是排序吗？这正是Tomas V 的疑惑：
我不得不问问：是什么让你想到要写这样的博文的？真有人在这么做吗？
Mike Cohn 很肯定。是的，确实有人在这么做：
嗨，Thomas——是的，怪就怪在，就是有人在这么做。我周六收到的一封电子邮件里就是这么说的，而发件人是个我觉得很不错的伙计，这才促使我写这篇博文。我当时很惊讶。为什么要这样去排序产品待办事项列表呢？我百思不得其解，可它确实就发生了。
亲爱的读者：你们见过团队乱用故事点估算技术的情况吗？你所在的团队是不是也把故事点当做排名值了……而不是用故事点来估算产品待办事项上的功能特性呢？
评论