Varför är DevOps viktigt för företagsledare?

Som affärsansvarig ägnar du arbetsdagen åt allt från försäljningssiffror och kundnöjdhet till medarbetarupplevelse och produktsortiment. Du håller sannolikt också noggrann koll på konverteringsgraden för onlineförsäljningen, leveransprocessen och tillhörande marknadsföringskostnader. Men intresserar du dig tillräckligt för värdet, kvaliteten och utvecklingen av digitala tjänster?

Det finns många olika typer av kvalitet: snabbhet, tillförlitlighet, felfrihet och skalbarhet för olika enheter. Är kvalitet enbart IT- eller marknadsavdelningens ansvar? Det borde den verkligen inte vara, särskilt inte när vi talar om onlineförsäljning. Och vilken försäljnings- eller inköpsprocess börjar inte i en onlinekanal nuförtiden? Potentiella kunder går igenom sin beslutsprocess när de lär känna tjänsteleverantörerna. Därför blir utvecklingen av digitala tjänster särskilt viktig när produkten i sig är en digital tjänst.

DevOps är avsett att automatisera IT-tjänstefunktioner kopplade till mjukvaruutveckling, testning och underhåll. Det är dock viktigt att notera att automatisering inte innebär att kostnaderna automatiskt minskar. DevOps-modellen möjliggör två saker som är avgörande för en affärsansvarig: kvalitetsförbättringar och snabb leverans av värde, även kallat Zero Day Delivery.

Att inkludera testautomatisering i processen för mjukvaruleverans är avgörande; mjukvaran testas ofta, det vill säga systematiskt, och regressioner eller nya fel som uppstår till följd av ändringar i kodbasen fångas upp av de automatiserade testerna. Testautomatisering och Robotic Process Automation (RPA) kan införas i de flesta mjukvaruprojekt, men kräver insatser från teammedlemmar med god kunskap om automatiseringsmöjligheter. Väl utformad testautomatisering går längre än att kontrollera kritiska komponenter och grundläggande funktionalitet. Den bör säkerställa att en produkt eller tjänst är användbar och fungerar som avsett även i ovanliga situationer.

Med DevOps-metoder kan processen som kopplar samman utvecklingsmiljön med produktionsmiljön automatiseras. Organisationens kultur kan dock fortfarande innebära att manuella steg läggs till i leveransprocessen. Helst är de tjänster som används integrerade, insikter om förändringar och deras effekter är spårbara, och allt kan återställas – även om det är bättre att gå framåt och lösa utmaningarna. Den största utmaningen är att komma överens med verksamheten om hur en förändring ska verifieras automatiskt med hjälp av en väl utformad leveranspipeline, så att alla har förtroende för mjukvarans kvalitet.

Om allt automatiseras, minskar inte kostnaderna då? Jo, på lång sikt. Att utveckla automatisering tar tid och kostar pengar, men när manuellt arbete automatiseras blir omarbetningen i olika aktiviteter billigare.

Testarens roll blir allt mer inriktad på automatisering, men tyvärr utvecklas manuella testare sällan till testautomatiserare. Det bör ändå finnas kompetens, eller åtminstone intresse, för kodning eller scripting, och manuella testare är bra på att definiera hur systemet ska fungera ur ett arbetsflödesperspektiv. Teammedlemmarna kommer överens om utvecklingsrutiner som stödjer beprövade utvecklingsmetoder och minskar det manuella arbetet.

Kunden börjar dra nytta av automatiseringen när projektet blir mer transparent, förändringar driftsätts i produktion och det är känt vilka funktioner slutanvändarna använder. Utvecklingsteamet kan fokusera på sitt arbete, utmaningar kan lösas snabbt och det krävs inget extra arbete för att släppa en korrigerad version.

Förbättra förutsägbarhet och transparens

Vore det inte bra att i förväg veta när en efterfrågad funktion skapar värde för dina kunder och därmed för din verksamhet? DevOps förbättrar förutsägbarheten ur både ett tekniskt och icke-tekniskt perspektiv. Som beskrivits tidigare verifieras nya funktioner automatiskt, installationer är inte känsliga för mänskliga fel och aktiviteter loggas. Det är också viktigt att behålla transparensen kring framtida utvecklingsaktiviteter. Att underhålla backloggen, prioritera den effektivt och dokumentera alla aktiviteter bidrar till att förutse projektets framtid och möjliggör även retrospektiv. Krav definieras av någon och har kriterier. Kriterierna för en förändring bör vara tydliga för alla som deltar i utvecklingsarbetet.

Nu fokuserar jag på den del av processen som handlar om beslutsfattande. En vanlig metod är att dela upp det som ska utvecklas i fyra nivåer. Till exempel:

Tema: Ett verksamhetsorienterat mål för produkten. Den affärsansvariga ansvarar för och prioriterar temat tillsammans med produktägaren.

Epic: Ett större arbetsområde som gör det möjligt att bedöma genomförbarheten (S–XL) och livskraften (affärsvärdet) hos en tydligt definierad värdeskapande funktionalitet. Produktägaren ansvarar för och prioriterar epicet tillsammans med den affärsansvariga.

