Het inschatten van een wijziging in het ontwerpsysteem

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 waar nog steeds het oude systeem wordt gebruikt. De schatting moet de uitrol omvatten (codemod of handmatige migratie, tijdschema voor de uitfasering, strategie voor visuele regressietests), anders komt het werk daar simpelweg maandenlang tot stilstand, 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?”

Leiding: “Gaan we een codemod uitvoeren, of voeren de featureteams de migratie zelf uit?”

Vraag: “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 call-sites gaat het, gemeten in plaats van geschat?
• Codemod of handmatige migratie? Wat is de dekkingsgraad van de Codemod?
• Welk tijdschema geldt er voor het afschaffingstraject (waarschuwing, foutmelding, verwijdering)?
• Wordt er visuele regressietesting uitgevoerd op de betrokken schermen?
• Communicatie tussen teams: aan wie brengen wij dit over, wanneer en hoe?
• Moet er worden teruggezet 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; daarom splits ze op: de nieuwe component vormt één story, het migreren van de aanroeplocaties 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-fase klein en zit het werk vooral in het opruimen in de downstream-fase. Bekijk de andere praktijkvoorbeelden van schattingen, of start een gratis Planning Poker-sessie wanneer de omvang van de downstream-fase vaststaat.