Smidig vs. DevOps: Hva bør du velge, og hvorfor?

Når du tenker på en høytytende organisasjon, har du noen gang lurt på hvilken beste praksis de følger for å oppnå denne posisjonen? Heller de mot smidige metoder eller DevOps-tilnærminger?

For å nå målene sine er disse organisasjonene ofte avhengige av en kombinasjon av smidige verktøy for håndtering av iterativ utvikling og adaptiv planlegging, samt DevOps-verktøy som effektiviserer automatisering, kontinuerlig integrasjon og utrulling.

Målet med en utviklings- og driftsprosess er å hjelpe selskapet med å oppfylle kravene sine, hjelpe teammedlemmene med å samarbeide og bryte ned siloer for å fjerne hindringer, og til slutt fullføre prosjektene/funksjonene de arbeider med, slik at de kan øke antallet daglige eller månedlige aktive brukere – eller, når det gjelder bedriftsapplikasjoner, øke funksjonaliteten i applikasjonene sine.

Når team arbeider i siloer, oppstår det kommunikasjonsgap, som igjen fører til kaos. Når team derimot arbeider sammen, er de mer effektive. 

Innenfor rammene av denne artikkelen vil jeg dekke smidige og DevOps-tilnærminger, eksempler på når man bør ta i bruk bestemte metoder, og hvordan testing påvirkes i hvert av disse scenariene. 

Praksis for smidig programvareutvikling

Sammenlignet med fossefallsprosessen for utvikling fokuserer smidig utvikling på et av kjerneprinsippene, som innebærer å tilfredsstille kundene tidlig i prosessen og gjennom kontinuerlig levering. Kontinuerlig levering er bare mulig når vi involverer kvalitetsteamet tidlig i prosessen og samarbeider hyppig med dem. 

For tiden befinner noen av de små og mellomstore selskapene seg i en situasjon der de verken følger en smidig tilnærming eller fossefallsmodellen fullt ut, men en kombinasjon av begge. Disse såkalte smidige teammedlemmene bruker så mye av energien sin på detaljerte prosesser som 30-minutters daglige statusmøter og 60-minutters retrospektive møter at de glemmer avkastningen på investeringen de bidrar med, noe som ender i en situasjon der mange feil oppdages i produksjon. 

Har bransjen virkelig gått bort fra en fossefallstilnærming? 

Har du noen gang vært del av en organisasjon (som du trodde fulgte smidige prosesser for programvareutvikling), for så å innse at kvalitetsteamet først involveres i testingen etter at utviklingen er fullført? 

I dette eksempelet kalte de det fortsatt smidig fordi utviklingsteammedlemmene arbeidet med flere grener (eller funksjoner) samtidig på en iterativ måte. Men da funksjonene skulle testes, ventet de til all utvikling var fullført – noe som er kjernen i fossefallsmetodikken. Ettersom selskapene ønsker å arbeide raskere for å kunne utvide kundebasen sin, ender teamene imidlertid ofte opp med å akkumulere teknisk gjeld. 

Den beste måten å løse dette problemet på er å omstille organisasjonen slik at den blir helt smidig, og arbeide hånd i hånd med kvalitetsteamet på en iterativ måte. Dette innebærer å samarbeide med alle interessenter for å sikre at de forstår konsekvensene av å ikke gjøre overgangen, og hvordan dette kan påvirke sluttbrukeropplevelsen. 

Smidige rammeverk og varianter av disse

Innenfor rammene av denne artikkelen vil jeg diskutere to av de mest populære smidige rammeverkene:

1. Scrum
2. Kanban

Scrum er en smidig metodikk som brukes i programvareutvikling, basert på iterative og inkrementelle prosesser. Den består av tidsavgrenset utvikling kalt sprinter. Varigheten på sprintene varierer fra organisasjon til organisasjon, fra ukentlig til månedlig eller kvartalsvis.

Det holdes en sprintplanleggingsøkt, etterfulgt av sprinten der implementering og testing finner sted, inkludert daglige statusmøter, og til slutt avsluttes den med en retrospektiv økt. 

Scrum implementeres vanligvis i produktutviklingsteam der teammedlemmene må tidsavgrense arbeidet sitt for å overholde kundenes tidsfrister. Det gjelder hovedsakelig B2C-applikasjoner, fordi funksjonen din ikke lenger er ny hvis du venter for lenge – noen kan allerede ha implementert den! 

I B2B-applikasjoner, som hovedsakelig brukes av bedrifter, benyttes det ofte en modifisert versjon av smidig metodikk kalt SaFe – skalert smidig rammeverk. 

De fleste prosjektene i bedrifter faller inn under én av følgende kategorier:

1. Teamnivå
2. Programnivå
3. Porteføljenivå

