DevOps kontra smidig metodikk: Likheter og forskjeller

Smidig utvikling og DevOps er forskjellige ved at smidig utvikling i større grad fokuserer på tilnærmingen til programvareutvikling og -levering, mens DevOps fokuserer på den løpende utrullingen av programvare. Disse to metodikkene har imidlertid også mye til felles, så la oss utforske dem.

Smidig utvikling versus DevOps er et tema som ofte dukker opp, men det grunnleggende skillet ligger i fokusområdene og metodikkene deres. Smidig utvikling er en filosofi som dreier seg om tilnærmingen til programvareutvikling og -levering, med vekt på trinnvis fremgang og samarbeid. DevOps handler derimot mer om den løpende utrullingen av programvare, ved hjelp av moderne verktøy og automatiserte prosesser for å effektivisere og forbedre effektiviteten ved kodeutrulling.

Økende krav om digitalisering, samtidig som bekymringen for datasikkerhet øker, har lagt større press på programvareutviklingsteam over hele verden. Kunder og interessenter forventer at utviklingsteamene skal gjøre mer med mindre, samtidig som tiden det tar å få tekniske produkter ut på markedet, skal reduseres.

I dette miljøet er det avgjørende for å lykkes å velge riktig metodikk for programvareutvikling. Når de står overfor to ledende metodikker, DevOps og smidig utvikling, kan teknologidirektører stille spørsmål ved om det å satse på den ene eller den andre vil gi bedre forretningsresultater. 

Likheter mellom smidig metodikk og DevOps

Programvareutvikling har vokst eksponentielt de siste årene. Ifølge data publisert av IBISWorld, økte inntektene med 3,1 % mellom 2018 og 2023 — selv om inntektene i mange andre sektorer slet. 

Hvis du prøver å velge mellom en smidig tilnærming eller DevOps-metodikk for arbeidsflyten din innen programvareutvikling, er det viktig å forstå hvor Venn-diagrammet for disse to valgene overlapper. 

Forstå smidig metodikk

Smidige praksiser er relevante for utvikling og prosjektledelse. Når de implementeres på riktig måte, kan de gi generelle positive fordeler for tekniske team, avdelinger og hele organisasjoner.

Oversikt over smidige prinsipper

Smidig utvikling bygger på en rekke sentrale verdier og prinsipper. De fire grunnleggende verdiene i smidig utvikling er:

• Individer og samhandling. Smidig utvikling prioriterer menneskene som er involvert, inkludert teammedlemmer og kunder, fremfor prosesser og verktøy. Dette omfatter organiske tilbakemeldingssløyfer, retrospektiver og daglige standup-møter for å ivareta behovene til enkeltpersonene gjennom hele prosessen.
• Fungerende programvare. Det viktigste målet med smidig utvikling er å levere fungerende programvare raskt, og resultater prioriteres fremfor omfattende dokumentasjon. 
• Samarbeid med kunden. Smidig utvikling er i sin natur en samarbeidsprosess. Den fungerer godt for interne team og solide partnerskap, blant annet fordi samarbeid prioriteres fremfor strenge kontraktsforhandlinger.
• Å reagere på endringer. Smidige team er fleksible. De er rustet til å reagere raskt på endringer i stedet for å holde fast ved et veikart eller en plan som kanskje ikke lenger er relevant.

I tillegg til de fire verdiene bidrar 12 prinsipper fra Det smidige manifestet til å styre hvordan denne metodikken fungerer. Disse prinsippene omfatter:

De smidige prinsippene støtter løpende kommunikasjon og kvalitet gjennom prosessen. De omfatter også krav om rask handling, blant annet å levere fungerende programvare på korte tidsrammer og bruke retrospektiver til å reflektere over prosessen og resultatene.

Smidighet er avgjørende for å håndtere usikkerhet i teknologiprosjekter.

Smidig utvikling for CTO-er

Agiles positive forhold til endringer, avhengighet av sprinter og andre hurtige arbeidsformer, samt fokuset på rask programvareutgivelse som mål, støtter den fleksible utviklingen som kreves i dagens teknologilandskap.

 

Tradisjonell teknologi krever at man med jevne mellomrom utvikler et veikart for å samordne teknologisk arbeid med forretningsmål. Organisasjoner som sentrerer arbeidet rundt veikart, støtter imidlertid kanskje ikke nye forretningsbehov. Smidig utvikling gir et rammeverk som styrer det teknologiske arbeidet, samtidig som det fjerner ufleksibiliteten ved tradisjonelle tilnærminger.

 

