Een schatting maken van een CI/CD-herziening

Voor de werkzaamheden aan de pijplijn is er geen demo. Beperk de selectie 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 en 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 ingenieur 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: “Het nieuwe systeem verricht al de helft van ons werk.”

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 kern van de zaak. Het gaat niet om „het bouwen van de nieuwe pijplijn“; het team heeft die waarschijnlijk al maanden geleden gebouwd tijdens een tijdig project in iemands vrije tijd. Het verhaal luidt: „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 het kan stemmen.

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 gevallen 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 kleine stap die 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 het waard zijn om te 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 niet op de hoogte zijn, zoals een extern team of een geplande taak?
• Wat is de terugdraaiingsprocedure indien 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.

Pijplijnwerkzaamheden worden 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 bekijk de andere voorbeelden van schattingen die wel hebben gewerkt. Start een gratis planning poker-sessie zodra het team een lijst met te verwijderen onderdelen heeft opgesteld.