我是DORA 4指标的忠实拥护者。如果在正确的情况下使用，它们是推动工程改进的有力工具。但是，作为一个社区，我们正在错误地使用它们。
DORA指标的定义
DORA 4指标来自《加速》，这是一本广受欢迎的工程领导参考指南。
旨在帮助工程团队弄清：
- A）作为精英团队运作的样子；以及
- B）他们与行业的比较，
DevOps研究和评估（DORA）小组建立了四个指标：
- 部署频率
- 周期时间（有时称为变更的准备时间）
- 变更失败率
- 平均恢复时间（有时称为恢复服务的时间）
他们说：
"部署频率和变化的准备时间衡量速度，而变化失败率和恢复服务的时间衡量稳定性。通过测量这些数值，并不断迭代改进，一个团队可以取得明显更好的业务成果"。
我们的问题就在这里...
我们对DORA指标的使用是不正确的
衡量DORA指标本身并不能带来改进或更好的商业成果。这有三个原因。
1.你的企业不知道如何将DORA指标转化为他们理解或关心的东西。
例如，周期时间和部署频率显示了小块工作通过管道并被发布到生产的速度。这对你的业务没有帮助，因为他们关心的是整个功能建立和发布的速度，以及你每个月/季度能发布多少个新功能。此外，如果你没有建立企业和客户想要的东西，你发布工作的速度有多快并不重要。
2.DORA指标是速度和稳定性的滞后指标。
为了真正改善它们，还有一组额外的领先指标指标，我们需要测量和改善，如拉动请求大小、审查时间和代码流失。
3.如果没有开发人员自下而上的改变，工程组织的持续改进就不会发生。
我曾经是一名开发人员（不久以前），我所知道的大多数开发人员对被叫到会议上展示仪表盘不感兴趣。真正的改变来自于优化工作流程，在那里开发人员花了他们所有的时间--在IDE和Slack中。
为了把DORA指标和更好的业务成果联系起来，我们必须停止把它们当作万能的东西，并着眼于工程改进的更大画面。
工程团队如何交付价值？
有人说，工程团队应该根据业务成果（如收入）来衡量成功。这是一个好主意。但在现实世界中，很难将工程与利润直接联系起来。这没关系，因为在工程中我们有两个可以控制和衡量的商业结果的代理。
价值变量1：更快地提供更多的功能
作为一个快速发展的初创企业的CEO，更快地交付新功能几乎总是我从工程部门想要的第一件事。新功能可以帮助销售人员达成新的交易，并帮助客户成功获得续约--这两点都可以转化为收入。
更具体地说，我希望从我们的工程部领导那里得到三样东西：
- 我们能否在现有的基础上逐步提高价值？
- 在我们投资新的工程师之后，我们能不能显著提高价值？
- 我们是否提供了业务所要求的功能？
前两个是关于速度和可预测性。第三是关于一致性。
价值变量2：兑现诺言
一个真正重要的、被高度低估的工程组织提供价值的方式就是贯彻他们说要做的事。当我还是工程部的副总裁时，我记得在执行会议上经常不得不改变日期和降低预期。如果我们经常为错过承诺而道歉，或者有很多影响客户的bug和事件--这对业务造成伤害。
两个非常适合显示工程成果的非DORA指标
由于我们的目标是兑现承诺并更快地交付更多的功能，我们的改进过程必须从我们的项目开始。项目、倡议、史诗、功能--无论你在组织中如何称呼它们--都是工程和业务之间的共同语言。
那么，企业如何知道我们在他们关心的项目上履行了承诺？
定期报告这两个指标是有帮助的：
资金指标1：项目分配
项目分配回答了这样一个问题："我们的团队中有多少人在为我们的每个项目工作？"CEO们喜欢这个指标，因为它能迅速显示工程部是否在做企业最关心的事情。记住，如果你交付的是错误的功能，那就无所谓了。你会喜欢这个指标，因为它为关于你的团队能做多少工作的谈判带来了逻辑。如果你被要求承担一个新项目，你可以指着项目分配报告说："当然可以。在这些现有的项目中，我们应该减少对哪些项目的投资？"而且，它可以给你一个合理的基础来要求更多的人员配置。
金钱衡量标准2：项目规划的准确性
项目规划的准确性回答了 "我们是否会实现对这个项目的承诺 "的问题。LinearB实验室的一项研究发现，2021年运行Scrum的1900个团队的平均冲刺计划准确率为46%
如果团队每2-3周交付的功能少于他们计划的一半，你就永远无法在一个季度内交付你所承诺的功能。
项目速度如何？一些团队使用这个指标来回答 "我们在XYZ项目上的进展是快了还是慢了？"要小心。不是所有的问题和故事点都是一样的，如果不小心使用，速度可能会被滥用。
连接DORA指标和工程结果之间的点
一旦你有了项目分配和规划准确性的基线，你就可以开始改善它们。这就是DORA指标变得有用的地方。
周期时间和结果
周期时间是衡量大块工作在开发周期中流动的速度。更快的周期意味着更少的流程瓶颈和更多的可预测性。
这就是为什么低周期时间是高规划准确性的首要指标。在LinearB实验室的研究中，超过一半的受访团队的周期时间超过了9天。如果这些团队正在进行为期两周的冲刺，这意味着他们在冲刺的第五天还没有开始编码的任何工作很可能会被延续下去。
部署频率和结果
部署频率表明新工作被发布到客户手中的频率。它是计划准确性的一个重要的领先指标。低的部署频率意味着需要更多的时间将新的功能、可用性增强和错误修复投入生产。
变更失败率（CFR），平均恢复时间（MTTR）和结果
这两个指标不仅仅是衡量客户体验的好代名词。是的，有更少的生产事故和更快地修复它们会让客户满意。但是，低的CFR和MTTR转化为更少的非计划性工作，从而导致更高的计划准确性和更多的时间用于新功能。
这就是DORA 4如何帮助提供更好的业务成果。现在让我们来看看如何实际改善你的DORA指标。
改善DORA 4指标的四步流程
LinearB与来自BigID、Drata、GRIN、Bumble、Rapid 7、Appcues和Nimble的精英工程组织合作，在过去三年里建立了这个流程。它对他们有用，所以可能对你有用。
第一步。对照你的表现
很明显，要改善你的DORA指标，你需要知道你的情况。你可以从很多地方获得这些信息：
- 一些问题跟踪器有计算周期时间和MTTR的方法。
- 大多数CI/CD工具会计算部署频率
- 很多可观察性工具都会计算CFR和MTTR
- 你可以从LinearB免费获得所有四个DORA指标。
专业提示：小心使用单一的数据来源来计算你的指标。例如，问题追踪器只有在你的卫生状况非常好的情况下才能提供准确的数据。LinearB 将来自 Git、问题、版本和事件的数据进行关联，以确保计算的完整性。
一旦你知道你的团队是如何表现的，它有助于将你的指标与行业基准进行比较。要了解你与其他工程组织的比较，请查看2019年的DORA研究或2022年第一季度的LinearB实验室研究。
第二步。看领先指标
DORA指标是计划准确性和可预测性的领先指标，但它们是效率和质量的滞后指标。这意味着，一旦你知道你想改善哪些DORA指标，还有一组指标需要学习：
拉动请求时间
这个指标平均占周期时间的2/3，所以它是一个很好的开始。我们将Pull Request Time定义为PR Pickup Time（PR发布后开始审查所需的时间）和PR Review Time（审查开始后PR被合并所需的时间）的组合。
LinearB实验室研究了847,000个拉动请求，发现一半的PR在其生命周期中闲置了50.4%。这意味着如果你的平均周期为8天，那么你的拉动请求平均有2.5天处于闲置状态！
缩短PR时间可以减少周期时间，而且，通过消除闲置时间和提高情景意识，它有助于减少CFR和提高质量。
拉动请求大小
这可以说是一个健康的开发管道的最重要指标。LinearB实验室发现，小的PR会导致更快的编码时间、拾取时间、审查时间和部署时间。
为什么？
- 小块的工作更有可能在没有干扰的情况下完成
- 小的PR更有可能被更快地接受
- 小的公共关系有较少的交接和闲置时间
- 小的PR更容易合并和发布。
所有这些都有助于周期时间和部署频率。小的PR也可能有更高的测试覆盖率和更彻底的审查，从而减少CFR。当然，它们也更容易回滚和修复，这有助于MTTR。
代码流失
代码流失，有时也被称为返工，突出了你在合并后三周内重写的代码的百分比。如果你的代码流失率很高，你就是：
- 浪费了时间
- 可能看到很多计划外的工作。
两者都会拖慢你的速度。
搅乱的代码也更有可能出现质量问题，从而增加你的CFR。
那么，我们如何实际改善PR时间、PR规模和代码流失？现在是时候让我们的开发人员参与到第三步中来了
第3步。建立团队工作协议
仅仅是指标和仪表盘并不能改善开发团队。为了持续改善DORA指标和步骤2中的所有领先指标，我们需要得到开发人员的支持。
建立团队工作协议的会议是一个好的开始。它看起来像这样：
- 目标：留下书面的团队工作协议，以改善影响第2步中领先指标的关键领域。
- 出席者： 团队领导和他们的直接团队。没有副总裁、总监或总经理。
- 时间长度 ：你可以在15-30分钟内完成，但为了安全起见，请阻止50分钟。
- 形式： 团队领导进行安全讨论，每个人都有机会说话。
- 准备工作 ：把过去90天的数据带到会议上，为讨论提供信息。
问题
团队领导可以根据数据准备一些问题，让事情开始。例子包括...
- "PR 保留的最长时间是多久？"
- "谁的工作，发行人或审查者，是为了确保审查准时开始？"
- "新专题工作的理想公关规模是多少？"
提示
- 解释会议背后的原因，改进的需要，并从 "一级改进 "开始。意思是，例如，如果你的平均公关规模目前处于 "需要关注 "的层次，那么就以 "一般 "而不是 "强 "为目标。
- 把一切都写下来，每30-90天回顾一次，以调整改进和你学到的东西。
我保证你的开发人员实际上会喜欢这个会议。他们希望产生高质量的工作，更快地合并，并回到解决新问题上。所有拖慢你的周期时间和增加你的CFR的事情也会伤害他们。
团队工作协议给了他们对工作的权力，在团队中的责任，并帮助他们看到他们的个人努力是如何与商业价值联系起来的。
第4步。优化开发人员的工作流程
我成为一名开发者是因为我想建造东西和解决问题。只是我们中的大多数人如果每天能写1-2小时的代码就很幸运了。我们其余的时间都花在审查其他人的代码，更新Jira票据，写状态更新，整理Slack的噪音和参加会议。这些任务与PR审核时间、代码流失率、DORA指标和计划的准确性都有负相关。
LinearB实验室发现，Git中31%的工作与票据没有联系，一半的拉动请求有50.4%的时间处于闲置状态。这些都证明了开发者的非编码任务的工作流程远未优化。
Git系统有一些内置的警报，可以帮助处理拉取请求，但我认为我们还处于建立支持开发者所需工具的早期阶段。我相信这些工具需要在三个方面进行改进：
- 从多个来源（如Git、问题、版本、事件）关联数据。
- 生活在开发者工作的 "边缘"，例如IDE、Slack。
- 超越警报，实现完全自动化
LinearB专门为开发人员建立了一个名为WorkerB的机器人。通过简化与非编码任务相关的重复性、琐碎的工作，我们帮助开发人员更快地合并，并将更多的时间用于编码，这导致了DORA指标的改善、更高的规划准确性和更好的工程成果。