Een schatting maken van een CI/CD-herziening

Voor de werkzaamheden aan de pijplijn is er geen demo. Beperk de scope tot „welke build vandaag kan worden verwijderd” om de inschatting haalbaar te houden.

CI/CD-herzieningen zijn de slechtst omschreven taken in de backlog. Er is geen resultaat voor de gebruiker, geen demo, geen schermafbeelding die iemand in de release-opmerkingen kan opnemen. Het werk is structureel van aard: het vervangen van de ene pijplijn door de andere, het migreren van een buildsysteem, het samenvoegen van drie testrunners tot één, en de overstap van een handmatig geschreven shellscript naar een degelijk workflowbestand. Het team weet dat dit werk moet gebeuren. Het team weet ook dat het een kwartaal in beslag zal nemen, en dat dit kwartaal onzichtbaar zal blijven voor iedereen buiten de engineeringafdeling.

De manier waarop de schatting mislukt, is voorspelbaar. Het team stemt voor 13 omdat „het een refactor is, en het is een omvangrijk project.” Na drie sprints draait de oude pijplijn nog steeds naast de nieuwe, zijn twee systemen gedeeltelijk geconfigureerd en heeft elke engineer een ander mentaal model over welke van de twee moet worden gebruikt. Het verhaal is nog niet afgerond omdat er geen definitie van ‘afgerond’ is — pijplijnen worden niet ‘geleverd’; ze worden in gebruik genomen, en die acceptatie is een aparte kwestie, los van het feit dat ‘het nieuwe systeem bestaat’.

Wat er in de kamer wordt gezegd

SRE: „We moeten de oude runner vervangen. Twee sprints.”

Inleiding: “Wat is de definitie van ‘klaar’?”

SRE: “…de nieuwe werkt.”

Kop: “De nieuwe versie is al geschikt voor de helft van onze taken.”

Backend: “Maar de oude draait nog steeds voor de andere helft.”

Lead: “Juist. We zijn dus klaar zodra we de oude kunnen verwijderen.”

Dat is de juiste aanpak. Het gaat niet om „de nieuwe pijplijn bouwen“ — het team heeft die waarschijnlijk al maanden geleden in iemands vrije tijd als tijdelijk project opgezet. Het verhaal is „de oude pijplijn verwijderen“. Zolang het oude buildsysteem nog bestaat, is de herziening niet voltooid; het is parallelle infrastructuur met alle kosten en geen enkel voordeel. Door het verhaal te definiëren als verwijdering in plaats van aanleg, krijgt het team een definitie van „klaar“ waarover gestemd kan worden.

Hoe snijdt u het?

Maak een overzicht van de taken die nog op het oude systeem draaien. Voor elke taak: wat is er nodig om de oude versie te verwijderen? Dat is een afzonderlijk verhaal. Sommige zijn triviaal (de taak was al naar de nieuwe pijplijn gekopieerd; verwijder gewoon het oude YAML-bestand). Andere vergen daadwerkelijk werk (de testsuite bevat een hardgecodeerd pad; de implementatiestap is afhankelijk van een oude omgevingsvariabele). Elke verwijdering is een klein onderdeel dat het team kan opleveren en demonstreren. „We hebben het Jenkinsfile voor de authenticatieservice verwijderd” is een resultaat dat gedemonstreerd kan worden.

Elke verwijdering kan op de gebruikelijke manier worden ingeschat: breng eerst de onbekende factoren in kaart (zijn er bij deze taak gebruikers waarvan wij geen weet hebben?), en schat vervolgens de verwijdering in aan de hand van een referentieverwijdering die u al hebt geïmplementeerd. De meeste segmenten komen uit op 2 of 3 punten. Het verhaal dat „13, refactor, groot“ heette, bleek in werkelijkheid vijftien keer 2 en één keer 3 in een trenchcoat te zijn.

Vragen die u zich het beste kunt stellen voordat u gaat stemmen

• Wat wordt er verwijderd als dit artikel klaar is?
• Welke functies zijn nog steeds afhankelijk van het oude systeem?
• Is er een gebruiker van de oude pijplijn waarvan wij geen weet hebben — een extern team, een geplande taak?
• Wat is de terugdraaiingsprocedure als de nieuwe pijplijn weer slechter presteert nadat wij de oude hebben verwijderd?
• Wie is de gezaghebbende bron met betrekking tot de stelling „de nieuwe pijplijn is de bron van de waarheid“?
• Houdt iemand bij welke taken er week na week op het oude respectievelijk het nieuwe systeem worden uitgevoerd?

Als het antwoord op de vraag „wat wordt er geschrapt?“ „niets deze sprint“ is, bevindt het team zich nog steeds in de fase van parallelle infrastructuur en voldoet het verhaal niet aan de gereedheidscriteria.

Pijplijnwerk wordt uitgevoerd zodra het oude systeem is verwijderd. Werk stapsgewijs door verwijdering; maak voor elke verwijdering afzonderlijk een schatting.

Zie horizontaal versus verticaal segmenteren om te begrijpen waarom „het nieuwe systeem bouwen” de verkeerde segmentatieas is, en de andere voorbeelden van geslaagde schattingen. Start een gratis planning poker-sessie zodra het team een lijst met te verwijderen elementen heeft opgesteld.