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

使用指南

如何使用四种 Issue Activity 报表核对单个 Jira 工作项

核对一个异常 Jira 结果时，应先记录源报表的历史边界、计算时间、Calendar、时区和 Format，再比较同一工作项的 Time in Status、Time in Assignee、Status Count 和 Transition Count。这是计算对账，不是 Jira Audit Log 或合规审计。Issue Activity 提供计算汇总；原始事件顺序和时间戳仍以 Jira History 为准。

本文只负责四视图对账

Issue Activity 文档负责控件、Chart/Table、Refresh 和与主报表的区别；返工指南负责按团队定义调查返工的方法；QA 瓶颈指南负责群体层面的 QA 诊断。本文只检查单个工作项的四种计算汇总能否核对回同一段源历史。

视图 对账问题 预期证据
Time in Status 纳入的时间累积在哪些状态？ 所有纳入的状态区间合计等于 Calendar 计入的窗口
Time in Assignee 同一段时间记录在哪些负责人名下？ 历史完整时，负责人和 Unassigned 区间合计等于同一窗口
Status Count 纳入了多少个状态进入区间？ 只证明进入次数，不证明时长、返工或根因
Transition Count 纳入了哪些有方向的状态变化？ 每条相关路径都能与相邻 Jira History 事件核对

Atlassian 说明 Jira 工作流由状态和流转构成；工作项的 History 会记录字段编辑和工作流移动，而 Work log 保存主动登记的时间。应把 History 作为事件来源，不能用 Work log 代替状态或 Assignee 历史。

对账示例：一段完整的 12 小时事件序列

Bug SR-5001 使用一段受控历史快照：2026 年 7 月 6 日 09:00 至 21:00 UTC。快照使用 All time (UTC) 和 Decimal Hours，因此 12 个自然小时全部纳入。真实工作项若存在开放的 Status 或 Assignee 区间，Refresh 后数值会继续增长；21:00 是可复现快照边界，不是 Issue Activity 的 endpoint 控件。

时间 Status 事件 Assignee 事件 随后的区间
09:00 创建于 To Do 创建时由 Ana Ruiz 负责 1h
10:00 To Do → In Progress 未变化 4h
14:00 In Progress → QA Ana Ruiz → Priya Shah 2h
16:00 QA → In Progress Priya Shah → Ben Lee 3h
19:00 In Progress → QA Ben Lee → Priya Shah 2h
21:00 QA → Done 未变化 快照边界

这张事件表来自计算使用的 Jira History 时间戳。下方产品视图汇总这些事件，但不会把这段原始顺序显示为时间线。

核查一：Time in Status 合计 12 小时

To Do       = 1h
In Progress = 4h + 3h = 7h
QA          = 2h + 2h = 4h
Done        = 快照边界时 0h
合计         = 1h + 7h + 4h = 12h
StatusPath Issue Activity 状态停留时间表格核对单个 Jira 工作项
Time in Status 将两次 In Progress 和两次 QA 停留验算回 12 小时计算窗口。

零时长的 Done 仍属于事件历史：工作项正好在快照边界进入 Done，因此之后尚未累积时长。本例使用 All time，所以 Calendar 纳入的窗口等于 12 个自然小时；若改用工作日历，纳入合计可能小于时间戳之间的自然时长。

核查二：Time in Assignee 也合计 12 小时

Ana Ruiz   = 1h To Do + 4h In Progress = 5h
Priya Shah = 2h QA + 2h QA             = 4h
Ben Lee    = 返回后的 3h In Progress    = 3h
合计        = 5h + 4h + 3h              = 12h

两种时长报表只是用不同维度拆分同一段 Calendar 纳入的时间。一般情况下，负责人时长验算必须包括所有 Assignee 和 Unassigned，使用完整负责人历史，并保持相同历史边界、计算时间、Calendar 和时区。不能把 12h + 12h 相加后描述为 24 小时工作量。Time in Assignee 表示记录中的归属，不是实际投入；详细边界见 Time in Assignee 指南。

核查三：Status Count 保留重复进入

To Do 进入次数       = 1
In Progress 进入次数 = 2
QA 进入次数          = 2
Done 进入次数        = 1
状态进入合计          = 6

重复进入只是次数证据。它是否属于返工，应由团队的工作流定义和返工指南判断；Status Count 本身不能解释原因或是否可避免。

核查四：Transition Count 保留方向

To Do > In Progress = 1
In Progress > QA    = 2
QA > In Progress    = 1
QA > Done           = 1
流转合计             = 5
StatusPath Issue Activity 流转次数表格核对五次有方向的 Jira 状态变化
计入最初的 To Do 状态后，五次有向流转与六次状态进入完成对账。

