paint-brush
Bye Bye DORA: Mängel im Stand der DevOps-Berichteby@icyapril
4,929
4,929

Bye Bye DORA: Mängel im Stand der DevOps-Berichte

Junade Ali5m2024/01/03
Read on Terminal Reader

Die DORA Four Key-Metriken weisen eine Reihe von Mängeln auf; von der Nichtbereitstellung von Rohdaten bis hin zur Methodik, die die Schlussfolgerung vorwegnimmt. Während DORA von denen unterstützt wird, die ein begründetes Interesse daran haben, dass Entwickler immer schneller liefern, haben jüngste Untersuchungen gezeigt, dass die von DORA gemessenen Ergebnisse für Benutzer und Softwareentwickler am wenigsten wichtig sind. Daher ist es wichtig, die Leistung im Rahmen der Risikobereitschaft jeder Umgebung zu bewerten.
featured image - Bye Bye DORA: Mängel im Stand der DevOps-Berichte
Junade Ali HackerNoon profile picture
0-item

Vor zwei Jahren untersuchte ich die Auswirkungen von Entwickler-Burnout auf Softwareentwickler und stellte fest, dass 83 % unter Burnout litten . In den letzten Monaten habe ich an weiteren Untersuchungen zur Wahrnehmung der Softwareentwicklung für verschiedene Organisationen gearbeitet und dabei herausgefunden, dass 75 % der Softwareentwickler Vergeltungsmaßnahmen ausgesetzt waren, als sie das letzte Mal Fehlverhalten meldeten , und dass 89 % der Unternehmensleiter darüber besorgt waren Pünktliche Lieferung der Software .


Das DORA-Team von Google führt seit mehreren Jahren eigene Umfragen unter Softwareentwicklern durch und die ursprünglichen Autoren des Mess-Frameworks haben inzwischen andere Frameworks entwickelt, darunter SPACE und DevEx. Während ich ursprünglich den von diesen Teams erstellten Forschungsergebnissen vertraute, wurden bei weiteren Untersuchungen die Mängel offensichtlich.


Während der Feiertage habe ich Dr. Andrew Jenkinsons Buch „Why We Eat (Too Much): The New Science of Appetite“ gelesen. Darin kritisiert Dr. Jenkinson eine Studie namens „Seven Countries Study“ von Dr. Ancel Keys. Dr. Jenkinson beschreibt den Erfolg von Dr. Key wie folgt: „Er hatte den Streit über seinen größten Rivalen gewonnen, indem er ihn mit unbestreitbaren Fakten übertrumpfte und seine fehlerhafte Logik bloßstellte. Die Bewunderung der Menge erfüllte ihn mit Freude und Ekstase. Sein Lebenswerk hatte Früchte getragen. Die Finanzierung seiner Forschung würde fließen, sein Ruf als führender Wissenschaftler auf seinem Gebiet wäre für Jahre gesichert. Der Ruhm war gut, aber jetzt hatte er sich die beiden größten echten Preise gesichert – Macht und Einfluss.“


Allerdings stellt Dr. Jenkinson fest: „Er war bei seiner Forschung nicht unehrlich gewesen – das wäre unethisch gewesen und hätte ihn diskreditiert.“ Technisch gesehen war das, was er präsentiert hatte, die Wahrheit. Aber er wusste sehr gut, dass es nicht die ganze Wahrheit war.“


Als ich die Forschungsergebnisse von DORA untersuchte und später detaillierter arbeitete, wurden die Parallelen zwischen dieser Beschreibung und der Forschungsgenauigkeit im State of DevOps Report von DORA und dem nachfolgenden SPACE- und DevEx-Framework deutlich.


Das Accelerate-Buch, erstellt durch die Forschung des DORA-Teams von Google.


Wo sind die Daten?