En CTO i helsesektoren kan for eksempel ha fått i oppgave å utvikle bedre pasientportalløsninger etter at forretningsmålinger viste at pasientkommunikasjon var en utfordring. Med en tradisjonell tilnærming kan dette bli et punkt i veikartet for teknologisk utvikling det året. Hvis medisinske faktureringsteam senere oppdager en feil i løsninger for erstatningskrav, kan teknologiteamet imidlertid være ute av stand til å flytte innsatsen på en hensiktsmessig måte for å arbeide med dette nye behovet.

 

Smidige team har ikke denne begrensningen. De kan raskt gå fra én oppgave til en annen og til og med videreutvikle en bestemt oppgave underveis. Det opprinnelige kravet til pasientportalløsningen kan for eksempel ha vært å gjøre det enklere for pasienter å sende meldinger til behandlere. Hvis ytterligere tilbakemeldinger fra kunder viser at fakturering er en like stor bekymring, kan teknologiteamet også endre kurs og legge til faktureringsløsninger.

Avmystifisering av DevOps

DevOps-kulturen bruker ofte mange akronymer og tekniske begreper, så den kan ved første øyekast virke langt mer kompleks enn smidig utvikling. Selv om DevOps-team kan gjennomføre prosesser og trinn som smidige team hopper over, er det overordnede målet med begge prosessene å skape nye produkter, gjennomføre forbedringer og samarbeide godt med tverrfunksjonelle team i virksomheten.

Kjernebegrepene i DevOps

DevOps-praksiser følger ofte CALMS-rammeverket. CALMS står for kultur, automatisering, Lean, måling og deling. Disse kan regnes som noen av kjernebegrepene i DevOps.

• Kultur – Det gir liten nytte å ta i bruk DevOps-verktøy uten forankring og et blikk for endringer i teknologiprosessene. For at DevOps skal fungere, må operasjonelle endringer i IT-prosessene bli standard, og interessenter fra hele virksomheten må forstå hvordan disse endringene kan forbedre de tekniske resultatene.
• Automatisering – Automatisering reduserer kjedelig og repetitivt arbeid og frigjør tekniske ressurser til å utvikle kreative løsninger.
• Lean – DevOps-team leter etter muligheter for kontinuerlig forbedring på tvers av alle prosesser og oppgaver. De aksepterer at feil er en del av prosessen, og kan lære av utilfredsstillende resultater for å forbedre fremtidige resultater.
• Måling – Kontinuerlig forbedring krever data som kan gjennomgås. DevOps-team er opptatt av sentrale ytelsesindikatorer og andre måleverdier, som bidrar til å informere beslutningene de tar i det løpende arbeidet.
• Deling – En sterk DevOps-kultur innebærer at virksomheten deler ansvar og forpliktelse for løsningene. I slike strukturer arbeider utviklerne ofte også videre med å betjene produktet.

DevOps' rolle i drift og infrastruktur

DevOps arbeider med å effektivisere prosesser og støtte kontinuerlig integrasjon og levering. I teorien er dette de samme målene som smidig utvikling har. DevOps fungerer imidlertid innenfor en mer strukturert tilnærming som driftsteam i større virksomheter kanskje lettere kan forutse og forstå. 

Eksempel

Vurder Netflix som et eksempel. Den populære strømmetjenesten har benyttet DevOps-kultur og -verktøy i over et tiår — helt siden den gjorde det enestående skiftet fra å sende lånte DVD-er til å strømme digitalt innhold. Netflix er en enorm virksomhet med tusenvis av bevegelige deler. Sammen med partnere som Amazon Web Solutions støtter den også en enorm mengde server- og digital aktivitet.

 

DevOps-metodikken er avgjørende for Netflix’ suksess. Strømmetjenesten satser så grundig på CALMS-konseptene at den automatiserte feil for å sikre at den kontinuerlig lærte og forbedret seg for å forhindre feil som sluttbrukere kan oppdage. Dette er én av grunnene til at Netflix-kontoen din fungerer så stabilt.

Agile vs. DevOps: Hva er forskjellen?

Selv om de overordnede målene kan være de samme, fungerer ikke Agile-team og DevOps-team på samme måte. Det finnes kritiske forskjeller i hvordan disse utviklingsteamene ledes og arbeider i virksomheter.

Tilnærming til programvareutvikling

Kanskje den viktigste forskjellen er Agiles iterative utvikling sammenlignet med DevOps' kontinuerlige levering.

Agiles iterative tilnærming

