使用指南

如何在 Jira 中发现代码评审瓶颈

要在 Jira 中发现代码评审瓶颈，先明确哪个状态代表 Review，再测量每个 Story 的状态占用时间，区分只进入一次与重复进入的 Story，并检查信号是否在可比时间分桶中持续。用 Transition Count 和 Jira History 验证 In Review → In Progress 回退。这些只是工作流证据：状态占用时间不能证明 PR 活动、评审者劳动或个人产出。

这项分析可以和不可以证明什么

本页只回答一个聚焦工程复盘的问题：Jira Review 阶段是否表现为大范围等待、重复评审循环、持续趋势，或这些模式的组合？ Jira 工作流瓶颈完整指南负责所有工作流阶段的通用方法，本页不重复那个更广泛的诊断。

首先定义 Review 边界。团队可能使用 In Review、Waiting for Review，也可能把多个状态映射到同一看板列。Jira History 记录状态变化及其时间戳；StatusPath 根据这些历史重建状态区间，并按报表的历史窗口和 Calendar 设置计算时长。Jira 状态延迟更新会让记录的状态占用时间与实际开发活动不一致。

应把三类信号分开：

信号	能回答的问题	不能证明什么
Review 时长分布	哪些 Story 累积了 Review 时间，延迟分布有多广？	活跃 PR 评审时间或成因
状态和流转计数	哪些 Story 重新进入 Review，哪些又回到 In Progress？	每次返回是否都是可避免的返工
Review 趋势	时长信号是否在可比分桶中持续？	趋势为什么改变

Atlassian 的 Control Chart 文档说明，该图表根据选定状态绘制 cycle time 或 lead time，并显示平均值、滚动平均和标准差。该页面仅适用于 company-managed spaces。原生报表可用时可以用它，但必须保留已配置列的定义：包含多个阶段的 Control Chart 与只统计 Review 的状态时长报表不是同一指标。

Jira 原生能力可以查找和验证什么

JQL 可以筛选进入过 Review 的 Story：

project = SR
AND issuetype = Story
AND status CHANGED TO "In Review"

也可以隔离一条已知的回退路径：

project = SR
AND issuetype = Story
AND status CHANGED FROM "In Review" TO "In Progress"

Atlassian 的 JQL 操作符参考说明，CHANGED 支持 FROM、TO、AFTER、BEFORE 和 DURING 等谓词。这些查询会返回匹配的工作项，但不会返回“每个工作项重复进入 Review 或回退了多少次”的数值列。需要频次时，应基于工作项历史计数。

验证单个工作项时，打开工作项的 Activity 区域并选择 History。Atlassian 将工作项 History定义为字段编辑、工作流移动等更新的记录。用它核对具有代表性的 Story 进入和离开 Review 的时间戳。

可复现的 Jira 测试场景：长时间单次评审与四个评审循环

一次工程复盘包含 16 个 Story。截图使用 Jira 测试项目中的合成演示数据。本演示明确选择 All time (UTC) Calendar、Decimal Hours 格式，以及包含场景中所有 Review 区间的历史窗口。All time (UTC) 是文章演示配置，不是产品内置默认值。生产复盘应主动选择并记录适用于团队的 Calendar。

12 个 Story 只进入 In Review 一次，Review 时长按 12h、14h、16h、18h 循环三次。另外 4 个 Story 各进入 In Review 两次，每个在其中停留 4h + 4h = 8h，并且恰好有一次 In Review → In Progress 回退。

Story 分组	Story 数	每个 Story 进入 Review 次数	Review 时长模式	分组 Review 总时长	分组平均	回退数
只进入一次 Review	12	1	`12h、14h、16h、18h` × 3	180h	15h	0
重新进入 Review	4	2	每个 `4h + 4h`	32h	8h	4
全部 Story	16	混合	上述两种模式	212h	13.25h	4

人工验算如下：

单次 Review 组总时长 = 3 × (12h + 14h + 16h + 18h) = 180h
单次 Review 组平均   = 180h ÷ 12 = 15h

重新进入组总时长   = 4 × (4h + 4h) = 32h
重新进入组平均   = 32h ÷ 4 = 8h

整体 Review 总时长    = 180h + 32h = 212h
整体 Review 平均值    = 212h ÷ 16 = 13.25h