Erstens wird die DORA-Forschung durchgeführt, indem mithilfe subjektiver Umfragen viele tausend Entwickler befragt werden. Diese Forschung wird intern vom DORA-Team durchgeführt. Normalerweise sind diejenigen, die solche Forschungen beruflich betreiben, Organisationen wie der Market Research Society (MRS) und dem British Polling Council (BPC) beigetreten, um sicherzustellen, dass die Öffentlichkeit Vertrauen in die Forschung haben kann, die von Organisationen durchgeführt wird, die Mitglied sind. Zum Beispiel; Die BPC-Regeln sehen für ihre Mitglieder strenge Offenlegungsregeln vor, die verlangen, dass sie innerhalb von zwei Arbeitstagen nach Veröffentlichung der Forschungsergebnisse vollständige Datentabellen mit den gestellten Fragen offenlegen.


Hier liegt unser erstes Problem; Das DORA-Team veröffentlicht seine Rohdaten nicht, sondern nur seinen State of DevOps Report.

Fehlerhafte Methodik

Die DORA-Forschung von Google und die in Teameinstellungen verwendeten SPACE- und DevEx-Frameworks verwenden subjektive Umfragen, um Messungen zu erstellen. Bei der Verwendung subjektiver Umfragen ist es wichtig, Maßnahmen zu ergreifen, um sicherzustellen, dass keine Voreingenommenheit ins Spiel kommt.


DORA verwendet jedoch vier Schlüsselmetriken, um die Ergebnisse zu messen: Änderungsvorlaufzeit, Bereitstellungshäufigkeit, Änderungsfehlerrate und Zeit bis zur Wiederherstellung (früher mittlere Zeit bis zur Wiederherstellung). Dies sind im Wesentlichen Maßstäbe für die Geschwindigkeit, mit der neue Funktionen bereitgestellt werden, und für die Geschwindigkeit, mit der Probleme gelöst werden.


Stellen Sie sich vor, Sie würden einige Leute fragen: „Essen Ihre Kollegen viel Gemüse?“ und „Trainieren Ihre Kollegen viel?“ Diejenigen, die sich an ihrem Arbeitsplatz wohler fühlen, würden beide Fragen wahrscheinlich eher mit „Ja“ beantworten – das bedeutet nicht, dass der Verzehr von mehr Grünzeug immer zu einem höheren Anteil an Fitnessstudiobesuchen führt. Obwohl möglicherweise ein Zusammenhang besteht, haben wir keine Ursache-Wirkungs-Beziehung hergestellt.


Die DORA-Forschung argumentiert, dass Geschwindigkeit und Zuverlässigkeit Hand in Hand gehen. Dies geschieht jedoch auf der Grundlage von Ergebnismaßen, die ausschließlich auf Geschwindigkeit basieren. Darüber hinaus kann der Einsatz subjektiver Umfragen dazu führen, dass Empfänger, die sich mit ihrer Arbeit wohler fühlen, beide Fragen mit „Ja“ beantworten. Und obwohl Unternehmen, die über eine höhere Kompetenz verfügen, zwangsläufig auch in beiden Faktoren kompetenter sein können, entsteht dadurch kein kausaler Zusammenhang.


Zum Beispiel; Bedenken Sie, wie hoch die Zuverlässigkeit von Luftfahrtsoftware im Vergleich zum seltenen Einsatz von Software in Flugzeugen geschätzt wird. Oder denken Sie daran, wie Toyota, der Pionier agiler Methoden, im Software-Zuverlässigkeitsfall „Bookout v. Toyota“ zu einem unbeabsichtigten Beschleunigungsfehler, der zu Todesfällen führte, in der internen Kommunikation einräumte: „In Wahrheit ist Technologie wie Failsafe nicht Teil von Toyota.“ DNA der Engineering-Abteilung“. Oder denken Sie daran, wie der Softwareentwickler Fujitsu während des Horizon-IT-Skandals, der für mehrere Selbstmorde und den „weitverbreitetsten Justizirrtum in der Geschichte des Vereinigten Königreichs“ verantwortlich gemacht wird und zu Unrecht inhaftiert war, darunter eine schwangere Frau, Pionierarbeit bei der Verwendung eines leistete agile Methodik zur Entwicklung von Software, nämlich Rapid Application Development .


