Softwareudviklingens livscyklus (SDLC) er den syvtrinsrejse, som al software gennemgår – fra den første idé til vedligeholdelsen af et færdigt produkt. Betragt det som en flod med syv sluser: Vandet når havet uanset hvad, men det er i sluserne, du styrer vandstanden, og en sluse, du aldrig har bygget, er en, du ikke kan lukke, når vandet stiger.
Denne artikel kortlægger 18 agile praksisser i forhold til disse stadier, så du kan se, hvad der hører til hvor, hvad det koster at implementere, og hvilken risiko det eliminerer. Den er skrevet til dig, der beslutter, hvor leveringsbudgettet skal placeres: en CTO, en teknisk chef eller en produktleder, der skal prioritere investeringer og stå til ansvar over for en bestyrelse. Praksisserne anvendes på tværs af softwarelivscyklussen af teams verden over, herunder vores eget hos Imaginary Cloud.
SDLC står for Software Development Life Cycle. I modsætning til hvad mange tror, er det hverken et framework eller en fastlagt proces. Det er en konceptuel model: en måde at illustrere, hvordan software bliver til, gennem en række trin fra idégenerering til levering.
Uanset hvilken metodik dit team bruger, dækker den alle syv trin i større eller mindre grad. En vandfaldsmodel behandler hvert trin som en separat fase, hvor afslutningen på hver fase fungerer som en milepæl, der skal godkendes, før den næste fase kan begynde. En agil metodik samler de samme syv trin i gentagne, cykliske og iterative forløb, hvor alle trin gennemgås i hver iteration.
Konceptet bag agil softwareudvikling har eksisteret i årtier. Indtil slutningen af 90'erne var vandfaldsmodellen normen, og det samme var klagerne: tunge processer, manglende fleksibilitet og en dyb modstand mod forandring. Så opstod en ny retning.
Det var her, agile metoder (som dengang ikke engang havde det navn) såsom Scrum, XP, Crystal, Feature-Driven Development (FDD) og Dynamic Systems Development Method (DSDM) begyndte at dukke op.
Fire ting. Agil udvikling byder ændrede krav velkommen i stedet for at fastfryse dem, leverer software løbende i stedet for i én samlet udgivelse, bringer forretningsfolk og udviklingsteamet i tæt og løbende kontakt og indbygger regelmæssig refleksion over, hvordan man kan forbedre sig.
Buzzwords og trends kommer og går. Den virkelige fordel ved agil udvikling er at tage de kendte, kedelige og tilbagevendende problemer inden for softwareudvikling og se på dem fra en ny vinkel.
I stedet for den fortærskede vej med at gennemgå de fire værdier i det agile manifest, vil vi tale om de agile principper og best practices. De bliver ofte overset, hvilket er en skam, da de indeholder langt mere af den detaljerede tankegang, som agil udvikling skal bidrage med.
De tolv principper bag det agile manifest, som er publiceret på agilemanifesto.org/principles, er referencepunktet for alt det nedenstående.
En "praksis" er "den faktiske anvendelse eller brug af en idé, overbevisning eller metode, i modsætning til teorier relateret til den". Hvilket er præcis, hvad en Agile-praksis er: teorien om at være agil, anvendt på noget virkeligt.
Du kan bruge disse praksisser uden at følge nogen specifik Agile-metodologi overhovedet. At bruge TDD (Test Driven Development) alene gør naturligvis ikke din leverance agil. De fleste af disse kaldes Agile-praksisser, fordi de enten opstod fra en Agile-metodologi eller blev opfundet af Agile-udøvere.
Forskellige metodologier fremmer forskellige praksisser for at gøre dem mere objektive og produktive. Hver enkelt fokuserer generelt på et enkelt aspekt: ledelse, udvikling, test og så videre.
Her er listen, kortlagt til trinene i din SDLC. Flere af dem gør sig gældende mere end én gang i løbet af et projekt, og en praksis, der dækker ét stadie fuldt ud, vil ofte dække det næste delvist. Tommelfingerreglen har altid været: mindre fokus på at være striks, mere fokus på at opnå de ønskede resultater.
Hvis du skal beslutte, hvor du vil investere først, viser tabellen nedenfor, hvad det typisk kræver at indføre praksisserne på hvert SDLC-stadie, hvilken risiko det fjerner, og hvor lang tid der går, før det kan ses i leverancen.
| SDLC-fase | Omkostning ved indførelse | Risiko, der fjernes | Tid til gevinst realized |
|---|---|---|---|
| Planlægning | En til to workshopdage for product owner, lead engineer og forretningssponsor | Udvikling af det forkerte produkt samt uenigheder om scope senere i projektet | Omgående: Visionen og backloggen udgør den plan, teamet arbejder ud fra |
| Analyse og krav | En uges arbejde for et tværfagligt team til en Lean Inception eller designproces | Krav, der opdages midt i udviklingen, hvor de er dyrest at indarbejde | En til to sprints, når backloggen holder op med at ændre sig konstant |
| Design og prototyping | Nogle dages arkitektonisk spike-arbejde samt disciplinen til at holde designbeslutninger åbne | En forhastet arkitektur, der skal omstødes, når de reelle krav opdages | Et til to kvartaler, når ændringsanmodninger ophører med at ramme fundamentet |
| Udvikling | Værktøjer til kontinuerlig integration og en fast andel af udviklernes tid afsat til testskrivning | Integrationskonflikter, regressioner og teknisk gæld, der hober sig op i det skjulte | En til tre måneder, når testpakken er dækkende nok til at opdage regressioner |
| Test | Testautomatisering samt værktøjslicenser og den pipeline-tid, det afvikles på | Fejl, der når produktion, og manuelle testcyklusser, der bliver længere for hver release | Et til to kvartaler, efterhånden som regressionscyklusser forkortes fra dage til minutter |
| Deployment og drift | Arbejde med Infrastructure-as-Code og DevOps-kapacitet, uanset om den rekrutteres eller opbygges internt | Langsomme, risikable releases og lange genoprettelsestider, når noget går galt | Tre til seks måneder, målt på deployment-frekvens og gennemsnitlig genoprettelsestid |
Planlægningspraksisser er de billigste på denne liste, og de eneste, der giver øjeblikkeligt afkast. En uges tid fra de rette personer er det, der forhindrer et team i at bruge seks måneder på at bygge det forkerte produkt.
Dit projekts første fase bør være produktvisionen. Den indledende vision kræver en håndfuld korte definitioner: hvem kunderne er, hvem teamet er, et overordnet omfang (og hvad der ligger uden for omfanget), skitser af den tekniske tilgang, potentielle risici samt estimeret tid og omkostninger.
En god tilføjelse her er visionserklæringen, også kendt som en "elevator pitch". Den kan rummes i en enkelt sætning: for en målkunde, der har et behov, er produktet en kategori, der leverer en vigtig fordel, i modsætning til den primære konkurrence, på grund af én klar differentiator.
Hvis du validerer en ny idé, er det her, tankerne om et minimum viable product starter, længe før en linje kode er skrevet.
Et Business Model Canvas former det produkt, du er ved at bygge, og giver en praktisk tilgang til at definere forretningsmodeller. Brugt sammen med Lean Startup fungerer det som et visuelt overblik over idéerne og opfattelserne bag en eksisterende eller ny forretning.
Det fungerer ved at tvinge forretningsmodellen ned på en enkelt side, opdelt i ni blokke: aktiviteter, partnere, ressourcer, værditilbud, kunder, kundekanaler, kunderelationer, omkostninger og indtægter. Ved at udfylde disse blokke omdannes antagelser til hypoteser, som du kan navngive, diskutere og teste. Det er her, værdien for en planlægningssession ligger.
Produktbackloggen er listen over forretnings- og projektmål, der indeholder det, som teamet forventes at udvikle, og som vedligeholdes af produktejeren. Det er et levende dokument: opdateres løbende, prioriteres og sorteres efter forretningsværdi.
Den kan også indeholde produktforbedringer, fejl, tekniske spørgsmål og lignende. Formålet er at have alt, hvad der er nødvendigt for at nå projektets produktvision, samlet ét sted.
Et krav, der findes under en workshop, koster blot en samtale. Det samme krav, fundet midt i udviklingsfasen, koster omarbejde, og fundet efter lancering koster det en hotfix og tilliden fra den, der bad om det. Det er det gab, som ugen her køber dig.
Paulo Caroli skabte Lean Inception som sin tilpasning og videreudvikling af den Inception-fase, der blev brugt hos ThoughtWorks. Ideen er at kombinere Design Thinking og Lean Startup i en discovery-workshop, der definerer produktets MVP: det mindste levedygtige produkt, altså den mindste version af et produkt, der stadig leverer værdi til brugeren.
I løbet af en uge har workshoppen til formål at finde den retning, teamet skal tage for at bygge det ideelle produkt. Tænk på det som en udvidet udgave af emnet produktvision ovenfor. Den dækker også definitionen af personaer, brugerrejser, funktioner samt tekniske, UX- og forretningsmæssige gennemgange – alt sammen inden for den uges tidsramme.
Vores Produktdesignproces er den måde, vi hos Imaginary Cloud definerer skabelsen af digitale produkter på. Vi bruger den internt i vores egne projekter, og forskellige aktører i branchen bruger den eksternt. Den dækker de nødvendige skridt for at skabe en løsning, der fungerer for både forretningen og brugeren, og placerer kunder og produktejere – sammen med brugerne – i centrum for diskussionen.
Det kan tage fra en til nogle få uger, afhængigt af hvor komplekst produktet er, og hvor dybt vi skal grave for at definere løsningen. Tolv trin, der strækker sig fra research og idégenerering til eksekvering og teknisk vurdering, for at identificere produktets retning så præcist som muligt. Vi har beskrevet, hvordan processen opstod, og hvert enkelt trin i den, i vores guide til produktdesignprocessen.
Vi nævnte tidligere produktbackloggen som en måde at strukturere dine produktmål på. Det er værd at vise en metode til at arbejde med den, forudsat at du bruger User Stories til at oprette og vedligeholde backloggen.
User Story Mapping, teknikken beskrevet af Jeff Patton, giver mulighed for en visuel opdeling eller "opskæring" af user stories, så de kan håndteres i en sekventiel rækkefølge, der giver mening for produktet: rygraden først, mindre detaljer bagefter.
Hvorfor gøre det? Fordi det viser, hvordan funktioner fordeler sig over hele projektet frem for blot at være en grupperet liste. Hvor tynde eller tykke "skiverne" skal være, med henblik på en sammenhængende fortælling, afgøres ved at tale direkte med kunder og brugere.
Designtilvalg er de dyreste at lave om. Praksisserne her er bevidst lette: Lås dig kun fast på lige præcis nok arkitektur til at komme i gang, og hold resten åbent, indtil kravene er konkrete.
Domain Driven Design, eller DDD, strukturerer softwarearkitekturmodeller ved hjælp af en abstraktion af applikationens forretningsdomæne. Det kræver, at de tekniske og forretningsmæssige sider arbejder sammen, hvilket er her, en af DDD's vigtigste egenskaber kommer ind i billedet: et fælles sprog (ubiquitous language). Det betyder et aftalt sæt termer for domænet, som udviklere, testere og forretningsinteressenter alle bruger i koden, i samtalen og i dokumentationen.
Da DDD læner sig så tungt op ad domænelaget og udnytter koncepter fra objektorienteret programmering, blev det populært i OOP-miljøet. Grundtanken fungerer dog uanset programmeringsparadigme, især fordi det kan bruges som fundament for TDD, BDD, CI, refactoring og resten af værktøjskassen.
DDD opdeler domænet i afgrænsede kontekster (bounded contexts), som er områder af forretningen, hvor én model og ét ordforråd gælder konsekvent. Inden for disse modelleres Entities – objekter med en identitet, der består gennem ændringer, såsom en kunde – og Value Objects – objekter, der kun defineres af deres attributter, såsom en postadresse. Sammen skaber de et strategisk design for applikationen, der kombinerer domænets struktur, livscyklus og adfærd på en præcis og sammenhængende måde.
Spike er et almindeligt agilt begreb, lånt fra XP (Extreme Programming). Det refererer til en type brugerhistorie, der bruges til at udforske en tilgang og opnå lige præcis nok forståelse til at reducere risikoen ved at vælge den. En arkitektonisk Spike går et skridt videre og fokuserer på softwaredesign og arkitektur.
Den definerer rygraden i modelleringsarkitekturen og hvordan det hele hænger sammen, pragmatisk nok til at løsningen foreslås ud fra den begrænsede information, der er tilgængelig om domænet. Definitionerne involverer typisk softwarelag, undersystemgrænser, sandsynligvis noget fungerende kode og kildekontrolværktøjer som et minimalt skelet for applikationen. Det understøtter systemmetaforen, en "enkel fælles fortælling om, hvordan systemet fungerer", som alle på projektet kan bruge til at beskrive det.
Efterhånden som projektet og applikationen udvikler sig, tilpasses og forfines arkitekturen i takt med dem. Den arkitektoniske Spike er kun den første opgave i den retning, og nedenstående praksis dækker, hvad der sker derefter.
Det ellevte princip i det agile manifest siger, at "de bedste arkitekturer, krav og designs opstår fra selvorganiserende teams". Rent designmæssigt spekulerer du måske stadig på, hvad det betyder i praksis.
Emergent Design opbygger løsningen evolutionært og lader designet og arkitekturen tage form gennem hele udviklingsrejsen. For at bruge fagjargon: I stedet for BDUF (Big Design Up Front) får du JEDI (Just Enough Design Initially).
Ved at arbejde inkrementelt får udviklere plads til at fokusere på det, projektet rent faktisk har brug for, og man undgår en tidlig, suboptimal arkitektur. Håndter de krav, du har. Lad være med at designe til dem, du gætter dig til.
Er Emergent Design ubestridt? Langt fra. Indvendingen er, at hvis man lader rygraden i en applikation være udefineret, risikerer man, at strukturelle beslutninger træffes stykkevis af den, der tilfældigvis skriver koden den uge. Risikoen er reel, og det er præcis derfor, den arkitektoniske Spike findes: et skelet, der er lige præcis stort nok til at starte med, og ikke mere.
Det er her, de vedvarende omkostninger ligger. Værktøjer til kontinuerlig integration er billige. Den tid, udviklere bruger på at skrive tests, er det ikke, og det stopper aldrig. Det, du får for pengene, er evnen til at ændre kodebasen i år tre lige så hurtigt, som du kunne i måned tre.
Kontinuerlig integration (CI) betyder, at man har én primær kodestrøm, der modtager de ændringer og tilføjelser, som udviklere foretager separat i et enkelt projekt-repository eller en branch. Hver integration bør udløse en række trin, såsom automatiserede tests og værktøjer til kontrol af syntaksstil, der normalt styres af et CI-værktøj sammen med et versionsstyringssystem.
XP foreslår at gøre dette flere gange om dagen, så der altid findes en kørende, integreret version af koden. CI er den første fase i en kæde, der dækker kontinuerlig udrulning (hvor en applikation frigives til produktion, hvis den består alle trin i den automatiserede udrulningsproces) og kontinuerlig levering (hvor kodebasen til enhver tid er klar til udrulning i forskellige miljøer).
Standardstrategien for kontinuerlig integration er den, der beskrives af Martin Fowler: et enkelt kilde-repository, et automatiseret og selvtestende build, hyppige commits til hovedgrenen, et hurtigt build, der holdes i funktionsdygtig stand, og en gennemsigtig, synlig pipeline.
Fordelene hober sig op: fejl opdages mere effektivt, intet overhead fra manuel integration, miljøer er altid tilgængelige til build-formål, en mere gennemsigtig proces (og dermed bedre kommunikation) og en mere robust testdækning. CI skaber også plads til pull requests og kodegennemgang.
DORA, forskningsprogrammet der startede i 2014 og siden har indsamlet data fra titusindvis af it-professionelle, finder konsekvent kontinuerlig integration blandt de tekniske evner, der forudsiger højere softwareleveringsperformance, målt på gennemløb og stabilitet. Et punkt, der er værd at holde sig opdateret på: I sin 2025-rapport droppede DORA akronymet for at stå alene, omdøbte den årlige undersøgelse fra "Accelerate State of DevOps" til State of AI-assisted Software Development, og videreudviklede de oprindelige fire leveringsmetrikker til fem ved at tilføje en pålidelighedsdimension ved siden af udrulningsfrekvens, gennemløbstid for ændringer, fejlrate ved ændringer og tid til genopretning efter mislykket udrulning.
Testdrevet udvikling, eller TDD, er test-først-programmering. Ved hjælp af automatiserede enhedstests følger det et gentageligt flow:
Målene er klarere, enklere og fejlfrit kode, skrevet af en person, der har været nødt til at tænke over struktur, interne grænseflader og ansvarsområder, før en eneste linje blev skrevet.
Mange værktøjer understøtter enhedstest og TDD. De mest kendte er xUnit-familien, de enhedstest-frameworks, der er modelleret efter det oprindelige SUnit: JUnit, NUnit, XPyUnit, PHPUnit og deres relaterede værktøjer.
For en udvikler, der aldrig har arbejdet på denne måde, er TDD et paradigmeskift. Den gængse indvending er, at det kræver for meget tid og energi til at kunne betale sig. Find middelvejen: TDD bør give dig både mere testet og dermed renere kode.
Et lille forbehold. TDD kan ikke udgøre hele din kvalitetssikringsstrategi, hvilket vi kommer ind på, når vi taler om QA. Og de automatiserede tests, det genererer, bør være en del af din Continuous Integration-strategi, da det at køre dem er et af de skridt, der får CI til at fungere.
To definitioner af refactoring fra Martin Fowler er værd at have i baghovedet. Den første kalder det en disciplineret teknik til at omstrukturere en eksisterende kodebase ved at ændre dens interne struktur uden at ændre dens eksterne adfærd. Den anden definerer det som en ændring af softwarens interne struktur, der gør den lettere at forstå og billigere at ændre, igen uden at ændre dens observerbare adfærd. Begge er beskrevet på Fowlers egen definition af refactoring.
Behovet for det melder sig typisk som en "code smell": et tegn på, at en reorganisering er påkrævet på grund af en svaghed eller et potentielt problem i koden. En almindelig brug af refactoring er at afvikle teknisk gæld, som akkumuleres i det stille og viser sig som langsommere levering, længe før nogen kalder det et problem. I TDD kaldes det trin, hvor man omskriver kode, der består testen, i øvrigt også for refactoring.
Vi kan sætte tal på dette. Da AppTweak, en platform til app-store-optimering, henvendte sig til os angående deres dashboard på forsiden, var det ærlige valg enten at genopbygge eller refaktorere. Vi valgte at refaktorere. Vores frontend-udviklere blev integreret i et af AppTweaks egne teams, arbejdede efter deres projektstyringsregler i stedet for at indføre vores, og omstrukturerede dashboardets tilstandshåndtering i React og TypeScript med Redux og Redux-Saga. Den observerbare adfærd forblev uændret; det gjorde de interne dele ikke. Indlæsningstiden faldt med 80 procent. Det er argumentet for refactoring i en nøddeskal: brugerne fik et hurtigere dashboard, og ingen behøvede at stoppe leveringen af nye funktioner for at opnå det.
Det forbehold, vi vil give enhver CTO, der overvejer det samme: refactoring er berettiget, når arkitekturen er sund, og koden blot er forfaldet omkring den. Når den underliggende model er forkert, polerer du noget, du burde udskifte, og en genopbygning – ikke en refactoring – er den mest ærlige investering.
Det kan være svært at retfærdiggøre indsatsen på kode, der allerede virker. Det øger dog vedligeholdelsesvenligheden, kohæsionen, læsbarheden, ydeevnen og genanvendeligheden, hvilket tilsammen plejer at retfærdiggøre tidsforbruget.
Refactoring handler ikke om at skabe nye funktioner. Det ligger uden for formålet. Målet er altid at bevare den nuværende adfærd intakt, med eksisterende eller nye tests på plads som garanti. Almindelige eksempler: brug af designmønstre, polymorfi, indkapsling af felter, ændring af brug af parametre, exceptions og så videre.
Testning er den fase, hvor omkostninger og risici er lettest at kvantificere. Automatisering medfører udgifter til både udvikling og licenser. Alternativet er en manuel regressionscyklus, der bliver længere for hver release, indtil den dikterer tempoet for hele projektet.
BDD eksisterer for at forhindre, at forretningen, udviklingsteamet og testteamet arbejder ud fra tre forskellige forståelser af den samme funktion.
BDD står for Behaviour-Driven Development – en udviklingstilgang, der forbedrer kommunikationen mellem forretningsmæssige og tekniske teams for at skabe software med forretningsværdi. Formålet er at fungere som bindeled mellem forretningsfolk, udviklere, QA-testere og alle andre på projektet, så applikationens egenskaber forstås og beskrives ens af alle. Det opnås ved at skrive specifikationer som scenarier og eksempler ved hjælp af "Given-When-Then"-mønsteret, der repræsenterer løsningens faktiske adfærd.
ATDD (Acceptance Test-Driven Development) går et skridt videre ved at bruge BDD som grundlag for at implementere kodede accepttest baseret på den adfærd, som scenarierne har defineret. Det minder om TDD: automatiser en række fejlslagne accepttest, og skriv derefter den kode, der får dem til at bestå.
Testværktøjer som Behat, Cucumber og SpecFlow understøtter eksekverbare specifikationer, hvilket gør det muligt at køre ATDD på baggrund af det, BDD har defineret.
Automatiseret testning er ikke formelt en agil praksis, men det er den struktur, som kvalitetssikring i agile miljøer hviler på, og den praksis, der gør ATDD, TDD og CI værd at benytte. Uden den bliver kvalitetssikring en fase frem for en vane.
Det indebærer brug af separat software til at køre test mod din egen software: eksterne grænseflader, såsom mobil- eller browserbaseret GUI-testning; intern kommunikation mellem lag, såsom API'er; eller performance. Den klareste fordel er at undgå gentagelse af manuelle processer samt de menneskelige fejl, som gentagelser medfører.
Du ser fordelen i strategier som regressionstest eller i en Continuous Integration-pipeline. Det er værd at overveje, hvad der skal automatiseres, og hvornår, da disse test kræver en vis indsats at implementere.
Beslutninger om dækning er også vigtige: unit-test, integrationstest eller de bredere end-to-end-test kræver forskellig indsats og giver forskellig værdi afhængigt af dit fokus. DORA's forskning identificerer konsekvent kontinuerlig testning – altså automatiserede test, der kører ved hvert commit frem for i en fase før release – som en af de evner, der adskiller højtydende leveringsteams fra resten.
Lignende logik gælder for værktøjskassen, som fortjener en grundig evaluering frem for et standardvalg. Selenium, Jasmine og RSpec er eksempler på værktøjer bygget til forskellige testformål.
Sessionsbaseret testning er en anden praksis, der aldrig officielt blev erklæret agil, men som alligevel er blevet bredt adopteret i den agile verden. Det er en mere struktureret måde at udføre manuel eksplorativ testning på: at teste software uden forudgående design eller definerede testcases, hvor man frit går på jagt efter fejl.
Den følger en "del og hersk"-filosofi, hvor tidsbegrænsede test opdeles i sessioner. Trinene er mission, charter, session, sessionsrapport, debriefing og parsing, som tilsammen dækker det, processen har brug for, med netop den rette mængde detaljer.
I en agil kontekst kan du definere flere sessioner pr. user story og gå mere eller mindre i dybden afhængigt af den risiko, der er forbundet med hver enkelt. Den fleksibilitet gør, at praksissen kan følge med tempoet.
Manuel testning har stadig sin berettigelse ved siden af automatisering. En eksplorativ session finder de fejl, som ingen havde tænkt på at skrive en test for, og det er netop den type fejl, der når ud i produktion. Begge strategier tilsammen er det, der garanterer den kvalitetssikring, et projekt har brug for.
Disse praksisser er længst tid om at give afkast, og deres fravær er mest synligt. Implementeringsfrekvens og gennemsnitlig tid til genopretning er de to tal, en bestyrelse før eller siden vil spørge ind til, og begge fastlægges på dette stadie.
DevOps er kombinationen og samarbejdet mellem udviklings- og it-driftsteams for at opnå kontinuerlig og hurtig levering. Det får begge parter til at arbejde sammen og understreger, hvor vigtig deres kommunikation og integration er gennem konceptet Infrastructure as Code (IaC).
Vejen dertil involverer infrastrukturautomatisering (systemer, konfigurationer og app-implementeringer, der håndteres som kode i projektets struktur), kontinuerlig levering (byg, test og implementer apps på en automatiseret og rettidig måde) samt Site Reliability Engineering (drift af systemer, hvilket betyder overvågning og orkestrering, og sikring af, at de understøtter disse funktionaliteter fra starten).
Det danner grundlaget for "DevOps-stigen":
Fordelene ved at bruge DevOps inkluderer skalerbarhed, pålidelighed, sikkerhed, hurtig levering (og hurtigere tid til markedet, hvor det er relevant), kortere gennemsnitlig tid til genopretning (MTTR), forebyggelse af risiko for menneskelige fejl og en lavere fejlrate ved nye udgivelser.
Størrelsen af det gab kan måles. I sin 2024 State of DevOps-rapport, fandt DORA, at de bedst præsterende organisationer implementerer efter behov, sender ændringer til produktion på under en dag og genopretter tjenesten på under en time, mens de dårligst præsterende måler de samme ting i måneder. 2025-udgaven tilføjer en vigtig advarsel til alle, der overvejer at investere i værktøjer: AI fungerer primært som en forstærker, der forstærker styrkerne hos teams, der allerede har et solidt leveringsfundament, og dysfunktionerne hos dem, der ikke har. DevOps komplementerer Agile: hyppig levering, tidlig opdagelse af fejl og mere gennemsigtighed ved overvågning af en applikation. Det er også indbygget i skalerede Agile-rammeværk såsom SAFe (Scaled Agile Framework, der bruges til at anvende Agile på tværs af mange teams på én gang).
Et konkret eksempel ligger bag disse tal. I et markedspladsprojekt med tusindvis af store aktiver var platformen hostet på Heroku, hvilket begrænsede dens evne til at skalere. Teamet flyttede databasen fra MySQL til PostgreSQL og infrastrukturen over til AWS, hvilket afsluttede første fase på to måneder, hvorefter de fortsatte med kontinuerlig udvikling. Beslutningen handlede ikke om AWS frem for Heroku for enhver pris; det handlede om skaleringsrum, som den gamle vært ikke kunne tilbyde, købt til en pris, som kunden kunne se værdien af.
Dette dækker områder, der allerede er beskrevet under kontinuerlig integration og DevOps, og det korrelerer tæt med automatiseret test. Når man binder koncepterne sammen, er kontinuerlig implementering det næste skridt efter kontinuerlig integration.
Det bruger automatiseret test til at sikre, at korrekt kode frigives til produktion automatisk, typisk via DevOps-infrastrukturværktøjer. Denne automatiserede frigivelse er det punkt, hvor der ofte opstår forvirring omkring Continuous Delivery: De to deler forkortelse, men i Continuous Delivery er handlingen "gå til produktion" manuel.
Continuous deployment er det komplette, automatiserede software-deployment-flow fra start til slut, og det kan køre så ofte, som den givne applikation kræver det. De typiske trin er:
Samlet set giver disse trin dig tilstrækkelig garanti for, at koden er dækket og tjekket, og at den er moden nok til at nå produktion uden større trusler, med mulighed for nemt at rulle ændringen tilbage fra pipelinen, hvis det skulle blive nødvendigt.
Bekymringer omkring automatisering af noget så vigtigt er forståelige, og risiciene er reelle. Opbygningen af strukturen medfører også omkostninger i form af pipeline-engineering og den overvågning, der skal ligge til grund for den. Til gengæld ophører releases med at være begivenheder, der kræver planlægning og øvelse, hvilket gør det økonomisk overkommeligt at levere små ændringer.
Kanban er en workflow-styringsmetode, der visualiserer det arbejde, den kontrollerer. Den blev skabt inden for japansk lean-produktion, mere præcist i Toyota Production System.
For nylig er dens hovedidéer flyttet ind i softwarebranchen som Kanban-metoden, hvis primære artefakt er Kanban-tavlen. Tavlen er det visuelle realtidsarkiv for information og fremdrift i en given proces, og den gør blokeringer og flaskehalse tydelige.
Kolonnerne repræsenterer trin i flowet og indeholder konceptet Work In Progress sammen med en grænse pr. kolonne, hvilket er en værdifuld ressource. Hele idéen er at få dine opgaver (tickets, issues og alt andet, teamet sporer) til at flyde gennem hver kolonne på tavlen.
Kanban er en evolutionær metode, der er nem at implementere og udvikle gradvist, efterhånden som du bruger den. Da det er et ikke-forstyrrende forandringsledelsessystem, er det blevet bredt anvendt i drifts- og vedligeholdelsesprojekter. Det er i denne kontekst, at det overgår Scrum: arbejde med kontinuerligt flow og en uforudsigelig ankomstrate, hvor faste sprint-grænser tilføjer unødigt bureaukrati uden at øge forudsigeligheden, fordi arbejde, der lander på tredjedagen af sprintet, ikke kan vente til det næste.
Kanban er ikke strengt defineret som en agil praksis. Det bruges dog til at implementere agile og lean-principper, samtidig med at det øger medarbejder- og kundetilfredsheden undervejs.
Formålet her var at præsentere konkrete muligheder, som du kan bruge i enhver softwareudviklingsproces, med et stærkt fokus på agile metoder.
Du behøver ikke at indføre alle 18 på én gang, og rækkefølgen er vigtigere end antallet. Start der, hvor jeres projekter gør mest ondt lige nu – uanset om det er omskiftelige krav, regressionscyklusser eller langsomme releases. De metoder giver afkast først, og tabellen ovenfor er tænkt som et beslutningsgrundlag for budgettet frem for blot en præference.
Hos Imaginary Cloud evaluerer vi altid hvert scenarie først. Derefter anvender vi de metoder og teknikker, der passer til produktets aktuelle stadie og den risiko, kunden løber, frem for at bruge en standardpakke til alle opgaver. Måden, vi håndterede en indlejret refaktorering for AppTweak på, lignede intet af det, vi gjorde med et greenfield MVP, selvom begge trak på de samme metoder som nævnt ovenfor.
Baseret på vores teams ekspertise kan vi definere og anbefale, hvordan I får mest muligt ud af agile metoder, og hvornår de bør anvendes i livscyklussen for jeres webapplikation eller UI/UX-designprojekter. Du kan gennemse vores cases for at se, hvordan det fungerer i praksis.
Planlægning, analyse og krav, design og prototyping, softwareudvikling, test, udrulning samt drift og vedligeholdelse. Alle metoder dækker disse syv faser i større eller mindre grad. Forskellen ligger i, om de køres én gang som sekventielle faser, som i Waterfall, eller gentages i hver iteration, som i Agile.
Nej. SDLC er en konceptuel model, der beskriver de faser, software gennemgår; Agile er en tankegang, og dens metoder er måder at bevæge sig gennem disse faser på. Et agilt team planlægger, analyserer, designer, bygger, tester og udruller stadig. De gør det bare i syv korte, gentagne cyklusser i stedet for i én samlet proces.
Planlægning: produktvision, Business Model Canvas og produkt-backlog. Analyse og krav: Lean Inception, produktdesignproces og user story mapping. Design og prototyping: Domain Driven Design, architectural spikes og emergent design. Udvikling: continuous integration, TDD og refactoring. Test: BDD og ATDD, automatiseret test og sessionsbaseret test. Udrulning og drift: DevOps, continuous deployment og Kanban.
Ja. Praksisser som TDD, continuous integration, refactoring og Kanban er uafhængige af enhver specifik metode, og de fleste teams indfører dem én ad gangen. Det omvendte er også sandt: At afholde Scrum-ceremonier uden nogen af disse praksisser gør ikke i sig selv leverancen agil.
Brug leveringsresultater frem for tjeklister for implementering. DORA-leveringsmetrikker – udrulningsfrekvens, gennemløbstid for ændringer, fejlrate ved ændringer og restitutionstid efter fejlslagen udrulning (med en tilføjet pålidelighedsdimension i 2025) – fortæller dig, om en praksis har forbedret teamets leveringsevne. Mål dem, før du indfører en praksis, så du har et sammenligningsgrundlag.
Det afhænger af fasen. Planlægningspraksisser giver afkast med det samme, fordi de skaber den plan, teamet arbejder ud fra. Udviklings- og testpraksisser kræver en til tre måneder, før en testsuite er omfattende nok til at fange regressioner. Udrulnings- og driftspraksisser tager tre til seks måneder, målt på udrulningsfrekvens og gennemsnitlig restitutionstid.
Er du i tvivl om, hvad du skal prioritere først? Kontakt os , så gennemgår vi, hvor jeres leverance spilder tid, hvilke praksisser der passer til jeres produkts nuværende fase, og hvad det vil koste at indføre dem.
Lidenskabelig omkring software ting og agile. Kan let findes ved madlavning, spille volleyball eller bruge lidt tid på videospil.
Alexandra Mendes er Senior Growth Specialist hos Imaginary Cloud med 3+ års erfaring med at skrive om softwareudvikling, AI og digital transformation. Efter at have gennemført et frontend-udviklingskursus fik Alexandra nogle praktiske kodningsevner og arbejder nu tæt sammen med tekniske teams. Alexandra brænder for, hvordan nye teknologier former erhvervslivet og samfundet, og hun nyder at omdanne komplekse emner til klart og nyttigt indhold for beslutningstagere.
People who read this post, also found these interesting:
-%2520Survey%2520Insights.webp)