Prosjekter på teamnivå er funksjonsbasert utvikling som innebærer at hvert teammedlem får eierskap til sitt prosjekt og sine prosesser. Disse teamene bruker vanligvis Scrum eller Kanban, avhengig av arbeidets art.

Hvis teamene hører inn under forsknings- og utviklingsorganisasjoner eller testautomatisering, er det avgjørende at de følger Kanban, som er mindre rigid, og at målet i større grad er å fullføre den pågående oppgaven enn å hoppe videre til det neste spennende som dukker opp! Hvis teamene er en del av produktutviklingsorganisasjonen, har de en tendens til å bruke Scrum-prosesser. 

Prosjekter på programnivå involverer flere team som arbeider mot et bestemt mål, for eksempel AWS-migrering. Selv om dette prosjektet kan falle inn under prosjekter på porteføljenivå, vil jeg hevde at det ikke nødvendigvis vil påvirke HR- eller regnskapsteamene.

I dette tilfellet kan prosjektet med AWS-migreringen vare i flere måneder på grunn av uforutsette problemer, så fokuset er på å fullføre AWS-migreringen på en vellykket måte samtidig som den deles opp i begrunnede sprinter. 

Prosjekter på porteføljenivå involverer ulike organisasjoner i selskapet; et eksempel kan være implementering av JIRA. Hver organisasjon vil kreve at JIRA-arbeidsflyter implementeres på ulike måter basert på behovene deres. HR-team trenger ikke testing; fokuset ligger hovedsakelig på å håndtere spesifikke forespørsler fra ansatte, og når de har hjulpet dem, merkes oppgaven som «fullført».

Smidige metoder bør tas i bruk av organisasjoner som er kjent for å gjennomgå konstante endringer. Men disse endringene må fortsatt gjennom en runde med testing og feilretting, og testing er ikke nødvendigvis automatisert, noe som fører til lengre prosesstider.

Til slutt, når funksjonene er klare til å distribueres, overleveres de til bygg-/driftsteamet. Testing skjer altså iterativt sammenlignet med fossefallstilnærmingen, men flyttes ikke langt til venstre, ettersom fokuset ikke ligger på kontinuerlig testing og levering. Derfor er det behov for DevOps-tilnærmingen! 

DevOps-tilnærming

DevOps-tilnærmingen fokuserer på aspekter utover utvikling og testing og fremmer en fullstendig automatisert CI/CD-pipeline sammen med overvåkingsfunksjoner. Mens Agile omfavner endringer, fokuserer DevOps-tilnærmingen på kontinuerlig testing og levering for å sikre at hyppige lanseringer til sluttbrukerne er vellykkede. 

Målet til IT-driftsteamet er å skalere programvareutviklings-prosessen for å fremskynde skrivingen og oppdateringen av koden som er ansvarlig for å opprette nye applikasjoner og tjenester samt oppdatere funksjoner i IT-teamet.

Selv når det gjelder teamoppsett, er kvalitets- og IT-driftsteamene i dag en del av den samme organisasjonen, slik at de kan arbeide tett sammen. Faktisk er det introdusert en ny rolle kalt TestOps som spesifikt fokuserer på å sette opp CI/CD-pipeline der automatiserte tester kjøres mot pull-forespørsler, noe som gir umiddelbare tilbakemeldinger til utviklingsteamene.

Automatisert testing er avgjørende for å skalere testinnsatsen, og verdien går tapt hvis den ikke er en del av kontinuerlig testing og kontinuerlig distribusjons- og utgivelsessyklus. TestOps-personellet har derfor alltid hendene fulle med vedlikehold av infrastrukturen for automatiserte tester.

Dette sikrer at medlemmene av driftsteamet kan konsentrere seg om å levere en infrastruktur i verdensklasse for programvareutvikling uten å bli distrahert av testinfrastrukturen. 

Det finnes i dag mange verktøy og DevOps-praksiser som effektiviserer den overordnede prosessen. 

• En Terraform-tilstandsfil viser til et sett med infrastrukturer som er definert og administrert som én enhet – slik defineres og administreres ulike test- og utviklingsmiljøer. Terraform bidrar til å konfigurere servere, men vi trenger en infrastruktur for å kjøre disse serverne. 

• AWS tilbyr infrastrukturen via EC2-instanser, som for øyeblikket er den mest kostnadseffektive måten å konfigurere og kjøre disse serverne på. Hvis du vil ta det et skritt videre og teknologistakken din har mange mikrotjenester, kan du med docker compose definere og kjøre flere Docker-beholdermiljøer.

• Ansible automatiserer prosessen med å konfigurere maskiner til å kjøre ulike prosesser eller servere. 

• Kubernetes bidrar til å administrere en klynge av disse EC2-instansene som en pod, og planlegger containere som skal kjøre på denne klyngen basert på de tilgjengelige databehandlingsressursene. 

