BlueGrove Labs
帮助中心StatusPath ReportsJira Cloud
联系支持
EN

使用指南

Jira 工作流报表完整指南：从数据范围到导出

可复现的 Jira 工作流报表应从一个决策问题开始，而不是从图表开始。先定义工作项范围，再选择能够回答问题的指标，设置历史窗口和日历，核查代表性工作项，最后保存配置或导出结果。把这些选择记录在一起，才能避免把两份设置不同但各自正确的报表误认为矛盾证据。

报表定义的七个部分

解释任何数字前，先写清楚：

  1. 问题： 这份报表要支持什么决策？
  2. 工作项范围： 包含哪个 Project、Filter、JQL、Sprint 或 Epic？
  3. 选择时间： 按 Created、Updated 还是 Resolved 日期选择行？
  4. 历史时间： 计算完整历史，还是使用 Trim History？
  5. 指标： 时长、平均值、负责人时间、首次进入日期还是事件次数？
  6. 日历： 自然时间，还是指定工作日历和时区？
  7. 输出： 在线检查、Saved Report、Dashboard、CSV 还是 XLSX？

这个流程用于补充 Jira 原生报表。Atlassian 的报表概览列出了 Sprint Report、Control Chart、累积流图和 Velocity 等报表；StatusPath Reports 则聚焦于按工作项、状态、负责人和流转计算 Jira 历史。

按问题选择报表类型

问题 StatusPath 报表 主要证据
每个工作项在哪里停留？ Time in Status 按状态和工作项计算时长
哪个分组的 Review 平均时间最长？ Average Time in Status 平均值和贡献工作项数
历史负责人分别记录了多久？ Time in Assignee 按负责人计算时长
哪个工作项重复进入某状态？ Status Count 按状态统计进入次数
每个工作项何时首次到达里程碑？ Status Entry Date 计算窗口内首次进入时间
哪条具体流转重复发生？ Transition Count 按方向统计流转次数

当前产品控件见报表类型文档。如果需要了解时长公式，请先阅读如何计算 Jira Cloud 中的状态停留时间。

当不同 Jira 工作流用不同详细状态表示同一分析阶段时，应保留源状态列，并按状态分组设计与验算方法核对结果。

先选择工作项范围，再选择指标

数据源 适用场景 重要边界
Project 空间级整体检查 对发布决策往往过宽
Saved Filter 复用团队维护的 Jira 范围 需要关注 Filter 所有者和变更
JQL 定义精确且可审计的范围 必须在 Jira 中验证查询
Sprint 检查一个 Jira Software Sprint Board 和 Sprint 身份都会影响范围
Epic 分析一个 Epic 下的子工作 受 Parent 关系和权限影响

当维护负责人、复用、审计证据或 Board 依赖决定数据源是否可靠时，请使用 Project、Filter、JQL、Sprint 与 Epic 决策指南。

当范围包含多条规则时，可以使用 JQL。Atlassian 的 JQL 运算符文档说明了 CHANGED、WAS 等运算符；它们用于选择工作项，不能替代时长计算。

真实 Jira 场景：从发布问题到可核查证据

发布经理要回答：

哪些发布工作项在 In Review 或 QA 中停留最久，发布准备会议前应优先检查什么？

团队定义以下配置：

project = SR
AND fixVersion = "July Release"
ORDER BY created ASC
  • 报表：Time in Status
  • 状态列：In Progress、In Review、QA
  • 历史：完整历史
  • 日历：自然时间
  • 上下文字段：Key、Summary、Current status、Assignee
  • 输出：Saved Report 用于重复运行，XLSX 用于保存会议证据

SR-2501 的人工核查结果为：

状态 时长
In Progress 8h
In Review 4h
QA 2h
所选工作流时间合计 14h

14 小时只有与状态分布和配置一起记录时才有意义。它不能直接说明根因，团队仍需检查 Jira History 和工作项上下文。

StatusPath Jira 工作流报表从范围选择到导出的过程
发布范围、报表类型、所选状态列和行级时长集中显示在同一报表工作区。

按正确顺序创建报表

