领导力大挑战
在实施Scrum项目的过程中，Scrum Master的角色是相当关键的，因为他是团队的推动者。本文围绕什么是仆人式领导、仆人式领导的起源、如何将领导力传达给团队、Scrum Master作为仆人式领导者的角色展开叙述，同时重点阐述仆人式领导者应有的基本内外特征。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
速率究竟有何用？
作者 Amr Elssamadisy 译者 顾全 发布于 2009年7月9日
雅虎的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中文站用户讨论组参与我们的线上讨论。
没有回复
关注此讨论 回复