paint-brush
再见 DORA:DevOps 现状报告的缺陷经过@icyapril
4,629 讀數
4,629 讀數

再见 DORA:DevOps 现状报告的缺陷

经过 Junade Ali5m2024/01/03
Read on Terminal Reader

太長; 讀書

DORA 四大关键指标存在多种缺陷;从未提供原始数据到预示结论的方法。虽然 DORA 得到了那些对开发人员更快地交付既得利益的人的支持,但最近的研究强调,DORA 衡量的结果对用户和软件工程师来说最不重要。因此,评估每个环境的风险偏好范围内的绩效非常重要。
featured image - 再见 DORA:DevOps 现状报告的缺陷
Junade Ali HackerNoon profile picture
0-item

两年前,我研究了开发人员倦怠对软件工程师的影响,发现83% 的人患有倦怠。近几个月来,我一直致力于对各种组织对软件开发的看法进行进一步研究,包括发现 75% 的软件工程师在上次报告不当行为时面临报复,以及 89% 的企业领导者担心按时交付软件


谷歌的 DORA 团队多年来一直对软件工程师进行自己的民意调查,测量框架的原始作者现在已经制作了其他框架,包括 SPACE 和 DevEx。虽然我最初相信这些团队所做的研究,但随着我进行进一步的研究,缺陷已经变得明显。


假期期间,我一直在读安德鲁·詹金森博士的书《我们为什么吃太多:食欲的新科学》,詹金森博士在书中批评了安塞尔·凯斯博士的一项名为“七国研究”的研究。詹金森博士这样描述基斯博士的成功:“他赢得了对最大对手的争论,用无可争议的事实击败了他,暴露了他有缺陷的逻辑。众人的赞美让他充满了喜悦和狂喜。他一生的工作已经取得成果。他的研究资金将会源源不断地涌入,他作为该领域领先科学家的声誉将持续多年。名声固然好,但现在他获得了最重要的两个真正的奖赏——权力和影响力。”


然而,詹金森博士指出:“他并没有对他的研究不诚实——这将是不道德的,也会使他名誉扫地。从技术上讲,他所陈述的是事实。但他很清楚,这并不是全部真相。”


当我研究了 DORA 的研究成果以及后来的工作时,这种描述与 DORA 的 DevOps 状态报告以及随后的 SPACE 和 DevEx 框架中的研究严谨性之间的相似之处变得显而易见。


《Accelerate》一书由 Google DORA 团队的研究成果编写。


数据在哪里?

首先,DORA 研究是通过主观调查对数千名开发人员进行抽样进行的。这项研究由 DORA 团队内部进行。通常,那些以进行此类研究为生的人会加入市场研究协会(MRS)和英国民意调查委员会(BPC)等组织,以确保公众对成员组织所做的研究有信心。例如; BPC 规则对其成员制定了严格的披露规则,要求他们在研究发表后 2 个工作日内披露完整的数据表以及所提出的问题。


这是我们的第一个问题; DORA 团队不发布他们的原始数据,只发布他们的 DevOps 状态报告。

有缺陷的方法论

Google 的 DORA 研究以及团队设置中使用的 SPACE 和 DevEx 框架使用主观调查来创建测量结果。使用主观调查时,重要的是要采取措施确保偏见不会发挥作用。


然而,DORA 使用四个关键指标来衡量结果 - 变更交付时间、部署频率、变更失败率和恢复时间(以前称为平均恢复时间)。这些本质上是衡量部署新功能的速度和解决问题的速度。


想象一下,你问一些人“你的同事吃很多蔬菜吗?”和“你的同事经常锻炼吗?”。那些对工作场所感觉更好的人可能更有可能对这两个问题回答“是”——这并不意味着吃更多的绿色蔬菜总是会导致更高的健身房出勤率。虽然可能存在相关性,但我们尚未建立因果关系。


DORA 研究认为,速度和可靠性是齐头并进的,然而,它们是基于完全基于速度的结果衡量标准来实现的。此外,主观调查的使用可能会让那些对自己的工作感觉更好的接受者对这两个问题都回答“是”。虽然能力更强的公司可能不可避免地在这两个因素上都更有能力,但这并不能产生因果关系。


例如;考虑一下航空软件的可靠性受到多么高的重视,而软件在飞机上的部署却很少。或者考虑一下敏捷方法论的先驱丰田公司在软件可靠性案例“Bookout 诉丰田公司”中,就一个导致死亡的意外加速错误在内部沟通中承认,“事实上,诸如故障安全之类的技术并不属于丰田公司的一部分”。工程部门的DNA”。或者想想在 Horizon IT 丑闻期间,软件开发商富士通是如何率先使用开发软件的敏捷方法,即快速应用程序开发


因果关系不是相关性 - Sketchplanations


有缺陷的测量结果

正如所讨论的,DORA 研究根据四个关键指标进行衡量,这些指标评估部署新工作和修复错误的速度以评估性能。然而,这些指标只有在它们是有用的衡量结果时才重要。


对软件工程师和公众的代表性样本(与研究公司 Survation)进行了研究,发现两者都同意速度是最不重要的因素。相反,公众最关心的是数据安全、数据准确性和防止严重错误。很难找到一个假设将四个关键指标与软件开发人员和公众认为最重要的这些结果联系起来 - 特别是考虑到预防严重错误的优先级完全低于快速修复错误或快速开展工作。即使对于数据安全等其他因素,也很难看出它们与四个关键指标中的任何一个有何联系。


即使对于业务决策者来说,准时交货似乎也比快速交货更重要。根据我与 JL Partners 进行的研究,英国 98% 的此类业务决策者和美国 96% 的此类业务决策者都同意“软件工程团队的目标是按时交付高质量软件”这一说法, 65% 的英国人和 62% 的美国人强烈同意。


最后;我与 Survation 进行的研究发现,不同行业对软件工程师的信任和公众对可靠性的期望可能存在很大差异,这意味着不应采用一刀切的方法,而应采用英国工程委员会在其报告中建议的方法。风险指南:“采用与风险成比例并符合组织规定的风险偏好的决策方法”。

追随金钱

就像基斯博士在他的研究中从制糖业获得资金一样 - 在许多调查中,跟踪资金以了解激励因素在哪里非常重要。 DORA 团队最初开始为 Puppet(一家专注于 IT 基础设施自动化的公司)做 DevOps 状态报告,现在他们为 Google Cloud 做这项工作。两者都希望开发人员能够尽快部署工作。但这并不意味着它可以解决我们所有的问题。


DORA 在软件工程领域做出了贡献,为流程添加了一定程度的实证评估。然而,我们必须避免混淆营销材料的全部真相,并认识到此类研究的缺陷。