周期时间与前置时间：Scrum 团队反复犯的五个流动度量错误
在疫情复苏期间，混合办公和远程团队规模扩大，许多 Scrum 团队开始寻找比速度更可靠的信号。流动度量正是显而易见的答案，它由 scrum.org 与 Daniel Vacanti 共同发布的《面向 Scrum 团队的看板指南》正式确立。问题在于，周期时间和前置时间虽然容易定义，却出奇地容易测错，而一个错误的流动度量比没有度量更糟，因为它披着数字的权威。
先从定义说起，因为一半的混乱都源于此。周期时间是单个工作项在你的工作流中所花的时间，从真正开始处理它到完成为止。前置时间，在通常的服务交付意义上，是从工作项被请求或被承诺到交付所经历的时间，因此它包含了在任何人着手之前的等待。前置时间是干系人所感受到的，周期时间是团队所能掌控的。把两者混为一谈，每次都会引向错误的对话。
悄悄误导团队的错误
只测量活跃部分。 团队常常在开发者接手某项工作时才启动计时，却忽略它在待办列表或「就绪」列中停留的天数。于是看板显得健康，而提出需求的人却为两天工作量的东西等了两周。要测量等待，而不只是投入的精力。
把平均值当成承诺。 周期时间并非正态分布，它有一条长尾。报告七天的平均值会掩盖那个花了三十天的工作项。应改用百分位数。说「我们 85% 的工作项在九天或更短时间内完成」是诚实的，也具备平均值永远做不到的可预测性。
起止点不一致。 如果一个人从需求精炼开始计时，另一个人从首次提交开始，你的数据就是噪声。要明确约定看板上的哪次状态变更启动周期时间、哪次结束它，把它写下来，并始终以同样方式应用。
放任在制品膨胀。 根据利特尔法则，平均周期时间会随在制品数量上升。一些远程团队为了跨时区显得忙碌而拉入更多工作项，结果周期时间因与工作本身无关的原因而攀升。限制在制品，周期时间往往会自行下降。
操纵看板。 拆分工作项以重置计时，或把卡片往回拖以保持好看的数字，都会摧毁这一度量唯一的价值。流动数据是供团队检视与调整的，不是供管理者给人排名的。一旦它变成目标，就不再是度量。
让度量赢得它的位置
流动度量应当融入既有的 Scrum 事件，而不是放进无人阅读的单独报告。把周期时间散点图带到 Sprint 回顾会上，问问那些异常值有什么共同点。在 Sprint 规划中使用前置时间的百分位数，与产品负责人设定切合实际的预期，而不是靠猜。在每日 Scrum 上，一张在制品老化图能告诉开发者今天哪个工作项有可能成为下一个异常值——而此时仍有时间采取行动。
把起止点一次性书面定义清楚，绝不悄悄更改。
报告百分位数，而不只是平均值，并始终展示完整分布。
为干系人跟踪前置时间，为团队跟踪周期时间，绝不把两者混在一起。
在着手优化任何其他东西之前，先为在制品设上限。
诚实地使用，这些数字能把模糊的挫败感转化为一个具体、可解决的问题。目标从来不是更漂亮的图表，而是让依赖这项工作的人等待更短、更可预测。
如果你的交付团队需要帮助，把流动数据转化为管理层可以信赖的决策，XNM 的项目群与项目交付咨询 可以帮你把它建立起来并正确解读。