重新进入的 Story     = 4 ÷ 16 = 25%
Review 回退              = 4 × 1 = 4 次事件

整体平均值遮蔽了两种不同结论。12 个只进入一次的 Story 拥有更长的 Review 平均时长，说明即使没有重复返回，Review 延迟也可能存在。4 个循环 Story 的 Review 总时长较低，但仍然暴露了另一个工作流反复信号。在检查工作项和开发证据之前，两种模式都不能证明成因。

Time in Status 表格显示代码评审瓶颈分析中 16 个 Jira Story 的 Review 时长 — Time in Status 表格保留每个 Story 的 Review 时长，便于检查分布和异常值。

可重复的 Review 瓶颈分析流程

1. 运行报表前先写明状态边界

记录哪个状态或状态组代表 Review。如果 Waiting for Review 和 In Review 含义不同，就分开分析。如果团队用一个宽泛的 In Review 状态同时表示等待、活跃讨论、自动检查和批准，要在复盘中写明这项局限。

2. 选择稳定的总体和配置

使用一个 Project、Saved Filter、JQL、Sprint 或 Epic。本文算例使用：

总体：project = SR AND issuetype = Story ORDER BY created ASC 返回的相同 16 个 Story。
历史规则：包含复盘中使用的每次 Review 进入和离开。
Calendar：本算例使用 All time (UTC)，因此所有自然时间区间都被纳入；所有生产时长视图应使用同一个已记录的团队 Calendar。
表格 Format：Decimal Hours。
Review 列：In Review，加上提供上下文所需的工作项字段。

工作项选择和 Trim History 回答不同问题。Sprint 源选择总体，Trim History 则剪裁这些行用于计算的 Jira 历史。比较两个时间段前，请参阅报表设置与范围和Jira Time in Status 日期范围如何裁剪历史。

3. 检查 Review 时长分布

运行 Time in Status，按 In Review 从长到短排序，并可选使用时长筛选器建立复核清单。不要停在平均值。应检查行数、在需要时在产品外计算中位数或分布范围、最长的行，以及总体中是否有很大一部分在相同设置下偏高。

使用Calendar 和时长记录工作日程和显示单位。即使 Jira 历史不变，不同 Calendar 也可能改变时长值。

4. 区分单次等待与重复 Review

在相同总体和历史窗口下切换到 Status Count，筛选或排序 In Review 中大于 1 的值。在本场景中，恰好 4 个 Story 的 In Review = 2，其他 12 个都是 In Review = 1。

然后使用 Transition Count 确认方向。4 个重复进入的 Story 都有 In Review → In Progress = 1，因此总共是 4 次回退事件。如果重复进入却没有预期的向后流转，应进一步调查，不要自动分类。

Jira Status Count 报表显示四个两次进入 In Review 的 Story — Status Count 隔离出了四个两次进入 In Review 的 Story。

Jira Transition Count 表格第一部分显示 SR-3201 至 SR-3211 的 Review 回退均为零 — 第一张表格视图显示 SR-3201 至 SR-3211 均为 0；下方续图补齐全部 16 行证据。

Jira Transition Count 续图显示 SR-3212 之前为零，SR-3213 至 SR-3216 各有一次回退 — 续图显示 SR-3206 至 SR-3212 均为 0，SR-3213 至 SR-3216 均为 1；四行各 1 次，因此 In Review → In Progress 回退总计 4 次。

Jira 返工分析指南说明了为什么 Status Count 用于筛查，Transition Count 用于验证方向。

如果延迟出现在 Review 之后而不是 Review 内部，请对照QA 与 Testing 瓶颈分析检查后续阶段。

5. 单独核查 Review 序列，不把整张堆叠图等同于 Review

在 Time in Status 结果中打开 Status Time Trend。使用可比的日、周、月、季度或年分桶，并保留相同的范围、Review 边界、Calendar、Format 和历史规则。Status Time Trend 会把累积状态时长分配到时间桶中；它不会自动变成固定总体的平均值。

图表初始包含 To Do、In Progress、In Review、QA 和 Done。点击另外四个图例标签可暂时隐藏这些序列，只保留 In Review，如下图所示。图例可见性属于图表交互，不是保存报表配置的一部分，因此通过 clean URL 重新加载后需要再次操作。本场景中，可见的 Review 序列及独立对账的贡献 Story 数为：

