Een raming maken van een framework-upgrade

Grote versie-upgrades zijn geen tickets. Het zijn projecten.

Patchversies zijn tickets. Minorversies zijn doorgaans tickets. Majorversies (die met ingrijpende wijzigingen, verouderingscycli, cascade-effecten bij afhankelijkheid van andere bibliotheken en de vermelding „wij raden aan om te migreren naar…“ in het changelog) zijn projecten, en planning poker is niet het juiste hulpmiddel om de omvang daarvan in zijn geheel in te schatten. Het verhaal dat luidt „upgraden naar React 19“ of „Postgres 16“ is niet het werk zelf; het is de omhulling rond het werk.

Als de upgrade als één enkele raming wordt behandeld, leidt dit tot één enkele faalmodus: het team stemt voor 13, komt in week drie tijd tekort en levert een half gemigreerde codebase op die zowel de bugs van het nieuwe framework als de idiomen van het oude framework bevat. De verantwoorde aanpak is om de upgrade op te splitsen in een reeks kleinere stories, die elk afzonderlijk kunnen worden ingeschat, waarbij de upgrade zelf als overkoepelend project fungeert.

Wat er in de kamer wordt gezegd

Ingenieur: “De codemod regelt het grootste deel ervan.”

Inleiding: “Het grootste deel van wat? Wat kan het dan niet aan?”

SRE: “Ondersteunen al onze afhankelijkheden de nieuwe versie al?”

Vraag: “Wat is onze strategie voor regressietesten van de diff?”

PM: “Gaan we deze sprint nog iets anders opleveren, of is dit de sprint?”

Vragen die het waard zijn om te stellen voordat u gaat stemmen

• Hoeveel ingrijpende wijzigingen zijn er van toepassing op onze codebase (lees de changelog en tel ze)?
• Ondersteunen de afhankelijkheden van de peer de doelversie, of passen we cascading toe?
• Codemod of handmatig? Hoe groot is de dekking van Codemod?
• Testdekking op de gewijzigde oppervlakken: is deze toereikend, of moeten wij eerst tests toevoegen?
• Welke terugdraaistrategie wordt gevolgd als het halverwege de sprint misgaat?
• Eén PR of meerdere? Indien meerdere, wat is dan de volgorde van afhankelijkheid?

De juiste uitkomst van dit gesprek is vaak: „Dit is geen verhaal, maar een project, dus laten we het ook op die manier plannen”, waarna het split wordt opgedeeld in delen die het team elk kan inschatten aan de hand van een referentieverhaal.

Geef een grote upgrade niet één enkel getal. Verdeel deze in verhalen en bepaal vervolgens de omvang daarvan.

Zie schattingstechnieken voor vager of omvangrijker werk, en het inschatten van een onderzoekspiek voor het onderzoek dat aan de schatting vooraf moet gaan. Bekijk de andere uitgewerkte schattingsvoorbeelden.