Een raming maken van een upgrade van het framework

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 verpakking rondom het werk.

Als de upgrade als één enkele schatting wordt behandeld, leidt dit tot één enkele faalmodus: het team stemt voor 13, raakt in week drie in tijdnood en levert een half gemigreerde codebase op die zowel de bugs van het nieuwe framework als de idiomen van het oude framework bevat. De juiste 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: “Leveren we deze sprint nog iets anders op, 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 andere componenten de doelversie, of passen we een cascade-aanpak toe?
• Codemod of handmatig? Hoe groot is de dekking van de Codemod?
• Testdekking op de gewijzigde oppervlakken: is deze toereikend, of moeten wij eerst tests toevoegen?
• Welke terugdraaistrategie moet er worden 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 als zodanig plannen”, waarna het 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 afzonderlijke verhalen en bepaal vervolgens de omvang daarvan.

Raadpleeg de schattingstechnieken voor vager omschreven of omvangrijkere opdrachten, en bekijk hoe u een „onderzoeksspike” kunt inschatten voor het onderzoek dat aan de schatting vooraf moet gaan. Bekijk de andere uitgewerkte schattingsvoorbeelden.