BT

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

是否应该为Bug分配故事点数?

| 作者 Dan Puckett 关注 1 他的粉丝 ,译者 鲍央舟 关注 1 他的粉丝 发布于 2011年1月31日. 估计阅读时间: 3 分钟 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。

在将一个项目迁移至Scrum时,经常会面对一份Scrum时代之前的缺陷列表。如何最好地处理这份缺陷列表呢?Mike Cohn推荐向以前的缺陷分配故事点数,并用标准的Scrum流程在每个Sprint对他们排序:

我通常推荐对缺陷修复分配故事点数。...那样,我们不仅能看到团队真正能完成多少工作,也能通过历史数据看出每个Sprint中花在修复缺陷上的工作量。知道这些对团队和产品负责人都很有用。比如,假想一种情况,产品负责人考虑在接下来的6个Sprint中暂停缺陷修复,为的是在下一次发布中增加一个有用的新功能。如果我们知道团队的历史平均速率是25,但是其中5点花在缺陷修复上,那我们就可以知道暂停下6个Sprint的缺陷修复工作可以增加 30(6*5)个点数的新功能。

除了Mike Cohn推荐的Sprint排序策略外,Charles Bradley想要有更多的选择,让开发团队在Sprint之内修改缺陷。

...PO可以排序缺陷的优先级使他们出现在Sprint中,开发团队也可以任意挑选他们认为需要修改的缺陷(不管缺陷是否在Backlog中),并且把它列为Sprint中的一个任务(他们不会为此得到速率中的点数,无论缺陷是否在Backlog中)。只有开发团队可以决定在一个Sprint中做多少产品Backlog条目,所以,如果他们决定花Sprint中50%的时间来修复PO没有排序的缺陷,那就只能这样。但这会清晰可见,因为他们的速率会减慢。

Jack Milunsky在处理遗留缺陷和当前Sprint产生的缺陷之间做了一个重要的区分:

如果要向缺陷分配故事点数,那只能分配给遗留缺陷。这对PO绝对有好处,特别是质量。在Sprint中发现和解决的缺陷不应该被分配故事点数,因为这会影响速率,造成团队工作更快的假象。

如果是在Scrum实施中产生的,由于一些原因在Sprint验收中漏掉的缺陷,我们应该分配故事点数嘛?也就是说,在之前Sprint认为“完成”的用户故事中发现的缺陷应该怎么办?Ron Jeffries写到

如果由于某些原因一个故事已经完成,然后发现了一个缺陷,而那个故事已经被记录在速率中,那速率是虚高的。我们应该做什么?一种做法是从我们的进度条中去掉那些量,当缺陷被修复后再把那些量加回去。这可能更准确,但却不必要。

我们所要做的,只是计算下次做完的故事。花在修复缺陷的时间不算在内。我们的进度线从现在开始减少了一个故事。这条线虚高了一阵子,但现在又恢复了。

注意,修复错误的时间可能比构建一个出错故事的时间要短,或者长。无论如何,正确 完成故事所必须的时间,以及完成故事的数目,对那个故事来说会回归平衡。不需要估计,不需要解释为什么我们应该如对待好事般对待一个明显的浪费。

查看英文原文:Should You Assign Story Points To Bugs?

评价本文

专业度
风格

您好,朋友!

您需要 注册一个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