【51CTO.com快译】用于衡量软件开发工作的客观数据和指标一直存在。但很长一段时间以来，人们认为使用这些数据或指标来衡量软件开发的想法是不可能的。而Martin Fowler和Joel Spolsky等软件开发专家也认为这是不现实的。显然，衡量软件开发工作是一项具有挑战性的任务，这让一些软件开发人员感到沮丧。
而如今随着Git、Jira和其他项目管理工具等工具的兴起，其指标开始变得清晰起来，使人们能够更密切地、以数据驱动的方式查看软件开发项目内部发生的事情。
当然，很多组织已经开始采取行动。其中最重要和最著名的结果之一是由DevOps研究和评估组织(DORA)完成的。该组织在六年的时间里对数千名DevOps工程师和领导者进行了调查，最终推出了被认为对软件开发项目成功至关重要的四个指标。
四个DORA工程指标是：
(1)部署频率
(2)变更的平均交付周期
(3)平均恢复时间(MTTR)
(4)更改故障率
部署频率和变更的平均交付周期这两个指标用来衡量开发团队的开发速度。平均恢复时间(MTTR)和更改故障率用来衡量项目质量和稳定性。所有四个指标都可以通过挖掘开发团队当前使用的工具得出。
这四个DORA工程指标旨在允许开发团队根据业务目标调整他们的工作，它们已成为组织中的首席技术官(CTO)和工程副总裁获得有关其组织绩效的标准方式。通过密切关注并改进DORA指标推进开发团队的工作，开发团队可以确保他们做正确的事情来推动他们的项目，更重要的是他们的业务如何向前发展。
当然，了解指标实际衡量的内容及其含义对于使它们有用是必要的。此外，了解这些指标的当前状态是在开发团队改进它们的必要条件。
以下了解这四个关键指标。
1.部署频率
(1)它是什么?
部署频率衡量代码部署到生产中的次数。通常在“每日部署”中报告。
生产如今对不同的客户意味着不同的东西。对于SaaS公司来说，通常意味着将代码实际交付给客户实际使用的生产平台。对于其他公司，这可能意味着提供可供客户使用的版本。
(2)为什么重要
增加部署频率表明开发团队的效率和对其流程的信心。能够更频繁地部署的团队能够更快地将工作转移到他们的管道中，并且更高效地开发和处理他们的产品。
(3)它是如何计算的?
它记录了组织在一天内进行的部署总数。如上所述，“部署”的定义可能因组织而异。如果软件开发团队拥有持续集成(CI)/持续交付(CD)工具为其活动提供API，则该指标可以实现自动化。
(4)如何改进它?
如果组织希望提高部署频率，应该：
提高自动化测试覆盖率。
与持续集成(CI)/持续交付(CD)工具集成。
自动化发布验证阶段和发布流程。
减少生产中的错误恢复时间。
2.变更的平均交付周期
(1)它是什么?
变更的平均交付周期是从提交代码到将代码发布到生产中所需的平均时间。
一些组织从项目代码的第一次提交开始来计算时间，而另外一些组织从将代码合并到主分支开始计算时间。
许多组织将变更的平均交付周期转化为一个称为周期时间(Cycle Time)的指标，以下将对此进行讨论。
(2)为什么重要
较低的平均交付周期意味着组织的开发团队可以高效地编码和部署项目，并及时为其产品增加价值。试图降低平均水平会激励团队适当地划分工作、彻底审查代码并进行快速部署。
(3)它是如何计算的?
每个项目都从头到尾进行衡量，并计算这些时间的平均值。
(4)如何改进它?
该指标可以通过以下方式改进：
将自动化添加到部署过程中。
确保持续集成(CI)/持续交付(CD)流程尽可能高效。
将项目分成更小、更易于管理的块。
创建高效的代码审查流程。
3.平均恢复时间(MTTR)
(1)它是什么?
该指标衡量团队从系统故障中恢复所需的平均时间。而“故障”可能意味着任何事情，从生产中的错误到生产系统宕机。
(2)为什么重要
显然，停机时间越短越好，团队需要更快恢复。关注平均恢复时间将鼓励构建更强大的系统，并加强对这些系统的监控。
快速恢复时间反映了开发团队诊断问题和纠正问题的能力。测量平均恢复时间可以使团队在整个开发过程中更加谨慎，并关注质量。
(3)它是如何计算的?
通常情况下，通过测量系统中创建生产错误报告与解决该错误报告之间的平均时间来跟踪此指标。或者，它可以通过测量创建报告和将修复部署到生产之间的时间来计算。
(4)如何改进它?
平均恢复时间(MTTR)可以通过以下方式变得更好：
构建快速报告故障的持续集成(CI)/持续交付(CD)系统。
确保有一个对故障立即采取行动的流程。
将故障恢复优先于所有其他任务。
缩短部署时间。
4.更改故障率
(1)它是什么?
更改故障率衡量代码更改导致生产故障的频率。导致回滚、生产失败或生产中出现错误的更改都会影响该指标。
(2)为什么重要
这个指标很重要，因为花在处理故障上的所有时间都不是花在向客户交付新功能和价值上的时间。显然，减少软件中的问题是可取的。
(3)它是如何计算的?
通常情况下，该指标的计算方法是计算部署导致故障的次数，然后除以总部署数以获得平均值。平均值越低越好。
(4)如何改进它?
当组织执行以下操作时，更改故障率会得到改进：
确保自动化单元测试涵盖所有新代码。
作为持续集成过程的一部分改进自动化测试。
进行彻底和完整的代码审查，以帮助防止将问题引入生产中。
跟踪DORA指标的好处
(1)决策
始终如一地跟踪DORA指标，将使开发团队能够在何处以及如何改进开发过程做出更好的决策。这样做将揭示面临的瓶颈，并使开发团队能够将注意力集中在可能导致流程停滞的地方，还可以确定发展趋势，并且验证关于关注点的决策质量。
跟踪DORA指标可以帮助开发团队和企业管理人员将注意力集中在能够真正推动价值的事情上。它们使开发团队能够根据指标做出决策，而不仅仅是凭直觉做出决定。
(2)交付价值
DORA指标可以衡量开发团队交付的价值。如果DORA指标是有利的，则组织的开发团队将为其客户提供价值并保持必要的质量，以免偏离重点。这是组织的主要目标——为客户提供价值。
(3)良性循环
当任何东西被衡量时，它很可能会被人为操纵或更改———也就是说，人们会改变行为来优化被衡量的东西。很多时候这会对开发团队的工作产生负面的的影响。
组织希望开发团队努力优化这些DORA指标，可以提高效率并减少浪费，这会带来良好的结果。通常情况下，刻意追求指标会对开发团队产生负面影响，因为这些指标是经过精心设计的，其目的却恰恰相反。
LinearB帮助组织衡量和改进DORA工程指标
DORA指标很重要，而LinearB可以轻松跟踪它们，为组织提供开箱即用的DORA指标，可以轻松显示和跟踪。
通过向开发组织的高管提供其DORA指标的更高级别视图，这样的仪表板可能会很有用。通过简单的视图，高管可以一目了然地了解开发团队的工作情况以及可能需要进行哪些中途更正的事项。
除了DORA指标之外，LinearB还可以跟踪有助于提高组织绩效的其他指标。例如拉取请求大小、拉取请求审查深度和拉取请求审查时间等指标都可以监控，改进后将会减少更改的平均交付周期和部署频率。
LinearB超越DORA指标
LinearB超越了DORA的变更的平均交付周期指标，以提供周期时间(Cycle Time)指标。
周期时间是一个强大的指标，用于衡量给定代码单元从分支创建到生产部署所需的时间。它实际上是对给定任务或子任务交付给最终用户速度的衡量。当然，交付功能是每个开发组织的目标之一。
周期时间分为四个部分：
(1)编码时间——通常是指第一次提交到给定分支和为该分支创建拉取请求之间的时间。
(2)拉取请求时间——这是创建拉取请求和开始审查该拉取请求之间的时间。
(3)拉取请求审查时间——从拉取请求审查开始到合并代码之间的时间。
(4)部署时间——部署时间是代码合并和代码实际部署到生产之间的时间跨度。
改善周期时间有很多好处：
密切跟踪编码时间可以鼓励开发团队将开发工作分成更小、更易于管理的块。如果给定的分支或项目很大并且需要很长时间，那么周期时间就会增加。相反，它鼓励更小的工作量。
推动团队及时处理拉取请求。它有助于防止缓慢的拉取请求和过大而无法有效审查的拉取请求。
跟踪部署时间的团队被激励专注于改进和简化构建和部署流程。
周期时间的增加可以成为项目遇到困难的早期预警系统。如果必须为团队选择一个指标来衡量，那就是周期时间。
WorkerB改进了DORA指标
空闲时间是在软件开发过程中等待事情发生的时间——拉取请求闲置且未经审查就是一个很好的例子。它是影响DORA中的部署频率和平均变更提前期这两个重要指标的主要因素。
WorkerB是由LinearB提供的一项功能，它可以减少对空闲时间产生的积极影响，从而提高组织的DORA指标。通过通知团队成员有关存储库事件，可以确保团队立即了解周期时间的组成部分(例如拉取请求提取时间和拉取请求审查时间)，并允许他们以更及时的方式做出反应。
根据LinearB一些用户的反馈，在使用WorkerB的前四个月内，周期时间减少了50%以上。
衡量成功
DORA指标基于对软件开发团队的多年研究。通过DORA指标来衡量成功将通过组织的开发管道交付更多价值。
LinearB可以帮助组织的开发团队始终如一地跟踪它们，从而对其软件开发过程和业务产生深远而持久的影响。
原文标题：How To Use DORA Engineering Metrics To Improve Your Dev Team，作者：Nick Hodges
【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】
