StatusPath Reports使用指南
Jira 平均状态时间中横线与 0.00 有什么区别
在 StatusPath 的 Average Time in Status 表格中，横线和 0.00 表示不同的证据。横线表示在报表范围、历史窗口和计算规则下，该分组行没有符合条件的状态贡献，因此没有可显示的数值平均值。0.00 是数值，但它本身不能证明未舍入时长精确为零：Decimal Hours 显示两位小数，精确零与舍入后为零的小正数可能看起来完全相同。解释前必须核对原始区间、Calendar 交集和贡献者数量。
本指南解释单元格，不重讲完整平均公式
这篇故障排查指南只回答一个问题：Average Time in Status 单元格显示 -、0.00 或正数时，分别应该检查什么？重复进入、分母规则和通用公式见Jira 状态平均时长如何计算。如果缺少的是整个状态列标题，而不是某个单元格数值，请看为什么 Jira 状态列没有出现在 Time in Status 报表中。
下文区分的是经过本地核验的 StatusPath 行为，不是 Jira 为横线或零定义的语义。Jira 提供流转证据。Atlassian 文档说明，工作项的 Activity → History 会记录字段编辑和工作流移动。StatusPath 再应用所选范围、历史控制、Calendar、分组与时长格式。
真实 Jira 场景：同一个 Calendar 下的三种 QA 结果
一名发布经理把包含 3 个工作项的 Average Time in Status 报表按自定义 Team 字段分组，并且只显示 QA。每个分组只有一个工作项，三种单元格状态因此可以逐项核对。
全程保持以下配置不变：
| 设置 | 值 |
|---|---|
| Report | Average Time in Status |
| 工作项范围 | project = SR AND key in (SR-5401, SR-5402, SR-5403) ORDER BY key ASC |
| Work item date range | 空 |
| Trim History | 关闭 |
| Calendar | Weekdays 09:00-17:00 UTC |
| Format | Decimal Hours |
| Group by | Team |
| 所选状态 | QA |
Jira History 证据与 Calendar 重叠时间如下：
| Team 分组 | 工作项 | 相关 Jira History | QA 贡献者 | 计入的 QA 时长 | 显示的 QA 平均值 |
|---|---|---|---|---|---|
| No QA entry | SR-5401 |
In Progress → Done；没有 QA 区间 | 0 | 无数值 | - |
| Weekend QA | SR-5402 |
周六 09:00 → 11:00 UTC 处于 QA | 1 | 0h | 0.00 |
| Business-hour QA | SR-5403 |
周一 09:00 → 11:00 UTC 处于 QA | 1 | 2h | 2.00 |
Weekdays 09:00-17:00 UTC 是这份可复现报表使用的 Calendar 名称，不代表 Jira 或 StatusPath 在所有环境中的默认日历。
人工核对三个单元格
横线：没有计算得到的 QA 贡献
SR-5401 在本报表使用的 History 中没有进入 QA：
QA 贡献者数量 = 0
QA duration 记录 = 无
数值 QA 平均值 = 未定义
显示值 = -
横线不是零的另一种写法。它保留了“该行没有计算得到的 QA 贡献”这一事实。在其他报表中，这种缺失也可能来自范围、权限、Work item date range、Trim History 或 Jira History 变化，而不一定是工作流路径跳过了 QA。
显示为零：先区分精确零与舍入零
SR-5402 确实记录了周六 09:00 到 11:00 UTC 的两小时 QA 自然时间区间。退出时间和报表运行时间都晚于该区间；Calendar 时区为 UTC，工作日为周一至周五，工作时间为 09:00-17:00，Trim History 关闭。因此整个区间都在所选 Calendar 之外：
已记录的 QA 区间 = 周六 09:00 → 11:00 UTC
与所选 Calendar 重叠 = 0h
QA 贡献者数量 = 1
QA 平均值 = 0h ÷ 1 = 0.00h
这套受控计算证明计入时长精确为零，但单元格文字本身不能。例如：
0.004h = 14.4 秒
按两位 Decimal Hours 显示 = 0.00h
这个舍入后的小正数与 0h 的原始结果不同，尽管两者都显示 0.00。因此，数值零保留了与横线不同的证据，但要判断它是否精确为零，仍需原始时间戳、Calendar 交集证据或更高精度的格式/导出。
正数：有一个位于 Calendar 内的 QA 贡献
SR-5403 在周一记录了同样的两小时区间，并且完整落在 09:00–17:00 UTC 内：
已记录的 QA 区间 = 周一 09:00 → 11:00 UTC
与所选 Calendar 重叠 = 2h
QA 贡献者数量 = 1
QA 平均值 = 2h ÷ 1 = 2.00h
这不是跨团队绩效比较。三个分组只是用于隔离状态参与情况和 Calendar 重叠时间的对照。
证明精确零仍保留在分母中
再运行一份只包含 SR-5402 和 SR-5403、按 Project 分组的 Average Time in Status 报表。两个工作项都进入过 QA，所以两者都是贡献者：
QA 计入总时长 = 0h + 2h = 2h
QA 贡献者数量 = 2
QA 平均值 = 2h ÷ 2 = 1.00h
如果错误地丢弃零值贡献者，结果会变成 2h ÷ 1 = 2.00h。截图中的 1.00 是符合条件的精确零贡献参与分母的聚合证据。
在 StatusPath Reports 中复现核对
- 打开每个工作项的 Jira Activity → History，核对 QA 进入与退出事件；不要根据当前状态推断过去的 QA 区间。
- 使用明确的三个工作项 key 范围运行 Average Time in Status。
- 本次核对中保持 Work item date range 为空，并关闭 Trim History。
- 选择
Weekdays 09:00-17:00 UTC，Format 设为 Decimal Hours，按 Team 分组，并且只显示 QA。 - 确认三个分组行的 Work item count 都是 1。
- 将鼠标悬停在每个数值 QA 平均值单元格上，或用键盘把焦点移到单元格，核对合计时长和参与者数量；不要只根据两位小数文字断定精确零。
- 运行两个 key 的聚合报表，确认
(0h + 2h) ÷ 2 = 1.00h。 - 对于横线，或仍无法解释的数值，请在完全相同的范围与时间控制下运行 Time in Status，检查工作项明细行，并确认 QA 贡献是否存在。
报表类型说明 Average Time in Status 与 Time in Status 的区别；Calendar 与时长用于核对工作日、工作时间、时区、节假日和例外；表格视图说明单元格和列的行为。
快速判断表
| QA 单元格显示 | 首先检查的证据 | 安全解释 |
|---|---|---|
- |
QA 参与者数量、范围、历史窗口和规则 | 该分组行没有符合条件的 QA 贡献 |
0.00 |
原始时长、精度、参与者数量和 Calendar 交集 | QA 数值存在；未舍入值为零或舍入后为零 |
| 正数 | History 区间和 Calendar 重叠 | 存在计入的 QA 时长；继续核对显示单位 |
不要用可见的分组总数代替证据检查。Work item count 是 Team 分组的总体大小，而某个状态的参与者数量可能更少。
常见错误
把所有横线都转换成零
这样会抹掉“没有计算得到的 QA 贡献”与“有贡献区间但计入时长为零”之间的区别。
把零当作没有时间经过的证明
SR-5402 确实经过了 2 个自然小时。所选工作 Calendar 计入零，是因为两个时间戳都落在周六。
把每个显示的 0.00 都当作精确零
Decimal Hours 会舍入到两位小数。区分 0h 与 0.004h 之类的小正数前，应检查原始证据或更高精度的结果。
只检查当前 Jira 状态
已完成工作项即使当前状态是 Done，也可能有历史 QA 区间。应检查 Activity → History。
比较使用不同 Calendar 的结果
同一个周六区间在 24×7 Calendar 下可能得到不同的计入时长。应把 Calendar 名称和定义与数值一同记录。
假设 Work item count 就是 QA 分母
三个受控 Team 分组都包含 1 个工作项，但只有两个分组包含 QA 贡献者。应检查 QA 单元格证据。
排查符号时同时修改范围和历史控制
不同的 JQL、权限、日期筛选或 Trim History 边界可能改变 QA 贡献是否存在。先保持这些条件不变，再把差异归因于 Calendar。
常见问题
横线一定表示工作项从未进入 QA 吗？
不一定。它表示当前分组结果没有计算得到的 QA 数值。确认原因前，应检查 Jira History、范围、权限、Work item date range 和 Trim History。
为什么周六两小时的区间显示 0.00？
该工作项贡献了 QA 区间，但 Weekdays 09:00-17:00 UTC 在周六没有工作时间窗口，因此与所选 Calendar 的重叠为零小时。
0.00h 可以代表正时长吗？
可以。采用两位小数显示时，足够小的正小时数会舍入为 0.00h。受控的周末行之所以是精确零，是因为整个区间与 Calendar 没有交集；只看显示文字无法证明这一点。
改用 24×7 Calendar 会改变周末行吗？
会，前提是同一个完整区间仍在范围内。24×7 Calendar 会计入 2 个自然小时，因此单贡献者的 QA 平均值会是 2.00 Decimal Hours。
仅看 Work item count 足以判断横线是否正确吗？
不足。它描述的是分组总体，不一定是该状态的参与者数量。应核对 QA 单元格，必要时再检查 Time in Status 明细。
可以直接把 0.00 与另一份报表中的零比较吗？
只有在范围、History 边界、Calendar、时区、分组、状态身份和显示格式都对齐后才可以。文本相同不能证明计算规则相同。
相关指南
- Jira 状态平均时长如何计算
- Jira 当前状态平均时长
- 为什么 Jira 状态列没有出现在 Time in Status 报表中
- 如何在 Jira Time in Status 中排除周末
- 如何在 Jira Cloud 中计算 Time in Status
把缺失与计入为零分开
横线表示该分组行没有符合条件的数值 QA 贡献；0.00 表示数值贡献存在，但它可能是精确零，也可能是舍入到两位小数后的正数。修改工作流、范围或 Calendar 政策前，应先保留并核对这三种状态。
在 Atlassian Marketplace 试用 StatusPath Reports，复现三种单元格核对，再保存经过验证的范围、Team 分组、QA 列和 Calendar 配置。