你应该跟踪的5个交付指标（除了速度之外）

我们都知道，我们应该关注结果而不是产出。但是，产品成果并不是凭空而来的。

产出会引导我们达到目的。

如果不首先产生合理的产出，你就不可能有有意义的结果。因此，尽管最大化产出并不能保证更好的结果，但它确实有很大的帮助。

顺利的交付会带来更好的敏捷性和更多的实验，从而带来更多的学习和更好的产品，产生更好的结果。

但到底什么是好的交付？你又是如何衡量的呢？

大多数人把速度（每个冲刺阶段交付的故事点数量）作为他们的主要交付指标。虽然这没有错，但速度本身给我们提供的信息量是有限的。

让我们来看看其他五个值得监测的交付指标。

目录

1. 周期时间
2. 可预测性
3. 技术债务
4. 在位时间
5. 进入市场的时间

1. 周期时间

周期时间是指从开始工作到完成一个工作项目（基于已完成的定义）之间所经过的时间。

为了让它更具体，我们假设你的平均工作时间是上午9点到下午5点，在这一周里你完成了以下任务。

• 周一上午10点开始计划工作
• 周三上午10点开始编写功能代码
• 星期四下午4点提交给QA和代码审查
• 周一上午11点将其合并到主站，因此符合你对完成的定义。

由于周期时间衡量的是从实际工作开始的时间，你衡量的是星期三上午10点到星期一上午11点之间的时间，这里的周期时间是29个工作小时。

周期时间=从工作开始到完成之间所经过的时间

周期时间是最全面的跟踪指标。低周期时间需要在产品开发的所有领域进行优化，包括。

• 小型工作项目
• 有限的正在进行的工作
• 最小的 “等待团队”
• 精简的程序

周期时间是衡量交付过程健康的最佳指标之一。保持较低的周期时间使团队能够实现。

• 更好的可预测性
• 更高的灵活性
• 更短的上市时间
• 更少的多任务处理

保持较低的周期时间是你可以做出的改善你的交付过程的最佳投资之一。

2. 可预测性

你可能已经知道这是不可能的，特别是在一个复杂的软件开发环境中。但你也不能落入 “一旦完成就能完成 “的做法。

外部的最后期限、依赖性和适当的资源管理要求你有一定程度的可预测性。但大多数团队并不跟踪它。

然后他们就会惊讶地发现，他们对承诺的最后期限没有信心。毕竟，你很难改善你没有跟踪的东西。

有各种方法来跟踪可预测性。其中一个常见的是跟踪冲刺计划与结果。

可预测性=100%-|交付百分比-100%|。

让我们看看一个例子。

• 冲刺1:
  • 计划中的。100个故事点
  • 已交付：90个故事点
  • 交付百分比：90
  • 可预测性：100%-|90%-100%|=90%。
• 冲刺 2:
  • 计划中的。100 sp
  • 已交付: 120 sp
  • 交付的百分比：120%
  • 可预测性：100%-|120%-100%|=80%。
• 冲刺 3:
  • 计划中的。50 sp
  • 已交付：63秒
  • 交付百分比：126%
  • 可预测性：100%-|126%-100%|=74%。

平均可预测性=（90%+80%+74%）/3=81.3

正如你所看到的，过度交付也降低了总体可预测性。它可以作为一种保障。

团队可以在每个冲刺阶段计划一个低得离谱的故事点，以便每次都能过度交付。但这并不会使他们变得可预测，不是吗？

提高可预测性是值得我们关注的，因为它允许。

• 更好的长期估计
• 更准确的计划
• 整个团队的压力更小

追踪你最近三到五个冲刺阶段的平均可预测性，并努力使其每次都能一点点地接近百分之百。

尽管你可能不会达到100%的可预测性，但这是一颗值得期待的北极星。

3. 技术债务

每个人都在谈论技术债务，但只有少数人在衡量它。

技术债务本身并不坏。它甚至可能是你最好的朋友。它是关于适当的债务管理。

它的作用类似于企业的货币债务。你承担的债务越多，你就能在短期内提供更多的东西，但代价是需要在长期内偿还利息。

而有时候，短期的效果会更好。特别是当你在一个全新的MVP概念上工作时。

正确管理技术债务的最好方法是衡量它，并与团队商定你在某一时刻的理想债务数额。

首先，什么是技术债务？这是一个每个团队都应该根据他们目前的情况单独达成共识的问题。

在大多数情况下，我将技术债务视为产品当前技术状态与理想状态之间的差异。这种差异可以包括。

• 积压的Bug
• 过时的库、框架和SDK
• 缺少自动化的E2E测试
• 冗长的代码或未使用的功能
• 破损的管道
• 不理想的云基础设施