在这段完整、未裁剪、没有同状态动作且纳入全部有向路径的序列中，6 次状态进入等于 1 个初始状态加 5 次状态间流转。这不是通用公式；历史裁剪或缺失、边界重建、遗漏流转列以及同状态动作都会打破该关系。Atlassian 说明 Jira 流转具有方向，也可以在不改变状态的情况下形成循环。

用六项检查核对异常结果

  1. 记录源结果。 保留工作项 Key、源报表历史边界、计算时间、Calendar、时区、Format 和异常值。若源报表使用 Trim History，应注明 Issue Activity 没有等价的 Trim History 控件。
  2. 相加 Time in Status。 在同一次 Issue Activity 运行中相加全部状态时长，并与所选 Calendar 实际纳入的时间比较；同时记录当前区间是否仍开放。
  3. 相加 Time in Assignee。 纳入每位负责人和 Unassigned。若缺少负责人区间或历史不完整，就不能完成有效比较。
  4. 汇总 Status Count。 记录每次纳入的状态进入，包括初始和最终状态，不把次数解释成时长或返工。
  5. 汇总 Transition Count。 纳入全部相关有向路径，并与相邻状态事件比较。
  6. 返回 Jira History。 用确切时间戳、字段编辑、同时间变化、状态改名、权限、历史缺失，或 Issue Activity 无法复现的源边界解释差异。

常见错误

把 Issue Activity 当作原始 Jira History

Issue Activity 提供单工作项的计算汇总；它不是 Jira 原始字段编辑日志，也不能证明责任或原因。审计若需要全部源字段编辑和 Jira 的权威事件记录，仍应回到 Jira 工作项的 History 区域。主报表页面的 Average 下探另见工作项下探与状态历程。

比较不同历史边界或计算时间

如果源报表和当前 Issue Activity 运行使用不同的纳入历史、Calendar、时区、Format 或计算时间，视图就无法对账。实时开放区间可能在源报表生成后继续增长。

忽略源报表的 Trim History

主报表可以使用裁剪后的历史窗口，但 Issue Activity 不提供相同的 Trim History 控件。应记录这项边界差异，而不能声称两个界面共享可配置 endpoint。

把平行的时长合计相加

两个 12 小时都在分类同一个观察窗口，不是可以相加的工时指标。

用一次状态进入对比单条流转列

本例 QA 进入两次，是因为 In Progress > QA 发生两次。其他工作流可能有多条进入 QA 的路径，单一方向列不会等于完整 QA 进入次数。

把算术可追溯性当成流程诊断

对账成功只证明计算汇总能追溯到纳入的历史，不能证明返工、根因、个人绩效或 QA 瓶颈。

忽略零时长的最终状态

Done 有一次进入但时长为零，是因为计算在同一个时间戳结束。次数和时长回答的是不同问题。

常见问题

这是 Jira Audit Log 或合规审计吗？

不是。这是一种单工作项计算对账方法，不检查管理员审计事件、访问变更或合规控制。

为什么 Time in Status 和 Time in Assignee 都等于 12 小时？

两个视图都在拆分同一段 Calendar 纳入的时间：一个按状态，一个按记录中的负责人。本例拥有完整 Status 和 Assignee 历史、没有 Unassigned 缺口、使用同一 All time Calendar 和同一快照边界，因此合计相等；其他场景必须逐项核查这些条件。

为什么 Done 有次数但没有时长？

工作项正好在快照边界进入 Done。进入事件存在，但计算窗口内没有该事件之后的时间。

Status Count 是否总比 Transition Count 多 1？

不是通用规则。仅当这个简单序列中的每次事件都移动到不同状态，且所有有向路径都被纳入时，才会出现该关系；同状态循环、所选列和范围边界都会打破它。

Time in Assignee 能衡量每个人完成的工作吗？

不能。它衡量 Assignee 字段记录每位负责人多久。Work log、评论、依赖和运营上下文属于其他证据。

四种视图无法对账时应该怎么做？

检查源历史边界、Calendar 和时区、计算时间及开放区间、Unassigned 覆盖、历史完整性与权限，以及是否纳入全部相关有向流转；再用 Jira History 解释第一处剩余差异。

相关指南

用一份完成对账的事件历史结束核查

当两种时长视图回到同一段 Calendar 纳入时间，状态进入与有向流转都能追溯到 Jira History，并且每个剩余差异都有明确的边界、设置或源事件可以继续调查时，单项核对才算完成。

前往 Atlassian Marketplace 试用 StatusPath Reports，跨四种 Issue Activity 报表核对异常结果，并把剩余差异追溯到 Jira History。

截图预览