Story: Något en användare kan uppnå med tydligt definierad ”Definition of done” (DoD) och arbetsinsats (story points). Produktägaren ansvarar för och prioriterar storyn tillsammans med utvecklingsteamet.

Task: En enskild delmilstolpe för att slutföra storyn, med tid som uppskattning. Utvecklingsteamet ansvarar för och prioriterar uppgiften enligt den metodik som teamet har kommit överens om.

Dessa kategoriseringar hänger ihop med beslutsprocessen eftersom de ger den affärsansvariga överblick över vad utvecklingsteamet gör. Det innebär att personen kan prioritera utvecklingstemat och underliggande epics, samtidigt som det finns frihet att snabbt ändra riktning vid behov. Om utvecklingen börjar gå åt fel håll kan onödiga tasks och stories enkelt överges och arbetet omprioriteras.

Det är också bra för utvecklingsteamets motivation att slumpmässiga ärenden inte dyker upp i sprintbackloggen. Det bör dessutom finnas utrymme reserverat för kritiskt arbete eller uppgifter som måste genomföras omedelbart. Uppgifter som dyker upp slumpmässigt har sällan något verkligt värde. De är ofta dåligt förberedda och leder till slöseri med tid och pengar. Systematisk utveckling tar tid, och om relevanta intressenter inte prioriterar förberedelser blir resultatet oundvikligen dåligt.

DevOps ger också en viss transparens kring kostnader. Det bästa arbetet fokuserar på att maximera kundvärdet och automatisera onödiga manuella uppgifter, vilket bidrar till bättre affärsresultat. I det här fallet använder verksamhetsansvarig och produktägaren pengarna klokt, och resultaten spelar roll. Det är svårt att mäta kundvärde, men det är till exempel enkelt att titta på inkommande intäkter och konverteringar i en e-handelsbutik och jämföra dem med hur mycket som läggs på utveckling.

Att förändra kulturen

Förändringen kan inte hanteras – den måste genomföras. Ett hinder för en lyckad transformation uppstår när högsta ledningen överlåter uppgiften att förändra organisationens arbetssätt till en enda person. Ledningen följer sedan förändringen genom styrgruppsmöten, ledningsgruppsmöten och PowerPoint-presentationer. Detta arbetssätt leder sannolikt inte till bästa möjliga resultat.

I stället bör ledningen använda sprintar i sitt eget arbete. Då får de egen erfarenhet av att arbeta på de nya sätt som införs. Det tydliggör vad som förväntas av organisationen som helhet och ger dem direkt erfarenhet av fördelarna med ett systematiskt, målinriktat och strukturerat arbetssätt. Det är förstås inte realistiskt att planera alla ledningsuppgifter för en eller två veckor, men vissa uppgifter kan planeras och hanteras som sprintar.

Att använda verktyg utan att förstå vilket värde de ger leder inte heller till framgång. Lean går till exempel ofta fel när fokus ligger på verktyg och metoder i stället för på Lean-värderingar. SAFe tillämpas i vissa delar av organisationen på grund av dess popularitet på mjukvarumarknaden.

En form av kulturförändring är att misslyckas tidigt. Det är det bästa sättet att spara mycket pengar i utvecklingen. När koncept valideras ofta och tidigt hamnar bara värdeskapande funktioner i utvecklingsbackloggen. Människor förlitar sig dock ofta för mycket på sina egna idéer och insikter och är ovilliga att visa ofärdiga lösningar för slutanvändarna, trots att det skulle vara både fördelaktigt och effektivt. I det här skedet blir de utvecklingsidéer som kostar minst och den tjänst som ska utvecklas verkligen relevanta för kundens behov.

DevOps och Agile-utveckling

DevOps ses ofta som en samling verktyg och metoder, till exempel testautomatisering, optimering av release-pipelines och att göra driftsättningsstatus synlig för utvecklare genom övervakning. Det stämmer, men detta är inte engångsinsatser i utvecklingen. I stället bör de utvecklas och optimeras kontinuerligt utifrån förändrade behov.

Ett bra tillvägagångssätt är att då och då ha en särskild ”teknisk sprint” med fokus på tekniska förbättringar, korrigeringar av verktyg och liknande. Det kanske inte är möjligt att hela utvecklingsteamet deltar, men det bör vara en teamaktivitet, det vill säga att relevanta experter tas in vid behov för att lösa problem som andra inte kan lösa effektivt. Det är dock viktigt att inkludera underhållsuppgifter i sprintupplägget, så att ni kan vara förberedda på avbrott i användningen av era verktyg och så att hela teamet snabbt kan se vilka förändringar som har skett.

DevOps möjliggör Agile-utveckling. Kontinuerligt värdeskapande på heltid kan bara uppnås när tid och energi inte slösas på manuella arbetsmoment eller problem med verktyg. För att fullt ut förverkliga den idén måste ledningen gå i bräschen och leva som de lär. Läs mer i bloggen ”Agile vs. DevOps: the grand debate.”