Het inschatten van een wijziging in het ontwerpsysteem
Hoe u de impact van een wijziging in het ontwerpsysteem kunt inschatten: de uitrol van tokens, verouderingstrajecten, de dekking van Codemod en de 200 plaatsen waar de oude component wordt aangeroepen. Breng de gevolgen voor de downstream in kaart.
In het artikel wordt een schatting gemaakt van het aantal nieuwe onderdelen, maar wordt geen rekening gehouden met de 200 locaties waar het oude onderdeel nog wordt gebruikt.
Een wijziging in het ontwerpsysteem omvat twee aspecten. Het eerste aspect betreft het systeem zelf: de nieuwe component, het nieuwe token en de bijgewerkte documentatie. Het tweede betreft de aanroepplaatsen — elke productfunctie die gebruikmaakte van de oude versie en naar de nieuwe versie moet worden gemigreerd. Het eerste toepassingsgebied is klein en bekend. Het tweede is wat ervoor zorgt dat het werk daadwerkelijk een kwartaal in beslag neemt.
Teams die de wijziging aan de systeemkant doorvoeren zonder een uitfaseringstraject, leveren in feite twee systemen op: het nieuwe systeem en alle onderdelen die nog steeds het oude systeem gebruiken. De schatting moet de uitrol omvatten — Codemod of handmatige migratie, tijdschema voor de uitfasering, strategie voor visuele regressietests — anders ligt het werk daar simpelweg maandenlang stil, terwijl de functieteams eraan beginnen wanneer het hen uitkomt.
Wat er in de kamer wordt gezegd
Ontwerper: “Het nieuwe token is een wijziging van slechts één regel.”
Frontend: “Hoeveel componenten maken er momenteel gebruik van?”
Lead: “Gaan we een codemod uitvoeren, of voeren de featureteams de migratie zelf uit?”
QA: “Visuele regressie — Percy? Handmatig? Beide?”
PM: “Wat is de overgangsperiode voor de oude versie?”
Vragen die u zich het beste kunt stellen voordat u gaat stemmen
- Om hoeveel locaties gaat het — op basis van metingen, niet op basis van schattingen?
- Codemod of handmatige migratie? Hoe groot is de dekking van de Codemod?
- Afbouwtraject: waarschuwing, foutmelding, verwijdering — volgens welk tijdschema?
- Wordt er visuele regressietesting uitgevoerd op de betrokken schermen?
- Communicatie tussen teams: aan wie, wanneer en hoe brengen we dit onder de aandacht?
- Moet er worden teruggedraaid als de nieuwe component een fout vertoont die pas in de productieomgeving aan het licht komt?
De wijziging stroomopwaarts is klein en het opschonen stroomafwaarts vormt het echte werk, dus splits ze op: de nieuwe component vormt één story, het migreren van de aanroepplaatsen een andere, en de omvang van de tweede wordt bepaald op basis van het gemeten aantal — niet op basis van een schatting.
Maak een schatting van de stroomafwaartse migratie. Het nieuwe token is een lijn; de 200 call-sites vormen het kwart.
Net als bij het inschatten van een framework-upgrade is de wijziging in de upstream klein en zit het werk vooral in het opruimen in de downstream. Bekijk de andere praktijkvoorbeelden van schattingen, of start een gratis planning poker-sessie wanneer de omvang van de downstream bekend is.