Abschätzung des Aufwands für ein Upgrade einer Abhängigkeit

Patch und „minor“ sind Rauschen. „Major“ über N Bibliotheken hinweg entspricht N Spitzenwerten – schätzen Sie den schlimmsten Fall, nicht den Durchschnitt.

Es gibt zwei Arten von Abhängigkeits-Upgrades, die in der Ausgabe des Paketmanagers identisch aussehen. Die erste: eine Reihe von Patches und geringfügigen Versionserhöhungen, die das Team bündeln, mit der Testsuite überprüfen und als einen einzigen, langweiligen PR zusammenführen sollte. Dieser PR hat den Status 1, manchmal 2, und der einzige Grund, darüber abzustimmen, besteht darin, zu bestätigen, dass das Team sich einig ist, dass er langweilig ist. Die zweite Form: eine Hauptversionserhöhung bei einer oder mehreren Bibliotheken, bei der das Changelog einen Abschnitt „Breaking Changes“ enthält und das Team diesen lesen muss. Das ist die Story, die sich vor aller Augen verbirgt. Das Team bewertet sie mit einer 3, weil „es ja nur ein Upgrade ist“, und veröffentlicht sie drei Sprints später mit einer 13.

Dies ist kein Framework-Upgrade. Ein Framework-Upgrade ist eine Bibliothek, auf die Sie sich ein ganzes Quartal lang vorbereitet haben; das Team weiß, dass es sich um ein Projekt handelt. Ein Abhängigkeits-Upgrade ist das unauffällige Wartungsticket, das jemand einreicht, weil der Sicherheitsscan sechs Bibliotheken als problematisch markiert hat und niemand die Änderungsprotokolle gelesen hat. Die Tücke liegt in der Verteilung: Von den sechs Versionssprüngen sind vier trivial, einer ist ein umbenannter Export und einer ist eine komplette Neugestaltung der API. Die Schätzung, die den Durchschnitt dieser Werte bildet, ist in beide Richtungen falsch.

Was in dem Raum gesagt wird

Ingenieur A: „Es sind sechs Unebenheiten. Je zwei. Insgesamt 13.“

Einstieg: „Sind sie alle minderjährig?“

Ingenieur A: „Drei kleinere, drei größere.“

Ingenieur B: „Hat jemand die wichtigsten Änderungsprotokolle gelesen?“

Ingenieur A: „…lassen Sie mich mal sehen.“

Leitzeile: „Wir haben noch keine Schätzung. Wir verzeichnen drei Spitzenwerte.“

Die Einleitung trifft den Nagel auf den Kopf. Es gibt keine einheitliche Zahl für diese Geschichte, da es nicht nur eine einzige Geschichte gibt. Die kleineren Probleme werden als eigene, geringfügige Störung zusammengefasst; jede größere Störung stellt einen eigenen Spitzenwert dar, bis jemand das Änderungsprotokoll gelesen hat und weiß, was nicht mehr funktioniert.

Fragen, die man sich vor der Stimmabgabe stellen sollte

Wie viele Bumps gibt es, und wie sieht die Aufschlüsselung nach Major-, Minor- und Patch-Versionen aus?
Hat jemand die Änderungsprotokolle zu den größeren Versionssprüngen gelesen?
Befinden sich einige davon in Bibliotheken, die dem Team gehören, im Gegensatz zu denen von Anbietern?
Gibt es einen transitiven Abhängigkeitskonflikt, der dazu führt, dass diese Ereignisse gemeinsam stattfinden müssen?
Was sind die Rückrollmaßnahmen, falls eines der Upgrades den Produktionsbetrieb beeinträchtigt?
Gibt es für das Sicherheitsteam eine Frist, oder handelt es sich hierbei um technische Schulden?

Sollte die Antwort auf die Frage „Hat jemand die Änderungsprotokolle gelesen?“ „Nein“ lauten, ist die Schätzung nicht realistisch. Stimmen Sie bei jeder größeren Version für einen begrenzten Anstieg ab, decken Sie auf, was tatsächlich nicht mehr funktioniert, und schätzen Sie die Implementierung dann anhand Ihrer Erkenntnisse neu ein.

Schätzen Sie die Umfang der Abhängigkeitsaktualisierungen nicht anhand der Versionssprünge ein. Lesen Sie zunächst die Änderungsprotokolle und schätzen Sie dann den Umfang anhand der dortigen Informationen ein.

Weitere Informationen zur Variante mit einer einzigen Bibliothek und einer Hauptversionserweiterung finden Sie unter „Schätzung eines Framework-Upgrades“, ebenso wie weitere Beispiele für durchgeführte Schätzungen. Starten Sie eine kostenlose Planning-Poker-Sitzung, nachdem die Spikes geklärt haben, was sich tatsächlich ändern wird.