Agil kontra DevOps: Hvad bør du vælge, og hvorfor

Når du tænker på en højtydende organisation, har du så nogensinde spekuleret på, hvilke bedste praksisser de følger, som gør det muligt for dem at opnå denne status? Hælder de til agile metoder eller DevOps-tilgange?

For at nå deres mål er disse organisationer ofte afhængige af en blanding af agile værktøjer til styring af iterativ udvikling og adaptiv planlægning samt DevOps-værktøjer, der effektiviserer automatisering, kontinuerlig integration og udrulning.

Formålet med en udviklings- og driftsproces er at hjælpe virksomheden med at opfylde sine krav, hjælpe teammedlemmerne med at samarbejde og nedbryde siloer for at løse problemer, der blokerer arbejdet, og endelig færdiggøre de projekter eller funktioner, de arbejder på, så de kan øge antallet af daglige eller månedlige aktive brugere – eller, når det gælder virksomhedsapplikationer, øge funktionaliteten i deres applikationer.

Når teams arbejder i siloer, opstår der kommunikationshuller, som igen fører til kaos. Når teams derimod arbejder sammen, er de mere effektive. 

Inden for rammerne af denne artikel vil jeg gennemgå agile tilgange og DevOps-tilgange, eksempler på, hvornår man bør vælge specifikke metoder, samt hvordan test påvirkes i hvert af disse scenarier. 

Agile praksisser for softwareudvikling

Sammenlignet med vandfaldsmodellen fokuserer agil udvikling på et af kerneprincipperne, som indebærer at tilfredsstille kunderne tidligt i processen og gennem kontinuerlig levering. Kontinuerlig levering er kun mulig, når vi involverer kvalitetsteamet tidligt i processen og samarbejder hyppigt med dem. 

I øjeblikket befinder nogle af de mindre og mellemstore virksomheder sig i en situation, hvor de hverken følger en agil tilgang eller vandfaldsmodellen fuldt ud, men en blanding af begge. Disse såkaldte agile teammedlemmer bruger så meget af deres energi på detaljerede processer som 30-minutters standupmøder og 60-minutters retrospektive møder, at de glemmer det investeringsafkast, de bidrager med, hvilket ender i en situation, hvor der findes mange fejl i produktionen. 

Har branchen virkelig ændret sig fra en vandfaldsmodel? 

Har du nogensinde været en del af en organisation, som du troede fulgte agile softwareudviklingsprocesser, for først senere at opdage, at kvalitetsteamet først blev involveret i test, efter udviklingen var afsluttet? 

I dette eksempel kaldte de det stadig agilt, fordi medlemmerne af udviklingsteamet arbejdede på flere grene (eller funktioner) på samme tid på en iterativ måde. Men når deres funktioner skulle testes, ventede de, indtil al udvikling var færdig – hvilket er kernen i vandfaldsmodellen. Da virksomheder imidlertid ønsker at bevæge sig hurtigere, så de kan udvide deres kundebase, ender teams det meste af tiden med at akkumulere teknisk gæld. 

Den bedste måde at løse dette problem på er at omdanne organisationen, så den bliver fuldstændig agil, og arbejde hånd i hånd med kvalitetsteamet iterativt. Det indebærer at samarbejde med alle interessenter for at sikre, at de forstår konsekvenserne af ikke at foretage skiftet, og hvordan det kan påvirke slutbrugeroplevelsen. 

Agile rammeværk og deres varianter

Inden for rammerne af denne artikel vil jeg gennemgå to af de mest populære agile rammeværk:

1. Scrum
2. Kanban

Scrum er en agil metode, der anvendes i softwareudvikling, og som er baseret på iterative og inkrementelle processer. Den består i at følge en tidsafgrænset udvikling kaldet sprint. Sprintenes varighed varierer fra organisation til organisation og spænder fra en uge til en måned eller et kvartal.

Der afholdes en sprintplanlægningssession, efterfulgt af sprintet, hvor implementering og test finder sted, herunder daglige standupmøder, og det afsluttes endelig med en retrospektiv session. 

Scrum implementeres normalt i produktudviklingsteams, hvor teammedlemmerne skal tidsafgrænse deres arbejde for at overholde kundernes deadlines. Det anvendes primært til B2C-applikationer, fordi en funktion ikke længere er ny, hvis man venter for længe, da en anden måske allerede har implementeret den! 

I B2B-applikationer, som primært anvendes af virksomhedsorganisationer, bruges ofte en modificeret version af den agile metode kaldet SaFe – det skalerede agile rammeværk. 

De fleste projekter i virksomhedsorganisationer falder ind under en af følgende kategorier:

1. Teamniveau
2. Programniveau
3. Porteføljeniveau