Bør du bruke smidig utvikling eller DevOps?

Selv om smidig programvareutvikling kontra DevOps er en vedvarende debatt i organisasjoner, er den beste måten å se på det å stille oss selv følgende spørsmål:

• Hvor tilpasningsdyktig er organisasjonen vår når det gjelder ny teknologi? 
• Er vi i stand til å konkurrere med konkurrentene våre når det gjelder kvaliteten på produktene våre? 
• Er det sannsynlig at kundene vil bruke produktene våre fordi de oppfyller forventningene deres? 

Hvis svarene på spørsmålene ovenfor innebærer en form for benektelse, er det på tide å fokusere mer på en kombinasjon av begge tilnærmingene og tilpasse den etter behovene våre.

Den ideelle metodikken for programvareutvikling

Den viktigste forskjellen mellom smidige og DevOps-baserte programvareutviklingsprosesser er at førstnevnte i større grad fokuserer på å håndtere konstante endringer, mens sistnevnte fokuserer på kontinuerlig testing, levering og utrulling. Samarbeid mellom utviklings- og driftsteamene er avgjørende for at utviklingsteamet ikke skal bli blokkert. 

Etter min mening bør derfor en ideell programvareutviklingsprosess omfatte følgende:

• Håndtering av kunde- og brukerpersonas og integrering av tilbakemeldinger fra kunder
• Fokus på beste praksis for å forhindre at teknisk gjeld akkumuleres
• Kontinuerlig forbedring, kontinuerlig testing, kontinuerlig integrasjon, kontinuerlig levering, kontinuerlig utrulling og overvåking

Slik ville prosessen sett ut:

Håndtering av ulike kunde- og brukerpersonas er ikke begrenset til produktledelsesteam. Når alt kommer til alt, hvorfor utvikler vi disse produktene? Hva er formålet med produktene hvis de ikke brukes av kundene? 

Ta det klassiske eksempelet med Nokia—da de fortsatte å akkumulere teknisk gjeld fordi de ikke holdt tritt med markedstrendene, særlig innovasjonen fra konkurrenten Apple. De fokuserte på å følge strenge sprintsykluser, bare for til slutt å bli glemt! 

Alle selskaper bør forstå hvorfor funksjonene deres utvikles, og hvilke typer kunder de henvender seg til. Dette vil sikre at vi utvikler funksjoner med brukeren i sentrum. 

Når et nytt produkt lanseres, enten det er en mobilapplikasjon eller en nettapplikasjon, bør du alltid sørge for at kundene har en måte å gi tilbakemeldinger på. Ikke alle selskaper følger en streng prosess for å samarbeide tett med kundestøtten. 

CI/CD

Til slutt bør du fremme AI/ML-basert kontinuerlig integrasjon og kontinuerlig levering. Når et prosjekt mislykkes, betyr det ikke nødvendigvis at teammedlemmene mangler kompetanse; det skyldes i stedet utilstrekkelig testing og at problemer ikke ble oppdaget tidligere i utviklingen.

Men noen ganger går ting galt selv med tilstrekkelig testing og automatisering på plass—så hvis det fantes et anbefalingssystem som kunne identifisere når noe burde lanseres og når det ikke burde lanseres, kunne kanskje slike katastrofale feil vært unngått.

Hyppige iterasjoner hjelper utviklingsteamet med å forstå hva som fungerer og hva som ikke fungerer, og bidrar til å tenke på skalerbarhet. Ulempen er at det er tidkrevende! Hvis et annet anbefalings-/prediksjonssystem kunne samle inn data om kunder og forutsi om en bestemt funksjon ville bidra til å skape gjennomslag eller mislykkes, allerede før utviklingen starter, ville det bidratt til å effektivisere prosessen med å bygge et produkt av høy kvalitet fra dag én! 

Det overordnede målet er å sikre at forretningspåvirkningen øker raskere når denne beste praksisen innføres som en del av utviklingsprosessen. 

Avsluttende tanker

Til syvende og sist spiller både smidig utvikling og DevOps avgjørende roller i moderne programvareutvikling, men det riktige valget avhenger av organisasjonens mål, teamstruktur, prisalternativer og prosjektbehov.

Agil utvikling fokuserer på iterativ utvikling og fleksibilitet, mens DevOps legger vekt på kontinuerlig levering, automatisering og samarbeid mellom utvikling og drift. Mange organisasjoner oppnår gode resultater ved å kombinere begge tilnærmingene for å maksimere effektivitet og kvalitet. Uansett hvilken vei du velger, er det viktig å samordne verktøyene og prosessene dine for å fremme innovasjon og levere verdi raskere.

Hvis du vil ha flere tips om hvordan du kan optimalisere utviklingsarbeidsflytene dine og holde deg oppdatert på bransjetrender, kan du abonnere på nyhetsbrevet til The CTO Club.