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 aanroepplaatsen die de oude component gebruiken. 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 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 systeemzijde 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, uitfaseringstijdlijn, strategie voor visuele regressietests), anders ligt het werk daar simpelweg maandenlang stil terwijl de featureteams 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 het waard zijn om te stellen voordat u gaat stemmen
- Om hoeveel locaties gaat het, op basis van metingen in plaats van schattingen?
- Codemod of handmatige migratie? Hoe groot is de dekking van Codemod?
- Welk tijdschema geldt er voor het afbouwtraject (waarschuwing, foutmelding, verwijdering)?
- Wordt er visuele regressietesting uitgevoerd op de betrokken schermen?
- Communicatie tussen teams: aan wie, wanneer en hoe brengen wij dit onder de aandacht?
- Moet er worden teruggezet als de nieuwe component een fout vertoont die pas in de productieomgeving aan het licht komt?
De wijziging in de bovenstroomse fase is klein en het opschonen in de benedenstroomse fase vormt het echte werk; splits deze daarom op: de nieuwe component vormt één story, het migreren van de aanroepplaatsen vormt een andere, en de omvang van de tweede story 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-fase klein en zit het werk vooral in het opruimen in de downstream-fase. Bekijk de andere voorbeelden van schattingen in de praktijk, of start een gratis Planning Poker-sessie zodra de omvang van de downstream-fase is vastgesteld.