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, anhand derer es die Testsuite ausführen und die es als einen einzigen, langweiligen PR zusammenführen sollte. Dieser PR hat den Prioritätsgrad 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. Jeweils 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.“

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

Die Einleitung trifft den Nagel auf den Kopf. Es gibt keine einzige Zahl für diese Geschichte, da es keine einheitliche Geschichte gibt. Die kleineren Probleme werden als eigene kleine Meldung zusammengefasst; jedes größere Problem 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, und nicht bei Anbietern?
• Gibt es einen Konflikt aufgrund transitiver Abhängigkeiten, 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. Legen Sie für jede größere Version einen begrenzten Anstieg fest, ermitteln Sie, was tatsächlich nicht mehr funktioniert, und nehmen Sie dann auf der Grundlage Ihrer Erkenntnisse eine neue Schätzung der Implementierung vor.

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 der gefundenen Änderungen ein.

Lesen Sie den Abschnitt zur Schätzung eines Framework-Upgrades für die Variante mit einer einzigen Bibliothek und einer Hauptversionsänderung sowie die weiteren Beispiele für erfolgreiche Schätzungen. Starten Sie eine kostenlose Planning-Poker-Sitzung, nachdem die Spikes geklärt haben, was sich tatsächlich ändern wird.