BT

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

对于有经验的团队,有没有一种更好的估算方法?

| 作者 Vikas Hazrati 关注 0 他的粉丝 ,译者 金毅 关注 0 他的粉丝 发布于 2010年11月16日. 估计阅读时间: 3 分钟 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。

软件估算的结果对于利益关系人进行人员和预算安排而言是很重要的。敏捷中,流行最广泛的估算技术就是基于共识的计划扑克。这种估算方式是不是太花时间了?对于有经验的团队,是不是有别的可供使用的估算方法呢?

Kane Mar曾经介绍过一种由Lowel Lindstrom发明的相似估算法(Affinity Estimating)。这种方法是:委派一个成员向团队念一下故事描述,随后团队把故事卡片按照他们认为的大小顺序横向地贴在墙上,整个过程不许讨论

Kane提到,用这种方法,团队在很短的时间内就可以估算出30个用户故事。kane分享了大家对这个流程的反馈意见:

我喜欢这种估算方法,有很多理由:快速简单;自然;整个决策过程可视化;最后,相似估算法使得估算不再是互相对抗性的,而是一种愉快的合作。

Boris Gloger发明了一种类似的估算方法,叫做魔术估算法(Magic Estimating)。David Campey提到,通过使用这种“魔术估算法”,他们能够在10-15分钟内估算100-200个用户故事。 而据David介绍,用计划扑克的话,每估算一个故事需要1-3分钟。他认为这种差别主要体现在两种方法的规则上:

计划扑克的规则是整个团队一起坦诚地讨论每个用户故事,从而希望把它们都理解透彻。这样当参阅故事卡片的时候,大家能达成一致。
魔术估算法则并行进行,每个参与者运用自己的评价方式去做估算。

David详细描述了它的机制,并且认为利用这种方法,他们还解决了对于开放性故事(fallout story)的估算。所谓开放性用户故事,就是指那些估算结果争议很大或者故事点数在100+的故事。团队针对这些故事进行讨论,产品负责人可以提供更多的细节内容。David认为这一方法汲取了瞬间决定(Blink)理论的要义,从而让估算快速、有效起来。他提到:

在试用之前,我觉得这个方法可能还行,但从能否获得好的估算结果这一点而言,应该比不上计划扑克。现在,我觉得它并不比计划扑克差。计划扑克重在交流,而这种估算方法大家可以独立完成,就像在变魔术。
没有了玩计划扑克所作的交流,也就避免了争论。正如Oscar Wilde所说的:“要避免争论,争论总是俗不可耐,而常常令人信服。”

Roger Brown认为,由于这种方法在估算过程中不允许讨论,就必然会在阐明用户故事和设计方面有所缺失。这是一个很大的缺点。作为对Roger的回应,Kane Mar指出虽然用这种方法前期也有某种程度上的讨论,但绝对不会像计划扑克中的那么深入。

Kane补充道:

我觉得有些方法适用于新组建的团队,而有些方法有经验的团队用起来更好。我个人认为相似估算法就属于后者。我只会在有经验的团队中使用这种方法。

因此,尽管相似估算法和魔术估算法似乎比较快速、有趣,但它们却缺少了计划扑克中的详细讨论。

你怎么看,哪种方法适合你呢?  

评价本文

专业度
风格

您好,朋友!

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

获得来自InfoQ的更多体验。

告诉我们您的想法

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

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

用过这种方法 by 胡 凯

对于发布级别粒度较粗的故事,这种方法简直是完美的,可以在几个小时内让团队达成一致,而从前我们用扑克要做好几天。

允许的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通知我

1 讨论

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


找回密码....

Follow

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

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

Like

内容自由定制

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

Notifications

获取更新

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

BT