2.6 周期时间及其构成

概述与动机

周期时间是把一次变更的流动时间（主题 2.4）内部分解为其构成的各个工程阶段：编码时间、评审时间、测试时间与部署时间，有时进一步拆分为接手时间（一次变更要等多久才有人开始处理它）与活跃时间（一旦有人处理，需要花多久）。流动时间给你一个单一数字，说明一次变更端到端穿过整条价值流需要多久，而周期时间则告诉你，一旦它到达工程，这些时间究竟去了哪里，这正是主题 2.4 承诺存在于其自身汇总数字之下的诊断层。

这种区分很重要，因为”交付周期太长”本身并不可行动。一个交付周期以编码时间为主的团队，需要的干预，与一个交付周期以三天评审队列为主的团队不同，而后者又与一个大部分时间都损失在一套不稳定、缓慢的测试套件上的团队所需的干预不同。没有周期时间分解，团队往往只能猜测瓶颈所在，而这种猜测出错的频率高到足以让人在修复错误阶段上浪费真实的努力，而真正的约束却原封未动。

对大团队而言，周期时间分解，正是把一次全组织范围的交付周期倒退，从一个谜团变成一个具体、可解决的问题的关键。当几十个团队共用相同的基础设施时，一个共享的评审瓶颈，或一条共享的缓慢CI流水线，可能正在把每个团队的交付周期同样地拖慢，只有跨团队的周期时间比较，才能揭示这个共享的根本原因，而不是每个团队各自独立地猜测自己的局部解释。

核心原则

周期时间解释交付周期；它不取代交付周期。 把两者一起报告，周期时间作为诊断，交付周期作为汇总。
等待时间通常主导活跃时间。 软件交付中的大部分延迟，来自工作在队列中闲置，而不是来自主动的努力（主题 2.5 通过流动效率直接涵盖了这一点）。
在提出修复方案之前先按阶段分解。 一个瞄准错误阶段的修复方案，会浪费努力，还可能打击一个被要求”更快工作”的团队的士气，而真正的瓶颈其实在别处。
多个团队共有的瓶颈，是一次平台投资机会，而不仅仅是一连串独立的团队问题。
周期时间数据暴露在与流动时间相同的操纵风险之下（主题 2.4）：留意悄悄漂移以美化某个数字的阶段边界。

建议

明确为每一个阶段边界埋点

把一次变更的旅程，拆分为有清晰、可埋点边界的命名阶段：编码（首次提交到拉取请求打开）、接手（拉取请求打开到首次评审）、评审（首次评审到批准），以及部署（批准到生产环境）。从版本控制和CI/CD事件中自动捕捉每一次转换的时间戳，而不是依靠自我报告的阶段跟踪，应用主题 1.5 埋点优先于自我报告的同一原则。

在每个阶段内部把等待时间与活跃时间分开

例如在评审阶段内，区分一份拉取请求在无人触碰的情况下等待评审者开始处理所花的时间（等待时间），与一旦开始，一场活跃的评审对话所花的时间（活跃时间）。这种区分通常会揭示，主导性的成本是排队，而不是努力，这指向一种与瞄准让评审对话本身更快的修复方案截然不同的方案（更多评审者容量、更好的通知、更小的待评审拉取请求）。

在逐个团队诊断之前，先寻找共享瓶颈

当多个团队都显示同一个阶段是其主导性延迟时，一条缓慢的共享CI流水线、一个超负荷的共享评审池、一趟不频繁的共享发布列车，这个共享的原因就是一次平台层面的投资机会，而不是一连串互不相关的局部问题。在假定每个团队的瓶颈都是该团队特有的之前，专门汇总跨团队的周期时间数据来寻找这种模式。

用周期时间设定现实的、阶段特定的改善目标

与其设定一个不给团队任何聚焦指引的单一”把交付周期缩短20%“目标，不如用周期时间分解来设定一个阶段特定的目标：“把评审等待时间的中位数从两天缩短到四小时。“一个具体的、以阶段为目标的目标，既更容易让团队据此行动，也更容易核实它是否真的是通过真实的流程变更实现的，而不是其他地方一次无关的偏移。

留意阶段边界操纵

正如流动时间的起点和终点可能漂移（主题 2.4），单独的周期时间阶段边界，也可能以美化某个特定阶段数字、却没有真实改善的方式发生偏移，例如，在评审者刚被指派的那一刻，就把评审标记为”已开始”，而不是在他们真正开始阅读变更的那一刻。定期依据文档化的定义，审计阶段边界埋点。

权衡取舍：利与弊

