【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)良性循环
当任何东西被权衡时，它很能够会被人为操纵或更改———也就是说，人们会改动行为来优化被权衡的东西。很多时分这会对开发团队的任务产生负面的的影响。
(责任编辑：admin)