敏捷项目管理中经常被诟病的一点是：由于故事点因团队而异，所以无法确定一个团队相较于其它团队在进度上的快慢。敏捷人士们普遍认为：比较团队间的速度并非明智之举，作为一种反模式，大家最好敬而远之，免得祸及总体生产率。
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
暂无签名
腾讯大规模云原生技术实践案例集
本案例集详细阐释了 QQ、腾讯会议、和平精英、小红书、斗鱼、微盟等十多个亿级用户产品背后的大规模云原生...
评论