我喜欢列出所有已知的东西，并像其他积压项目一样估计它们。虽然估计错误是相当有争议的，但我还没有找到更好的方法。

通过列出和估计所有已知的问题，你可以计算出技术债务的总体规模。

技术债务规模=估算当前技术状态和期望状态之间的所有已知差异

估算技术债务是非常模糊的，这没关系。我们更感兴趣的是规模，而不是一个具体的数字。

让我们假设你的技术债务积压有400个故事点大。

现在你可以计算出你的技术债务与速度的比率，这应该可以大致回答这个问题：你需要多少个完整的冲刺阶段来偿还所有已知的债务？

技术债务比率=技术债务规模/速度

如果你的技术债务是400sp，而你的平均速度是90，那么你的技术债务比率是4.44，意味着你大约需要五个冲刺来偿还债务。

尽管这不是一个精确的计算，但它仍然是有价值的洞察力。

4.44的比率是高还是低，取决于具体的情况。

我鼓励所有团队有意识地坐下来，讨论他们理想的技术债务比率。比如说，你同意在你目前的产品状态下，你的目标是3-7的技术债务比率。

超过7将表明你承担了太多的债务，你应该优先偿还部分债务以避免长期的后果。

另一方面，无论如何，低于这个数字并不完美。它可能意味着你专注于技术上的卓越而不是快速的价值交付。

也许你可以通过承担一些债务，让自己在接下来的冲刺阶段提供更多的价值。

尽管我很想给你一个最佳范围，但这是一个复杂的问题，你必须根据具体情况而定。

作为一个经验法则：如果你的首要任务是学习和测试假设，那么就承担更多债务。如果你有一个经过验证和确定的想法，就保持较低的债务比率。

4. 处于状态的时间

监测一个特定的产品积压项目在特定状态下花费的时间，可以让你对你的工作流程有一个更详细的看法。

处于状态的时间=进入状态和退出状态之间所花费的时间

这个指标对于有多种状态的更复杂的工作流程尤其重要。通过监测一个票据在特定状态下花费的时间，你可以迅速发现瓶颈。

你的工作项目是否在代码审查状态下花费了太多时间？也许你需要深入挖掘资源库的指标来解决这个问题。你的QA花了太多时间吗？也许是时候增加资源或改进测试流程了。

我把状态时间当作一个指南针的指标。它可以帮助你把注意力集中在最需要改进的地方。

5. 进入市场的时间

有不同的方法来衡量进入市场的时间。

比方说，你正在开发一个新功能。你的上市时间是指从决定建立该功能到将其推向生产的时间。

低上市时间可以提高你的敏捷性，帮助你更快地测试和修复想法，并允许你捕捉更多时间敏感的机会。

它是等待时间、史诗般的周期时间、构建和集成时间以及发布稳定期的总和。

等待时间

在大多数情况下，在决定一个功能和实际开始工作之间会有一些时间。造成这种情况的原因有很多，比如。

• 等待团队的能力
• 收集所有必要的批准文件
• 澄清概念
• 官僚主义

注重及时计划和流畅的流程，限制等待时间。

史诗般的周期时间

史诗般的周期时间是工作的主体。它的工作方式与周期时间相同，但涉及整个史诗。

意思是它是指从拿起第一个与史诗有关的任务到完成最后一个任务之间的时间。

当然，功能越小，范围越大，周期时间就越短。

构建和整合时间

在所有工作完成后，是时候准备一个包或将其与主代码库集成。这可能需要几分钟或几周，取决于产品的规模和你的流程。

通过使用强大的自动化管道来保持较低的构建和集成时间。

发布稳定期

发布稳定期是指从开发人员说可以发布到实际发布给客户这段时间内，纠正产品问题的时间。

所有最后的润色都在这里，这些包括。

• 集成测试
• 回归测试
• 用户验收测试
• 安全和性能审查
• 获得所有签收
• 应用程序发布过程

自下而上的发布过程，以减少稳定期。

上市时间=等待时间+史诗般的周期时间+构建和整合时间+发布稳定期

通过不断审查和改进你的上市时间，在竞争中保持领先地位。

结束语

虽然这个清单并不全面，但也没有必要跟踪50个各种交付指标。

专注于大块的内容，只有在你需要更好地理解核心指标时，才深入挖掘更详细的指标。

适当地跟踪你的速度（周期时间、状态时间和上市时间）、可预测性和质量（技术债务）应该给你一个足够宽广的画面，以了解你的低价果实在哪里，以及你应该把大部分注意力放在哪里。

翻译：云瑞设计

原文：https://blog.logrocket.com