class="topic_img" alt=""/>
英文原文：Concerns about Measuring Velocity for Team Improvement
敏捷团队需要测量其 Sprint 速率，以帮助团队计划并跟踪其进度，同时也为产品所有者规划产品发布提供洞见。那么当团队想要改进自身的时候，是否也可以使用速率数据？若干作者围绕速率撰文，并针对测量速率以改进团队生产力分享了各自的关注点。
Catia Oliveira 在 Scrum 联盟网站上发表了一篇文章：如何计算并使用速率，以帮助我们的团队和项目。她总结了测量速率对团队的帮助如下：
如果了解了团队的速率，那么我们将能够了解：
她还列出了一系列能够对速率产生影响的因素：
George Dinwiddie 编写了一篇题为跟踪速率的博客文章。在文章中他表示，由团队测量速率是有帮助的行为，因为它会帮助我们了解团队工作情况如何。但是他也针对使用速率数据来测量生产力给出了警告：
速率并不是对生产力的模拟，然而人们很容易陷入这种思维陷阱。“在一次 Sprint 中，我们可以完成的故事点总量是 28 个。”但 28 个故事点并不是工作总量，而是一种预估。（……）我们可以使用更多的故事点进行预估，或是将工作切分为更小的故事，以此来轻易地操纵这种预估的总量。这是如此简单，我们可能在不经意或非刻意的情况下就这么去做了。
（……）尽管速率也许能够用来大略地跟踪生产力，但随着我们试图这样使用它来促进生产力提升而失效。
2012 年，Tim Ottinger 发表了一篇博客文章观察敏捷团队速率发现的 14 件怪事，在其中针对他经常遇到的关于速率的问题，给出了一系列答案。他首先表示，虽然我们可以测量速率，但却无法直接地控制它：
速率是一套“测量仪表”，而不是“控制旋钮”。我们不可能简单地将它调高——这样做只会让我们把它弄坏。
Tim 认为，团队绩效提升与团队速率测量结果之间的关系，可能会非常复杂：
当团队表现提升时，要么速率上升而故事点大体保持不变，要么速率基本相当而分配给每个故事的故事点有所减少。然而，在某种程度上，很多时候二者都会出现。这也正是我们无法跨团队比较速率的原因之一（当然，还有其他许多原因）。
在博客文章速率并非目标中，Jeremy Jarrell 解释了对敏捷团队来说，为何拥有可预测的速率非常重要：
对组织机构来说，始终如一地施行高速率的团队是非常宝贵的。而那些往往更不稳定的团队——在一个 Sprint 中落实高速率，而在接下来的则出现大幅下跌——将不像它们最开始表现出的那样有价值。
其原因在于，速率的价值无法与可预测性相比拟。在敏捷团队中我们所做的许多事情，都是以增加团队可预测性为目标而完成的。团队可预测性越高，我们对未来的规划就越高效。这让我们能够更聪明地面对风险，并且基于我们的团队在给定的时间表中有能力交付哪些东西，来制定更加现实的战略。
对于想要变得更加具有可预见性，同时又希望自身速率得到提升的团队，Jeremy 给出了一些解决方案：
那么，是否这就意味着团队不应该努力测量出自己的速率？其实并非如此，而是意味着团队不应该以提高速率作为其目标。与之相反，团队应该专注于为提高速率所需采取的那些行动。采用这类实践将自然而然地得到更高的速率，例如持续改进工程流程，或是系统地识别并消除风险。
Nathan Dintenfass 撰写了博客文章敏捷的语言已经衰败，在其中他提到了使用速率数据来提高团队生产力时面临的一些风险：
速率作为生产力的可量化测量指标，对大部分团队在改变自身流程方面设立的目标来说具有毁灭性的影响。管理者往往希望对完成更多故事点的员工给予更多奖金，以这种方式来提高速率。然而，这种态度完全走入了歧路，激励机制会带来明显的“腐化”——特别是当团队找到了一些让故事点“通胀”的理由，或是为了团队自身的原因而给出更大数字的时候。实际上我们想要的，是真实坦率地对相关难度进行评估，从而能够准确且满怀信心地测量在我们可以给定周期内完成哪些工作。如果速率褪变为某些不良内容，而不是可供参考的估算（以及承诺），它将会对制作出良好的软件产生完全负面的作用。
Tim Ottinger 总结了他对敏捷团队速率的观察，对此他表示：
速率最大的问题，来自于不理解它却又将它当作生产力或繁忙程度的通用指标。使用速率的诀窍在于，不要过分严肃地对待它；同时，应该以改进我们的工作系统和组织机构为重点，而不是提升团队的速率。
相关文章
