BT

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

为了更准确的速率,重新估算已经完成的故事?

| 作者 Dan Puckett 关注 1 他的粉丝 ,译者 石永超 关注 0 他的粉丝 发布于 2010年11月9日. 估计阅读时间: 3 分钟 | GMTC大前端的下一站,PWA、Web框架、Node等最新最热的大前端话题邀你一起共同探讨。

最近在Scrum开发组的邮件讨论中, Paul Battison询问在sprint结束后,他的团队是否应该重新估算已经完成的故事,以便让团队的速率反映出团队完成故事实际投入的精力。

粗略的共识是什么?不要对已经完成的故事进行重新估算。

因为故事一旦完成,重新进行估算没有多大价值。 Kelly Waters解释了原因

速率之美在于:统计结果表明,它可以弥补不良估算。对于计划外任务,例如,一个估算为3个点的用户故事实际上可能需要13个点才能完成——但团队还是只估算为3个点。这种结果说明,团队的速率低于预期,意味着团队以后做Sprint计划时要以更加实际的目标为根据,要基于团队的实际速率,而实际速率基于他们估算用户故事时的预测。

经过几个Sprint后,团队的速率自然会因此调整,以适应那些惯于估计过低或过高的故事估算。速率自己会变得更加准确——没必要事后去做调整,让它与实际一致。

事实上,对已经完成的故事调整估算,不仅没什么用处,更可能是有害的。 Pual Oldfield写道

……如果你调整backlog,那么你现在的速率就会变得靠不住。准确预测未来几轮迭代,会有多重要呢?回到一个合理可靠的速率上可能需要相当长的时间。

估算故事的主要意图是决定团队的速率。什么是速率?根据Scrum联盟上的描述:

在Scrum中,速率是一个团队在一个sprint中可以处理的产品backlog的工作量。

事后调整估算会降低速率对未来sprint的预测能力(通过混合在sprint前所做的故事估算和sprint结束后对故事的“估算”)。比较解释这两种估算是非常困难的——也许是不可能的。

是否绝对不应该重新估算已经完成的故事?几乎从不需要,但也有例外。 Mike Cohn写道

一般来说,当原有估算完全一团糟的时候,重新估算是有用的,但你可以看到这种错误很少会发生。(也就是说,如果每个估算都系统地削减为一半,我不会重新进行估算。)其次,当相对大小改变时,你应该重新进行估算。例如,团队发现学习AJAX比设想的难易程度要简单一半。我们想要修正估算,因为新的知识告诉我们,对于严重依赖AJAX的故事而言,我们的相对估算不太平衡。

一般而言,如果故事已经完成,那么最好不要再去更改它的估算。基于目前你了解的情况,你会非常冲动,想要去修正那些估算,但绝大多数情况下,应该克制这种冲动。

查看英文原文 Re-estimate Completed User Stories for a More Accurate Velocity?

评价本文

专业度
风格

您好,朋友!

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