Kausalität ist keine Korrelation – Skizzenplanungen


Fehlerhafte Messergebnisse

Wie bereits erwähnt, wurden in der DORA-Forschung vier Schlüsselmetriken gemessen, die die Geschwindigkeit bei der Bereitstellung neuer Arbeiten und der Behebung von Fehlern bewerten, um die Leistung zu bewerten. Diese Kennzahlen sind jedoch nur insoweit von Bedeutung, als sie nützliche messbare Ergebnisse darstellen.


Ich habe sowohl bei Softwareentwicklern als auch bei einer repräsentativen Stichprobe der breiten Öffentlichkeit (mit dem Forschungsunternehmen Survation) Untersuchungen durchgeführt und bin zu dem Ergebnis gekommen, dass beide der Meinung sind, dass Geschwindigkeit der unwichtigste Faktor ist. Stattdessen liegt der Öffentlichkeit vor allem die Datensicherheit, die Datengenauigkeit und die Vermeidung schwerwiegender Fehler am Herzen. Es ist schwer, eine Hypothese zu finden, die die vier Schlüsselmetriken mit diesen Ergebnissen in Verbindung bringt, die laut Softwareentwicklern und der Öffentlichkeit am wichtigsten sind – insbesondere angesichts der Tatsache, dass die Vermeidung schwerwiegender Fehler eine völlig geringere Priorität hat als die schnelle Behebung von Fehlern oder die schnelle Erledigung von Arbeiten. Selbst bei anderen Faktoren wie der Datensicherheit lässt sich nur schwer erkennen, wie diese mit einer der vier Schlüsselkennzahlen zusammenhängen.


Selbst unter Entscheidungsträgern in der Wirtschaft scheint es, dass die pünktliche Lieferung wichtiger ist als die schnelle Lieferung. Laut einer Studie, die ich mit JL Partners durchgeführt habe, stimmen 98 % dieser Unternehmensentscheider in Großbritannien und 96 % in den USA der Aussage „Das Ziel eines Software-Engineering-Teams ist es, qualitativ hochwertige Software pünktlich zu liefern“ zu 65 % im Vereinigten Königreich und 62 % in den USA stimmen voll und ganz zu.


Endlich; Die von mir mit Survation durchgeführte Untersuchung ergab, dass das Vertrauen in Softwareentwickler und die Zuverlässigkeitserwartungen der Öffentlichkeit von Branche zu Branche erheblich variieren können, was bedeutet, dass von einem einheitlichen Ansatz zugunsten der Empfehlungen des Engineering Council UK abgeraten werden sollte Leitlinien zum Risiko : „Einen Entscheidungsansatz anwenden, der im Verhältnis zum Risiko steht und mit der definierten Risikobereitschaft ihrer Organisation übereinstimmt.“

Folge dem Geld

So wie Dr. Keys für seine Forschung Gelder von der Zuckerindustrie erhielt, ist es bei vielen Untersuchungen wichtig, das Geld im Auge zu behalten, um zu verstehen, wo Anreize liegen. Das DORA-Team begann ursprünglich mit der Erstellung von State of DevOps-Berichten für Puppet, einem Unternehmen, das sich auf die Automatisierung der IT-Infrastruktur konzentriert, und erledigt diese Arbeit jetzt für Google Cloud. Beide haben ein begründetes Interesse daran, dass Entwickler ihre Arbeit so schnell wie möglich bereitstellen können. Das bedeutet jedoch nicht, dass es die Lösung aller unserer Probleme ist.


DORA hat einen Beitrag zur Welt des Software-Engineerings geleistet, indem es dem Prozess ein gewisses Maß an empirischer Bewertung hinzugefügt hat. Wir müssen jedoch vermeiden, Marketingmaterial mit der ganzen Wahrheit zu verwechseln und die Mängel solcher Forschungen erkennen.