Kostenvoranschlag für ein Framework-Upgrade

So schätzen Sie den Aufwand für ein Framework-Upgrade ein: Warum eine Erhöhung der Hauptversionsnummer ein Projekt und kein Ticket ist – und wie Sie es in Stories aufteilen, 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 – jene 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 herum.

Wird das Upgrade als ein einziges Schätzobjekt betrachtet, ergibt sich ein einziger Fehlerfall: Das Team stimmt mit 13 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.“

Einleitung: „Was genau? Was kann es denn nicht?“

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

Frage: „Wie sieht unsere Strategie für die Regressionstests des Diff aus?“

PM: „Werden wir in diesem Sprint noch etwas anderes ausliefern, oder ist das hier der 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 für die geänderten Oberflächen – ist sie ausreichend, oder sollten wir zunächst Tests hinzufügen?
  • Welche Rückrollstrategie 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 entsprechend planen“, um es anschließend split in Abschnitte zu unterteilen, die das Team jeweils 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.

Weitere Informationen zu ungenaueren oder umfangreicheren Projekten finden Sie unter Schätzverfahren, und Informationen zu den vor der Schätzung durchzuführenden Untersuchungen finden Sie unter Schätzung eines Forschungsschwerpunkts. Sehen Sie sich auch die anderen Beispiele für durchgeführte Schätzungen an.