Michael de la Maza 提出这样一个问题:故事点到底是什么东西?他不断寻找,并找到了很多答案,比如“故事点表示模糊的时间单元”,或者“故事点是Scrum 团队使用的一种随机度量方式,用来度量实现一个故事需要付出的工作量”,还可能是“故事点数的估算混合了对于开发特性所要付出的努力、开发复杂度、个中风险以及类似东西”【引自Mike Cohn 的《敏捷估算与规划》】。
Michael 接下来记录了故事点的使用方式:“说实话,速度是度量生产力的一种方式”,以及与之相对的“使用故事点数或理想人天来度量生产力是坏主意,因为这会促使团队不断膨胀一个点数的内涵……”
面对这些迷惑,Michael 开始思考故事点数到底是什么?你要怎么向新接触敏捷和Scrum 的人介绍这个概念呢?
Dan Rawsthorne 的回复是:
- 团队常常希望速度成为成产力的度量指标,这样就能跟外界其他人说自己的“速度有多快”。
- 如果故事点数在项目生命周期中能保持常量,速度才是有意义的度量指标。想做到这一点,团队必须找到一两个标准的故事,它们的大小在整个项目生命周期中都得保持不变。
- 如果“基线故事不仅在一个团队内部保持大小不变,而且在各团队之间也是如此,那么速度不仅可以用来度量生产力,还能用做不同团队工作效率的有效对比,并因此而成为组织内部的添加剂。”多说一句,这篇文章的作者非常反馈这个实践:速度在敏捷项目中的错误使用。
- 一旦团队有了稳定的故事点数,它们就能被用在未来的发布规划中,用以得到即将成功完成的工作的大致估算。
Ron Jeffries 的回复是:
故事点数是需要实现一个故事所付出时间的相对度量,借鉴于 XP(故事这个概念也是如此)。它们应该被用来估算困难程度,而不是承诺一个特定的时间阶段,这样不同的团队规模或是任务上花去的时间就不会影响故事点数”。
他还说:
是的,它们用来度量规模和复杂度。使用‘规模’和‘复杂度’这两个词,是要表达‘用完成任务所需时间来表示难度’。”
最后,Ron 说他(和其他专家)不再认为故事点数是必要的了。
InfoQ 之前有关新闻: Sprint 规划:故事点数 vs. 小时数
评论