Kostenschätzung 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 einzuschä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 auf 13, 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 Konventionen des alten Frameworks enthält. Der sinnvolle 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 nicht bewältigen?“

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 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 eine Kaskadierung an?
  • Codemod oder manuell? Wie hoch ist die Abdeckung durch Codemod?
  • Testabdeckung der 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 also entsprechend planen“, und anschließend wird es split in Abschnitte unterteilt, 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.

Weitere Informationen zu ungenaueren oder umfangreicheren Projekten finden Sie unter Schätzverfahren, und Informationen zu den Voruntersuchungen, die der Schätzung vorausgehen sollten, finden Sie unter Schätzung eines Forschungsschubs. Sehen Sie sich auch die anderen Beispiele für durchgeführte Schätzungen an.