是不是所有的敏捷团队都真正理解故事点的用途呢？显然不是。Mountain Goat 软件的创始人 Mike Cohn 近期发表博文，重申了故事点的作用——用来估算完成产品特性所需要的相对工作量，而不是根据功能的复杂度进行排序所得到的排名值。
为了说清楚这两者的区别，Mike 通过买车来举例子。根据功能的复杂度进行排序的团队会先把车按价格排序，价格最低的车给一个点，并且从低到高给每辆车多加一点。如果给 Tata Nano 标一点，那么依次加下去，Bugatti 则是十点。这个例子告诉大家，利用故事点对产品待办事项列表进行排序会导致对成本的理解偏差，要知道，Bugatti 的成本几乎是 Nano 的 960 倍。
但为什么会有这样的问题呢？真的有敏捷团队搞不清楚用故事点是为了估量相对工作量、成本……而不是排序吗？这正是 Tomas V 的疑惑：
我不得不问问：是什么让你想到要写这样的博文的？真有人在这么做吗？
Mike Cohn 很肯定。是的，确实有人在这么做：
嗨，Thomas——是的，怪就怪在，就是有人在这么做。我周六收到的一封电子邮件里就是这么说的，而发件人是个我觉得很不错的伙计，这才促使我写这篇博文。我当时很惊讶。为什么要这样去排序产品待办事项列表呢？我百思不得其解，可它确实就发生了。
亲爱的读者：你们见过团队乱用故事点估算技术的情况吗？你所在的团队是不是也把故事点当做排名值了……而不是用故事点来估算产品待办事项上的功能特性呢？
暂无签名
最新发布
QCon 北京路宁专访：精益开发
2012 年 5 月 16 日
熊节谈精益在软件开发中的应用
2010 年 12 月 21 日
讨论：Scrum 回顾会议怎么开最有效？
2009 年 6 月 8 日
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
参数化陷阱与 DSL 缺陷：K8s 声明式应用管理的实践与教训
中小前端团队 Team Leader 的管理之路
大规模时间序列数据的分析和预测
评论