Ständiga förbättringar

DevOps förenar agil utveckling och LEAN. Ständiga förbättringar genom fokus på flödet, ständiga feedbackloopar och en kultur som uppmuntrar experimenterande. Det är DevOps tre vägar för att leverera mjukvara i toppklass.

Små ständiga förbättringar – Kaizen

DevOps är ett sätt att jobba med utveckling av mjukvara så att man bygger ett helhetstänkande från idé till leverans. Det innebär att utveckling och drift arbetar tillsammans med ett gemensamt mål i sikte – att leverera en produkt som uppfyller kundens behov på ett snabbt och effektivt sätt och med hög kvalitet, även efter produktionssättning.

Idéerna bakom DevOps bygger på en kombination av Agil utveckling och Lean. En viktig ingrediens hämtad från den japanska Lean-filosofin är Kaizen, att arbeta i små ständiga förbättringar. Inom DevOps pratar man om att utveckla i små iterationer, alltså att utveckla, testa, utvärdera och förändra ofta och i små steg. Fördelen är att det är lätt att rätta till om något blir fel, men det minskar också rädslan för att släppa en ny release.
– Idén är att göra små förändringar ofta, istället för att ta de stora jättekliven någon gång per år. Vad är det minsta möjliga steget vi kan ta? Fördelen är att det blir inte så dramatiskt när vi gör en förändring och om det skulle bli något fel så är det också lätt att rätta till, förklarar Martin Comstedt, seniorkonsult på Onbird inom Agil organisationsutveckling och förändringsledning.

Skapa kundvärde i varje steg

Martin Comstedt förklarar att kvalitet i DevOps-sammanhang handlar om att skapa kundvärde i alla steg, både i det interna flödet och med fokus på slutkunden. Första frågan man bör ställa sig är därför, vad är kvalitet för vår kund?
– Se upp med den fällan, att du inte säkert vet vad som skapar värde för kunden eller förutsätter att kunden vill ha det på ett visst sätt. Vi måste förstå vad som skapar kundvärde – är det en snabb leverans, hög funktionalitet eller något helt annat?

Kunden i DevOps-sammanhang finns på flera plan. Förutom slutkunden så är det också viktigt att ha koll på sina interna kunder i utvecklingsflödet. Det innebär att den som arbetar mitt i flödet inte bara ska se till sin egen avgränsade uppgift, utan ha förmåga att både se vad som skapar värde för slutkunden och sin interna kund. Risken om man enbart fokuserar på sin del i kedjan är att man optimerar sitt eget arbete, men istället försvårar för andra.
– För att lyckas måste vi titta på kundvärde på ett annat sätt. Vi måste hitta sätt att ständigt utvärdera kundvärdet, inte bara efter leverans utan även mitt i arbetet, förklarar Martin Comstedt.

Han konstaterar att det gamla sättet att utvärdera hur nöjd kunden är när en produkt väl lanserats inte fungerar i IT-världen. Här krävs det att medarbetarna jobbar mycket mer med snabba utvärderingar och regelbundna avstämningar med kunden.
– Det kanske tar mer tid och kräver ett större engagemang från kunden. Men sannolikheten att det blir rätt är så mycket större.

Vad är Kaizen?

Kaizen är japanska där kai betyder förändring och zen betyder ständigt till det bättre. Begreppet har sitt ursprung i Toyotas produktionsfilosofi och handlar om att sträva efter att hela tiden ta de små stegen till ständig förbättring. Målet med kaizen är att minska slöseri inom företaget, det vill säga eliminera moment som innebär kostnader utan att de tillför något värde.

Feedbackloopar

En annan viktig nyckel i sammanhanget är feedbackloopar, att utvecklarna får återkoppling på sitt arbete och direkt kan göra förändringar när det är nödvändigt.
– Vi vill ha små avstämningar, ofta. Att titta kort tid bakåt och utvärdera vad som funkar bra och vad som funkar dåligt är betydligt lättare för det mänskliga psyket. Dessutom minskar det risken för surdegar.

Ständig leverans, ständig testning och ständig integration

Inom DevOps är automatisering centralt och idén är att automatisera allt som går att automatisera, även feedback. Begreppen Continuous delivery, Continuous testing och Continuous integration handlar exempelvis om att automatisera och integrera förbättringsarbetet i själva flödet.

