Togdrift er en glimrende metafor for softwareudvikling. Vi lægger planer for vores leverancer af software, og vi overholder dem med større eller mindre held og dygtighed. På samme måder lægger togselskaberne køreplaner for afgangene og efterlever dem med varierende held og dygtighed.
Jeg kan godt lide at rejse med tog, fordi sjælen kommer med. Jeg har både kørt med tog i Danmark, Japan og Sudan, og togrejser kan være vidt forskellige. Fint nok. Det giver gode oplevelser på hver sin måde. Men når det kommer til softwareleverancer, så har jeg en klar favorit.
I 1982 var jeg i ørkenen syd for Khartoum i Sudan.
Vi skulle ikke med toget, men så det holde på den interimistiske station i ørkenen i mere end en halv dag. Det var ikke til at vide, hvornår toget ville køre. Passagerer blev ved med at strømme til. Indimellem så vi folk stige af, gå i byen for at købe ind eller få noget at spise på en af de små restauranter i nærheden. Da toget endelig gik i gang, kørte det meget langsomt og folk der ikke lige var ombord løb langs toget for at komme med. Efter en rum tid var det oppe i marchhastighed, som næppe kom over 50-60 km/t.
Så bød Japan på en helt anden oplevelse mange år efter. Det japanske jernbanesystem er nok verdens bedst udviklede. Regionale og lokale tog er velorganiserede og punktlige. Nationens stolthed er Shinkansen netværket, som transporterer passagerer rundt i hele landet med hastigheder på op til 320 km/t.
Når man skal med Shinkansen, kan man stille sit ur efter toget og behøver ikke at være bekymret over, at man med mangelfulde japansk kundskaber ikke vil være i stand til at stå af på den rette station. Man står bare af toget på det tidspunkt, der står på ens billet – det holder stik hver gang.
Den danske togdrift ligger et sted midt i mellem Japan og Sudan. For nylig oplevede vi to gange at S-stogs systemet gik på grund af en såkaldt “uforklarlig fejl” hos BaneDanmark, og dagligt oplever vi små og store forsinkelser. DSB’s definition af rettidighed er meget bred. Inden for 5 minutter kan et tog betragtes som rettidigt. I Japan taler vi om sekunder.
At release nye versioner af softwareprodukter er som en togafgang. Passagererne er de projekter/features, der skal med i en bestemt release og en release kan sendes ud af døren på enten japansk, dansk eller sudansk facon.
Alt for ofte ser man i store it-organisationer, private som offentlige, at evnen til at sende nye versioner på gaden, er som de sudanske jernbaners forhold til køreplanen.
Releases kommer sjældent ud af døren til tiden. De er ofte overfyldte og det er ikke unormalt, at iagttage dramatiske scener ved afgangstidspunktet. Features som egentlig ikke er helt klar til at komme med presses ombord og andre kommer halsende bagefter. Ikke sjældent sender vi manuelt drevne dræsiner afsted med patches og efterleverancer…
Hvorfor går det så dårligt?
Paradoksalt nok er kernen i problemet, at der er for få afgange/releases. Når der kun sjældent afgår tog, er det tilsvarende svært at få afsted. Det bliver overfyldt. Der er mange der vil bruge deres overtalelsesevner og politiske tæft til at argumentere for at deres – politisk eller forretningsmæssigt – helt uundværlige ting, skal med på denne afgang, da der er meget længe til at chancen opstår næste gang.
Hvorfor er der så længe mellem afgangene? Det er vi nødt til, fordi det er så svært at få det afsted lyder svaret. Hvorfor er det så svært at få det afsted? – fordi der er så længe mellem afgangene lyder mit svar så…..
Hvis vi ændrer en releasefrekvens fra 4 gange årligt til 12 gange årligt, vil mængden af gods i form af features kun være en tredjedel med hver afgang. Alt andet lige skulle det betyde en stor lettelse i arbejdet med den enkelte release, men desværre er det ofte sådan, at man har opbygget systemer, som har så høje transaktionsomkostninger at prisen kun mindskes marginalt, når der er mindre materiale med på afgangen.
Det bunder ofte i ikke-standardiserede og manuelle processer. En stor post på det budget er manuel test. Automatisering og standardisering er vejen til at reducere transaktionsomkostningerne.
Fra sudanske til japanske tilstande
Arbejdet er på samme tid et enkelt og krævende. Man starter på at gøre tingene hurtigere, men ikke hurtigere, end at man har kvaliteten under kontrol. Falder man for fristelsen til at slække på kvaliteten for at nå at få noget funktionalitet med, har man kastet en boomerang, som med usvigelig sikkerhed rammer en selv i nakken. Som regel når man mindst af alt venter det, og når det er allermest ubelejligt.
Derimod kan man sagtens simulere at man leverer oftere end man rent faktisk gør og f.eks hver anden uge, lade som om at man releaser. Derved arbejder man sig frem mod det punkt, hvor man rent faktisk kan release oftere og pludselig er release frekvens en mulighed man har kontrol over – og ikke en ørkenvandring.
Vejen dertil går som regel over, at organisationen lærer, at features skal skæres til i mindre uafhængige bidder, at alle processer skal automatiseres, at test skal ske tættere på og som en del af selve udviklingen og at der skal være et tæt samarbejde mellem alle aktører, hele vejen gennem den værdistrøm et softwareprodukt er.
Og så er man en dag nået til den tilstand, at man behersker continuous delivery – at kunne levere nye versioner af produktet nårsomhelst man skulle ønske det. For nogen er det en utopisk drøm – men for en række softwareorganisationer er det i dag en naturlig evne -
Shinkansen er i drift mange steder – bl.a hos Google, Amazon og en lang række mindre virksomheder.
Leave a Reply