Neu von Aviator: Der Rechner zur Bewertung der technischen Effizienz

Die Messung der technischen Produktivität ist ein komplizierter Prozess – es ist schwierig, sich ein vollständiges Bild davon zu machen, wie Entwickler ihre Zeit verbringen. Eine gängige Methode zur Messung der Produktivität ist die Analyse von Systemmetriken wie DORA oder SPACE. Dies können äußerst nützliche Kennzahlen sein, um die Produktivität des Teams im Vergleich zu den Industriestandards zu verstehen. Das Eintauchen in jede dieser Kennzahlen kann auch Erkenntnisse darüber liefern, was das Team ausbremst.

Aber manchmal gibt es auch „versteckte Zeitabschnitte“, die Entwickler im Laufe ihres Tages verbringen und die möglicherweise nicht als Auswirkungen auf die Produktivität wahrgenommen werden. Wenn wir jedoch anfangen, diese Dinge zusammenzurechnen, können die Zahlen alarmierend sein.

Bedenken Sie beispielsweise, wie viel Zeit ein Entwickler damit verbringt, einen fehlerhaften Test zu debuggen und herauszufinden, ob er aufgrund der Änderung fehlgeschlagen ist oder nicht. Oder die Zeit, die ein Entwickler damit verbringt, einen Fehler beim Mainline-Build zu beheben.

Um diese Perspektive zu vermitteln, haben wir einen Rechner entwickelt, der die technische Effizienz bewertet. Dies stellt keineswegs eine vollständige Analyse der Effizienz Ihres Ingenieurteams dar. Was es bietet, ist ein Einblick in die „versteckten Bereiche“ verschwendeter Zeit, die normalerweise nicht in allgemeineren Produktivitätskennzahlen auftauchen.

Der Rechner konzentriert sich darauf, wie viel Zeit Sie und Ihr Team durch Build- und Testfehler in Entwickler-Workflows verlieren.

Wenn Sie dies mit den DORA-Metriken vergleichen, wird die Vorlaufzeit für Änderungen erheblich durch Build- und Testinstabilität beeinflusst. Diese Auswirkungen können mit diesem Rechner abgeschätzt werden.

Wie es funktioniert

Wir bitten Sie um die Eingabe von Daten basierend auf Ihren GitHub-Aktivitäten und der Art und Weise, wie Sie GitHub-Zweige nutzen. Um die tatsächlichen Berechnungen unten zu erklären, weisen wir jeder von ihnen Variablen zu:

M – pro Tag zusammengeführte PRs

X – Hauptleitungsausfälle in einer Woche

T – durchschnittliche CI-Zeit

F – Flockigkeitsfaktor %

Basierend auf diesen Eingaben schätzen wir, wie viel Zeit Ihr Engineering-Team wöchentlich mit der Verwaltung von Build-Fehlern und der Bewältigung unzuverlässiger Tests verschwendet. Lassen Sie uns die Ergebnisse einzeln durchgehen.

Für die Reparatur wurden Stunden verschwendet

Dadurch wird berechnet, wie viele Stunden verschwendet werden, um den Build zu identifizieren, zu selektieren, zu reparieren und erneut zu starten, wenn ein Fehler beim Mainline-Build erkannt wird. Normalerweise wird in einem großen Team jemand den fehlerhaften Hauptlinien-Build bemerken und melden.

Wir gehen davon aus, dass ein Mainline-Build-Fehler durchschnittlich 1–3 Entwickler zum Debuggen und Beheben erfordert. Wenn wir davon ausgehen, dass es durchschnittlich eine Stunde dauert, bis das Problem gemeldet und eine Lösung bereitgestellt wird, verbringen wir (2*T + 1) Stunden damit, das Problem zu verfolgen, zu untersuchen und zu lösen.

Das heißt, wenn es X Fehler pro Woche gibt, verbringen wir (( 2 Entwickler * X/5 * (2*T + 1)) Stunden Entwicklerzeit, um jeden Tag Mainline-Build-Fehler zu bekämpfen.

Es werden Stunden mit der Lösung von Zusammenführungskonflikten verschwendet

Rollbacks und Zusammenführungskonflikte können weitere Probleme verursachen. Unter der Annahme, dass es etwa 2 % der PRs gibt, die während des Fensters der unterbrochenen Build-Zeit ((2*T + 1) * X/5) Zusammenführungskonflikte haben, und M/8 PRs, die jede Stunde eingehen, werden wir ((2* T + 1) * X/5) * 0,02 * M/8 wurde bei der Lösung dieser Konflikte verschwendet.

Wöchentliche CI-Ausfälle aufgrund fehlerhafter Builds

Wenn das Team keinen Golden Branch als Grundlage für seine Feature-Zweige verwendet, würde es wahrscheinlich Feature-Zweige auf einem ausgefallenen Hauptzweig erstellen. Da die Anzahl der zu einem beliebigen Zeitpunkt erstellten PRs der durchschnittlichen Anzahl von Feature-Branches außerhalb der Hauptlinie entsprechen würde, würde dies zu (2*T + 1 Stunde) * X/5 * M/8 Anzahl von CI-Fehlern führen, die jeden Tag auftreten .

Zeit, CI zu lösen

Bei etwa fünfzehn Minuten Kontextwechsel des Handles bei jedem Build-Fehler sind das (2*T + 1 Stunde) * X/5 * M/8 * 0,25 Stunden Entwicklerzeit, die jeden Tag durch CI-Fehler verschwendet werden.

Zeitaufwand für die Wiederholung unzuverlässiger Tests.

Ähnlich verhält es sich bei den Flaky-Tests: Die Kontextwechselzeit, die erforderlich ist, um zu untersuchen, ob der Test flockig oder real war, und die Wiederholung der Tests selbst dauern durchschnittlich fünfzehn Minuten pro Lauf. Abhängig vom Flockigkeitsfaktor würden die Entwickler jeden Tag (0,25 * M * F / 100) Stunden verschwenden.

Verbesserung der Effizienz

Obwohl sich die meisten davon auf die DORA-Metriken im Zusammenhang mit der Vorlaufzeit für Änderungen auswirken, kratzen wir bei der Messung der Ineffizienzen in den Arbeitsabläufen des Entwicklungsteams immer noch nur an der Oberfläche. Die Auswirkungen von Build- und Testfehlern führen auch zu verzögerten Releases, die sich auf andere DORA-Metriken wie Bereitstellungshäufigkeit, Zeit zur Wiederherstellung des Dienstes und die Persistenz fehlerhafter Tests im System auswirken, was zu einer höheren Wahrscheinlichkeit einer Fehlerquote führen kann. Erfahren Sie mehr über DORA-Metriken . Oder erfahren Sie mehr über ihre Nachteile.

Wir haben Aviator entwickelt, um einige dieser versteckten Herausforderungen für große Ingenieurteams zu lösen. Mit Aviator MergeQueue können heute viele Ingenieurorganisationen ihren Merge-Workflow skalieren, ohne Builds zu unterbrechen. Durch die Kombination mit einem System zur Unterdrückung schuppiger Tests wie TestDeck können Teams jede Woche Hunderte von Entwicklungsstunden einsparen.

Auch hier veröffentlicht.