BT

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

速率究竟有何用?

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

雅虎的ScrumDevelopment讨论组近日有个话题讨论速率的各种应用和误用。Kurt Häusler描述了他对速率及其价值的理解:

嗨,速率是以上个迭代完成的故事点数来计算的。我不确定它是否适合做生产率指标。对我而言,它是一个中性的度量,作为一个工具,用来计算下个迭代该尝试多少故事点数。速率高低之于我,与好坏不一定相关。
但是速率是个很重要的工具,不过你得理解它的含义和作用;在我看来它就是用来计划下个迭代的,而非衡量生产率。

Kurt也承认这并非关于速率的唯一观点,如在Joe Little的博客 中写道:

...不超过6个月内,我们将使团队的速率翻倍。
倍增速率(每轮冲刺完成的故事点数)通常意味着我们必须做如下改善:
  • 更清晰地定义完成(或者你更喜欢用“完成之完成”(“done-done”))。我们对“完成”的定义经常很模糊。对某些故事通融是必须的,但对大多数软件的用户故事来说,“完成”必须得到清晰、一致的定义。而我的观点是,完成就意味着“没有(已知的)缺陷溜出该轮冲刺”,而且测试必须至少包含功能测试。
  • 必须测量速率。我发现好多团队都没有对速率的某种度量,这令人难以置信。以后我再展开讲,目前简而言之:“速率:走遍天下不可或缺。”
  • 必须对障碍分优先级,并持续消除或减弱优先级最高的障碍,直到速率得到翻倍。提示:我们也许可以通过消除/减弱障碍所能获得的速率提升大小对他们进行分级。这里25%,那里30%;很快你就会发现速率的实际提升了。

    提示:提升质量和减少技术债,这两点几乎总是重大速率提升的关键。不是唯一关键,但是极为重要。

Adam Sokra同意Kurt,也认为速率用来度量团队表现不太合适, 但是他认为速率应主要用于长远规划而非迭代计划。

用速率来度量表现是糟糕至极的做法,除非你的目的仅仅是要看到生产率如何随时间逐步稳定下来。人们习惯用速率来表达“上个迭代我们完成了X个点,所以这个迭代我们该尝试不多于X的点数”。但是我们中很多人已经开始相信,如此做出承诺的方法值得商榷。已经有人建议,我们只需承诺自认为每个迭代能够完成的工作量,这就够了。

速率用于长远规划最为合适。我可以看看我几个迭代的速率,提出一个平均值(区间值更好)。然后我就能用这一信息说出诸如:1)考虑目前的待完成清单(backlog),还需要多少轮迭代才可能完成给定数量的故事? 2)到日期X为止(比如要及时赶上贸易展),我能交付多少故事点数、以及哪些高优先级故事?

当然,还有不断增长的一个思想流派把计划看作是浪费行为

速率该被用作生产率指标吗?该被用于迭代计划吗?用于更长远发布的规划又怎样呢?它该被切实使用,还是只是浪费功夫呢?

查看英文原文:What is Velocity Good For?


译者简介:顾全,历史学科班出身,澳洲计算机硕士,工作于数据仓库行业多年。08年CSM认证后成为Agile的坚决拥护者和热心传播者。

志愿参与InfoQ中文站内容建设,请邮件至 editors@cn.infoq.com。也欢迎大家到InfoQ中文站用户讨论组参与我们的线上讨论。

评价本文

专业度
风格

您好,朋友!

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