En djupgående analys av 19 DevOps-utvärderingar

Ett oreflekterat liv är inte värt att leva. En DevOps-utvärdering ger ett företag en tydlig bild av var deras användning av DevOps står i dag, vilka åtgärder de behöver vidta och i vilken ordning för att nå dit de vill.

Analysen bygger på DevOps-utvärderingar som genomfördes 2016–2018 hos 19 finländska företag inom följande branscher: media, bygg, tung industri, mjukvara, telekommunikation, el, medicin samt hälso- och pensionssektorn.

DevOps-utvärderingarna genomfördes som en del av Eficodes tjänst DevOps Development Plan.

Först och främst – vad är en DevOps-utvärdering?

En DevOps-utvärdering resulterar i en DevOps Development Plan med prioriterade åtgärdspunkter för det aktuella företaget. En utvärdering är en heltäckande bedömning av företagets DevOps-förmåga. Den analyserar den teknik som används och omfattar en rad intervjuer med utvecklingsteamet och ledningen samt en granskning av processerna. Slutresultatet är en skräddarsydd roadmap för de team som har analyserats och övergripande rekommendationer till företagets ledning.

Några av de DevOps-pelare som vanligtvis utvärderas är:

Organisation

• DevOps handlar om att överbrygga silos. I ett idealt scenario gör organisationsstrukturen det möjligt för alla delar av utvecklingsorganisationen att samarbeta eftersom teamen är tvärfunktionella och kan arbeta självständigt.

Automatisering

• Automatisering minskar behovet av manuella insatser genom att definiera allt som kod. Det gör att skript och verktyg kan ta över repetitiva delar av mjukvaruutvecklingen, medan människor kan fokusera på att skapa värde. Automatiserade processer kan också omvandla kundfeedback, utvecklingsmått, kvalitetssäkringsdata, data om affärsvärde och annat till meningsfulla dashboards.

Processer

• Metoderna för mjukvaruutveckling är optimerade och mängden spill är minimal. Utveckling och driftsättning flyter på smidigt. Det är enkelt att uppgradera till nya versioner och att återgå till en äldre version.

Kultur

• Experimenterande uppmuntrar nya arbetssätt och tröskeln för att föreslå nya idéer är låg. Kommunikation med ledningen är öppen och stressfri, och varje misstag ses som en möjlighet att lära.

Var och en av dessa kategorier omfattar ett stort antal metoder, till exempel oföränderliga servermiljöer, automatiserad kvalitetssäkring, helhetsansvar för produkten och att riva muren av förvirring mellan olika team.

Vissa har använts brett inom IT-branschen i årtionden, medan andra inte fanns för bara några år sedan. Det bästa scenariot är när en metod är djupt förankrad i det dagliga arbetet.

Hur brett hade DevOps-metoder införts i de 19 finländska företagen?

Min forskning visade att även metoder som vissa ser som självklara, som versionshantering och tillgänglig dokumentation, inte används överallt.

En översikt över de 19 DevOps-utvärderingarna

Figur 1: En översikt över de analyserade DevOps-utvärderingarna

Det är tydligt att företagen som utvärderades skiljde sig mycket åt i DevOps-mognad. (Se mognadspoängen i de två sista kolumnerna).

De vanligaste DevOps-metoderna

De mest använda metoderna är versionshantering (hos 12 av 19 företag) och Scrum-metoder (hos 10 av 19 företag). Båda metoderna har varit en viktig del av modern mjukvaruutveckling betydligt längre än DevOps-konceptet har funnits (ordet DevOps myntades 2009).

Bland de DevOps-specifika metoder som var måttligt vanliga fanns någon form av Continuous Integration-plattform, som triggas av commits i versionshanteringen, och en kultur av experimenterande (båda förekom hos ungefär en tredjedel av företagen).

En lucka i DevOps-arbetet: kvalitetssäkring

Att automatisera kvalitetssäkring och bygga in kvalitet genom kvalitetsgrindar och kodningskonventioner är ett mycket viktigt steg. Det möjliggör den hastighet och kvalitet som DevOps utlovar.

Jag konstaterade dock att endast ett fåtal organisationer faktiskt använde dessa metoder. Merparten av testningen och kodvalideringen gjordes fortfarande manuellt och var därmed känslig för mänskliga fel.

Flest observationer gjordes inom QA-kategorin

Figur 2: Totalt antal kodgrupper i varje kategori i kodmognadsmodellen. Förslag, gult: förslag som Eficode gav under utvärderingen. På rätt väg, grönt: områden som bedömdes vara på rätt väg under utvärderingen. Nuvarande, blått: problemkategorin och kategorin för sådant som är på rätt väg, sammanslagna, vilket visar sådant som det för närvarande arbetas med.

