如何找到 Jira 状态平均时长背后的工作项
从 Jira Average Time in Status 分组值下钻到参与工作项，复算贡献者平均值，并检查单项完整状态旅程。
在 StatusPath Reports 2.5 中，如果要找到 Jira 分组 Average Time in Status 背后的工作项，请使用该分组 工作项数量 单元格里的操作。第一层下钻会列出参与工作项及其状态贡献；随后可以打开某个工作项旁的状态旅程操作，把所选分组贡献与完整状态时间线、历史路径图进行比较。
15 分钟评测路径
选择一个较小的 Jira 范围：在主报表页面运行 Average Time in Status，打开一个分组的工作项数量，检查一个贡献项的 Journey，再告诉我们哪些地方清楚、困惑或缺失。
为什么平均值需要工作项下钻
平均值可以显示哪个分组更慢，却不能单独解释分布。可能是一个特别慢的工作项拉高了平均值，也可能是多个中等延迟形成同一个结果；分组中的部分工作项还可能从未对所选状态产生贡献。
Atlassian 的 “当前状态时长”Dashboard 模板 也把平均值、工作项数量和明细表放在一起。该原生模板回答的是另一个问题：它只分析开放工作项的当前状态，以向上取整的天数计算，并不显示过去状态。两者共同体现的分析原则是：当底层工作项可检查时，汇总指标才更有解释力。
Atlassian 的 Control Chart 指南 也说明异常项会影响平均值，可能需要进一步调查。Control Chart 的 Cycle Time 或 Lead Time 并不等同于 StatusPath 的分组单状态平均值。应先选择与问题一致的报表，再检查结果背后的工作项，不要直接把均值当成诊断结论。
从分组 Average Time in Status 报表开始
在主报表页面运行 Average Time in Status，并确定问题所需的 Jira 总体、日期边界、Calendar、时长 Format、状态和 Group by 字段。下例把 9 个工作项按工作项类型分组。
Story 行显示 4 (44.44%)。数量表示 4 个不同工作项参与该分组，百分比则把这 4 个工作项与报表的 9 个工作项总体进行比较。
请点击 4 (44.44%) 旁的操作，而不是 4.75 平均值单元格。Average 状态时长明细会显示所选分组、参与项数量、工作项键、摘要，以及各工作项对每个状态的计算贡献。
根据贡献项复算显示的平均值
示例中的 Story 参与项对 In Review 贡献如下：
| 工作项 | In Review 贡献 |
|---|---|
| SR-4101 | 1.00 小时 |
| SR-4104 | 3.00 小时 |
| SR-4107 | 5.00 小时 |
| SR-4109 | 10.00 小时 |
该分组值可以复算：
(1.00h + 3.00h + 5.00h + 10.00h) ÷ 4 个贡献项 = 4.75h
这个表格把一个平均值无法回答的两个问题分开：
- 哪些工作项属于该分组？ 已打开分组的参与项列表会回答这个问题。
- 哪些工作项对某个状态平均值产生贡献？ 对应状态列的数值和分母会解释该指标。
分组的工作项数量不保证等于每个状态的分母。如果 Story 分组有 4 个工作项，但其中一个从未进入 In Review，分组数量仍为 4，而 In Review 平均值只使用 3 个符合条件的贡献项。存在真实 0 时长贡献的工作项，与完全没有贡献的工作项也不同。
打开一个贡献项的状态旅程
使用参与项旁的状态旅程操作。在主报表页面中，嵌套视图会显示工作项信息、所选分组贡献卡、状态时间线和历史路径图。
请分别理解两个数据边界：
| 视图 | 回答的问题 |
|---|---|
| 所选分组贡献 | 该工作项如何在报表所选状态、Calendar、时间桶和 Trim History 设置下向 Average 分组贡献数据。 |
| 状态时间线 | 截至报表生成时刻，在当前权限下可访问的完整历史包含哪些状态区间、进入/退出时间，以及 Jira 可提供时的流转人。 |
| 历史路径图 | 哪些状态和有向流转构成完整工作流路径，包括重复停留和循环。 |
“完整历史”不会应用报表的 Trim History 起止边界。因此，完整历史中的状态合计可能比所选分组贡献更长。请用贡献卡和参与项表核对汇总值，用状态时间线和历史路径图调查生命周期背景。
一个可执行的调查顺序
- 固定报表问题。 记录 Jira 数据源、日期边界、Trim History、Calendar、Format、分组字段和所选状态。
- 比较各分组。 找出值得检查的分组和状态组合，但暂时不要称其为根因。
- 打开工作项数量。 确认参与工作项和分组百分比。
- 复算一个平均值。 汇总可见状态贡献，再除以该状态符合条件的贡献项数量。
- 排序或扫描参与项数值。 找到一个高贡献项、一个典型项，以及任何看似空白或为零的项。
- 打开一个状态旅程。 比较所选贡献与完整历史，并检查重复状态或流转。
- 在 Jira History 中验证关键变更。 报表帮助定位证据；底层状态变更仍以 Jira 记录为准。
必须明确的边界
工作项数量不一定是状态分母
分组数量包含该行的不同工作项；某个状态平均值只包含当前计算下对该状态产生符合条件贡献的工作项。
各行百分比之和可能超过 100%
如果 Group by 使用 Jira 多值字段，一个工作项可以参与多个分组行。每行内部仍会去重该工作项，但重叠行的百分比合计可能超过 100%。
参与项列表基于报表快照
第一层下钻使用保留的报表结果。报表运行后 Jira 中发生的变化，不会自动改变已经打开的参与项列表。需要当前 Jira 数据时，请先运行或刷新报表。
嵌套 Journey 会单独进行当前读取
打开参与项的 Journey 会读取该工作项及其当前可访问的 changelog。权限、Issue security、工作项变更或无法读取的 changelog 分页，可能使 Journey 与参与项快照不同或暂时不可用。
下钻提供证据，而不是自动诊断
当前报表不会计算 Median、P85 或统计异常阈值，也不会推断延迟为何发生。应结合单项数值、工作流路径、Jira History 和团队背景验证原因。
仅在主报表页面使用这条路径
上文所述的“汇总 → 参与项 → Journey”路径仅在主报表页面提供。请从 Average Time in Status 表格的工作项数量操作进入；不要在 Time in Status 行、Dashboard Gadget 或 Issue Activity 中寻找相同入口。
常见问题
下钻操作在哪里？
在分组 Average Time in Status 表格中，找到 工作项数量 单元格，使用数量和百分比旁的操作。平均时长单元格不是第一层入口。
为什么工作项数量与平均值分母不同？
部分分组成员可能没有对所选状态产生符合条件的贡献。请检查参与项表格中的该状态列和分母信息。
为什么完整历史比所选贡献更长？
报表可能使用 Trim History 或日期时间桶，而状态时间线和历史路径图显示截至报表生成时刻的完整可访问历史。
下钻能证明延迟的根因吗？
不能。它用于识别值得调查的工作项、状态贡献、区间和流转。请在 Jira History 和团队背景中验证关键事件。
Issue Activity 或 Dashboard Gadget 可以使用这条路径吗？
不可以。请在主报表页面使用已支持的“Average 分组 → 参与工作项 → 单个工作项 Journey”路径。Issue Activity 只分析当前工作项，Dashboard Gadget 提供紧凑报表视图；两者都不提供这条主报表下探路径。
相关指南与文档
从平均值进入证据链
运行 Average Time in Status 报表，打开一个分组的工作项数量，根据参与项数值复算某个状态平均值，再检查一个贡献项的状态旅程。在 Atlassian Marketplace 试用 StatusPath Reports，即可在自己的 Jira 数据范围内完成 2.5 下钻路径。