1. 写出决策问题

“在发布批准前找出 Review 延迟”可以验证；“展示工作流分析”则过于宽泛。

2. 配置数据源

选择 Project、Filter、JQL、Sprint 或 Epic。计算指标前，先确认几个应包含和应排除的工作项。

3. 区分选择范围和历史计算

Work item date range 使用 Jira 日期字段选择行；Trim History 改变每个已选工作项参与计算的 Changelog 区间。混淆两者是报表不一致的常见原因。

4. 选择报表、字段和列

只保留有助于解释问题的字段。动态状态、负责人或流转列取决于所选数据和计算窗口。

5. 核查代表性行

至少用 Jira History 检查一条普通行、一条高值行和一条空值或零值行。次数分析可使用返工指南中的方法。

6. 保存配置或导出结果

Saved Reports 保存可复用配置，不冻结 Jira 数据。CSV 和 XLSX 保存一次运行的输出。选择前请阅读 Saved Reports、可复用报表运行指南和导出文档。

StatusPath Jira 工作流报表的 CSV 和 XLSX 导出菜单
检查范围和计算列后，可将当前表格结果导出为 CSV 或 XLSX。

Jira 原生报表与 StatusPath 属于不同层次

  • Atlassian 的 Sprint Report 文档适用于 company-managed space，并说明报表受 Board 约束，只包含匹配 Board Saved Filter 的工作项，适合 Sprint 范围和完成情况检查；完整回顾顺序见 Sprint 工作流分析指南。
  • Atlassian 的 Control Chart 根据所选工作流列计算 Cycle time，并显示变异、滚动平均值和异常点。
  • Jira Dashboard 可以添加 Gadget；Atlassian 的 Gadget 文档说明添加和编辑方式。
  • Jira 原生 CSV 导出说明针对 Jira 搜索字段。StatusPath 导出不同，它包含当前报表配置计算出的状态、负责人、日期或流转列。

不应把其中一层描述为另一层的替代品。Jira 原生报表用于其文档定义的 Board 和 Project 问题；需要逐工作项计算证据时，再使用基于历史的表格。

常见错误

从图表开始，而不是从决策开始

图表即使看起来合理，也可能使用了错误的工作项范围或历史窗口。

把 Work item date range 当成 Trim History

前者选择工作项，后者裁剪计算使用的历史。

比较不同 Calendar

自然时间和工作时间是不同指标定义。共享结果时应写明日历和时区。

保存报表后期待数值冻结

Saved Report 会根据当前 Jira 数据和权限重新运行。需要时间点文件时应导出。

混淆 Jira 原生 CSV 和计算报表导出

Jira 字段导出和 StatusPath 计算列不是同一种文件，应记录实际使用的来源。

常见问题

应先选择哪种 Jira 工作流报表？

行级等待用 Time in Status；分组比较用 Average Time in Status；归属分析用 Time in Assignee；重复阶段用 Status Count；里程碑用 Status Entry Date；具体流转用 Transition Count。

应使用 JQL 还是 Saved Filter？

团队已经维护范围时使用 Saved Filter；需要自包含查询时使用 JQL。两者都应记录选择规则的所有者。

哪些内容需要人工核查？

用 Jira History 核查代表性行，确认数据源范围、日期和 Trim History 设置，以及 Calendar 和时区。

导出的表格是实时报表吗？

不是。它是一次运行的输出，之后 Jira 数据仍可能变化。

可以把报表放到 Jira Dashboard 吗？

StatusPath Reports 提供紧凑的 Dashboard Gadget。完整创建、核查、保存和导出应使用主报表页面。

让每个报表数字都能复现

可靠的工作流报表会把问题、工作项范围、选择窗口、历史窗口、指标、日历和输出保存在一起。StatusPath Reports 提供六种基于历史的报表、五种数据源、可核查表格、Saved Reports、Dashboard 和 CSV/XLSX 导出，让团队从分析到评审都保留同一份定义。

前往 Atlassian Marketplace 试用 StatusPath Reports，从一个决策问题和一份明确配置开始复现报表。

截图预览