周分桶	In Review 时长	对 In Review 产生时长的 Story 数
6 月 22–28 日	72h	5
6 月 29 日–7 月 5 日	74h	5
7 月 6–12 日	66h	6
7 月 13–19 日	0h	0

前三个有 Review 活动的分桶具有相近的汇总时长；第四个分桶为零，是因为没有 Review 区间向该桶贡献时长，不能单独证明 Review 已改善。应同时保留贡献工作项数；如果问题是平均时长，应使用 Average Time in Status 或单独的标准化计算。

Jira Status Time Trend 图表仅显示四个周分桶中的 In Review 序列 — 通过图例隔离 In Review 后，可见经对账的四个周值依次为 72h、74h、66h 和 0h。

请参阅图表视图了解受支持的趋势间隔和时长控件。

6. 验证工作项并组织复盘

打开全部 4 个循环 Story，再从只进入一次的组中各选一个长、中、短时长 Story。将 StatusPath 数值与 Jira History 对比，如果团队有 PR 系统，再与其开发证据核对。提问：

长 Review 区间是在等待处理、进行活跃讨论，还是 Jira 状态延迟更新？
每次回退来自修改要求、范围变更、错误流转，还是预定工作流路径？
延迟是否集中在某个组件、工作类型、优先级或交接点？
趋势分桶之间的 Review 定义、Calendar 或历史窗口是否变化？
哪一项流程实验可以在下次用同一报表定义评估？

记录证据和不确定性，不要把 Review 状态占用时间做成评审者排行榜。

常见错误

把 Review 状态占用当作 PR 活动

Jira 状态区间不会显示 PR 何时打开、何时发生评论，或某人何时真正评审了代码。在得出这些结论前，要与开发证据核对。

只使用整体平均值

13.25 小时平均值遮蔽了 15 小时的单次进入组和 8 小时的重新进入组。应把行级分布和进入次数与汇总结果并列。

认为 JQL 会返回重复次数

status CHANGED 可以找到匹配的工作项，但不会生成本次复盘需要的 In Review = 2 或回退计数列。

比较不同 Calendar 或历史窗口

更改工作时间、时区、例外日、Trim History 或选定总体都可能改变结果。每次对比都要保留这些设置。

把每次 Review 返回都称为缺陷

向后流转可能代表修改请求、更正状态、预定流程、自动化或实际返工。分类前应检查 Jira History 和工作项。

常见问题

Jira 能从状态历史测量 PR 评审时间吗？

Jira 可以测量工作项被记录在 Review 相关状态中的时长。只有在团队的集成和工作流能保持这些事件对齐、且已验证这种对齐时，这个值才可能与 PR 打开时间、活跃评审时间或评审者劳动相关；两者并不自动等价。

平均时长最长的状态一定是瓶颈吗？

不一定。应检查贡献的 Story 数量、分布、异常值、重复进入、定向流转，以及信号在可比时间段的持续性。Jira 工作流瓶颈指南提供完整证据阶梯。

JQL 能告诉我每个 Story 进入了多少次 Review 吗？

JQL CHANGED TO "In Review" 可以找到发生该流转的 Story，但查询本身不会返回每个 Story 的重复次数。应使用 Status Count 或基于 changelog 历史计算。

两个 Review 区间应如何计算？

在同一 Calendar 和历史窗口下相加被纳入的区间。在本例中，每个循环 Story 贡献 4h + 4h = 8h Review 状态占用时间，并且 In Review 的 Status Count 为 2。

Jira Control Chart 适用于所有空间类型吗？

本文引用的 Atlassian Control Chart 页面仅适用于 company-managed spaces。使用该图表前，要确认实际 Jira 空间中可用的原生报表；状态时长和流转分析仍然需要明确定义总体和 Review 边界。

把 Review 猜测转化为可验证的复盘

StatusPath Reports 可以围绕同一 Jira 总体组合 Time in Status、Average Time in Status、Status Count、Transition Count 和 Status Time Trend。使用这些视图分开保留时长、重复与趋势证据，然后在修改工作流之前，先在 Jira History 和团队开发系统中验证具有代表性的 Story。