2000+ lyttinger
NDC
Build - Microsoft
DevOps - fora
Dora DevOps Report - viktig rapport av noen som var tidlig ute og hadde troen på DevOps.
Del denne Masterclass
Dette lærer du om i denne Masterclass
Bibliotek
Om LØRN
© 2024 LØRN AS
“
Velkommen til LØRN.Tech – en læringsdugnad om teknologi og samfunn med Silvija Seres og venner.
Silvija Seres: Hei og velkommen til LØRN Fundamentals om DevOps med Kjetil Kværne. Velkommen til deg også Kjetil.
Kjetil Kværne: Takk skal du ha Silvija.
Silvija: Jeg skal si to ord om produktet vårt før vi setter i gang med selve samtalen. Dette her er et minikurs, samtale baserte forelesninger hvor jeg spør og du svarer om temaet DevOps. Første leksjon er om introduksjon til selve temaet. Andre er om dine favoritt eksempler. Sånn at vi skal forstå litt de konseptene du gir oss i første samtale. Tredje er verktøykasse og fjerde er et lite verksted hvor du hjelper meg som leder en SMB og begynne å bruke disse flotte konseptene rundt DevOps. Høres det greit ut?
Kjetil: Da høres veldig bra.
Silvija: Veldig bra, og da starter vi alltid med å be folk introdusere seg. Fortell oss litt om hvem er Kjetil og hvorfor synes han at det DevOps er et spennende tema?
Kjetil: Yes. Kjetil, og jeg har jobbet i IT bransjen i godt over 20 år. Jobber i dag som utviklingssjef hos Forte Technology. Har programmert aktivt gjennom hele min karriere. Synes det å programmere er veldig morsomt. Har jobbet i veldig mange både små og kjempestore prosjekter. Og etter hvert som jeg har programmert så har jeg fått interessen for at det å bli en god programmerer handler om noe mer enn å bare programmere og lage ting. Det handler om å lage god kvalitet og det handler om god kommunikasjon og få det ut til kunden. Derfor har jeg fattet litt interesse for hvordan skal vi lage god programvare effektivt. Og i gamledager så pratet vi om fossefall, også kom vi over til smidig og agile. Og i dag prater vi gjerne om DevOps og agile 2.0 sånn som jeg også gjerne kaller det, da.
Silvija: Vi kommer tilbake til DevOps. Egentlig forteller navnet veldig mye om konseptet, men det høres veldig, veldig skremmende ut. Men før vi gjør det – du gikk veldig fort på fag. Hvem er Kjetil når han ikke nerder?
Kjetil: Nei, en nerdig er jo en stor del av livet mitt. Jeg synes det er moro å sitte på kveldstid å programmere. Men jeg er en godt voksen mann med tre voksne barn. Og har to til fire hunder som er en stor del av fritiden min.
Silvija: To til fire?
Kjetil: To til fire. Datteren min har to hunder som ofte er på besøk. Så da sier jeg at vi har to til fire hunder som er relativt kaotisk i hjemmet med så mange bikkjer. Ellers er jeg engasjert, veldig samfunnsengasjert. Jeg har ofte tatt på meg frivillige verv innenfor idretten. Å være fotballtrener for barn og unge i mange år. Veldig interessert i den biten. Har kjørte ismaskin i mange år på Kongsvinger.
Silvija: Her kommer det.
Kjetil: Vært formann i idrettslag også videre. Liker det å gi litt tilbake til samfunnet.
Silvija: Ismaskin? Ikke brøytemaskin, men den som lager is på baner?
Kjetil: Ja. Og det er jo en teknologi i seg selv med millimeter presentasjon på isen og riktig temperatur og alt det som skal til for å lage en optimal isflate.
Silvija: Ser så vakkert ut også.
Kjetil: Det er spennende å kombinere dette med teknologi også. Jeg har laget hjemmesider for de her. Idrettslagene har jeg vært med på å lage løsninger for kommunikasjon. Mitt fag inn i også det arbeidet jeg gjør fritiden, da.
Silvija: Og ditt fag er da programmering. Du er utviklingssjef hos Forte Technology. Si bare kort hvem Forte Technology er.
Kjetil: Forte Technology er et underselskap til Forte Digital. Forte Digital er jo veldig i vinden om dagen. Det er et ungt selskap som startet i 2017 og har hatt en enorm vekst siden da. Og vant jo den uken her årets Gaselle bedrift. Så vi er veldig stolt over det og hva man har fått til i løpet av de årene.
Silvija: Hva lager dere?
Kjetil: Vi er et konsulentselskap hvor vi hjelper kundene med hverdagslige løsninger av problemer. Vi har veldig fokus på dette med å hjelpe kunden til å bli mer datadrevet og utnytte det gullet som kundene sitter på i form av sine egne data. Så de kan dra nytte av de dataene de har og få litt mer innsikt i sine egne data, da.
Silvija: Datadreven verdiskapning. Hvis jeg gjetter riktig så holder du på med noe plattformer for å gjøre det enklere? Eller?
Kjetil: Ja, vi har fokus på å lage en digital plattform som handler om å lage en plattform slik at kunden veldig enkelt kan lage nye ting oppå den plattformen og få en effektiv og god plattform å bygge videre på. For å hjelpe dem å løse hverdagsproblemer. Også er det sånn at kunden sine behov i dag vet vi mye om, men ikke i morgen. Og da har vi en plattform som er god som betyr at vi også tar høyde for det som kommer i løpet av morgendagen.
Silvija: Og du, hvor kommer DevOps inn i dette her?
Kjetil: DevOps vil jeg si at i moderne programvareutvikling så handler DevOps om en helhetlig tilnærming til hvordan vi kan få effektive og gode arbeidsmetoder og arbeidsflyt på tvers av utvikling og drift. Det var vel opprinnelig der det begynte. Det begynte jo i 2008 hvor to personer kom sammen og begynte å diskutere litt svakheten og mangelen i denne agile eller smidige metodikken. Hvor den ene representerte utvikling og den andre representerte operation. Derav Dev og Ops. Drift ja. Og da kom de frem til dette DevOps begrepet også i 2009 fikk du den første DevOps konferansen. Så vil jeg si at DevOps er et veldig buzzword som alle bruker i dag. Også vil jeg påstå at det er veldig mange som kanskje ikke har forstått konseptet med DevOps slik at de bruker det feil. Hvis du går på Finn for eksempel så er det over 400 DevOps stillinger de søker. Og når du søker etter en DevOps utvikler så vil du se at da har du ikke forstått hva DevOps egentlig handler om.
Silvija: Og enkelt forklart?
Kjetil: Enkelt forklart? Spør du 10 personer får du 10 forskjellige definisjoner av DevOps. Min definisjon er at det er et sett med praksiser og tankesett som gjør oss i stand til å bygge og prodsette programvare av høy kvalitet raskt og mer pålitelig.
Silvija: Men vent litt. Det var ikke en enkel definisjon. Men det du sier er rask utvikling og god utvikling. Men i selve navnet så hørte jeg deg si at dette dreier seg om å gjøre helhetlig utvikling og drift?
Kjetil: Ja, det handler om hvordan kan vi lage programvare med høy kvalitet og som brukerne faktisk treffer. I gamle dager når vi pratet om fossefall så var det jo sånn at da laget kundene en kravspekk, også leverte en det til en programmerer også satte programmereren seg på bakrommet og jobbet et års tid også kom han frem og sa se her, nå er jeg ferdig. Og i løpet av året så hadde kanskje behovet til kunden forandret seg. Og ikke minst så dekker jo ikke kravspekket absolutt alle ting. Og det programmereren laget traff ikke 100%% på brukeren faktisk ønsket fordi man misforstår hverandre. Og i en moderne programvareutvikling så handler det mye mer om samarbeidet. Ikke bare at man leverer en kravspekk og får laget det, men det handler om hvordan man sammen kan lage god programvare.
Silvija: Og det er nesten sånn sirkulær utvikling. Og med agile så bryter man det ned i små biter, men det er ofte ikke nok læring tilbake kanskje?
Kjetil: Nei. Læring er en viktig del av DevOps. Men vi prater gjerne om Scrum som en agile metodikk. Og i Scrum så handler det om at vi tenker i iterasjoner. Kanskje 2 uker, kanskje 3 uker, litt variabelt. Mens i DevOps så bruker vi gjerne kanban, som gjerne handler om at vi ikke tenker i iterasjoner. Vi tenker kontinuerlig. Kontinuerlig på alt. Slik at når vi skal lage en ny funksjon så venter vi ikke til at sprinten er ferdig. Da lager vi den funksjonen, også får vi den ut i produksjon med en gang. Får feedback fra brukerne med en gang. Og da kan vi enklere justere kursen. Da vet vi om brukeren var fornøyd med den funksjonen eller om de ikke likte den. Og justere kursen med en gang i stedet for at vi skal bruke fire uker på å lage noe også treffer vi kanskje.
Hvis jeg skal bruke bilder – jeg liker å bruke bilder, og veldig sånn lego enkelt språk. Så tenker jeg at man kunne tenke seg en type lean metode som en god middag som kommer med mange forskjellige retter i mellom. Mens dere har en slags buffet hvor man legger ting nye ting til buffet, også må helheten fungere fortsatt.
Kjetil: Ja, hvis du bruker den analogien der så kan du si at når du kommer inn og skal spise den middag med mange retter så har du kanskje ikke bestemt deg for om ønsker du deg pannacotta eller ønsker du deg jordbær dessert. Og i en sånn DevOps tankegang så trenger du ikke å bestemme det før du er der. Og da kan du ombestemme deg på veien, men når du har lyst på den pannacottaen så får du den pannacottaen med en gang.
Silvija: Og si to ord om kanban. Det er et Toyota relatert begrep. Hvor kommer det inn?
Kjetil: Kanban er jo en metodikk ala Scrum som handler om å lage programvare. Kanban egentlig bare at vi kontinuerlig lager ting. Vi lager ting smått, og så er den store forskjell fra Kanban og Scrum at i Kanban, så som utvikler før, så lager jeg ting, levert det til test og så tok test og testet. Og hvis det var bra nok, så ga de det videre til drift. I Kanban så har utvikleren ansvaret fra man lager det til det er ute i produksjon. Det er den store forskjellen. Så man har et begrep som heter “”you build it, you run it“”, slik at da tar man ansvaret for det hele veien. Det er ikke sånn at man slipper det fra seg før man vet det er ferdig. Og når jeg lager noe så vet jeg ikke om det er bra nok før brukeren faktisk har tatt det i bruk. At det får den feedbacken fra brukeren. Men da får du et større eierskap og du følger det helt ut. Om du ikke følger det ut så får du sånne overleveringer hvor man misforstår hverandre også må du ha masse seremonier rundt overlevering. Og du får gjerne type gatekeepers som jeg kaller det. Autoritære personer som skal passe på at de vil ha det på den måten her. Vi må ha kontrollorgan. Så det blir veldig sånn kontroll regime rundt i stedet for at man gir tillit til teamet som skal lage noe. At teamet tar ansvaret for at det er god kvalitet og for at man lager det som skal lages. Og da kommer det hele veien ut da.
Silvija: Når du har ansvar for å drifte det, så tenker du at det må være bærekraftig programvare, rett og slett. Det skal leve godt når det er ute i produksjon også.
Kjetil: Ja, altså, som utvikler liker jeg ikke at noen ringer meg midt på natta og sier at ting ikke funker. Og når jeg må kjenne på den smerten selv så lager jeg noe som er bra. For du ønsker ikke den forstyrrelser på natta.
Silvija: Hvis jeg skal ha en annen analogi og ikke vår pannacotta og mange retters middag, men jeg tenker bygg og byggebransjen. Det er veldig stor forskjell på å bygge et bygg nøkkelferdig også er du ferdig. Eller å bygge et bygg hvor du også selger noe form for pågående vedlikehold hvor du også sier at vi skal oppgradere energisystemene, vi skal legge inn sensorikk, vi deler kostnader eller vi deler på innsparingene ved at vi har bygget et så fantastisk bygg. Det er litt mer en DevOps model tenker jeg.
Kjetil: Ja, da er nok en litt mer DevOps modell. Men i den DevOps modellen så handler det om at når du bygger dette huset at du har mulighet til å gjøre endringer på huset underveis. Hvis du for eksempel på kjøkkenete finner ut at oppvaskmaskinen skal stå ved vinduet, så fant du ut at det var en fryktelig dårlig ide. Så skal man i DevOps veldig enkelt kunne snu seg opp og flytte den oppvaskmaskinen uten at det skal involvere store kostnader og at det skal være mye planlegging for å få det til. Da ser man at dette fungerer ikke. Da justerer vi fortløpende.
Silvija: Og det er en fleksibilitet i spesifikasjoner. Det er der du også startet. At man er smidig på spesifikasjonen?
Kjetil: Ja, fordi at det handler om samarbeidet mellom de som eier produktet og de som skal bruke produktet og de som skal lage produktet og de som drifter produktet. Og her er det litt svakheter i DevOps som står for Development Operation, så fungerer ikke det i praksis. For du må også ta med de som eier produktet og de som skal bruke produktet. Så du får med hele verdikjeden til alle de som er involvert i det og lage programvare da.
Silvija: Men hvis vi er tilbake til de fire hundre manglende hoder på Finn som er i DevOps. Hva er det man egentlig burde søke etter? Man burde søke etter programmerer som klarer å tenke helhetlig?
Kjetil: Når man skal ha folk så bør man søke etter folk som har kompetanse på det man skal ha. DevOps handler ikke om kompetanse på DevOps, det handler mer om en kultur man ønsker inn i bedriften og hvordan vi tilnærmer oss det og løser problemer og lager kvalitet på ting. Og det kan du ikke søke etter når du søker stilling. Du kan si noe om at du ønsker personer som er fleksible og åpne og som er opptatt av kvalitet og som er opptatt av eierskap til det du skal lage. Så kan du selvfølgelig søke etter personer som har erfaring med å bygge DevOps. Og da prater vi om hvilke type verktøykasse teknologi man skal bruke. Men du kan ikke si at du skal ha en DevOps utvikler fordi en DevOps utvikler vil ikke fungere i en organisasjon som ikke har et DevOps tankesett.
Silvija: Hvordan bygger man et DevOps tankesett?
Kjetil: Da bygger du gjennom å skape en kultur. En kultur hvor det er lov å feile. Fail fast, learn fast er et av DevOps prinsippene som er like. Du bygger en kultur hvor det å skulle levere kontinuerlig er veldig viktig. Du bygger en kultur hvor du gir det teamet som skal lage tillit og mandat til å kunne lage de tingene og at de vil kunne ta avgjørelser på ting på egenhånd.
Silvija: Mandat tror jeg var et sentralt ord her. At folk forstår mandatet sitt og at de forstår hvordan mandatene kobler seg på hverandre også?
Kjetil: Ja, og om du pratet litt tidligere om dette med kravspek. Det er også en viktig bit i DevOps fordi vi kan ikke lage store lange kravspekker. En viktig del av det å kunne levere kontinuerlig er det å lage bitene mye mindre. Og da må du også ha en kravspekk mye mindre som går på å kun levere den ene funksjonaliteten av gangen. Og det er noe av de tingene jeg opplever som kanskje det vanskeligste for folk å tenke. Tenke små nok biter av gangen. Og få det til.
Silvija: Jeg sitter nå Kjetil og tenker på at vi snakker om programvare og programmerer, men jeg har hatt veldig spennende diskusjoner om den nye ledelsen og organisasjonskulturen som oppstår i post korona tider hvor vi ikke nødvendigvis sitter sammen lenger og hvordan leder du. Telenor for eksempel snakker veldig mye om en modell som heter Tight-Loose-Tight hvor første Tight dreier seg om å komme med veldig tydelige bestillinger, men fleksible nok “spekker” på hva folk skal gjøre. Sånn at folk kan gå på loose hvor de får lov til å finne ut selv hvordan de skal jobbe med dette her. Så må de bygge det inn i helheten med siste Tight også sjekke at dette er virkelig riktig retning også videre. Så jeg tror denne tankegangen hvor man deler oppgaver i små nesten autonome biter, men klarer å dra folk høyt nok opp til å se helheten og det kommer til å oppstå i veldig mange jobber i disse nye nettverksorganisasjoner som vi går inn i nå.
Kjetil: Ja, jeg er forsåvidt ikke kjent med det begrepet, men det er mye sånn buzzword og begreper innad i bransjen vår. Man er nok inne på noe, og jeg pleier å kalle det i DevOps sammenheng at du må ha en form for transformasjonsledelse. Og det er jo litt sånn teamet som skal lage noe må vite hva dem skal lage. I gamle dager når du leverte en kravspekk så var det sånn hva koster dette å lage? Du skulle ha en sum tilbake. I den transformasjonsledelsen må du stole på at det teamet som du har koster så og så mye penger. Du vet ikke helt hva du får. Og du må stole på at teamet jobber sammen med det for å lage og skape verdi sammen. Bruke teamet sin kompetanse på teknologi som din kompetanse på det domenet og forretningsområde. Det er jo prosjekteieren og selskapet som vet bedre, men teamet kan teknologi og kan muliggjøre dette med å skape verdi for kunden da. Så det å finne den balansegangen som du sier med Tight-Loose-Tight, du må ha rammer som gjør at teamet kan jobbe innenfor. Men det må ikke være for løse rammer slik at du teamet lager noe som ikke er etterspurt, da. Det er jo en utfordring der.
Silvija: Jeg har lyst å prøve å oppsummere. Og så må du korrigere meg hvis jeg har misforstått. Okey? Så det jeg har hørt de snakke om er at DevOps er en metode og en ganske konkret praksis for å utvikle i første runde programvare av høy kvalitet og høy fleksibilitet. Og tankegangen er at man integrerer utvikling med drift og at dette egentlig dreier seg om en kultur hvor alle må både forstå sin rolle, men også se helheten. Og en veldig viktig del av måten å drive med transformasjonsledelse når man ikke er helt sikker på hvor man skal. Så må man prøve å få med seg hele gjengen dit og bytte motoren mens flyet flyr. Det er sånn noenlunde?
Kjetil: Det er sånn noenlunde, også er det viktig det her med kontinuerlighet. Det er et av kjernebegrep prinsippene i DevOps. At vi skal kontinuerlig levere verdi.
Silvija: Helt fra starten? Eller hvorfor er det så viktig?
Kjetil: Jo, fordi at det å skape verdi og levere noe når vi leverer noe fortløpende, da har vi mulighet til å justere kursen underveis. Hvis vi venter for lang tid så vet vi ikke om vi treffer hele. Og for å bruke en annen analogi da, i en sånn agil tankesett eller fossefalls tankesett er det sånn at du lager noe også stabler du det på et lager også ser vi at nå skal vi har produksjonssetting. Også produksjonssetter du en så stor bit. Forskjellen er når du produksjonssetter en liten bit, så kan du bevege deg mye raskere fordi biten er mindre. Pluss at de små bitene er veldig lett å teste. Du trenger ikke så mye kontroll organer rundt fordi hvis noe går galt når du produksjonssetter en bitte liten bit, så er det ofte sånn at du vet, da har du jobbet med det. Du vet at det er mye lettere å fikse opp i det med en gang. Og da sparer du de store iterasjonene. Jeg kan jo nevnte et eksempel fra et prosjekt jeg jobbet i tidligere hos Helsedirektoratet. Der hadde vi det ene prosjektet som jobbet med DevOps også hadde vi de andre prosjektene som ikke jobbet DevOps. Når vi skulle ha produksjonssetting så var det sånn at man begynte på en fredag, man kalte alle mann inn til dekk. Man bestilte hotell og sånn og planla. Og pizza og mat og sånn. Man skulle prod-sette, og man tok ned systemene og oppgradere også var det masse testing også videre. Og man brukte gjerne et par dager på det. I DevOps prosjektet hadde man ikke rukket å åpne pizzaen en gang før teamet var ferdig med prodsettingen sin.
Silvija: Og det var testet underveis?
Kjetil: Ja, og det er liksom sånn skift løft prinsipp at vi gjør ting tidligst mulig. Vi tester tidligere, vi tester sikkerhet, vi tester alt. Også har vi også automatisert alt inn i DevOps sånn at hvis noe går galt så er det bare å trykke på noen knapper også er man tilbake der man var før.
Silvija: Du ga meg noen veldig fine sånne taglines som jeg tror vi skal oppsummere. Shift left, det har noe med tidslinje å gjøre? Å gjøre alt litt tidligere enn du hadde tenkt. Også sa du også you build it, you run it. Også sa du også fail fast and learn fast. Nå skrev jeg det med norsk LØRN, men jeg tror du mente engelsk “”learn“”. Og det konseptet har jeg lyst å bruke et minutt til på. Fordi vi har hørt at Silicon Valley liker å si fail fast and learn fast også videre. Men egentlig er det ingen av oss som synes det er så innmari kult å innrømme at vi har feilet. Men for meg er det to innmari viktige komponenter her. Det ene er at du gjør ingenting nytt hvis du ikke feiler noen ganger. Så det skal være lov å feile. Også skal det være nødvendig å lære. Det er også den andre delen som er nødvendig for å rettferdiggjøre den første.
Kjetil: Ja, og det er ett av kjerneprinsippene. Feile gjør man hele tiden og feiling er en viktig bit for å faktisk lære. Hvis du ikke feiler så lærer du antageligvis ikke. Og i den kulturen så handler det også om at når man feiler, så har man ikke noe syndebukk som man kan peke på og si at du feiler. Men det at teamet sammen tar ansvaret for å lære av det, også bygger man opp mekanismer slik at vi vet at vi faktisk lærer. Vi vet at vi gjør ikke den feilen igjen. Og vi fanger det opp fordi vi gjerne skulle skrevet automatiske tester. Har vi feilet en gang, så lager vi en test og sørger for at det ikke skjer igjen, da. Så vi har mye vi bruker teknologien rundt oss til å lære av og forbedre at det ikke skjer igjen, da.
Silvija: Institusjonalisere det man har lærte. Det å implementere læringen er veldig, veldig spennende. Du, Kjetil! Jeg tror kanskje vi stopper der med vår første leksjon, og så møtes vi om et par minutter for å snakke om noen av dine favoritt eksempler. Tusen takk så langt.
Du har nå lyttet til en podcast fra Lørn.Tech – en læringsdugnad om teknologi og samfunn. Nå kan du også få et læring sertifikat for å ha lyttet til denne podcasten på vårt online universitet Lørn.University
“
“
Velkommen til LØRN.Tech – en læringsdugnad om teknologi og samfunn med Silvija Seres og venner.
Silvija Seres: Hei og velkommen tilbake til LØRN Fundamentals i DevOps med Kjetil Kværne. Nå er vi i leksjon 2 og nå skal Kjetil fortelle oss om noen av sine favoritt eksempler. Ting du har sett Kjetils om du mener vi andre har godt av å lære fra. Hvem tenker du på da?
Kjetil Kværne: Nei, jeg tenker først og frem tilbake til 2013-2014 også tenker jeg på et prosjekt som jeg da jobbet i hos Helsedirektoratet som da var fastlege prosjektet. Dette var jo et prosjekt i 60-millioners klassen. Det var et stort og viktig samfunnsprosjekt hvor man skulle flytte fastlegeordningen fra NAV over til Helsedirektoratet. Og man skulle lage løsninger helt på nytt. Det prosjektet begynte egentlig veldig dårlig fordi man hadde veldig mange mann som jobbet i det prosjektet. Dette var et prosjekt som også gikk over Helsedirektoratet, e-helse og NVM. Så det var stort. Mange organisasjoner. Jeg tror vi pratet mellom 80 og 100 integrasjoner fordi det var komplekse greier.
Silvija: Kan jeg bare spørre deg – du sier fastlege prosjektet, men hva betyr det? Er det liksom det det fastlegen bruker når vi kommer til fastlegen og han skal registrere? Hva er prosjektet?
Kjetil: Prosjektet skulle da lage en ny fastlegeordning, og det omhandler når du og jeg skal bytte fastlege så kan du gå inn på Helsenorge og bytte fastlege der. Så det var den ene biten av det. Den andre biten av det var jo det å sørge for at alarmfunksjonene, altså politiet, sykehus også videre hadde riktig informasjon folk og fastlege. Det tredje var at det er kommunen som ansetter fastleger. Så der var kommunen involvert i dette. Det handler også om at fastlegene skulle følge regelverk og få betaling per pasient. Så det var den ene biten av det. Det var veldig mange biter det handlet om, da.
Silvija: Både stort prosjekt og hørs ut som mange stakeholders. For du nevnte e-helse og kommuner?
Kjetil: Og ja, veldig mange stakeholders. Så kompleksiteten i det når du har mange stakeholders øker jo betraktelig. Og det var også litt drakamp om hvor mye skal ligge hos e-helse og hvor mye skal ligge hos Helsedirektoratet og hvor mye skal ligge hos NHN. Hvor alle har sine interesser på hvor man skal bygge de ulike komponentene, da. Men eierskapet lå hos Helsedirektoratet. Men det som er interessant med dette prosjektet var at det var et prosjekt som begynte veldig dårlig. Man hadde jobbet med prosjektet i veldig mange måneder. Også var det også et prosjekt som hadde en endelig dato. Den datoen der som var et år frem i tid så måtte man skru av den gamle løsningen hos NAV, og da måtte den nye løsningen være ferdig. Hvis man ikke nådde den datoen så var det straffe kostnader på ganske mange millioner kroner og konsekvensene var store. Så det var ikke noe rom for å feile. Etter fire måneder så så man at fremdriften i prosjektet var kjempedårlig. Man hadde egentlig brukt veldig mye tid på å diskutere, planlegge også videre, men man hadde egentlig ikke laget noe. Så man begynte å bli bekymret for om man skulle komme i mål eller ikke med prosjektet. Og i den fasen så jobbet jeg som en ren programmerer utvikler i prosjektet. Og jeg stilte litt spørsmålstegn fordi det var prat om at man skulle få på plass en servicebuss, en integrasjonsarkitektur. Så sa jeg da hvorfor dra inn den kompleksiteten inn i prosjektet. Jeg stilte litt spørsmålstegn ved det da. Og da var det en litt fremoverlent avdelingsdirektør som heter Richard Åstrand som så at dette var feil vei. Og da gjorde vi om litt i organiseringen av prosjektet. Og da fikk vi et mandat på at dere skal tenke annerledes. Ikke gjør ting som det er gjort før. Også skal dere få til ukentlige releaser. Det var de to tingene han sa til oss. Så da tok vi rett og slett de folkene som jobbet på prosjektet og flyttet dem fysisk fra alle andre utviklere. Vi flyttet dem ned i kjelleren slik at man kunne begynne å bygge en kultur på dette basert på DevOps prinsippene. Hvor man skulle levere kontinuerlig hele tiden. Man skulle lære å feile. Så da flyttet vi de fysisk ned i kjelleren bort fra de andre teamene. Dette var veldig, veldig konfliktfylt fordi man var vant til å ha fire realeaser i årete. Man hadde en veldig sterk test kultur hvor man hadde brukt mye tid på å lage strategier og dokumentere de ulike prosessene også videre som ikke passet med den tankegangen vår om at vi skulle gjøre dette kontinuerlig. Så det var litt snørr og tårer og mange harde konflikter for å få det til. Og det var folk som sa at når jeg sa vi skulle levere en gang i uken, så lo dem av det. Det hadde dem ikke noe tro på. Og vi brukte det året på å lære å feile og få dette til. Men vi hadde veldig troen på de prinsippene vi jobbet etter. Vi jobbet etter noen Lean prinsipper. Vi jobbet etter – den gangen kalte vi det ikke DevOps, men jeg vet at DevOps begynte å bli et buzzword den gangen. Men det var ikke det som var fokuset vårt. Fokuset vårt var å levere en gang i uken. Men resultatet av dette var at vi klarte å levere fastlege-prosjektet på både tid og kostnader som egentlig var ganske imponerende i seg selv sett på tidshorisonten. Og kvaliteten på det vi leverte var veldig bra. Og det var veldig lett å sammenligne fastlege mot alle de andre prosjektene som var i helsedirektoratet. Og de andre prosjektene som jobbet litt tradisjonelt. Fordi når vi leverte prosjektet så gjorde vi en verdistrømsanalyse og det viste seg at DevOps teamet, fastlege teamet var 70% mer effektivt enn de tradisjonelle teamene.
Silvija: Jeg må stoppe deg nå, for nå er det kjempe tettpakket med spennende info her. Så du må forklare oss litt om hva er verdistrømsanalyse også er jeg veldig fascinert over 70% mer effektivitet. At man får ut mer sunn kode enn andre på samme tid. Altså 70% på samme tid eller noe. Teller man da antall linjer koder eller hvordan måler man effektivitet? Og det viktigste spørsmålet mitt er egentlig hvordan deler man den elefanten i biter? For det å bestemme seg for å levere noe hver uke har en ekstrem konsekvens for planleggingen og det er at du må vite hva disse ukentlige bitene er. Og det må være kjempevanskelig å definere?
Kjetil: Ja, mange spørsmål her. Hvis jeg går først til verdistrøms analysenn da. Så er rett og slett det en analyse av hvor mye funksjonalitet vi klarer å levere av teamet. Hvor vi bryter ned i små biter også ser vi på tidstyver. Fjerner alle tidstyver. Så det betyr at når DevOps teamet begynner på en oppgave, en funksjonalitet – så er den 70% mer effektiv på å få dem ut i produksjon kontra et tradisjonelt team. Det var det ene vi så. Det andre er at ingen team er feilfrie. Vi leverer feil og mangler, men det vi så i DevOps teamet var at vi blir helt kvitt A-feil, altså kritiske feil. De kom ikke ut i produksjon. Men vi hadde fremdeles B- og C-feil som var mindre alvorlige feil. Det hadde man fremdeles, men det var mye mindre av det. Og dette er også noe som bekreftes gjennom denne DevOps report hvor man har testet veldig mange team som har jobbet på den måten. Men jeg vet ikke om det var en forklaring på verdistrøms analysen, også hadde du også noen andre spørsmål inni der?
Silvija: Ja, verdistrømsanalysen hvis jeg forstår deg riktig, så har dere forstått nødvendig funksjonalitet og hvordan den henger sammen også har dere klart å levere 70% raskere målt på funksjonaliteten. Så det svarte du på og dette med hva måler man og hvordan tenker man på effektivitet i programmeringsprosjekter. Men litt sånn om hvordan finner man disse by size* da? Hvordan deler man disse i biter? Hvis man sier at vi skal gjøre noe, vi skal levere noe hver uke, så kan jeg se for meg at den planleggingsoppgaven er kanskje det mest krevende i hele prosjektet?
Kjetil: Den er kjempe vanskelig og utfordrende. Vi visste hva vi skulle levere på slutten totalt sett. Men det er også å dele opp den elefanten i småbiter som er kjempevanskelig. Og en veldig viktig bit for å lykkes med DevOps fordi du må dele den opp i små nok biter for at teamet skal kunne levere hver uke. Hvis biten er for stor betyr det at vi bruker lengre tid på å lage den og da klarer vi ikke målet på hver uke. Så det krever veldig mye disiplin for å gjøre det. Så tror jeg også at man kanskje må gi litt slipp på kontrollregimet. Rett og slett begynne å lage noe å få det ut er en viktig ting. Man trenger ikke å detaljplanlegge så mye som man kanskje gjorde før. Og der ligger også noe av effektiviteten og verdien i DevOps fordi vi ser på det konkrete av teamet leverer. Også bruker vi noe som heter Story Points som gjør at vi sier ikke at en oppgave tar 20 timer. Vi ser at denne oppgaven her bruker vi ca. to Story Points på, også sammenligner vi den. Den oppgaven her er dobbelt så stor så da bruker vi fire Story Points på den.
Silvija: Det er prosjekt valuta.
Kjetil: Ja, vi har prosjekt valuta. Og vi vet ikke noe om et Story Point er 10 timer eller 20 timer. Men etter hvert som vi begynner å bli god og får ting til å rulle så vet vi at det teamet her er i stand til å levere 20 story points i løpet av en uke. Så vet vi kanskje at det andre teamet er i stand til å levere 15 story points i teamet i løpet av en uke. Og vi må gjerne la det gå en måned og kanskje to måneder før vi klarer å sette den farten. Men etter hvert når vi har klart å sette farten så vet vi hvor mye vi klarer å levere. Og da er det også lettere å planlegge og se hvor langt vi klarer å komme frem til 1. juli som er vår dato hvor vi faktisk må ha dette i produksjon. Men det handler om å gi litt slipp på dette. Du vet ikke alt på forhånd. Men vi baserer ting basert på fakta. Hva vi faktisk klarer å levere. Og etter hvert som vi klarer å levere klarer vi også å forutsi hvor mye vi klarer å levere frem til 1 juli eller den datoen som vi hadde satt, da.
Silvija: Veldig spennende, fordi dere finner ut oktanen til de forskjellige teamene også justerer dere oppgaver sånn at de klarer å levere i disse ukentlige rytmene. Det er nesten sånn at alle puster i samme fart og man synkroniserer teamet på et vis med dette.
Kjetil: Ja, man gjør i grunnen det. Også er det sånn at hvert team er selvstendig, men det vi også fant ut er at vi hadde jo et frontend utviklingsteam også hadde vi et backend utviklingsteam. Og da fant man ut etter hvert at disse teamene synes det var veldig spennende å konkurrere, så de konkurrerte litt om hvem var det mest effektive teamet da. De målte effektiviteten på teamet også var vi veldig opptatt av synlighet på der vi leverer. Så da fikk vi litt konkurransesituasjon på det og det ga en ekstra motivasjonsboost.
Silvija: Et siste spørsmål om dette eksempelet. Hvordan fikk dere da teamene til å også samarbeide og lære fra hverandre? Hvordan får man dette til å bli en helhet og ikke bli mange flotte hester som løper hver sin vei?
Kjetil: Nei, det handler mye om ledelse rett og slett. Hvor vi er flinke til å kommunisere hva som blir gjort. Vi er flinke til å skryte av de teamene som leverer og folkene som leverer bra. Vi skryter aldri av enkeltpersoner fordi superhelter er en ting man ikke skal ha. Som er tvert i mot DevOps prinsippene. Men det teamet og vi sammen som leverer og sammen som tar ansvar på ting. Så lager vi møteplasser med for eksempel demoer. Vi hadde demoer en gang i uka. Vi hadde tekniske demoer en gang i uka hvor alle de interne folka og alle utviklingsteamene sammen demonstrere hva man hadde gjort med fokus på nerdebiten, den tekniske. Så hadde vi også med litt lengre mellomrom funksjonelle demoer hvor alle de som skulle bruke systemene fikk lov til å se produkteiere også. Fikk se hva er det teamet har levert og hva er det de har laget. Og det ga en veldig sånn tillit følelse når de så at de siste 14 dagene så har teamet gjort kjempemye. Det ser bra ut også har man noen meninger om at den fargen der likte vi ikke også videre. Da fikk man feedbacken fra brukerne også. Så vi laget noen sånne arenaer hvor vi kommuniserte også laget vi også noen nyhetsbrev og litt sånn. Ha åpen og god kommunikasjon. Kommunikasjon er det vanskeligste du driver på med, men det er også det viktigste for å lykkes i et prosjekt. Og da tror jeg det er uavhengig om det er DevOps eller agilt eller fossfalt kommunikasjon. Det er liksom nøkkelen til dette her da.
Silvija: Kjempespennende. Jeg noterer meg egentlig allerede noen ting som jeg tror vi må begynne å innføre i LØRN. Vi kommer tilbake til denne lille workshopen vår i siste leksjon. Jeg sitter å tenker at vi har verdens flinkeste CTO og utrolig bra utviklingsteam som jobber etter disse veldig moderne metoder. Men vi får så mye støy fra ledelsen fra resten av organisasjonen som bråker om pitcher og krav også videre. Og hvor mye roligere organisasjonen kanskje hadde vært om vi hadde fått en ukentlig demo. Og se det nye vi har gjort denne uken, ikke sant. Det er noe med å lære opp resten av organisasjonen også involvere dem.
Kjetil: Ja, og det er den viktigste biten og faktisk også den vanskeligste biten å få til fordi det å gi slipp og tillit til folk er vanskelig. Du må stole på at de faktisk gjør jobben sin, men når du har demoer og viser at du faktisk klarer å levere så får du den tilliten. Og du får også den tilliten når du leverer god kvalitet. Og leverer du ikke god kvalitet så mister du den tilliten. Så det er ekstremt viktig dette med at det må være kvalitet i alle ledd. Og for å få kvalitet så handler det om at du må automatisere dette. Litt sånn tradisjonelt sett så har vi utviklere laget noe, også sender vi det til test også tester dem de tingene du lager. Det er litt sånn “”shift left”” DevOps, som betyr at utviklerne må begynne å lage automatiske tester på ting. De må begynne å lage automatiske sjekker av kodekvalitet. Vi må ha automatisk sjekk av funksjonalitet også videre. Og dette var en av de tingene som vi hadde kjempekrasj på i fastlege-prosjektet. Test ville ikke ta i mot det utvikling hadde laget fordi dette var ikke i henhold til dens strategi og rutiner. Så vi fikk ikke lov til å levere til tst fordi det var ikke i henhold til det tradisjonelle. Og det vi gjorde da var å lage et nytt miljø som vi kalte for automatiske A-test miljøer. Så sa vi til test at se her, vi hører hva ere sier. Vi er ikke enig med dere, men hver uke klokken da og da så er det en ny versjon i dette A-test miljøet. Dere er velkommen til å teste og se på det vi lager. Og vi sa også til alle de andre teamene rundt at dere kan begynne å bruke dette. Det har vi laget. Vi vet at det er ikke verifisert av test, men vi jobber med den saken. Men at dere bruker det og da får vi en form for feedback*. Så det tok ganske lang tid, men vi fikk inn en innovativ testleder og plutselig så løsnet den kabalen der. Da hadde vi samme mål om ukentlige leveranser og vi jobbet på samme side i stedet for å jobbe mot hverandre. Dette var noe kulturell krasj mellom test og utvikling hvor man ikke var enig med hverandre. Så det var en veldig tøff og vanskelig oppgave å løse.
Silvija: For noe av den viktigste effekten av å innføre disse nye ledelsesmetoder er vel egentlig alltid at det er en stor kulturendring i måten man planlegger og måler suksess også videre. og det er derfor det er så krevende, men også nødvendig. Hvis vi bruker noen veldig få minutter på å fortelle oss om kanskje et eksempel til. Hva ville du valgt?
Kjetil: Nei, hos Kværner så leverte vi en mobil løsning. Og egentlig skal jeg gi et annet eksempel, for jeg hadde flere prosjekter hvor vi leverte DevOps som var kjempe suksess. Det ga meg veldig gehør internt i organisasjonen. Etter at vi hadde levert første prosjektet så var det veldig mye enklere å levere andre prosjekter for da var det ingen motstand mot oss. Alt gikk av oss selv. Så jeg hadde tre-fire prosjekter med kjempesuksess. Også kom jeg over til bank, også tenkte jeg det at nå skal jeg bruke de samme prinsippene fordi dette har jeg klart å få til før og det har vært kjempe suksess. Så kom jeg til bank og vi skulle levere et større ERP-prosjekt, og vi feilet totalt. Det fungerte ikke i det hele tatt. Alle disse fine flotte prinsippene. Den oppskriften jeg hadde brukt før bare funket ikke.
Silvija: Og det har noe med kultur regimet versus måle regime eller hva er din analyse av hvorfor?
Kjetil: Det var en kulturkrasj hvor man jobbet mot og hadde en negativ kultur hvor de ulike teamene jobbet mot hverandre i stedet for med hverandre. Vi jobbet ikke mot felles mål. Og jeg tror mye av det skyldes at vi ikke leverte kontinuerlig. og fordi vi ikke leverte kontinuerlig så mistet vi den tilliten fra kunden. Kunden visste ikke hva han fikk. Det var noen møter innimellom som sa at dette ønsker jeg og vi skal lage det. Så så han ikke det resultatet han faktisk ønsket. Også var det også sånn teknologi krasj fordi vi bygde dette på ferdig produkt og skreddersøm sammen. Og de som tenker ferdig produkt er lært opp til at inni denne boksen vår så kan vi løse alle verdens problemer. Så har du de som tenker skreddersøm med at vi kan løse alle verdens problemer med vår teknologi. Så ble det en kamp mellom boks programmene og de som var skreddersøm programmererne som vi ikke tok alvorlig nok. Og som vi ikke klarte å få løst på en god måte. Så det var veldig interessant læring og en skikkelig på snørra. Man begynte å bli litt høy på seg selv fordi man hadde lykkes. Også klarte man ikke å få til den greien der.
Silvija: Det er ikke alltid det funker og kanskje det er også noe med at det ville funket over tid, men det ville tatt så lang tid. Eller hva tenker du?
Kjetil: Jeg tenker det at det du sier der er veldig viktig fordi kulturendringer skjer ikke over natta. Du må la det modnes i organisasjonen. Du må la det ta litt tid. I helsedirektoratet så brukte vi ett år på å få til den biten der. Andre plasser så har jeg opplevd at det får vi til bare med en gang. Men å endre på kultur og endre på holdninger er noe av det vanskeligste vi gjør og da må vi ta tiden til hjelp og ha fokus på det. Men litt av årsaken til at vi feilet i det bankprosjeket tror jeg og var at vi var ikke tro til våre prinsipper. Så en av de prinsippene er at vi skal prodsette en gang i uken. Og vi skal automatisere alt. Men vi fulgte ikke prinsippene med å prodsette en gang i uken. Så da tror jeg kanskje at hadde vi vært mer tro mot prinsippene så hadde vi kanskje fått det til. Og det var vanskelig fordi organisasjonen motarbeides og skulle prodsette en gang i uken, men da tenker jeg at vi trenger ikke å prodsette til produksjon. Vi kan si at i den fasen vi er i nå så prodsetter vi til et QA miljø. Også øver vi på å bli god på DevOps. Og det var det vi gjorde i fastlege prosjektet. Vi skulle ha et år frem i tid, men vi øvde hele tiden på å bli god på det og release en gang i uken. Men jeg har tenkt mye på hvorfor vi feilet og grubler stadig over det, men det var en viktig lærepenge å få seg. Det er ikke alltid den suksess oppskriften du bruker en plass fungerer en annen plass. Man må tilpasse seg også organisasjonen man er i da.
Silvija: Jeg har lyst å kaste inn to mulig faktorer, hvis jeg bare kunne tatt det fort. For vi må lande denne leksjonen snart. Tror du det er nødvendig å ha en sterk støttespiller i ledelsen og tror du at det helseprosjektet hadde en slags styrke i seg på at man måtte bare bli ferdig? Det var ikke noe annet alternativ enn å få det til?
Kjetil: Jeg tror at den største nøkkelfaktoren var mandatet vi fikk fra toppledelsen om at dere skal levere en gang i uken og dere skal tenke annerledes. Uten det mandatet så ville vi aldri ha lykkes med den biten. Så ja, du må ha en forankring fra toppledelsen, og toppledelsen må forstå verdien av hvorfor man skal gjøre det litt annerledes da.
Silvija: Veldig spennende. Tusen takk for spennende og gode eksempler så langt, Kjetil. Vi møtes om noen få minutter for å snakke om verktøykassen.
Du har nå lyttet til en podcast fra Lørn.Tech – en læringsdugnad om teknologi og samfunn. Nå kan du også få et læring sertifikat for å ha lyttet til denne podcasten på vårt online universitet Lørn.University
“
“
Velkommen til LØRN.Tech – en læringsdugnad om teknologi og samfunn med Silvija Seres og venner.
Silvija Seres: Hei og velkommen til LØRN Fundamentals i DevOps med Kjetil Kværne fra Forte Digital. Eller egentlig Forte Technology fra Forte Digital. Nå er vi i leksjon tre, og nå skal Kjetil lære meg og lære dere om noen verktøy som man kan bruke når man skal begynne å anvende DevOps. Hvor begynner vi Kjetil?
Kjetil Kværne: Vi kan begynne med den enkle biten som er den tekniske verktøykassa vi har. Fordi i den tekniske verktøykassa så handler det om at vi har verktøyene for å automatisere alt slik at man har minst mulig manuelle prosedyrer eller manuelle gjøremål.
Silvija: Bare så jeg skjønner det så er det program biter som lager en slags software skjelett som du kan koble på de forskjellige utviklings bitene på? Eller?
Kjetil: Ja, litt sånn ferdig komponenter som vi drar i å bruke når vi utvikler programvare og i forhold til programvare prosessen. For eksempel ett av verktøyene som jeg er veldig glad i er et verktøy som heter Azure DevOps. Veldig dårlig navn på det verktøyet fordi det har egentlig ikke noe med DevOps å gjøre, men det er et verktøy som hjelper oss med å holde styr på prosessen. Dette med backlog og oppfølging av estimater og det å få ting ut. Det verktøyet har også kildekodekontroll. Altså Git. Det har også det vi kaller for pipelines som hjelper oss med å automatisere og dette med å bygge koden som sier at når utvikleren sjekker inn kode så har vi automatisert pipelines som bygger koder og sjekker at den faktisk funker på andre maskiner enn utviklerens maskin. Den kjører også automatiske tester også lager den automatisk infrastruktur og alt som trengs og gjør det enkelt for prosjekteieren. Den kan bare trykke på en knapp også får den den nye versjonen. Så det har veldig mye funksjonalitet og den har også funksjonalitet for automatisk kvalitetskontroll på sikkerhet og kodekvalitet og masse sånn type ting. Så det er verktøy du må ha i bånn for å kunne få til dette med kontinuerlige leveranser. Jeg nevnte Azure DevOps, men det finnes også GitLab, Atlassian, Jira og BitBucket og en del sånne type ting som gjør det samme. Her har du mange leverandører av den type verktøy som du kan bruke. Men den tekniske verktøykassen er egentlig den enkleste biten. Man må bare bestemme seg for hvilken type verktøykasse man skal bruke.
Silvija: Kan jeg spørre deg, for hvis det er noen programmerer som hører på dette – hvis det er ikke-programmerere så tror jeg ikke de bryr seg så veldig mye om akkurat denne delen. Men hvis det er programmerere og de ikke har brukt disse verktøykassen, hvor går man for å både og anvende? Er det Coursera kurs? Er det Github? Hva gjør man?
Kjetil: I utviklere verden så er flink veldig flinke til å dele kunnskap. Det finnes masse på Youtube rundt da. Du har også profesjonelle kursleverandører som har kurs i det. Konsulentselskapene som blant annet Forte leverer også kurs på bruk av verktøyene, da. Men ofte så opplever jeg at kundene som vi er hos har verktøyene på plass allerede, også opplever jeg at dem kanskje ikke er like god til å bruke verktøyene. Og bruker de litt feil. Og som du nevnte i sted med å dele opp elefanten. Så er jo den typiske tingene man gjør feil at man lager alt for store brukerhistorier slik at det ikke er sjanse til å levere det på kort tid. Også er man heller ikke nøye med å definere kvaliteten på det som skal lages. For utviklerne må vite hvordan kvalitet han skal levere. Hvordan ting skal funke. Men da er man over på den viktigste biten. Den tekniske verktøykassa er enkel, men den viktigste biten er jo dette med verktøykassa på prosess. Hvordan kan du ha en verktøykasse som sørger for at du følger DevOps prinsippene og klarer å levere den gode kvaliteten. Og en av de metodene jeg er glad i er Kanban som sier noe om at man har en prosess for å følge en funksjon fra ide til den er ute i produksjon. Og der har du også sånne viktige prinsipper som Wip Limit som sier at du sier en limit på teamet får kun lov til å jobbe med fem oppgaver på en gang. Hvis det er sånn at man tar inn den sjette oppgaven så vil boardet lyse rødt. “”Hei, her har du gjort noe gærent””. Og da er prinsippet at da skal teammedlemmene som er ledig skal da i stedet for å begynne på ny oppgave, så skal de løpe å hjelpe de andre som driver på med det slik at vi har fokus. Vi beholder fokus på det vi faktisk skal levere. At vi ikke tar inn for mange ting. For dette er et av de største problemene innenfor agile at vi gjør for mange ting om gangen. Vi gjør oss ikke ordentlig ferdig med det fordi det er alltid noen hindringer eller noe sånt som stopper oss, også blir oppgaven stående på vent. Og hva er det som skjer med oss mennesker når vi har for mange ting å tenke på? Da går det bare i surr, også blir vi mindre effektiv i stedet for å fokusere på at denne oppgaven skal jeg gjøre ferdig. Jeg begynner ikke på noe ny oppgave før dette er ferdig. Så det er den viktigste biten. Dette med enkel endringsprosess, at ledelsen legger til rette for at det ikke skal være et stort byråkrati med godkjenninger, kontrollapparater også videre for å få til en endring. Det er en av de største showstoppere jeg ser for å lykkes med kanban. Det er veldig mange som skal mene noe og være involvert i prosessen ved å gjøre en endring. La oss si at du lurer på om den knappen her skal være rød eller blå. Og hvis det er veldig mange som skal mene noe om det, hvorfor ikke bare basere dette på fakta? Hvorfor ikke bare lage en rød og en blå knapp også kjøre det ut også har du halvparten av brukerne som får se den rød knappen og halvparten av brukerne som får se den blå knappen. Også får du feedback på hva brukerne synes? Da har du fasitsvaret på hva som faktisk er riktig i stedet for at veldig mange skal diskutere på forhånd om den skal være rød eller blå. Så enkel endringsprosess, brukerorientert er jo den viktigste greien. Arkitektur er veldig viktig i verktøykassen vår. Skal du lykkes med DevOps så må du basere deg på et godt fundament, en god plattform. Og da liker jeg å referere til det vi kaller mikro basert arkitektur. Det er mulig det blir litt teknisk nå, men mikro basert arkitektur kontra monolittisk arkitektur som har vært veldig vanlig frem til nå. Forskjellen der er at det er en monolittisk arkitektur så er det sånn at hver gang du releaser noe så er det en risiko for at hvis du gjør en feil så berører det hele systemet. At hele systemet går ned. I en mikro basert arkitektur så er det selvstendige komponenter som sier at hvis du gjør en feil så påvirker det kun den ene komponenten. Så da er risikoen veldig lav hvis du gjør en feil. Så arkitektur i bånn her er også en veldig viktig ting at man har fokus på, da.
Silvija: Dette med fleksibel arkitektur er noe som vi har diskutert veldig mye i LØRN. Hvor vi har prøvd å bruke en del eksterne biblioteket for å lage disse såkalte LMS’er eller som nå heter LXP’er. Learning Management System eller Learning Experience System. Men det blir så veldig fort låst inn i en litt for monolittisk arkitektur, og du får kanskje tilgang til noe av aspektene ved dataene, men det er også veldig låst til systemet. Så vi har funnet ut at hvis vi skal bygge noe som er fleksibelt nok så må det være mikrotjenester og en sånn modulær komponent basert arkitektur. Det som jeg sitter å tenker på nå Kjetil er at du snakker egentlig om masse progammeringsrealterte begreper, men hvor viktig er det for ledelsen å forstå i hvert fall overflaten hvordan disse begrepene henger sammen, nettopp for å klare å gi det mandatet til utvikling til software teamet sitt. Og nå er det sånn at alle bedrifter holder på å bli software bedrifter, så mens man programmerer hele businessen så må ledelsen ha dette språket innebord selv om de er økonomer og selv om de er noe helt annet for å kunne samarbeide med de som bygger softwaren.
Kjetil: Ja, og det er det viktig. Før så var det veldig populært med såkalt Togaf kurs som var en sertifisering av arkitekter. Og det som var der var at arkitektene skulle få et felles språk slik at man kunne prate sammen. Og jeg tenker i forhold til ledelse er det også veldig viktig å ha et felles språk, også er det litt vanskelig fordi i en sånn maktkultur så er det veldig lett for teknologer å begynne å bruke masse tekniske termer. Og her er du inne på læringskulturen. Fordi folk er redd for å stille dumme spørsmål. Man har ikke forstått det. Jeg kan nevne et eksempel fra da jeg var fersk utdannet programmerer og hadde min første jobb. Så satt jeg i et møte med 15 mann, også satt alle å pratet om iterasjoner. Og iterasjon en og ditt og datt. Og jeg satt å klødde meg i hodet og tenkte hva er iterasjon? Det betyr jo bare en gjentagelse? Hva legger de i det? Men som ung utvikler så tør du liksom ikke å spørre. Også til slutt så tok jeg motet til meg og spurte hva betyr iterasjon en? Hva legger dere i det? Og vi hadde brukt en halvtime på å prate om iterasjoner og det var ingen rundt bordet som egentlig kunne svare på hva dem egentlig pratet om.
Silvija: De mente utgave en og utgave to, men det var for enkle ord.
Kjetil: Ja, de som satt rundt bordet pratet om iterasjon, men den ene mente noe annet enn den andre. Så man pratet ikke samme språket. Men jeg tenker at ledelse og det å finne et felles språk er en ting. Også kan jo ledelsen også stille spørsmål, ikke sant. Når du lager noe, hva er konsekvensen hvis du lager det på den måten? Hvis du feiler? Hva er konsekvensen hvis du feiler med den? Si at det er en risiko for at hele fastlegeordningen går ned, så vet du at du kan stille spørsmålet om vi kunne laget det på en annen måte? En mer fornuftig måte? Men det er vanskelig det der, fordi vi er veldig opphengt i buzzword. Også drar vi rundt på store konferanser og sånt. Et eksempel på det er at de siste årene har vi pratet veldig mye om containere og kubernetes og docker. Og jeg registrerer at noen som går rundt å holder foredrag om DevOps prater om DevOps og containere. Og containere er kjempebra. Kan absolutt brukes i en DevOps sammenheng. Men det er absolutt ikke noe forutsetning for å gjøre det. Og jeg ser at containere er en kompleks teknologi. Og det er mange prosjekter som ser opp til Google og Netflix og alle disse store som har brukt containere og har lykkes med det. Men hva krever det? Jeg har opplevd at kunder sier at vi må ha containere også spør jeg dem hvor mange mann har du til å drifte de containerne? De har team på tre mann. Og sånn som NAV har et stort team som kun fokuserer på containere. Og da blir det helt feil å bruke det i en sammenheng hvor de ikke har de type ressurser.
Silvija: Men nå som en avdanket programmerer skal jeg innrømme noe helt upassende på live. Men tingen er at jeg tror en del av oss bruker disse ordene bare for å bløffe litt og late som vi kan noe om DevOps og moderne programmeringsmetodikk. Så jeg tror kanskje at igjen det man trenger er en litt ærlig opplæring på hva er greia med containere? Hva er Kubernetes? Så hvis du går gjennom de tre tingene du nettopp sa og prøver å forklare oss veldig enkelt hva er greia med det? Jeg digger å si at nå bygger vi en lagdel arkitektur og vi er så mikrotjeneste basert også bruker vi containere.
Kjetil: Ja, og containere er kjempefint fordi du kan lage programvare også kan du putte det i en container også kan du ta med den containeren hvor som helst og kjøre.
Silvija: Det er en pakke?
Kjetil: Det er en pakke som har absolutt alt som trengs for å få den komponenten til å kjøre. Og da høres det veldig fint og flott ut for da kan du ta med deg containeren om du skal kjøre i Amazon eller på Azure, uansett hvor du er. Så kan du bare ta med deg containeren også funker det med en gang. Og den ideen synes jeg er bra og jeg liker den. Men kompleksiteten med å bygge disse containerne. Kompleksiteten med å få containerne til å prate med hverandre. Den tror jeg veldig mange undervurderer. Og alternativet til disse containerne er mangement tjenester hvor du for eksempel sier til sky leverandøren at du ønsker å fokusere på funksjonalitet. Jeg skal lage de og de tingene. Også kan du fungere på alt det avanserte med plattform og containere. Så lager du bare funksjonalitet og pusher det opp til tjenesten i der. Og der mener jeg at det er for mange bedrifter som bruker for mye ressurser og penger fordi dem har hørt at containere er løsningen på alt. Og de viser til at de store som har lykkes med det. Om Netflix lykkes med det er det ikke sikkert det er riktig strategi for din bedrift. For skal du ha en container plattform så må du ha et team som er spesialister på det og som jobber med det. Grunnen til at Nav har lykkes med containere er fordi de har satt av og har penger og ressurser som har kun fokus på den teknologien.
Silvija: Å skyte spurv med kanonens sier du. Og jeg tenker det å kunne ha en sånn forklaring kunne hjulpet utrolig mange bedrifter, men så er det en del konsulentselskaper som kanskje synes at det er greit å bruke containere fordi det blir større prosjekter og mer penger.
Kjetil: Ja, bukken som passer havresekken. Og det ser jeg ofte hos kunder at her er det konsulentene som har styrt teknologien. Og jeg var hos en kunde hvor dem hadde absolutt alt av teknologi. Alt av nyeste og fancy ting. Dem brukte fire-fem forskjellige kodespråk. Dem brukte tre forskjellige bygg servere også videre. Og de stakkars faste ansatte som skulle drite dette hadde jo ikke sjanse fordi dem hadde ikke sjanse til å lære seg alt. Mens konsulentene brukte dette til å bygge CV. Og lære seg nye ting. Jeg må innrømme at som teknolog så synes jeg jo det er moro å lære nye ting. Lære nye kodespråk. Og synes jeg også at i DevOps så bruker man gjerne begrepet autonome team. Og autonome team betyr at du gir teamet tillit til å kunne velge selv og ta avgjørelser også videre. Og det synes jeg er en veldig bra ting. Men jeg synes også at du må sette noen rammer for det teamet her. Jeg kan jo nevne at nå i Forte har vi fått inn en bachelorgruppe som skal lage en mobil løsning til oss. Men de har fått veldig klare rammer på at dere får lov til å ta avgjørelser selv, dere kan velge ting, men innenfor de rammene. Og rammene våre er at dere skal lage det på Azure som skyplattform. Og dere skal bruke .NET som teknologi. Men innenfor det kan dere gjøre det dere ønsker. Da har vi gitt dem noen grove rammer som vi som bedrift trenger, for når de er ferdig med det produktet så vet vi at andre skal overta og gjøre det og da må vi vite at vi har kompetanse på at noen kan ta over og vite at vi får driftet det på vårt foretrukne innenfor vår plattform.
Silvija: Ja. Jeg tror i tillegg til containere så tror jeg at hvis jeg husker riktig at du nevnte kubernetes og .NET?
Kjetil: Ja, .NET er jo en utviklingsplattform hvor du skriver kode med C# eller F# eller noe sånt. Men det er rammeverk som er enabled til å bygge ting kjapt og effektivt. Kubernetes er jo noe av det vi pakker inn i en docker container, også sender vi den docker containeren kanskje til Kubernetes som administrerer mange containere, da.
Silvija: Hva er en Docker container?
Kjetil: Docker er en container teknologi. En måte vi pakker programvaren inn i den containeren, da.
Silvija: Du aner ikke hvordan jeg skal imponere mannen min i kveld. Må utfordre ham littegrann på den siste koden han har skrevet. Veldig bra. Hvis jeg skal oppsummere denne samtalen, så har vi snakket det om to typer verktøy. Det første gikk på at det finnes teknologi, biblioteker, software som hjelper til med å automatisere prosesser og automatisere testing. Det finnes biblioteker som du kan bruke for å komme i gang raskt med DevOps. Men det vanskeligste og det viktigste her er prosessinnovasjon, og der har jeg notert meg Kanban som går på helhetlig tankegang, men det viktigste jeg har hørt deg si der er bit limit og fokus sånn at man virkelig disiplinerer seg til å tenke en uke om gangen på en realistisk måte. Jeg har hørt deg snakke mye om brukerorientering, endringsprosess og ikke minst arkitektur. Jeg tror det poenget med at før så hadde man arkitektkurs for å samle IT arkitekter rundt samme språk, at det er noe som vi kanskje etterhvert må lære opp folk som ikke er programmerere i også. Som er helt basic. Hva er et lite arkitektur og hvordan henger det sammen og hva kan du mene noe om og hva kan du ikke mene noe om?
Kjetil: Det var godt oppsummert, da.
Silvija: Veldig bra. Da sier vi tusen takk for denne tredje leksjonen om gode verktøy, også skal vi møtes om noen minutter for vår aller siste minileksjon på ti minutter hvor du hjelper meg å tenke litt om hvordan jeg kan få brukt dette i mitt lille selskap.
Du har nå lyttet til en podcast fra Lørn.Tech – en læringsdugnad om teknologi og samfunn. Nå kan du også få et læring sertifikat for å ha lyttet til denne podcasten på vårt online universitet Lørn.University
“
“
Velkommen til LØRN.Tech – en læringsdugnad om teknologi og samfunn med Silvija Seres og venner.
Silvija Seres: Hei og velkommen til LØRN Fundamentals i DevOps med Kjetil Kværne. Dette er vår fjerde og siste leksjon og dette er et lite verksted. Settingen og scenarioet er at jeg er en leder i en SMB og vi er et teknologiselskap. Vi bygger en digital plattform og jeg trenger litt mentoring Kjetil. Jeg har virkelig verdens beste CTO. Vi har veldig flinke folk som kan tenke lagdelt, de kan tenke modulært, vi bruker de nye bibliotekene og verktøyene. Det er forresten en læring vi har hatt hvor vi hadde folk som ikke kunne noe av dette. Og de lagde monolittiske systemer som vi brukte masse penger på og måtte forkaste egentlig før de kom ut av starten. Men jeg merker at jeg roter det til for dette gode utviklingsteamet ved å komme inn å si at nå trenger jeg at dere fokuserer på student opplevelsen og det er akkurat denne siden av det, også trenger jeg at dere fokuserer på ditt og datt. Jeg kunne tenkt meg at du lærer meg nok om DevOps til at jeg vet hvordan jeg skal riktig snakke med dette fantastiske utviklings teamet mitt.
Kjetil Kværnes: Ja. De første du kan begynne med er å sette DevOps på kartet og si at dette er sånn vi ønsker å jobbe. Dette er vår filosofi. Som leder er det viktig at du kommuniserer deg klart og tydelig overfor teamet om at dette er vår foretrukne måte å jobbe på. Det er det ene. Og det andre er at du også setter fokus på at teamet skal levere kontinuerlig. Det kontinuerlig begrepet er så sentralt inn i DevOps og det er veldig lett å måle også hvis du sier til teamet ditt at du ønsker en ny funksjonalitet også sier teamet ditt at ja, da tar det fem uker. Da kan du stille spørsmålet om at tenker vi ikke DevOps? hvordan kan vi få en kontinuerlig leveranse på dette? Kan vi bryte det opp i småbiter og levere forløpende? Det er den ene biten av det. Også tenker jeg at synlighet er en viktig greie i DevOps. At du som leder engasjerer deg litt i teamet. Det er ofte motiverende. Og det er også litt morsomt å se. For eksempel i teamet som vi leverer så pleier vi å ha automatisert kodekvalitet og si at som leder så er du ikke interessert i det kodeteksniske språket. Det gir deg antageligvis veldig lite. Men hvis du kan få opp et dashboard som sier at den koden her er grønn på kvalitet og rød på sikkerhet, så er du i en posisjon til å skryte av teamet når dem leverer godt. Du er også i en posisjon hvor du kan spørre hvorfor scorer vi så dårlig på sikkerhet? Hva er årsaken til det? Og da har man straks en kommunikasjon med teamet rundt viktige temaer. Så synlighet og få litt gode rapporter for hvordan dette er i produksjon. Hvis for eksempel systemet går ned så få på dashbordet som viser at det går ned. Er du veldig god på DevOps, så vil du fange opp feilen før brukeren fanger opp feilen. Da er du såkalt elite performance, for da har du på plass alle de mekanismene som må på plass for at du skal kunne lykkes med DevOps biten.
Silvija: Kjetil, to ting som jeg nå driver å understreker i notatene mine her. Dette med synlighet synes jeg er veldig spennende og det er akkurat det som min fantastiske CTO har sagt til meg i dag at nå må vi ha ukentlige møter og vi må samkjøre oss. Jeg vil at du skal høre på. Jeg og flere andre i organisasjonen, produksjonsteamet, produktteamet, utviklingsteamet gjør. Og han sier at han må sitte alene i disse møtene og snakke om dette her så gjør han det, men dette setter han opp som møter. Jeg tror at det å forvente at ledelsen bryr seg, at organisasjonen bryr seg, at organisasjonen etter hvert lærer seg litt om hvordan ser vår arkitektur ut. Hva er de viktigste arbeids sporene i disse teamene som jobber her. Jeg tror det er en utrolig viktig del hvis man skal mene noe konstruktivt i forhold til produktstrategi.
Kjetil: Absolutt. Det er så viktig. Og igjen handler det om kommunikasjon. Ting som er lett å få til. Den her læringskulturen, hvis det går feil i produksjonen og du som leder stiller det første spørsmålet hvem har skylden? Så har man litt feil kultur. Da må man heller stille spørsmålet hvordan kan vi lære av dette? Hvordan kan vi bli bedre til neste gang og ufarliggjøre det litt?
Silvija: Og enda verre Kjetil hvis man ikke spør, men bare skyter. Jeg tror at vi lærer veldig mye av litt feil som oppstår i systemet også lærer man kanskje mye større ting om systemet også når feilen oppstår. Så det å lære seg at feil er faktisk bra er en viktig del av systemet her. Det andre som jeg merker teamet trenger er i den samtalen jeg hadde med min fantastiske CTO, og jeg virkelig digger han. Det er at han vil ikke ha ad hoc, men han vil ha ting som passer inn i en plan. Det kommer tilbake til det du snakker om kontinuerlig utvikling, ikke sant?
Kjetil: Og som leder så ønsker du å vite. Du må legge en plan overordnet. Du vet hva du ønsker ut av produktet og hva du vil ha. Så må du være åpen for at kanskje det var noen feil i den planen. Kanskje må vi justere planen underveis. Men som leder må du kommunisere den planen til teamet ditt slik at dere har et felles mål. Det er ekstremt viktig. Så tenker jeg også som lede – jeg satt i lunsjen der vi hadde fått en gjeng med graduates og så satt jeg å spiste sammen med dem. Så går samtalen veldig uformelt og hyggelig. Også er det en som spør hva er stillingsbeskrivelsen min i Forte også sier jeg da at jeg er utviklingssjef. Og da endret plutselig samtalen seg litt, for da var det litt sånn skremmende. For da var jeg plutselig sett på som noe litt mer autoritært, litt mer skummelt. Og da tenker jeg at som leder, ta å gå ned på gulvet og ta en uformell prat med utviklerne innimellom. Kanskje møte opp på daglige standup og bare observer og vær tilstedet. Sånn at man kanskje hvisker litt ut dette skillet. Som leder skal du være leder, ingen tvil om det. Men du må få en god kjemi med teamet og man må prate samme språk. Og der begynner hjernen med at man har det uformelle og at man kan prate uformelt med hverandre.
Silvija: Og det gode i kjemien begynner kanskje med å vise oppriktig interesse for det de bygger, og hvordan de tenker rundt det de bygger på. Da tenker jeg at det er fortsatt litt for mange ikke-teknologer som ser på teknologi som noe som det der får bare de teknologene finne ut av. Men når det er blitt så strategisk er man nødt til å lære seg noe av dette språket.
Kjetil: Ja, det er så viktig det også. Tenke litt på hvor du lærer fra også. Vi er litt for opptatt av buzzword i bransjen vår, og vi bruker kanskje buzzword som et maktvåpen. Så ikke vær redd for å stille dumme spørsmål. For det finnes ikke dumme spørsmål, bare dumme svar. Tenk på at læringskilden er ekstremt viktig.
Silvija: Kan jeg spørre deg om en annen ting. Investeringer, du må velge noen plattformer. Jeg hører dere snakke mye om Azure. Vi har lagt det på en annen. Men dette trenger ikke koste forferdelig mye? Det er noen tydelige valg man må ta, men det viktigste er kanskje at man skal ha noen skybaserte løsninger? Hva skal man tenke på ut i fra ressursbruk og tilrettelegging for at det skal være mulig å jobbe godt med DevOps.
Kjetil: Jeg tenker jo at man bør jo ha en teknologisk arkitekt som kan legge opp litt av de teknologiske føringene for hvilken skyplattoform man velger og dette med IT strategi. Skal du lage løsningen din basert på jern du har i kjelleren, eller skal du bruke en skyleverandør? Hvilke teknologiplattform skal du gå for er liksom strategiske valg som ledelsen bør ha et forhold til, slik at du ikke havner i en situasjon hvor de ulike teamene og alle teamene velger forskjellig teknologi også får du et problem når dem er ferdig for da er det ingen som klarer å drifte det, også blir det en dyr drift også blir du kanskje avhengig av enkeltpersoner. Men som leder så hvis du ikke er tungt forankret i teknologi, så er det viktig at du har støttespillere rundt deg som kan bistå den biten. Og da prater en gjerne om at du har arkitekter som gir deg råd og veiledning på hvilken skyplattform som passer for dere og hvilken teknologi skal vi basere det på. Og også kanskje litt DevOps type prinsipper, da.
Silvija: Du, jeg skal google litt. Hvis jeg skal finne noe godt på Youtube, hvor starter jeg uten å være programmerer selv? Har du en favoritt foreleser om dette?
Kjetil: Jeg pleier vel egentlig å google å finne veldig mange kilder. Jeg pleier å delta som utvikler på NDC som er en konferanse. Jeg pleier å dra på Build som er Microsoft sin store utviklerkonferanse. Også har du også noe Devops forskjellige fora. Du kan Google Dora DevOps Report som er en veldig viktig rapport som omhandler og starter med at det var noen teknologer som mente at DevOps funket, men de ble ikke helt trodd på. Så da tok de mange prosjekter og målte det på og lagde en rapport ut i fra hvordan det funket med Devops. Det er absolutt en rapport du burde se igjennom som leder.
Silvija: Den legger vi til som lenke i jukselapp dette kurset.
Silvija: Kjetil. Tusen takk for lærerik og inspirerende samtale om DevOps som er veldig viktig som en metode og utviklingsprosess, både for de som jobber med software, men også for alle de andre som skal da lede selskaper som etter hvert baserer seg på denne softwaren.
Kjetil: Og takk for at jeg fikk komme å prate om det temaer som jeg syns er veldig spennende og morsomt å jobbe med.
Du har nå lyttet til en podcast fra Lørn.Tech – en læringsdugnad om teknologi og samfunn. Nå kan du også få et læring sertifikat for å ha lyttet til denne podcasten på vårt online universitet Lørn.University
“
Du må være Medlem for å dokumentere din læring med quizes og motta læringsbevis. Prøv et
Allerede Medlem? Logg inn her
Du må være Medlem for å dokumentere din læring med quizes og motta læringsbevis.
Allerede Medlem? Logg inn her
