2.0 Inleiding tot deel 2: Flowmetrieken

Als deel 1 de filosofie van meten is, is deel 2 waar die filosofie levering zelf ontmoet: de metrieken die niet alleen beschrijven hoe snel en hoe veilig een team code beweegt van een idee naar een draaiend systeem, maar welke soort waarde überhaupt door die pijplijn beweegt. Dit deel is georganiseerd rond het Flow Framework, een model gecreëerd door Mik Kersten in zijn boek Project to Product uit 2018 dat softwarelevering behandelt als een waardestroom en die waardestroom een gedeeld vocabulaire geeft: vier flowitemtypes en vijf flowmetrieken die ingenieursactiviteit verbinden met bedrijfsstrategie in termen die een niet-technische belanghebbende daadwerkelijk kan gebruiken.

Die keuze van organiserend raamwerk is bewust. De DORA-metrieken, deploymentfrequentie, doorlooptijd, wijzigingsfoutpercentage, en hersteltijd, zijn echt onderzoek-gevalideerd en blijven een van de best-onderbouwde leveringsraamwerken beschikbaar, maar ze meten de mechanica van de pijplijn, niet wat erdoor stroomt. Een team kan uitstekende DORA-cijfers posten terwijl zijn daadwerkelijk geleverde waarde stilletjes is afgedreven richting omarbeid of weg van het schuld- en risicowerk dat de toekomst van een systeem beschermt. Dit deel behandelt DORA volledig, maar als een enkel, geconsolideerd referentieonderwerp aan het einde (onderwerp 2.10), omdat de urgentere, vaker ontbrekende vraag voor de meeste organisaties niet “hoe snel is onze pijplijn” is maar “wat levert onze pijplijn daadwerkelijk.” Elk onderwerp in dit deel volgt nog steeds dezelfde discipline gevestigd in deel 1: stel de metriek, benoem hoe hij gemanipuleerd wordt, en paar hem met de beschermmetriek die die manipulatie vangt.

Voor grote teams zijn flowmetrieken wat teamoverschrijdende vergelijking mogelijk maakt zonder waarde uit het oog te verliezen. Een platformteam, een mobielteam, en een datateam kunnen bijna niets gemeenschappelijk hebben in hun dagelijks werk, maar flowsnelheid en flowverdeling, consistent berekend, laten leiderschap een eerlijke vraag stellen over alle drie: levert dit team het soort waarde dat zijn huidige fase daadwerkelijk vereist. Grote bedrijven en overheidsinstanties vertrouwen op de metrieken van dit deel om platforminvestering te rechtvaardigen, om het rendement van concurrerende moderniseringsinspanningen te vergelijken, en om, met bewijs in plaats van anekdote, te demonstreren dat ingenieurscapaciteit toegewezen wordt zoals leiderschap gelooft dat het is.

Onderwerpen in dit deel

2.1 Het Flow Framework: De oorsprong van het raamwerk, zijn waardestroommodel, en waarom dit boek het gebruikt, in plaats van DORA alleen, om levering- en flowmetrieken te organiseren.
2.2 Flowitems: functies, defecten, risico’s, en schuld: De vier-type-taxonomie van het raamwerk, zijn zero-sum-capaciteitstoewijzing, en hoe classificatie gemanipuleerd wordt als retroactief toegepast.
2.3 Flowsnelheid en flowverdeling: Hoeveel geleverd werd en welk soort waarde het was, altijd samen gelezen.
2.4 Flowtijd en flowbelasting: Hoe de Wet van Little bewijst dat een overbelaste waardestroom wiskundig vertraagt, niet alleen waarschijnlijk.
2.5 Flow-efficiëntie en onderhanden werk: Waarom druk niet hetzelfde is als snel, en hoe het beperken van onderhanden werk doorvoer contra-intuïtief verbetert.
2.6 Cyclustijd en zijn componenten: De ingenieurstijd van een wijziging afbreken in zijn samenstellende stadia zodat een team precies weet waar tijd daadwerkelijk naartoe gaat.
2.7 Wachtrijtheorie: De wiskunde onder flowbelasting, flowtijd, cyclustijd, en onderhanden werk, en waarom wachttijd op een gedeelde resource explodeert naarmate benuttingsgraad zijn limiet nadert.
2.8 Lean-waardestroommetrieken: De klassieke Lean-gereedschapskist, doorlooptijd, verwerkingstijd, cyclustijd, percentage volledig en juist, en takttijd, waarvan de softwarespecifieke metrieken van dit deel afstammen, en hoe de twee vocabulaires te overbruggen.
2.9 Pull-request- en codereviewmetrieken: De metrieken die leven binnen een enkel stadium van de leveringspijplijn, en hoe ze reviewkwaliteit kunnen vervormen als onvoorzichtig gebruikt.
2.10 Het DORA-metriekenraamwerk: De vier DORA-metrieken volledig, bewust laatst geplaatst omdat ze de pijplijn meten, niet de waarde die erdoor stroomt.

Hoe deze onderwerpen samenhangen

Onderwerp 2.1 introduceert het Flow Framework als geheel; onderwerp 2.2 geeft zijn taxonomie van flowitems, en onderwerp 2.3 en 2.4 behandelen zijn vijf flowmetrieken tussen hen, snelheid en verdeling samen, dan tijd en belasting samen, met belasting en tijd direct gekoppeld aan de Wet van Little. Onderwerp 2.5 tot 2.7 zoomen in op de mechanica onder flowtijd en cyclustijd specifiek: flow-efficiëntie en onderhanden werk verklaren waarom ingenieursstadia vaak langzamer zijn dan ze lijken, cyclustijd breekt dat ingenieursdeel af in zijn stadia, en wachtrijtheorie formaliseert, in bewijsbare wiskundige termen, waarom alle beweringen van de voorafgaande onderwerpen over belasting, wachttijd, en benuttingsgraad waar zijn. Onderwerp 2.8 stapt terug om alles te traceren naar zijn oorsprong in klassieke Lean-waardestroomkartering, het gemeenschappelijke vocabulaire waarvan de softwarespecifieke metrieken van dit deel generaliseren. Onderwerp 2.9 behandelt het enkele pijplijnstadium dat de meeste teams het snelst kunnen verbeteren. Onderwerp 2.10 sluit het deel af met de DORA-metrieken volledig, gepresenteerd als een goed-onderbouwde maar nauwere referentielaag zodra het bredere, bedrijfsgerichte beeld van de eerdere onderwerpen al in zicht is.

De beschermmetriek-discipline van dit deel koppelt direct terug naar onderwerp 1.2: flowsnelheid wordt nooit gerapporteerd zonder flowverdeling erbij, en DORA’s snelheidsmetrieken blijven gepaard met zijn stabiliteitsmetrieken, zodat een team geen snelheidscijfer kan verbeteren door stilletjes risicovoller code te leveren of een nauwere mix van waarde. Die paring is niet incidenteel aan beide raamwerken; het is elk raamwerks centrale inzicht, en deel 6’s betrouwbaarheidsmetrieken breiden dezelfde stabiliteitshelft van die paring uit naar productieoperaties zodra code al geleverd is.