Projekter på teamniveau er funktionsbaseret udvikling, der involverer, at hvert teammedlem ejer sit projekt og sine processer. Disse teams bruger normalt Scrum eller Kanban afhængigt af arbejdets karakter.

Hvis teams hører under forsknings- og udviklingsorganisationer eller testautomatisering, er det afgørende, at de følger Kanban, som er mindre rigid, og hvor målet i højere grad er at færdiggøre deres aktuelle opgave end at springe videre til det næste spændende objekt, der dukker op! Hvis teams er en del af produktudviklingsorganisationen, har de en tendens til at bruge Scrum-processer. 

Projekter på programniveau involverer flere teams, der arbejder mod et specifikt mål, såsom AWS-migrering. Selvom dette projekt kan falde ind under projekter på porteføljeniveau, vil jeg hævde, at det ikke nødvendigvis vil påvirke HR- eller økonomiteams.

I dette tilfælde kan projektet med AWS-migreringen vare i flere måneder på grund af uforudsete problemer, så fokus er på at gennemføre AWS-migreringen med succes, samtidig med at den opdeles i håndterbare sprints. 

Projekter på porteføljeniveau involverer forskellige organisationer i virksomheden; et eksempel kunne være en JIRA-implementering. Hver organisation vil kræve, at JIRA-arbejdsgange implementeres forskelligt baseret på deres behov. HR-teams har ikke behov for test; fokus er primært på at imødekomme specifikke anmodninger fra medarbejdere, og når de har hjulpet dem, markeres opgaven som “færdig.”

Agile-metoder bør anvendes af organisationer, der er kendt for konstant at gennemgå forandringer. Men disse ændringer skal stadig gennemgå en runde med test og fejlrettelse, og test er ikke nødvendigvis automatiseret, hvilket fører til længere procestider.

Endelig, når funktionerne er klar til at blive implementeret, overdrages de til bygge-/driftsteamet. Test udføres altså iterativt sammenlignet med vandfaldsmetoden, men flyttes ikke markant til venstre, da fokus ikke er på kontinuerlig test og levering. Derfor er der behov for DevOps-tilgangen! 

DevOps-tilgangen

DevOps-tilgangen fokuserer på aspekter ud over udvikling og test og fremmer en fuldt automatiseret CI/CD-pipeline sammen med overvågningsfunktioner. Mens Agile omfavner forandringer, fokuserer DevOps-tilgangen på kontinuerlig test og levering for at sikre, at hyppige udgivelser til slutbrugerne lykkes. 

Målet for IT-driftsteamet er at skalere softwareudviklingsprocessen for at fremskynde skrivningen og opdateringen af den kode, der er ansvarlig for at skabe nye applikationer og tjenester samt opdatere funktioner i IT-teamet.

Selv med hensyn til teamopsætningen er kvalitets- og IT-driftsteams i dag en del af den samme organisation, så de kan arbejde tæt sammen. Faktisk er en ny rolle kaldet TestOps blevet introduceret med specifikt fokus på at opsætte CI/CD-pipelines, hvor automatiserede tests køres mod pull-anmodninger, hvilket giver øjeblikkelig feedback til udviklingsteams.

Automatiseret test er afgørende for at skalere testindsatsen, og værdien går tabt, hvis den ikke er en del af kontinuerlig test og en kontinuerlig udgivelsescyklus for implementering. Derfor har TestOps-medarbejderne altid hænderne fulde med vedligeholdelse af den automatiserede testinfrastruktur.

Dette sikrer, at medlemmerne af driftsteamet kan fokusere på at levere en infrastruktur i verdensklasse til softwareudvikling uden at blive distraheret af testinfrastrukturen. 

Der findes i dag mange værktøjer og DevOps-praksisser, som effektiviserer den overordnede proces. 

• En Terraform-tilstandsfil henviser til et sæt infrastrukturer, der er defineret og administreres som en enkelt enhed—sådan defineres og administreres forskellige test- og udviklingsmiljøer. Terraform hjælper med at konfigurere servere, men vi har brug for en infrastruktur til at køre disse servere. 

• AWS leverer infrastrukturen via EC2-instanser, som i øjeblikket er den mest omkostningseffektive måde at konfigurere og køre disse servere på. Hvis du vil gå et skridt videre, og din teknologistak indeholder mange mikrotjenester, kan du med Docker Compose definere og køre flere Docker-container-miljøer.

• Ansible automatiserer processen med at konfigurere maskiner til at køre processer eller servere. 

• Kubernetes hjælper med at administrere en klynge af disse EC2-instanser som en pod og planlægger, at containere kører på denne klynge baseret på de tilgængelige computerressourcer. 

Bør du bruge agil udvikling eller DevOps?

