BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

故事点是什么?它们有必要么?

| 作者 Mark Levison 关注 0 他的粉丝 ,译者 郑柯 关注 3 他的粉丝 发布于 2010年3月7日. 估计阅读时间: 2 分钟 | Google、Facebook、Pinterest、阿里、腾讯 等顶尖技术团队的上百个可供参考的架构实例!

Michael de la Maza提出这样一个问题:故事点到底是什么东西?他不断寻找,并找到了很多答案,比如“故事点表示模糊的时间单元”,或者“故事点是Scrum团队使用的一种随机度量方式,用来度量实现一个故事需要付出的工作量”,还可能是“故事点数的估算混合了对于开发特性所要付出的努力、开发复杂度、个中风险以及类似东西”【引自Mike Cohn的《敏捷估算与规划》】。

Michael接下来记录了故事点的使用方式:“说实话,速度是度量生产力的一种方式”,以及与之相对的“使用故事点数或理想人天来度量生产力是坏主意,因为这会促使团队不断膨胀一个点数的内涵……”

面对这些迷惑,Michael开始思考故事点数到底是什么?你要怎么向新接触敏捷和Scrum的人介绍这个概念呢?

Dan Rawsthorne的回复是:

  1. 团队常常希望速度成为成产力的度量指标,这样就能跟外界其他人说自己的“速度有多快”。
  2. 如果故事点数在项目生命周期中能保持常量,速度才是有意义的度量指标。想做到这一点,团队必须找到一两个标准的故事,它们的大小在整个项目生命周期中都得保持不变。
  3. 如果“基线故事不仅在一个团队内部保持大小不变,而且在各团队之间也是如此,那么速度不仅可以用来度量生产力,还能用做不同团队工作效率的有效对比,并因此而成为组织内部的添加剂。”多说一句,这篇文章的作者非常反馈这个实践:速度在敏捷项目中的错误使用
  4. 一旦团队有了稳定的故事点数,它们就能被用在未来的发布规划中,用以得到即将成功完成的工作的大致估算。

Ron Jeffries的回复是:

故事点数是需要实现一个故事所付出时间的相对度量,借鉴于XP(故事这个概念也是如此)。它们应该被用来估算困难程度,而不是承诺一个特定的时间阶段,这样不同的团队规模或是任务上花去的时间就不会影响故事点数”。

他还说:

是的,它们用来度量规模和复杂度。使用‘规模’和‘复杂度’这两个词,是要表达‘用完成任务所需时间来表示难度’。”

最后,Ron说他(和其他专家)不再认为故事点数是必要的了。

InfoQ之前有关新闻:Sprint规划:故事点数 vs. 小时数

查看英文原文:What is Story Point? Are they Necessary?

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT