比较不同团队的速度毫无意义

敏捷项目管理中经常被诟病的一点是：由于故事点因团队而异，所以无法确定一个团队相较于其它团队在进度上的快慢。敏捷人士们普遍认为：比较团队间的速度并非明智之举，作为一种反模式，大家最好敬而远之，免得祸及总体生产率。

Sterling Barton认为团队的速度取决于多种因素。速度可以被归纳为如下函数：

  f（sprint长度，团队构成，估算方式，产品）

所有这些因素都因团队而异，因此团队间的速度是无法比较的。

Danilo Sato同样提到：由于速度依赖于如此多的因素，所以只有在一个团队内对速度进行比较才合情合理。也就是说应该通过比较趋势来度量团队的进度。他提出：

“为什么说团队A比团队B慢呢？”也许是因为他们估算的尺度不同？也许他们迭代的长度不同？也许团队构成有差别？这么多的因素都能影响速度，那么速度只有在同一团队中做比较才有用，即使只是为了识别趋势。速度的绝对值没那么重要。

Bob Hartman还提到了比较团队间速度可能导致的更深层次弊端，这些团队可能通过更改他们故事点尺度的方式让他们的速度看起来比别的团队更好。

然而，大多数管理者们都争论说要有某种机制形成团队间的故事点基线，以便于有效地类比。Mike Cohn曾试图通过如下方式确定故事点的共同基线：他从各个团队组织一批人，让大家一起估算十二个backlog任务条目。Mike主持了这个过程，一共有46人参与其中。他说道：

当那个会议结束后，每对估算者都带着12个估算案例回到了他们的团队中。这些估算可以在未来的估算工作中充当基准。当每个团队估算新的backlog任务时，他们会拿自己的估算和最初的12个以及基线形成后所做的任何估算（可能是他们做的，也可能是其他团队的）做对比。

但Mike紧接着又提到了此实践中一个常犯的错误。他说团队间一旦有比较，他们会让故事点逐渐“膨胀”，以此来应对同级压力。

举个例子，试想一下，一个团队正在讨论某个故事应该被估算为5个点还是8个点。如果团队受压力所迫（不管是真有压力，还是感觉上），觉得需要提高速度，那么他们会更倾向于给它8个点。团队要估算的下一个故事要稍稍大一点儿。他们拿那个8个点的故事比较了一下，决定给这个故事13个点。要是没有提升速度的压力，相同的团队可能会给第一项5，而给第二项（仍然是那个稍大点的）8。在这一个假设中，团队让他们的故事点从5+8=13膨胀到了8+13=21，换句话说，膨胀超过了50%。

Mike确实提倡建立一个共同的基线，但他也告诫管理者们要谨慎小心，要始终如一地警惕故事点可能 “膨胀”的情况发生。

Dave Nicolette给出了一个很有趣的例子，说的是故事点怎样在团队间变化：

在草原上有多少个大象点呢？让我们来做个兽群调查。象群A报告有50,000kg。象群B报告有84条腿。象群C报告有92,000磅。象群D报告有24个头。象群E报告每天听到546声象鸣。象群F报告大象皮肤的RGB值是（192，192，192）。象群G报告说平均高度是11英尺。那么，在草原上就是有50,000 + 84 + 92,000 + 24 + 546 + 192 + 11 = 142,857个大象点喽。象群平均有20,408.142857143个大象点。我们知道这是一个有用的数字因为它里面有个小数点。

他又说道，如果现在用这些故事点绘制一张图来判断这些数据，很简单，象群D和G将立刻被炒鱿鱼，象群A和C则会被表彰。

因此，在很多情况下，团队间的比较其实是无用功。如果在某种情况下，团队间就分配故事点达成了共识，随后某人可能尝试做比较，那就要格外小心了。

查看英文原文：Comparing Velocity Across Teams