Selvom diskussionen om agil softwareudvikling kontra DevOps-tilgangen er tilbagevendende i organisationer, er den bedste måde at se på det at stille os selv følgende spørgsmål:

• Hvor tilpasningsdygtig er vores organisation, når det gælder nye teknologier? 
• Er vi i stand til at konkurrere med vores konkurrenter, hvad angår kvaliteten af vores produkter? 
• Er det sandsynligt, at kunderne vil bruge vores produkter, fordi de lever op til deres forventninger? 

Hvis svarene på ovenstående spørgsmål indebærer en eller anden form for benægtelse, er det tid til at fokusere mere på en kombination af begge tilgange og tilpasse den, så den opfylder vores behov.

Den ideelle metode til softwareudvikling

Den vigtigste forskel mellem agile og DevOps-baserede softwareudviklingsprocesser er, at førstnævnte i højere grad fokuserer på at imødekomme konstante ændringer, mens sidstnævnte fokuserer på kontinuerlig test, levering og implementering. Samarbejde mellem udviklings- og driftsteams er afgørende, så udviklingsteamet ikke bliver blokeret. 

Efter min mening bør en ideel softwareudviklingsproces derfor omfatte følgende:

• Håndtering af kunde-/brugerpersonaer og indarbejdelse af kundefeedback
• Fokus på bedste praksis for at forhindre ophobning af teknisk gæld
• Kontinuerlig forbedring, kontinuerlig test, kontinuerlig integration, kontinuerlig levering, kontinuerlig implementering og overvågning

Sådan ville processen se ud:

Håndtering af forskellige kundepersonaer er ikke begrænset til produktledelsesteams. Når alt kommer til alt, hvorfor udvikler vi disse produkter? Hvad er formålet med disse produkter, hvis de ikke bliver brugt af kunderne? 

Tag det klassiske eksempel med Nokia—da de blev ved med at ophobe teknisk gæld ved ikke at følge med markedstendenserne, især innovationen fra deres konkurrent Apple. De fokuserede på at følge strenge sprintcyklusser for til sidst at blive glemt! 

Alle virksomheder bør forstå, hvorfor deres funktioner udvikles, og hvilke typer kunder de henvender sig til. Det sikrer, at vi udvikler brugercentrerede funktioner. 

Når et nyt produkt lanceres, uanset om det er en mobilapplikation eller en webapplikation, skal du altid sikre, at der er en måde, hvorpå kunderne kan give deres feedback. Ikke alle virksomheder følger en streng proces, hvor de arbejder tæt sammen med kundesupporten. 

CI/CD

Endelig bør du fremme AI/ML-baseret kontinuerlig integration og kontinuerlig levering. Når et projekt mislykkes, er det ikke nødvendigvis et tegn på manglende kompetencer hos teammedlemmerne; det skyldes i stedet utilstrækkelig testning og manglende evne til at finde problemer tidligere under udviklingen.

Men nogle gange går tingene galt, selv når der er tilstrækkelig testning og automatisering på plads—så hvis der fandtes et anbefalingssystem, der kunne identificere, hvornår man skulle lancere, og hvornår man ikke skulle, kunne sådanne katastrofale fejl måske være undgået.

Hyppige iterationer hjælper udviklingsteamet med at forstå, hvad der fungerer, og hvad der ikke gør, og understøtter overvejelser om skalerbarhed. Ulempen er, at det er tidskrævende! Hvis et andet anbefalings-/forudsigelsessystem kunne indsamle data om kunderne og forudsige, om en bestemt funktion ville bidrage til at skabe fremdrift eller mislykkes, allerede før udviklingen begynder, ville det hjælpe med at strømline processen med at bygge et produkt af høj kvalitet fra dag 1! 

Det overordnede mål er at sikre, at forretningspåvirkningen vokser hurtigere, når disse bedste praksisser indarbejdes som en del af udviklingsprocessen. 

Afsluttende tanker

I sidste ende spiller både agil udvikling og DevOps afgørende roller i moderne softwareudvikling, men det rigtige valg afhænger af organisationens mål, teamstruktur, prismuligheder og projektets behov.

Agile fokuserer på iterativ udvikling og fleksibilitet, mens DevOps lægger vægt på kontinuerlig levering, automatisering og samarbejde mellem udvikling og drift. Mange organisationer opnår gode resultater ved at kombinere begge tilgange for at maksimere effektivitet og kvalitet. Uanset hvilken vej du vælger, er det vigtigt at tilpasse dine værktøjer og processer for at fremme innovation og levere værdi hurtigere.

Hvis du vil have flere indsigter i optimering af dine udviklingsarbejdsgange og holde dig ajour med branchens tendenser, kan du abonnere på The CTO Clubs nyhedsbrev.