Een schatting maken van een upgrade van een afhankelijkheid

Patch en minor zijn ruis. Major over N bibliotheken is N pieken — ga uit van het slechtste scenario, niet van het gemiddelde.

Upgrades van afhankelijkheden komen in twee vormen voor die er in de uitvoer van de pakketbeheerder identiek uitzien. De eerste: een reeks patches en kleine versieverhogingen die het team in één batch moet verwerken, waaraan de testsuite moet worden uitgevoerd en die als één saaie PR moeten worden samengevoegd. Dat verzoek heeft prioriteit 1, soms 2, en de enige reden om erover te stemmen is om te bevestigen dat het team het erover eens is dat het saai is. De tweede vorm: een grote versie-upgrade voor één of meer bibliotheken, waarbij de changelog een sectie met „breaking changes“ bevat en het team deze moet doorlezen. Dat is het verhaal dat voor het oog verborgen blijft. Het team stemt met een 3 omdat „het gewoon een upgrade is“ en levert het drie sprints later uit met een 13.

Dit is geen framework-upgrade. Een framework-upgrade is één bibliotheek waarvoor u al een kwartaal lang plannen hebt gemaakt; het team weet dat het om een project gaat. Een upgrade van afhankelijkheden is het stille onderhoudsticket dat iemand indient omdat de beveiligingsscan zes bibliotheken heeft gesignaleerd, en niemand de changelogs heeft gelezen. De valkuil zit hem in de verdeling: van de zes versieverhogingen zijn er vier triviaal, één betreft een hernoemde export en één is een volledig herontwerp van de API. De schatting die hieruit het gemiddelde berekent, klopt in beide richtingen niet.

Wat er in de kamer wordt gezegd

Ingenieur A: „Het zijn zes oneffenheden. Twee per stuk. 13 in totaal.”

Kop: “Zijn het allemaal minderjarigen?”

Ingenieur A: „Drie kleine, drie grote.“

Ingenieur B: “Heeft iemand de belangrijkste wijzigingslogboeken gelezen?”

Ingenieur A: “…laat mij eens kijken.”

Leidinggevende: “We hebben nog geen schatting. We hebben drie pieken.”

De inleiding klopt. Er is geen enkel cijfer voor dit verhaal, omdat er niet één verhaal is. De kleine storingen vormen samen een apart, klein probleem; elke grote storing is een eigen piek totdat iemand de changelog heeft gelezen en weet wat er misgaat.

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

Hoeveel updates zijn er, en hoe is de verdeling tussen major-, minor- en patch-updates?
Heeft iemand de changelogs voor de grote versie-updates gelezen?
Zijn er bibliotheken die het team zelf beheert, in tegenstelling tot die van leveranciers?
Is er sprake van een transitief afhankelijkheidsconflict waardoor deze gebeurtenissen gelijktijdig moeten plaatsvinden?
Wat is de terugdraaiingsprocedure als een van de upgrades de productie verstoort?
Heeft het beveiligingsteam een deadline, of gaat het hier om technische schuld?

Als het antwoord op de vraag „Heeft iemand de changelogs gelezen?“ „nee“ is, is de schatting niet realistisch. Breng voor elke grote update een beperkte piek in de planning aan, breng aan het licht wat er daadwerkelijk niet meer werkt, en maak vervolgens een nieuwe schatting van de implementatie op basis van uw bevindingen.

Maak geen inschatting van upgrades van afhankelijkheden door het aantal versienummerverhogingen te tellen. Lees eerst de changelogs en maak vervolgens een inschatting op basis van wat u daarin hebt aangetroffen.

Zie het maken van een schatting voor een framework-upgrade voor de variant met één bibliotheek en één hoofdversie, en de andere praktijkvoorbeelden van schattingen. Start een gratis planning poker-sessie nadat de spikes duidelijkheid hebben verschaft over wat er daadwerkelijk verandert.