– Fördelen är att datorer ger all information mer exakt, både det som gick bra och dåligt. Det innebär att jag på ett helt annat sätt kan styra vilken information jag är intresserad av. Jag ser tydligt var de röda flaggorna finns och kan åtgärda dem direkt, förklarar Martin Comstedt.

Att mäta rätt – exempel på nyckeltal

Hur vet man då att man håller fokus på det som skapar värde för kunden? Här gäller det förstås att mäta rätt saker. Om det är en snabb leverans som är viktigast för kunden, så är ledtiderna ett viktigt nyckeltal. Genom att ha koll på hur lång tid olika steg tar kan man också hitta förbättringspunkter som gör att den totala tiden från beställning till leverans blir kortare. Ett annat mätetal kan vara antal fel.

Det viktiga är att mätetalet styr det beteende som är värdeskapande för kunden.
– Det är ofta lätt att mäta ledtider, men kanske är det något helt annat som är viktigast för kunden. Ta reda på vad som är värdeskapande för kunden och se till att ta fram mätvärden som driver medarbetarna mot det målet, säger Martin Comstedt.

Exempel på nyckeltal som kan vara relevanta att mäta i ett DevOps-flöde är ledtider, antal fel, releasefrekvens, tid att återställa en release samt tillgänglighet.

Ständiga förbättringar på tre plan

  • 1

    Kunden

    Vad skapar värde för kunden? Kunden får möjlighet att testa och utvärdera förändringar under hela processen för att på så sätt säkerställa att leveransen lever upp till kundens behov och förväntningar.

  • 2

    Flödet

    Hur ser flödet ut, från beställning till leverans? Gemensamma utvärderingar säkerställer att alla håller fokus på kunden och hittar lösningar för att leverera kundvärde.

  • 3

    Medarbetaren

    Hur fungerar den kod jag skriver i förhållande till andras arbete? Korta feedbackloopar underlättar möjligheten att rätta till fel som uppstår under vägen.

Ladda hem

Guide DevOps

  • Bocka för de dokument du vill ladda ner
                • Hidden
                • Hidden
                • Detta fält används för valideringsändamål och ska lämnas oförändrat.

                Förbättringar utifrån två perspektiv

                Något som är utmärkande för DevOps är att förbättringsarbetet måste ske utifrån två perspektiv där varje medarbetare både ser helhetsperspektivet och sin egen del i flödet. Helt avgörande för att detta ska fungera är att det finns en förbättringskultur som uppmuntrar medarbetarnas driv att göra kunden 100 procent nöjd.
                – Det är först när alla har koll på vad kundvärdet är som vi kan dra nytta av den samlade hjärnkapaciteten. Då kan vi hitta lösningar som vi inte hade sett om var och en bara tittade på sin lilla del i flödet.

                Här är det två saker som är extra viktiga – att medarbetarna känner att det är ok, eller till och med önskvärt, att de då och då misslyckas, samt att det är fritt fram att experimentera.
                – För att varje medarbetare ska kunna ta ansvar för helhetsleveransen måste de också känna att de har mandat att fatta egna beslut och att misslyckanden är en del av resan. Det är när folk vågar ta egna initiativ, testa och experimentera som vi når de riktigt disruptiva innovationerna.

                Utveckling, test och förbättring i ett flöde

                Produkten testas i små iterativa steg där alla komponenter i produkten och dess underliggande tekniklager verifieras med den nya versionen av produkten.

                Continuous Integration. Innebär att utvecklarna integrerar sin kod ofta till en gemensam kodbas, ibland kallad ’master’ eller ’trunk’. Utifrån denna görs regelbundna tester och automatiserade byggen, allt för att upptäcka brister och problem så tidigt som möjligt

                Continuous Deployment. Innebär att koden automatiskt testas och deployas till produktionsmiljö.

                Continuous Delivery. Det är när koden går igenom hela det automatiserade flödet för att göras klar för deployment, men att själva releasen/deployment sker manuellt.

                Anna Nyström

                Anna Nyström

                Anna är journalist och skriver om DevOps, design thinking och ledarskap.