2.0 Introduktion till del 2: Flödesmätetal

Om del 1 är mätningens filosofi är del 2 där den filosofin möter själva leveransen: mätetalen som beskriver inte bara hur snabbt och hur säkert ett team flyttar kod från en idé till ett körande system, utan vilken sorts värde som överhuvudtaget flödar genom den pipelinen. Den här delen är organiserad kring Flow Framework, en modell skapad av Mik Kersten i hans bok Project to Product från 2018 som behandlar mjukvaruleverans som ett värdeflöde och ger det värdeflödet ett delat vokabulär: fyra flödesobjekttyper och fem flödesmätetal som kopplar ingenjörsaktivitet till affärsstrategi i termer en icke-teknisk intressent faktiskt kan använda.

Det valet av organiserande ramverk är medvetet. DORA-mätetalen, driftsättningsfrekvens, ledtid, ändringsfelfrekvens, och återställningstid, är genuint forskningsvaliderade och förblir ett av de bäst beprövade leveransramverken tillgängliga, men de mäter pipelinens mekanik, inte vad som flödar genom den. Ett team kan posta utmärkta DORA-tal medan dess faktiskt levererade värde tyst har drivit mot omarbete eller bort från det skuld- och riskarbete som skyddar ett systems framtid. Den här delen täcker DORA i sin helhet, men som ett enda, konsoliderat referensämne i slutet (ämne 2.10), eftersom den mer brådskande, mer vanligt saknade frågan för de flesta organisationer inte är “hur snabb är vår pipeline” utan “vad levererar vår pipeline faktiskt.” Varje ämne i den här delen följer fortfarande samma disciplin etablerad i del 1: ange mätetalet, namnge hur det manipuleras, och para det med skyddet som fångar den manipulationen.

För stora team är flödesmätetal det som gör jämförelse mellan team möjlig utan att tappa värdet ur sikte. Ett plattformsteam, ett mobilteam, och ett datateam kan ha nästan ingenting gemensamt i sitt dagliga arbete, men flödeshastighet och flödesfördelning, beräknade konsekvent, låter ledningen ställa en rättvis fråga över alla tre: levererar det här teamet den sortens värde dess nuvarande fas faktiskt kräver. Stora företag och myndigheter förlitar sig på den här delens mätetal för att motivera plattformsinvestering, för att jämföra avkastningen på konkurrerande moderniseringsinsatser, och för att demonstrera, med belägg snarare än anekdot, att ingenjörskapacitet allokeras på det sätt ledningen tror den är.

Ämnen i denna del

2.1 Flow Framework: ramverkets ursprung, dess värdeflödesmodell, och varför den här boken använder det, snarare än enbart DORA, för att organisera leverans- och flödesmätetal.
2.2 Flödesobjekt: funktioner, defekter, risker, och skuld: ramverkets fyrtypstaxonomi, dess nollsummekapacitetsallokering, och hur klassificering manipuleras om den tillämpas retroaktivt.
2.3 Flödeshastighet och flödesfördelning: hur mycket som levererades och vilken sorts värde det var, alltid lästa tillsammans.
2.4 Flödestid och flödesbelastning: hur Littles lag bevisar att ett överbelastat värdeflöde matematiskt saktar ner, inte bara troligen.
2.5 Flödeseffektivitet och pågående arbete: varför upptagen inte är samma sak som snabb, och hur att begränsa pågående arbete förbättrar genomströmning kontraintuitivt.
2.6 Cykeltid och dess komponenter: att bryta ner en ändrings ingenjörstid i dess beståndsdelar så att ett team vet exakt var tiden faktiskt går.
2.7 Könteori: matematiken under flödesbelastning, flödestid, cykeltid, och pågående arbete, och varför väntetid på en delad resurs exploderar när utnyttjandet närmar sig sin gräns.
2.8 Lean-värdeflödesmätetal: det klassiska Lean-verktygslådan, ledtid, processtid, cykeltid, procentandel komplett och korrekt, och takttid, som den här delens mjukvaruspecifika mätetal härstammar från, och hur man överbryggar de två vokabulären.
2.9 Mätetal för pull request och kodgranskning: mätetalen som lever inom ett enda steg i leveranspipelinen, och hur de kan snedvrida granskningskvalitet om de används vårdslöst.
2.10 DORA-mätetalsramverket: de fyra DORA-mätetalen i sin helhet, placerade sist medvetet eftersom de mäter pipelinen, inte värdet som flödar genom den.

Hur dessa ämnen hänger ihop

Ämne 2.1 introducerar Flow Framework som helhet; ämne 2.2 ger dess taxonomi av flödesobjekt, och ämnen 2.3 och 2.4 täcker dess fem flödesmätetal mellan sig, hastighet och fördelning tillsammans, sedan tid och belastning tillsammans, med belastning och tid direkt kopplade till Littles lag. Ämnen 2.5 till 2.7 zoomar in på mekaniken under flödestid och cykeltid specifikt: flödeseffektivitet och pågående arbete förklarar varför ingenjörssteg ofta är långsammare än de ser ut, cykeltid bryter ner den ingenjörsdelen i dess steg, och könteori formaliserar, i bevisbara matematiska termer, varför alla de föregående ämnenas påståenden om belastning, väntetid, och utnyttjande är sanna. Ämne 2.8 tar ett steg tillbaka för att spåra allt det till dess ursprung i klassisk Lean-värdeflödeskartläggning, det gemensamma vokabulär den här delens mjukvaruspecifika mätetal generaliserar från. Ämne 2.9 täcker det enda pipelinesteg de flesta team kan förbättra snabbast. Ämne 2.10 avslutar delen med DORA-mätetalen i sin helhet, presenterade som ett väl beprövat men smalare referenslager när den bredare, affärsvända bilden från de tidigare ämnena redan är i sikte.

Den här delens skyddsdisciplin kopplar direkt tillbaka till ämne 1.2: flödeshastighet rapporteras aldrig utan flödesfördelning vid sidan av, och DORA:s hastighetsmätetal förblir parade med dess stabilitetsmätetal, så att ett team inte kan förbättra ett hastighetstal genom att tyst leverera riskablare kod eller en smalare blandning av värde. Den parningen är inte tillfällig för något av ramverken; det är vart och ett av ramverkens centrala insikt, och del 6:s tillförlitlighetsmätetal utökar samma stabilitetshalva av den parningen till produktionsdrift när kod väl har levererats.