方案	优点	缺点
粗粒度周期时间（两三个阶段）	埋点和解释简单	可能无法足够精确地定位真正的瓶颈以采取行动
细粒度周期时间（许多阶段，等待与活跃分离）	诊断精确，可行动的阶段特定目标	需要更多埋点工作；需要维护和解释更多数字
逐团队周期时间审查	贴合每个团队的实际工作流	可能错过一个隐藏在相似局部数字背后的共享跨团队瓶颈
跨团队汇总周期时间审查	揭示共享的平台层面瓶颈	需要跨团队标准化的阶段定义才有意义

核心张力是诊断精度与埋点成本之间的张力。更细粒度的周期时间跟踪能给出更可行动的诊断，但构建和维护成本更高，也增加了团队需要理解和信任的数字数量。解决之道是从粗粒度开始（编码、评审、部署），只有在某个阶段被确认为一个真正、反复出现、值得额外埋点投入的瓶颈之后，才添加更细的拆分（在特定阶段内区分等待与活跃时间）。

与团队讨论的问题

如果交付周期今天倒退了，我们能在一小时内用数据而不是猜测说出是哪个具体阶段造成的吗？ 这是你的周期时间埋点是否真正发挥其诊断作用的核心检验。如果诚实的答案是不能，那个缺口值得在下一次倒退发生之前补上。
在我们主导性的瓶颈阶段内，有多少延迟是等待时间，有多少是活跃时间？ 大多数团队在检查之前，都假定主动的努力是约束所在，而排队通常才是更大的成本。为你最慢的阶段拉出实际的划分，看看这个假设是否成立。
多个团队是否共有同一个主导性瓶颈阶段，暗示需要一次平台层面而不是团队层面的修复？ 在假定每个团队的缓慢都是局部原因造成的之前，跨团队汇总你的周期时间数据，明确寻找这种模式。
我们是否设定过阶段特定的改善目标，还是只有一个不提供任何聚焦指引的单一整体交付周期目标？ 一个模糊的目标，让团队只能猜测该把努力投向哪里；一个阶段特定的目标则不会。用这个区分核对你当前的目标。
我们埋点中的任何一个周期时间阶段边界，是否曾随时间偏离其文档化的定义？ 阶段边界暴露在与流动时间本身相同的定义漂移风险之下（主题 2.4）。用书面定义，抽查一批近期的阶段转换事件。
一种以评审为重的文化，与一种以信任为重的文化，在我们的周期时间数据中会有怎样不同的表现？ 一个进行非常彻底、多轮评审的团队，评审阶段时间会比一个信任单人批准合并的团队更长；讨论一下你目前的平衡，反映的是一个刻意的选择，还是一个未经审视的默认状态。

行业视角

初创公司。 周期时间通常以编码时间为主，而不是评审或部署阶段，仅仅因为流程极简。当团队壮大到超过寥寥数名工程师之后，开始专门留意评审等待时间，因为这通常是随着更多人的工作需要通过更少可用评审者而首先变慢的阶段。

小型企业。 基础的版本控制平台分析，通常已经暴露出足够的阶段层面计时（首次评审时间、合并时间），无需定制埋点。先关注评审阶段，因为它是最常见的早期瓶颈，也最容易用像评审者轮换这样的小流程变更来修复。

企业。 几十个团队共有的瓶颈很常见，找到它们也很有杠杆效应：一个超负荷的共享CI队列，或一个强制性的中央评审步骤，可能正在悄悄拖累全组织的交付周期。专门投资于跨团队周期时间汇总，来揭示这些共享约束，而不是让每个团队独立诊断。

政府。 周期时间数据是向持怀疑态度的利益相关方证明流程现代化合理性的一个强有力、具体的工具，因为”评审等待时间平均四天，因为一个单一的审批角色成了瓶颈”，比一句抽象的”我们的流程很慢”，是对投资更有说服力、也更具体的理由。

案例

企业。 一家云基础设施公司的工程领导层，注意到交付周期几乎在所有团队中同时悄悄攀升。跨团队周期时间汇总揭示，评审等待时间，而不是活跃评审时间，是主导性且共同的原因：一个小型、集中化的安全评审团队，随着需要其签核的团队数量增长快于该团队自身规模的扩张，已经成了瓶颈。扩充并培训一个更广泛的、经过安全认证的评审者群体，而不是要求各个团队设法更快地编码或测试，解决了这个共享瓶颈，并在一个季度内让交付周期在全线范围内回落。

