无需 Jira 的工程度量
无需 Jira 即可衡量重要事项。了解如何从 Git、CI 及团队已有的工具中追踪工程健康状况。
By Ellis Keane · 2026-03-23
可见性最佳的小型工程团队，往往是那些停止追逐 Jira 要求他们追踪的指标的团队。
我知道这听起来像是为了反对而反对，老实说，可能有一点 – 但我曾花了将近三年时间忠实地维护 sprint 看板、梳理 backlog，以及更新那些在当天早上有人打开 Jira 之前就已经做了一半的 ticket 估算。每两周我们就会坐在一个房间里（其实是 Zoom – 那是 2023 年），盯着一张 velocity 图，它没有告诉我们任何通过互相交流就已经知道的事情。无需 Jira 的工程度量不是我主动寻找的。它发生在我停止假装 velocity 图在告诉我任何有用的东西的时候。
如果你的团队小到可以围坐在一张桌子旁，你可能不需要 Jira 来了解团队状况。你需要的是从已有工具中获得更好的信号。
这不是一篇"Jira 很糟糕"的文章。对于需要 Jira 式追踪的组织来说，Jira 是一个很好的工具（在某种规模下，他们确实需要）。但如果你是一家 10–40 人初创公司的 engineering manager，仅仅为了产出 velocity 图而为 Jira 付费，有点像买工业烤箱来热午饭。
"仅仅为了产出 velocity 图而为 Jira 付费，有点像买工业烤箱来热午饭。" attribution: Chris Calo
Jira 指标实际在衡量什么
直说了吧：大多数 Jira 指标衡量的是 Jira 的使用情况，而非工程产出。Story points 衡量团队估算 story points 的能力。Velocity 衡量团队以大致相同容量填满 sprint 的一致性。Burndown 图衡量是否有人记得在周四下午把 ticket 拖过看板。
这些并非完全没有用。但它们都是披着 developer productivity metrics 外衣的流程指标，两者之间的差距正是 engineering manager 迷失方向的地方。
我曾经是那个在与利益相关者开会前花将近一小时，将 Jira 数据捏造成一份显示"我们进展顺利"的幻灯片的 EM。利益相关者点头，问了一个关于上周二登录 bug 的问题，会议结束。那一小时是为幻灯片服务的。真正的答案是"去问工程师"。
如果你的指标需要比它们所衡量的工作更多的维护，那么指标本身才是问题所在。
来自 Git 的 cycle time，而非来自 ticket 看板
对于小型产品团队来说，cycle time 通常是你能追踪的信号最强的指标。它衡量从第一次 commit 到 production 部署的持续时间，完全可以从 Git 历史和 CI pipeline 中推导出来 – 无需 ticket 看板。
组成部分：
- 分支或 PR 上的第一次 commit 时间戳
- PR 合并时间戳
- 部署时间戳（来自你的 CI/CD – GitHub Actions、CircleCI 或你正在运行的任何工具）
1 和 3 之间的差值就是你的 cycle time。将其分解为各个阶段 – 编码时间（1 到 PR 打开）、review 时间（PR 打开到合并）以及部署队列（合并到 production）– 你就拥有了一个能告诉你工作实际在哪里停滞的诊断工具。
当我第一次为我们的团队做这件事时，数据真的令人惊讶。我本以为 review 时间是我们的瓶颈（每个人总是认为 review 时间是瓶颈，不是吗？）。结果发现我们的 coding-to-PR 阶段没问题，review 也没问题，而我们在合并和部署之间平均损失了约两天，因为我们的 staging 环境不稳定，没有人将修复它列为优先事项。Velocity 图永远不会发现这一点。
如何衡量
如果你在使用 GitHub，可以通过 CLI 拉取数据：
```bash
Get merged PRs for the last 30 days
gh pr list – state merged – limit 50 – json number,createdAt,mergedAt,headRefName ```
对于部署时间戳，大多数 CI 系统通过 API 或 webhook 提供。将 PR 合并 SHA 映射到部署事件，你就获得了按阶段分解的 cycle time。
提示： 如果你的 CI 无法清晰地提供部署时间戳，一个极简的方法是让 Slack bot 向 #deploys 频道发布带有 commit SHA 的消息。你可以获得时间戳、人类可读的日志，以及 – 作为副效果 – 一个告诉你发布频率的频道。
Code review 吞吐量
Review throughput – 每名工程师每周 review 的 PR 数量，以及从 PR 打开到第一次 review 的中位时间 – 比任何 sprint 指标都能更好地反映团队健康状况。它被低估了。
为什么？因为 review 行为是一个领先指标。当 review 时间开始延长时，通常意味着工程师超负荷、频繁上下文切换，或者（这是令人不舒服的一个）彼此回避对方的代码。在这些问题作为两周后错过的截止日期显现之前，任何一个都值得了解。
GitHub 通过其 API 提供这些数据。关键字段是 PR 上的 createdAt 和第一个 review 事件上的 submittedAt。
我关注的数字是到第一次 review 的中位小时数。根据我们在几个小型团队中的经验，健康的 review 节奏通常保持在约 8 小时以下。当它持续超过一天时，说明某些结构性的东西已经改变 – 不管是什么，在 Jira 中都是看不见的。
会议与决策比率
这不是一个传统的工程指标，我应该坦率地说：这是一个粗略的启发法，而不是 KPI。但对于小型团队，我发现它出人意料地具有启发性。
统计你的团队本周开了多少次会议。统计其中产生的具体决策（不是"我们应该研究 X"– 而是有责任人和后续步骤的真正决策）。将后者除以前者。
如果你的会议中不到一半产生了决策，值得问一问这些会议是否值得花时间。有些会议的存在是为了降低风险或共享上下文，这是合理的 – 不是所有事情都需要以决议结束。但当你开始追踪这一点，哪怕是非正式地（我真的在笔记本上记录计数），你会对哪些会议有成效、哪些只是没人质疑的仪式培养出一种感觉。
我追踪这个指标大约一个月，它改变了我安排会议方式的程度超过了任何生产力文章。当你能看到你的周一 standup 连续三周没有产生任何决策时，取消它就不再感觉激进了。
无需 Jira 构建工程度量：轻量级仪表板
你不需要 BI 工具。一个 Notion 页面、一个 Google Sheet，或每周一条包含四个数字的 Slack 消息就够了：
- 中位 cycle time（来自 Git/CI）– 我们发布得更快还是更慢？
- 到第一次 review 的中位时间（来自 GitHub）– 团队是否及时 review？
- Deploy frequency（来自 CI 或 #deploys 频道）– 我们多久发布一次？
- 会议与决策比率（手动计数）– 我们的会议值得吗？
四个数字，全部可从你已有的工具中推导，没有任何一个需要维护 Jira 看板。每周更新。如果某个数字连续两周朝错误方向移动，进行调查。如果保持稳定，置之不理。
重点不是建立一个监控系统（请不要这样做 – 你的工程师会恨你，而且他们有理由这样做）。工程团队的可见性应来自工作本身，而不是要求人们汇报工作。
最好的工程指标收集成本低、难以被操控，并且能告诉你可以采取行动的事情。Story points 在这三点上全部失败。
真正需要 ticket 看板的时候
我说这不是一篇"Jira 很糟糕"的文章，我是认真的。有些合理的情况下，不使用项目管理工具追踪指标会变得确实不负责任：
- 合规要求严格的行业，任务状态的审计追踪在法律上是必须的
- 规模较大的工程组织，跨团队依赖关系使非正式协调难以为继
- 拥有专职项目管理职能的组织，需要跨团队的权威真实来源
如果这是你的情况，Jira（或 Linear，或 Shortcut）是正确的选择。我的论点是，对于小型团队，仅仅为了指标而维护一个重型工具是一笔糟糕的交易。你最终会为了工具的工作模型而优化，而不是为了团队的实际工作。
说真的？即使是使用 Jira 的团队，也会从用上面的 Git 衍生指标补充看板数据中受益。Jira 告诉你人们说他们在做什么。Git 告诉你他们实际在做什么。两者都有用，但只有一个对状态更新表演免疫。
如果指标问题在你的初创公司中不断出现，试试这个四数字仪表板一个月。无需 Jira 的工程度量听起来可能像是没有安全网 – 但一旦你看到 Git 历史和 CI pipeline 中有多少信号，你会想知道 ticket 看板究竟增加了什么。
自动呈现 cycle time、停滞的 PR 和 review 瓶颈 – 无需自定义脚本或 Jira 看板。
Q: 没有项目管理工具能否获得有意义的工程度量？ A: 可以。Cycle time（从第一次 commit 到部署）、review throughput 和 deploy frequency 全都存在于你的 Git 历史和 CI pipeline 中。对于少于约 40 名工程师的团队，这些指标通常比 ticket 看板上的任何东西更精准、更难被操控 – 并且不需要任何人拖动卡片来保持准确。
Q: Sugarbug 会自动呈现工程度量吗？ A: Sugarbug 连接 GitHub、Linear、Slack 和日历，为你的团队活动构建知识图谱。它会标记停滞 PR、review 瓶颈和未解决决策等模式 – 无需编写和维护针对 GitHub API 的自定义脚本，就能覆盖这里描述的许多信号。
Q: 如何获得批准停止使用 Jira 来衡量指标？ A: 将其定位为一次实验，而不是一场革命。将 Git 衍生的指标与现有的 Jira 仪表板并行运行四周，然后比较哪些数字推动了实际变化。如果 Git 指标被证明更具可操作性（根据我们的经验，它们往往如此），情况就会不言而喻。
Q: 流程指标与性能指标有什么区别？ A: 流程指标（story points、velocity、burndown）衡量团队遵循工作流的一致性。性能指标（cycle time、deploy frequency、review throughput）衡量团队实际交付了什么以及速度有多快。小型团队几乎总是从后者获得更多信号，因为性能指标来自工作本身，而不是手动状态更新。