当速率说谎：一支混合团队的惨痛教训
我合作过的一支产品团队——姑且称之为 Atlas 团队——在 2021 年上半年分散在三个时区，一半人居家办公，另一半轮流去人手稀薄的办公室。和那一年许多团队一样，他们仍在应对供应中断、病假以及疫情复苏期间的种种动荡。他们的 Scrum Master 最为看重一个数字：速率。四个月里它从每个 Sprint 28 点攀升到 41 点，管理层很喜欢这张图表。问题是，几乎没有任何东西真正交付出去。
速率是有用的规划工具，但它也是 Scrum 中最容易自欺欺人的度量之一。Atlas 团队的故事值得一讲，因为他们的错误平常普通，并不离奇——而纠正它不需要任何新工具，只需要诚实。
数字如何偏离了现实
仔细观察后我们发现，有三件事在抬高计数，却没有给客户带来价值。
估算逐渐膨胀。 在「展现进步」的压力下，团队悄悄把类似的工作估得更高。三月里估 3 点的任务，到六月就成了 5 点。图表在涨，工作量却没变。
为未完成的工作计点。 「基本做完」的条目在 Sprint 结束时被计入，下一周又被悄悄重新打开。速率是在向未来透支。
完成的定义被侵蚀。 测试人员被混合排班拉得疲于奔命，「完成」变成了代码已合并，而非已测试、可发布。增量其实并不可用。
这一切在动机上并非不诚实。这是一支想要显得健康、却在悄悄下沉的团队。但速率已不再描述交付的价值，而是描述团队的乐观情绪。
把诚实找回来
《Scrum 指南》写得很清楚：增量必须满足完成的定义才算可发布，而且只有已完成的工作才计数。我们从这里入手。团队恢复了严格的完成定义——已测试、已集成、可演示——并约定凡是不达标的都顺延，且计为零分。下一个 Sprint 速率跌到了 22。管理层为之一震。我们顶住了。
速率用于团队自身的预测，绝不是自上而下下达的目标，也不可用于团队之间的横向比较。
估算相对大小，然后别再动标尺；中途重新设定基准会摧毁信号。
在 Sprint 评审时只计入满足完成定义的工作——不给部分分，不打欠条。
观察若干个 Sprint 的趋势，而非任何单一数字；一周的波动说明不了什么。
五个 Sprint 内，这个诚实的数字稳定在 26 上下，更重要的是，Sprint 评审终于展示出 Product Owner 可以发布的可用软件。团队的预测重新变得可信，这对干系人的意义远大于一张讨喜的图表。混合办公让这种偏移容易被掩盖；透明是唯一持久的解药。
教训很明白。速率本身什么都衡量不了——只有搭配一个你真正信守的完成定义，它才有意义。一旦某个指标变成目标，人们就会去优化指标，而不是结果。顾问或教练能帮上忙，但归根结底，团队必须比起漂亮的曲线更想要真相。
如果你的交付指标讲述的故事与你实际交付的东西对不上，XNM 的项目集与项目交付咨询 可以帮助你重建干系人能够信赖的度量。