政府。 一家州政府的数字服务团队，正承受着缩短交付周期的压力，最初的应对方式是要求工程师更快地工作，这是一种自然但最终无益的本能反应。周期时间分解显示，活跃编码时间年复一年几乎没有变化；几乎所有的倒退，都来自十八个月前作为合规措施引入的一个强制性架构评审阶段中不断增长的队列。该团队为低风险变更重新设计了那个评审流程，改为一个更轻量、按风险分级的流程，在为真正高风险的变更保留完整评审严谨度的同时，大幅缩短了评审等待时间。

商业理由：动机、投资回报与总拥有成本

周期时间分解的回报，是有针对性的、有效的投资：一个确切知道哪个阶段是瓶颈的组织，可以修复那个具体阶段，而不是把努力稀薄地铺满整个流程，寄望于总有一处能起作用。上面的安全评审案例很典型：一个精确瞄准的修复方案（扩充一项具体的瓶颈资源）以远低于一场宽泛、无聚焦的”加快交付”行动的成本，解决了一个全组织范围的问题。

总拥有成本，是可靠地捕捉阶段层面时间戳所需的埋点工作，以及定期审计阶段边界是否漂移的持续自律。这份成本是值得的，因为另一种选择（猜测瓶颈并修复错误的阶段）随时间推移，浪费的工程努力远超埋点本身的成本。

反模式与陷阱

在没有周期时间诊断的情况下应对交付周期倒退： 经常导致修复错误的阶段。
假定主动的努力而不是等待时间是主导性成本： 通常是错的；在大多数真实的交付流水线中，排队占主导（主题 2.5）。
只逐团队审查周期时间，错过共享的跨团队瓶颈： 让一个高杠杆的平台修复机会未被发现。
设定一个模糊的整体交付周期目标，没有阶段特定的指引： 让团队只能猜测该把努力聚焦在哪里。
阶段边界的定义漂移： 美化某个特定阶段的数字，却没有真实改善。
在确认任何一个细粒度阶段是真正的瓶颈之前，就为所有可能的细粒度阶段埋点： 把埋点精力浪费在尚未为任何决策提供信息的细节上。

成熟度模型

第一级，启动： 周期时间完全没有被分解；交付周期倒退时，团队只能猜测瓶颈。
第二级，发展： 部分团队非正式地跟踪粗粒度的阶段计时，但没有一致的埋点或跨团队比较。
第三级，标准化： 阶段边界在全组织范围内被一致地埋点，主导性瓶颈阶段中等待时间与活跃时间被分开。
第四级，管理： 跨团队周期时间汇总主动揭示共享瓶颈；阶段特定的改善目标取代了模糊的整体交付周期目标。
第五级，协奏： 周期时间数据直接驱动平台投资的优先级排序，组织能够指出具体的、有针对性的修复（扩充的评审池、更快的共享流水线），一次性可衡量地改善了许多团队的交付周期。

讨论思路

我们当前主导性的瓶颈阶段是什么，我们对这个答案有多大信心？
那个瓶颈阶段的时间中，有多少是等待时间，有多少是活跃时间？
我们的团队中是否有共享同一个瓶颈的，暗示需要一次平台层面的修复？
我们上一次设定阶段特定而不是整体的交付改善目标是什么时候？
我们工具中的某个阶段边界定义，是否曾在没有文档记录的情况下发生过变化？

要点回顾

周期时间把流动时间分解为工程阶段（编码、评审、测试、部署），是该汇总数字之下的诊断层。
在每个阶段内把等待时间与活跃时间分开；排队通常主导主动的努力（主题 2.5）。
在假定一次放缓是团队特有的之前，先寻找团队之间共享的瓶颈；一个共享的原因往往是一次平台投资机会。
设定阶段特定的改善目标，而不是模糊的整体目标，让团队确切知道该把精力聚焦在哪里。
阶段边界暴露在与流动时间本身相同的定义漂移风险之下；定期审计它们。
主题 2.7 给出了在制品与周期时间为何同步移动背后的数学原理：利特尔法则。

参考文献与延伸阅读

The Principles of Product Development Flow，Donald G. Reinertsen著（周期时间分析背后的排队论与批量大小推理）。
Actionable Agile Metrics for Predictability，Daniel S. Vacanti著（软件交付的周期时间与基于流动的衡量）。
Accelerate: The Science of Lean Software and DevOps，Nicole Forsgren、Jez Humble、Gene Kim著（交付周期及其与交付绩效的关系）。
The Goal，Eliyahu M. Goldratt著（约束理论，以及寻找并修复真正瓶颈而不是到处优化的原则）。