Eine Figur aus einem Haftnotizzettel, die eine hohe Leiter erklimmt, auf der eine große Versionsnummer steht.

Kostenvoranschlag für ein Framework-Upgrade

So schätzen Sie ein Framework-Upgrade ein: Warum eine Erhöhung der Hauptversionsnummer ein Projekt und kein Ticket ist – und wie Sie es in Stories unterteilen, deren Umfang Sie tatsächlich einschätzen können.

Upgrades auf eine neue Hauptversion sind keine Tickets. Es handelt sich dabei um Projekte.

Patch-Versionen sind Tickets. Minor-Versionen sind in der Regel Tickets. Major-Versionen (diejenigen mit kompatibilitätsbrechenden Änderungen, Auslaufzyklen, Kaskaden bei Peer-Abhängigkeiten und dem Hinweis „Wir empfehlen die Migration auf …“ im Changelog) sind Projekte, und Planning Poker ist nicht das richtige Werkzeug, um deren Gesamtumfang abzuschätzen. Die Story mit dem Titel „Upgrade auf React 19“ oder „Postgres 16“ ist nicht die eigentliche Arbeit; sie ist lediglich die Hülle um die eigentliche Arbeit.

Wird das Upgrade als ein einziges Schätzobjekt betrachtet, ergibt sich ein einziger Fehlerfall: Das Team stimmt mit 13 Stimmen ab, hat in der dritten Woche keine Zeit mehr und liefert eine nur zur Hälfte migrierte Codebasis aus, die sowohl die Fehler des neuen Frameworks als auch die Idiome des alten Frameworks enthält. Der richtige Ansatz besteht darin, das Upgrade in eine Abfolge kleinerer Stories aufzuteilen, die jeweils unabhängig voneinander geschätzt werden können, wobei das Upgrade selbst als übergeordnetes Projekt dient.

Was in dem Raum gesagt wird

Ingenieur: „Der Codemod übernimmt den Großteil davon.“

Leitzeile: „Was genau? Was kann es nicht?“

SRE: „Werden alle unsere Abhängigkeiten bereits von der neuen Version unterstützt?“

Frage: „Wie sieht unsere Strategie für Regressionstests hinsichtlich der Änderungen aus?“

PM: „Werden wir in diesem Sprint noch etwas anderes ausliefern, oder ist das hier der gesamte Sprint?“

Fragen, die man sich vor der Stimmabgabe stellen sollte

  • Wie viele kompatibilitätsbrechende Änderungen betreffen unsere Codebasis (lesen Sie das Changelog und zählen Sie nach)?
  • Unterstützen die Abhängigkeiten von anderen Komponenten die Zielversion, oder wenden wir die Kaskadierung an?
  • Codemod oder manuell? Wie hoch ist die Abdeckung des Codemods?
  • Testabdeckung der geänderten Oberflächen: Ist sie ausreichend, oder sollten wir zunächst Tests hinzufügen?
  • Welche Rückfallstrategie gibt es, falls es mitten im Sprint zu Problemen kommt?
  • Ein PR oder mehrere? Falls mehrere, wie sieht die Reihenfolge der Abhängigkeiten aus?

Das richtige Ergebnis dieses Gesprächs lautet oft: „Das ist keine Story, sondern ein Projekt; lassen Sie uns es also entsprechend planen“, woraufhin es in Teilabschnitte unterteilt wird, die jedes Teammitglied anhand einer Referenz-Story einschätzen kann.

Weisen Sie einem größeren Upgrade nicht eine einzige Zahl zu. Unterteilen Sie es in einzelne Stories und ermitteln Sie dann deren Umfang.

Lesen Sie mehr über Schätzverfahren für ungenauere oder umfangreichere Projekte sowie über die Schätzung eines „Research Spikes“ für die Untersuchung, die der Schätzung vorausgehen sollte. Sehen Sie sich die weiteren Beispiele für durchgeführte Schätzungen an.