Een raming maken van een upgrade van het framework
Hoe u een framework-upgrade kunt inschatten: waarom een grote versie-upgrade een project is en geen ticket, en hoe u dit kunt opsplitsen in stories waarvan u de omvang daadwerkelijk kunt inschatten.
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 schatting wordt beschouwd, 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 u zich het beste kunt stellen voordat u gaat stemmen
- Hoeveel ingrijpende wijzigingen zijn er in onze codebase doorgevoerd — moet u de changelog doorlezen en ze tellen?
- Ondersteunen de afhankelijkheden van de peer de doelversie, of passen we een cascade-aanpak toe?
- Codemod of handmatig? Hoe groot is de dekking van Codemod?
- Testdekking op de gewijzigde oppervlakken — is deze toereikend, of moeten we eerst tests toevoegen?
- Welke terugdraaistrategie moet er worden gevolgd als het halverwege de sprint misgaat?
- Eén PR of meerdere? Zo ja, wat is dan de volgorde van afhankelijkheid?
De juiste uitkomst van dit gesprek is vaak: „Dit is geen verhaal, maar een project — laten we het dan ook zo 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 afzonderlijke 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.