Här ser du att flest observationer gjordes inom QA-kategorin.

Men efter utvärderingarna vidtogs minst åtgärder inom QA-kategorin

Diagrammet nedan handlar inte om själva utvärderingarna. I stället bygger det på intervjuer som jag genomförde långt efter utvärderingarna. Det visar vilka delar av utvärderingarna som ledde till åtgärder. Grönt betyder att åtgärden genomfördes helt.

Figur 3: Antal förslag som implementerats i varje kategori i mognadsmodellen (baserat på intervjuer som genomfördes en tid efter utvärderingen). Helt och delvis implementerade förslag är till viss del utbytbara, eftersom vissa intervjupersoner menade att ”ingenting blir någonsin helt klart” och därför inte ville markera implementeringar som helt genomförda.

Det här diagrammet analyserar vilka åtgärder som vidtogs efter utvärderingen. Vilka kategorier fokuserade organisationen på efter att ha fått sin DevOps-utvecklingsplan och roadmap?

Som du kan se fick QA-kategorin minst framsteg av alla områden, trots att vi gav flest förslag inom just QA.

Det kan bero på att andra kategorier är enklare att implementera. Jag drog slutsatsen att det fanns fler åtgärder med snabba vinster i de andra kategorierna, medan QA-kategorin innehöll förslag som kräver mycket resurser att implementera. Med tanke på hur viktig kvalitet är för mjukvara överlag är den slutsatsen dock oroväckande.

Omfattande DevOps-transformationer består inte enbart av snabba vinster och ad hoc-lösningar, utan kräver att man har helheten i åtanke. Det är det enda sättet att dra nytta av DevOps i organisationens dagliga arbete.

Skillnader mellan branscher

Jag gjorde också en jämförelse mellan organisationer inom mjukvarubranschen och organisationer som verkar inom andra branscher.

Figur 4: Genomsnittligt antal problemkoder per bransch. ”Koderna” på y-axeln syftar på en dataanalysmetod som kallas öppen kodning/axial kodning. Metoden delar upp data och identifierar återkommande koncept, vilket hjälper till att visa samband mellan koncept och kategorier.

Här ser vi att mjukvaruföretag presterar sämre inom QA än andra branscher. När mjukvara är din huvudsakliga verksamhet fokuserar du på att leverera så snabbt som möjligt, vilket kan innebära att QA hamnar i skymundan. Testmetoder utvecklas inte nödvändigtvis i samma takt som andra faktorer som ökar hastigheten.

Inom exempelvis hälso- och sjukvård eller gruvindustrin behöver du däremot inte uppdatera din mjukvara lika ofta. Produkterna har längre livscykler, vilket ger dig tid att utveckla bättre kvalitetsgrindar och metoder.

Vi ser också en skillnad inom kategorin miljöer och releaser. Här ligger mjukvaruföretag före, eftersom stabil och snabb mjukvara kräver en solid grund i form av en stabil miljö och stabila releasecykler. Om ett företag fortfarande ser sin mjukvara som en sekundär produkt kan det hända att de nöjer sig med äldre infrastruktur.

DevOps som helhet är mindre vanligt än dess delar

DevOps-utvärderingarna visar att DevOps som helhetskoncept inte är lika vanligt som dess enskilda delar. Det är oklart om företagen siktar på en fullskalig DevOps-transformation, med ett fördjupat kulturellt samarbete i hela organisationen, eller om de väljer ad hoc-baserade stegvisa förändringar i stället.

Att införa ett enskilt verktyg leder inte till att hela potentialen i DevOps förverkligas. Men, och det kan vara självklart: när du gör små förändringar kontinuerligt förbättras effektiviteten i mjukvaruutvecklingen stadigt.

Varför genomförde företagen en DevOps-utvärdering?

Organisationernas skäl för att utvärdera sina DevOps-metoder varierade. Det vanligaste skälet var att skala upp och samtidigt öka hastigheten och kvaliteten. CTO:n på ett av företagen berättade att organisationen behövde växa och att de ville säkerställa att deras nuvarande metoder för mjukvaruutveckling skulle vara skalbara.

Hur är det att genomgå en DevOps-utvärdering?

Alla intervjuade företagsrepresentanter ansåg att DevOps-utvärderingarna var värdefulla.

Målet med utvärderingarna är att ge en ärlig och sanningsenlig överblick över situationen i den utvärderade organisationen.

Generellt blir DevOps-metoder allt populärare, och alla 19 finska företag som jag talade med ansåg att DevOps var värdefullt. Det var uppmuntrande att se att de utvärderade företagen vidtog de rekommenderade åtgärderna. 

Den här texten bygger på en masteruppsats som jag skrev 2018.