Den sprintbaserte tilnærmingen og fleksibiliteten i smidig programvareutvikling prioriterer tilbakemeldinger fra kunder og støtter kortere utviklingstider totalt sett. Agile-utviklere itererer gjentatte ganger for å forbedre tilbudene over tid, uavhengig av om programvaren utvikles via plattformer med lite kode eller ved hjelp av mer tradisjonelle metoder. Hver sprint i denne tilnærmingen kan resultere i et produktinkrement som kan leveres, noe som kan bidra til løpende kundetilfredshet og engasjement blant interessenter. 

Et eksempel på Agile-suksess kommer fra CISCO – de bruker et «team av team» for å støtte trinnvise Agile-leveranser. CISCO bruker Agile-metodikk til å styre prosjekter, skape nye funksjoner og lansere feilrettinger.  

DevOps’ kontinuerlige leveranse

DevOps-team arbeider med kontinuerlig integrasjon og kontinuerlig levering for å forkorte livssyklusen for system- eller programvareutvikling uten at det går ut over kvaliteten på leveransene. De slår automatisk sammen kode i hovedproduktet uten å vente på bestemte lanseringsdatoer. Dette muliggjør kontinuerlige oppdateringer samtidig som det reduserer integrasjonsutfordringene som oppstår ved større oppdateringer.

Verktøy for kontinuerlig levering følger denne prosessen og distribuerer kode automatisk til de aktuelle test- og produksjonsmiljøene. Leveringen kan skje etter en fast tidsplan, for eksempel ukentlig. I mange virksomheter gjennomføres kontinuerlig levering under nattlige systemoppdateringer. Kontinuerlig utrulling kan effektivisere integrasjonene ytterligere. Her lanseres oppdateringer til kunder eller sluttbrukere umiddelbart etter automatisert testing.

Evnen til å levere sanntidsoppdateringer til hundretusenvis av kunder som bruker AWS, er avgjørende for den digitale gigantens suksess, og det er ofte komplekse automatiserte testprosesser som må stanse utrullingen hvis det oppstår en kritisk feil.

Teamstruktur og samarbeid

Hvordan teamene er organisert — og hvordan de samarbeider med andre i virksomheten — varierer avhengig av hvilken modell du velger.

Agile-teamets dynamikk

Agile-team består vanligvis av utviklere, scrummastere og produkteiere. De arbeider gjennom daglige standup-møter og regelmessige møter, og kan bruke verktøy som kanban-tavler til å håndtere oppgaver. Agile-team er vanligvis små og tverrfunksjonelle; de er ofte selvstyrte innenfor rammene av rollene og mandatene sine. Hvert teammedlem eller gruppen kan ta prosjektbeslutninger eller endre fokus uten spesifikke anbefalinger fra ledelsen.

Hvert Agile-team kan være ansvarlig for et bestemt prosjekt eller til og med et spesifikt fokusområde innenfor et større produkt. De kan også gå fra én innsats til en annen, noen ganger som et teknisk beredskapsteam, uten å se hele programvarens livssyklus.

Fokus for DevOps-team

I motsetning til smidige team er DevOps-team ofte ansvarlige for hele programvareutviklingslivssyklusen. De kan fortsette å støtte produkter etter at de er tatt i bruk. Teamene består av utviklings-, QA-, IT-drift- og sikkerhetsressurser, med langt mer samarbeid på tvers av team og avdelinger enn i smidig utvikling.

Mens smidige team måler suksess ut fra leveringen av fungerende programvare, bruker DevOps-team ytelsesindikatorer, som ledetid for endringer og distribusjonsfrekvens, til å måle suksess.

Smidig utvikling og DevOps: Komplementære eller motstridende?

Ofte krever optimaliseringen av programvareutviklings prosesser og bruken av teammedlemmer en hybrid tilnærming. I slike tilfeller kan CTO-er ønske å bruke DevOps som en overordnet praksis og benytte smidige metoder innenfor dette rammeverket for å håndtere behov for rask utvikling eller endringer i fokus.

Du kan for eksempel ha en DevOps-kultur, men innenfor denne ha et eget smidig prosjektteam. Du kan bruke dette teamet til å håndtere endrede eller spesielle behov som oppstår i løpet av året, og som ikke er i tråd med et DevOps-veikart.

Hva du kan gjøre videre

Det finnes mange verdifulle ressurser om programvareutvikling, inkludert nyhetsbrev om utvikling, som du kan bruke til å lære mer.

For CTO-er og teknologiledere som står i front innen utvikling, meld deg på nyhetsbrevet vårt for ekspertråd om suksess og utfordringer knyttet til smidig utvikling og DevOps.