什么是研发 Lead Time？我悟了！

本文主要是介绍什么是研发 Lead Time？我悟了！，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

嗨，朋友！你听说过「新型工伤」吗？

我好像「赛博确诊」了😣

那天朋友约我吃饭，我下意识回复了句「好的，那我提一个日程」……还有上次跟一位准妈妈聊天，我好奇宝宝的预产期，结果脱口而出「宝宝预计什么时候发布呀？」

在这里插入图片描述

小编观察到，这种生活语言系统被职场黑话污染的「新型工伤」辐射范围还不小。就比如昨天，我只是抱怨了一句「外卖等了好久」，就被拉着科普了一中午「什么是 Lead Time」😓

简单地说，用「餐品已送达」的时间减去你下单的时间——更准确的说法是「商家已确认订单」的时间——得到的时间差，就是商家的 Lead Time。因为点外卖需要提前下单，所以 Lead Time 也被翻译成了提前期或前置时间……

在这里插入图片描述

01 什么是 Lead Time？

和 Cycle Time 一样，Lead Time 也是精益生产的专业术语。Lead Time（交付时间）是指企业从接受客户订单开始，到成功向客户交付货物结束，中间所间隔的全部时间。

在软件开发语境中，研发团队的 Lead Time 是需求从被确认（即产品经理采纳需求）到上线交付所需的时间，也就是「From Idea To Launch 」的时间。

以 LigaAI【看板视图】中的研发需求为例，单一用户故事的 Lead Time 可以通过计算完成状态与创建状态的时间差值得出。而有统计结果表明，研发团队的整体交付时间通常符合韦伯分布，因此建议选用 85% 分位数进行分析，而不是平均值。

在这里插入图片描述

在之前介绍 Cycle Time 的文章中，我们曾讨论过，Cycle Time 是指技术团队从头到尾完成一单位研发工作所需的平均时间。那么，Lead Time 和 Cycle Time 二者有怎样的关系或区别呢？

02 Lead Time vs Cycle Time

这个问题，让我们从「一个需求的一生（敏捷开发版）」说起。

一个创意/想法/反馈被提出后，要先通过产品愿景和目标的价值匹配等处理，由产品负责人确认是否可以接纳其成为待开发需求。

已采纳的研发需求会被记录在产品待办列表（Product Backlog）中，经过需求分析、需求拆分、需求评审、优先级排序、工作量估算等一系列步骤，变成一个个清晰明确的小粒度、高优先级的用户故事。这个过程会剥离出当前优先级/价值较低的需求，继续接受待办列表细化的考验。

在迭代计划会议上，Scrum 团队讨论符合 DoR（Definition of Ready）要求的用户故事，并结合优先级、工作量等，将其规划进迭代待办列表（Sprint Backlog）中，投入迭代开发。

当需求顺利通过开发、测试、部署，被成功发布到生产环境后，Lead Time 和 Cycle Time 的计时就按下终止键。

在这里插入图片描述

也就是说，Lead Time 包括了用户故事的准备时间、在积压列表中的等待时间和研发团队实现需求的周期时间（即 Cycle Time）。

在这里插入图片描述

敏捷联盟（Agile Alliance）还指出，Lead Time 和 Cycle Time 分别代表了不同角色的度量视角。前者从「用户视角」出发，衡量了需求从被确认到被满足的时间，而后者从「开发者视角」出发，衡量的是研发需求/用户故事从开始开发到成功交付的间隔时间。

总结一下。Lead Time 和 Cycle Time 都是用于度量研发速率的有效指标。Lead Time 以 PBI 的创建为起点，体现了研发团队响应需求的能力，而 Cycle Time 以需求进入迭代开发为起点，反映的是研发团队交付价值的能力。在数值关系上，Lead Time 包含了 Cycle Time。