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

Ett liv utan självreflektion är inte värt att leva. En DevOps-utvärdering ger företaget en tydlig bild av var de befinner sig i sin DevOps-användning, vilka åtgärder de behöver vidta och i vilken ordning för att nå sina mål.

Den här analysen bygger på DevOps-utvärderingar som genomfördes 2016–2018 hos 19 finska 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 Eficode's DevOps Development Plan service.

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. Utvärderingen ä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 analyserade teamen och övergripande rekommendationer till företagets ledning.

Generellt bedöms bland annat följande DevOps-pelare:

Organisation

• DevOps handlar om att överbrygga silos. I ett idealscenario 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 låter skript och verktyg ta hand om repetitiva delar av mjukvaruutvecklingen, medan människor kan fokusera på att skapa värde. Automatiserade processer kan också omvandla kundfeedback, utvecklingsmått, kvalitetssäkring, data om affärsvärde med mera till meningsfulla dashboards.

Processer

• Metoderna för mjukvaruutveckling är optimerade och mängden slöseri är minimal. Utveckling och driftsättning flyter 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. Kommunikationen 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 arbetssätt, till exempel oföränderliga servermiljöer, automatiserad kvalitetssäkring, helhetsansvar för produkten och att riva muren av missförstånd mellan olika team.

Vissa har använts brett inom IT-branschen i årtionden, medan andra inte existerade förrän för några år sedan. Det bästa scenariot är när ett arbetssätt är djupt förankrat i det dagliga arbetet.

Hur brett hade DevOps-arbetssätt införts i de 19 finska företagen?

Min undersökning visade att även arbetssätt som vissa ser som självklara, till exempel versionshantering och tillgänglig dokumentation, inte används överallt.

Översikt över de 19 DevOps-utvärderingarna

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

Det är tydligt att det fanns stora skillnader i DevOps-mognad mellan de utvärderade företagen. (Se mognadsnivåerna i de två sista kolumnerna).

De vanligaste DevOps-arbetssätten

De mest använda arbetssätten är versionshantering (i 12 av 19 företag) och Scrum-arbetssätt (i 10 av 19 företag). Båda dessa har varit en viktig del av modern mjukvaruutveckling längre än själva DevOps-konceptet har funnits (ordet DevOps myntades 2009).

Bland de DevOps-specifika arbetssätt som var relativt vanliga fanns någon form av Continuous Integration-plattform, som triggas av commits i versionshanteringen, och en kultur av experimenterande (båda förekom i 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 snabbhet och kvalitet som DevOps utlovar.

Trots det upptäckte jag 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 kategorin QA

Figur 2: Totalt antal koder i varje kategori i mognadsmodellen. 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. Aktuellt, blått: summan av problemkategorin och kategorin på rätt väg, vilket visar sådant som organisationen för närvarande arbetar med.

Här kan du se att flest observationer gjordes inom kategorin QA.

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

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 i viss mån utbytbara, eftersom vissa intervjupersoner menade att ”ingenting någonsin är helt klart” och därför inte ville markera implementeringar som helt slutförda.

Det här diagrammet analyserar vilka åtgärder som genomfördes efter utvärderingen. Vilka kategorier fokuserade organisationen på efter att ha fått sin DevOps Development Plan och Roadmap?

Som du kan se fick QA-kategorin minst utveckling 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 som gav snabba resultat i de andra kategorierna, medan QA-kategorin innehöll förslag som kräver mycket resurser att genomföra. Med tanke på hur viktig kvalitet är för mjukvara över hela linjen kan man dock säga att denna slutsats är oroande.

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 enda sättet att få ut fördelarna med DevOps som en del av organisationens dagliga verksamhet.

Skillnader mellan branscher

Jag jämförde också organisationer inom mjukvarubranschen med organisationer som verkar inom andra branscher.

Figur 4: Genomsnittligt antal problemkoder per bransch. De ”koder” som nämns 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 hitta samband mellan koncept och kategorier.

Här ser vi att mjukvaruföretag presterar sämre inom QA än andra branscher. När mjukvara är kärnan i verksamheten ligger fokus 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 till exempel hälso- och sjukvården 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 release. Mjukvaruföretag ligger före här, eftersom stabil och snabbrörlig mjukvara kräver en stabil grund i form av tillförlitliga miljöer och releasecykler. Om ett företag fortfarande ser sin mjukvara som en sekundär produkt kanske de nöjer sig med äldre infrastruktur.

DevOps som helhet är inte lika vanligt som dess enskilda delar

DevOps-utvärderingarna visar att DevOps som helhetskoncept inte är lika vanligt som dess enskilda delar. Det är oklart om företag strävar efter en fullskalig DevOps-transformation, som omfattar fördjupat kulturellt samarbete i hela organisationen, eller om de i stället väljer stegvisa ad hoc-förändringar.

Att införa ett enskilt verktyg ger inte hela den effekt som DevOps utlovar. Men, och det här är kanske uppenbart: när du genomfö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 till 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.

Syftet med bedömningarna är att ge en ärlig och sanningsenlig bild av den bedömda organisationens situation.

Generellt blir DevOps-metoder allt populärare, och alla 19 finländska företag som jag pratade med såg fördelar med DevOps. Det var uppmuntrande att se att de bedömda företagen genomförde de rekommenderade åtgärderna.

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