Hvad er forskellen mellem iterativ og inkrementel udvikling?

Henny Portman

on Oct 13, 2026

At arbejde iterativt og trinvist er to centrale elementer i agil udvikling, som ofte forveksles med hinanden. Her er en guide til at forstå forskellen, så du kan vende tilbage til dine agile arbejdsmetoder.

I mine undervisningstimer bemærker jeg ofte, at de studerende forveksler iterativ og inkrementel udvikling (IID). Formålet med denne artikel er at skabe en forståelse af forholdet mellem inkrementel og iterativ udvikling.

Jeg begynder med en sammenligning af en vandfalds- og en agil tilgang ved hjælp af eksemplet med udviklingen af en betalingsapp. Der er også inkluderet et tilsvarende miniwebinar om disse tilgange. I anden del af denne artikel placerer jeg vandfalds- og agil udvikling i en matrix, der viser skæringspunktet mellem inkrementel og iterativ udvikling, og forklarer alle fire kvadranter i matrixen.

Agil kontra vandfald: Udviklingen af en betalingsapp

Vandfaldstilgangen

Hvis denne eksempelapp udvikles efter en traditionel vandfaldsmodel, kan de følgende trin observeres i figur 1.

Figur 1: Dette diagram viser en typisk vandfaldslivscyklus med eksemplet på leveringen af en app.

Projektinitiering

Det hele starter med en projektsponsor fra marketingafdelingen, som var i stand til at frigøre de nødvendige midler til denne app. Det var hans antagelse, at appen ville forbedre fastholdelsen af kunder og tilgangen af nye kunder. Han visualiserede tre overordnede funktionsgrupper.

Da projektet er godkendt, tildeles en projektleder, og der oprettes et projektteam. Efter mange diskussioner og workshops om indsamling af krav blev der opnået enighed om at levere en betalingsapp med 250 funktionaliteter. Alle disse funktioner registreres i et omfattende og meget detaljeret dokument med softwarekrav, som underskrives af projektsponsoren og kunderepræsentanten (samt andre centrale interessenter).

Projektets designfase

I det næste trin omsætter projektteamet kravene til et design for appen. Arkitekten kontrollerer designet i forhold til designprincipperne. Han kontrollerer også, om alle nødvendige dataattributter er tilgængelige i backend-systemet.

Vi er nu to måneder inde i projektet, og kunden har endnu ikke set noget, der fungerer, kun nogle statusrapporter. Og disse statusrapporter involverer sandsynligvis en eller anden form for ‘vandmelon’-rapportering, som efterlader kunden uden nogen idé om, hvorvidt projektet følger planen eller ej.

Projektets udviklingsfase

Det tager seks måneder at udvikle appen, og når det er gjort, bliver kunderepræsentanten bedt om at stille nogle personer til rådighed, som kan hjælpe med en brugergodkendelsestest. Under testen bliver det klart, at flere funktioner ikke virker.

Projektteamet forstår ikke hvorfor. Det er præcis det, der blev beskrevet i kravdokumentet. Det fører til masser af diskussioner, omarbejde og forsinkelser, og kunderne er ikke tilfredse med resultaterne. Hvis vi desuden ser på det endelige resultat, kan vi måske bemærke, at mange af de udviklede krav ikke anvendes af kunden eller kun anvendes sjældent.

Det kunne endda være værre. Antag, at udviklingen af appen tog 1,5 år, og at en anden bank leverer en betalingsapp, når du er halvvejs færdig. Hvad ville du gøre på det tidspunkt? Ville du stadig have en levedygtig forretningscase for at fortsætte og færdiggøre din egen app?

Når man ser på figur 1, bliver det tydeligt, at omfanget og de underliggende kvalitetskriterier ved en vandfaldstilgang er fastlagt med én enkelt levering. Alle trin udføres én gang for hele projektet, og ledelseskontrollen fokuserer på omkostninger og tid. Værdileveringen til kunden finder først sted efter implementeringen af den komplette app.

Den agile tilgang

Hvis vi udvikler appen ved hjælp af en agil projektledelsestilgang, ser vi følgende mønster:

Udviklingsteamet angiver, at de er i stand til at levere de første to funktioner, som produktejeren har prioriteret, i den første iteration.
Projektteamet leverer et inkrement af produktet hver tredje uge (sprint, iteration eller tidsboks).
Efter de første leverancer eller inkrementer ser vi en kunde, der har tillid til, at projektet vil levere. Kunden har allerede en fungerende app og forstår, at alle funktioner endnu ikke er på plads, men at de funktioner, der er med, fungerer.

Når de ser på den seneste udgivelse og de leverede funktioner, nævner de en helt ny funktion. En funktion, som ingen havde tænkt på ved projektets begyndelse, men som kunne gøre kundens hverdag mere produktiv.

Efter hvert inkrement resulterer kundefeedback i nye funktionelle muligheder (som ikke var på den oprindelige liste) eller justeringer af potentielle funktioner. Produktet bliver mere og mere modent. For hvert inkrement modtager kunden en ny version og bliver mere tilfreds.

diagram, der viser agil udvikling med værdi i forhold til tid og den overordnede tilfredshed med kravene

Figur 2: Diagrammet viser den agile udviklingscyklus ved hjælp af det samme eksempel med levering af en app.

Hvis vi ser på figur 2, ser vi et jævnt leveringsflow inden for en fastlagt varighed og ved hjælp af permanente agile teams (det er faste omkostninger). Omfanget og de underliggende kvalitetskriterier er fleksible (dynamiske) med hyppige, små leverancer (det er inkrementerne).

Alle trin, der har til formål at levere en funktion eller en brugerhistorie, udføres gentagne gange (hvilket gør processen iterativ), indtil den krævede kvalitet er opnået. Ledelseskontrollen fokuserer på levering af kundeværdi. Værdileveringen til kunden finder sted efter hver implementering af et inkrement.

Vandfaldsmetoden kontra agil udvikling: Leveranceresultater

Hvis vi ser nærmere på de to produkter fra henholdsvis vandfaldsmetoden og den agile softwareudviklingstilgang, ser vi et produkt med 250 funktioner og en knap så tilfreds kunde samt et produkt med kun 150 funktioner og en meget tilfreds kunde (se figur 3).

diagram, der viser forskellen mellem agile metoder og vandfaldsmetoden

Figur 3: Dette diagram sammenligner forskellene i tid, antal funktioner og kundetilfredshed for vandfaldsmetoden og agile tilgange.

Hvis vi ser endnu mere detaljeret på det produkt, der blev leveret med den agile tilgang, ser vi kun en delmængde på 100 funktioner fra den oprindelige liste samt 50 funktioner, der er nye eller justerede. Dette er i tråd med nogle vigtige principper i det agile manifest, herunder:

Enkelhed, som er kunsten at maksimere mængden af arbejde, der ikke udføres: kun 150 funktioner i stedet for 250 funktioner
Byd ændrede krav velkommen, selv sent i udviklingen: tilpasning til kundefeedback efter hver iteration og hvert inkrement

Agile udviklingsprocesser udnytter forandringer til kundens konkurrencemæssige fordel (50 nye eller justerede funktioner blev leveret). Derfor er kunden meget tilfreds. Teamets højeste prioritet er at tilfredsstille kunden gennem tidlig og kontinuerlig levering af værdifulde softwaresystemer.

Kort webinar: Leverancer med vandfaldsmetoden kontra agil udvikling

Her er et kort webinar med mere om forskellene mellem leverancer med vandfaldsmetoden og agile leverancer.

Forskelle mellem iterativ og inkrementel udvikling

Nu hvor jeg har gennemgået forskellene mellem en vandfaldsbaseret og en agil tilgang ved hjælp af eksemplet med at skabe en betalingsapp, vil jeg placere vandfaldsmetoden og agil udvikling i en matrix, der sammenligner iterativ og inkrementel udvikling.

Som det sidste trin vil jeg uddybe det minimum levedygtige produkt (MVP) og det minimum markedsklare produkt (MMP) og vise, hvor disse passer ind i de forskellige tilgange og et historiekort. Jeg har også inkluderet et tilhørende kort webinar.

Matrix for iterativ og inkrementel udvikling

Som nævnt bemærkede jeg, at studerende ofte forveksler iterativ og inkrementel. I figur 4 finder du fire kvadranter, som fremkommer ved en vandret linje, der angiver inkrementel eller ikke-inkrementel, og en krydsende lodret linje, der angiver iterativ eller ikke-iterativ. Se denne YouTube-video for en meget enkel version af figuren.

matrix, der viser forskellen mellem iterativ og inkrementel udvikling

Figur 4: Denne matrix viser forskellige udviklingstilgange, og hvorvidt teammedlemmer, der følger disse tilgange, skal iterere og/eller arbejde i inkrementer.

Nederste venstre kvadrant

I det nederste venstre hjørne ser vi den tilgang, hvor der hverken er iterationer eller inkrementer. Dette er vandfaldsmetoden. Alle aktiviteter (design, analyse, opbygning, test og implementering) udføres én gang for hele projektet.

I dette tilfælde ser vi en enkelt levering af det endelige produkt baseret på et fastlagt omfang. Kundeværdi kan kun opnås efter leveringen af det endelige produkt. Et af de vigtigste mål med denne tilgang er at styre omkostningerne.

Nederste højre kvadrant

I den nederste højre kvadrant ser vi en inkrementel tilgang uden iterationer. Dette er en trinvis eller inkrementel levering af mindre dele af produktet. Alle aktiviteter for et givent trin (design, analyse, udvikling, test og implementering) udføres én gang.

Inden for et givent trin er omfanget fastlagt, men det samlede produkt er baseret på et mere dynamisk eller fleksibelt omfang. Kundeværdi kan opnås efter hver levering af produktet. Et af de vigtigste mål med denne tilgang er hurtig levering.

Øverste venstre kvadrant

I den øverste venstre kvadrant ser vi en spiralformet eller iterativ tilgang uden inkrementer. Dette er en enkelt levering, hvor det endelige produkt skabes gennem flere iterationer. Et godt eksempel på denne tilgang er designtænkning. I grafen ser du en sekvens af aktiviteterne indramning, analyse, idégenerering, realisering og refleksion.

Denne sekvens udføres gentagne gange eller iterativt, hvor du i hver iteration kommer tættere på det endelige, korrekte eller krævede produkt. I mange tilfælde er dette endelige produkt en prototype eller model. I denne spiralformede tilgang har vi et dynamisk eller fleksibelt omfang. Kundeværdi kan kun opnås efter leveringen af det endelige produkt. Et af de vigtigste mål med denne tilgang er løsningens korrekthed.

Øverste højre kvadrant

I den øverste højre kvadrant ser vi den agile tilgang, der bruger inkrementer og en iterativ metode. Scrum er et godt eksempel på denne tilgang.

Ved afslutningen af hvert inkrement, ofte kaldet et sprint eller en tidsboks, leveres et inkrement af produktet. Dette inkrement er resultatet af mange iterationer med henblik på at udvikle små, men korrekte dele af produktet, ofte kaldet brugerhistorier eller elementer fra produktbackloggen. Det endelige iterative projekt leveres stykke for stykke.

I denne agile tilgang har vi et dynamisk eller fleksibelt omfang. Kundeværdi kan opnås efter hver levering af produktet. Et af de vigtigste mål med denne tilgang er kundeværdi gennem hyppige leverancer og brugerfeedback.

MVP eller MMP?

I figur 4 finder du også akronymerne MVP og MMP. MVP står for minimum viable product og er en version af et nyt produkt eller en ny tjeneste, som gør det muligt for et team at indsamle den størst mulige mængde læring om kunderne og opnå validering med den mindst mulige indsats. MVP'et for Dropbox-tjenesten var en simpel film. Det betyder, at P'et i MVP kan være et helt andet produkt end det, der ender med at blive det endelige produkt.

Et eksempel, der illustrerer MVP og MMP

Jeg bruger ofte følgende eksempel på et nyt finansielt produkt. En entusiastisk salgschef har en god idé til et nyt finansielt produkt. Han mener, at de kan sælge mindst 100.000 af disse produkter.

Sammen med nogle finanseksperter designer de produktet på et par måneder. Et udviklingsteam bliver tildelt opgaven, og det tager dem 4 måneder at udvikle produktet. Parallelt udvikles kommercielle brochurer, og produktet lanceres ved et stort arrangement.

Desværre køber kun få mennesker produktet. Hvis vi følger MVP-tilgangen, kan vi antage, at 10 % af deres webbrugere er interesserede i dette produkt. Vi ville derefter udvikle et MVP for at teste denne hypotese.

I dette tilfælde kunne MVP'et være en simpel knap på hjemmesiden. Hvis du klikker på den, får du vist en skærm med en besked om dette nye produkt og mulighed for at tilføje din e-mailadresse, hvis du er interesseret. Lad os sige, at mindre end 1 % af de besøgende trykkede på knappen — produktet ville ikke blive udviklet, og virksomheden ville have sparet mange knappe ressourcer.

Hvis vi ser nærmere på figur 4, kan vi se den potentielle anvendelse af MVP'er i alle kvadranter. Når du bruger en vandfaldsmodel, kan du oprette et MVP i den første softwaredesignfase for at kontrollere, om der er en forretningsmæssig begrundelse for projektet.

Det samme kan gøres i den første fase af det første inkrement, når man følger en trinvis levering. I nogle tilfælde kan resultatet af din designtænkningstilgang være et MVP. MVP'et kan også være nyttigt i begyndelsen af en agil tilgang.

Mange mennesker ser det første produkt, der leveres ved afslutningen af din trinvise levering, som MVP'et. Det kan være tilfældet, men i de fleste tilfælde er dette ikke et MVP, men et MMP. MMP eller minimumssalgbare produkt er det mindste produkt, der kan skabe værdi for din kunde.

Hvordan ser agil levering ud?

Nu hvor det står klart, at inkrementelle modeller og iterative modeller ikke er det samme, og vi forstår anvendelsen af MVP og MMP, kan vi undersøge mere detaljeret, hvordan inkrementel og iterativ levering ser ud.

Du har sikkert set Jeff Pattons berømte eksempel med Mona Lisa, hvor maleriet skabes stykke for stykke (trinvis levering). En anden måde at gøre det på er at starte med det første inkrement, hvor der kun skabes en grov skitse, og med hver ny iteration tilføjes flere detaljer til skitsen, indtil du i sidste ende har det færdige maleri (inkrementel og iterativ eller agil levering).

I den første situation skal du allerede have en detaljeret idé om det endelige produkt, mens du i den anden situation blot har brug for en overordnet skitse, da ændringer er meget nemmere at foretage. Hvis vi ser på figur 5, kan vi se et historiekort for et nyt produkt kaldet ABC.

Figur 5: Et eksempel på en kortlægning af brugerhistorier for et specifikt eksempelprodukt.

Produktejeren havde forestillet sig syv funktioner til dette produkt. De første fire funktioner er skal-krav. Funktion 5 og 6 er bør-krav, og den sidste funktion er et kan-krav. Mange ville kalde dette MoSCoW-prioritering (skal-krav, bør-krav, kan-krav og vil-ikke-krav).

Hver funktion kan i sig selv opdeles i mindre dele. På figuren kan du se funktioner eller brugerhistorier med skal-, bør- og kan-krav. En funktion kan være et skal-krav, men det betyder ikke, at alle de underliggende brugerhistorier også er skal-krav. Eller en funktion kan være et bør-krav, men hvis du implementerer den funktion, er nogle brugerhistorier skal-krav, mens andre er bør- eller kan-krav.

For at implementere dette ABC-produkt kan du se fem inkrementer eller udgivelser. Den første er det minimum markedsførbare produkt. Dette MMP består af de første to brugerhistorier med skal-krav fra funktion 1 samt de første brugerhistorier med skal-krav fra funktion 2 og 3.

Udgivelse 2 indeholder de næste to brugerhistorier med skal-krav fra funktion 1, 2 og 3 (iterativ udvikling). Produktudviklingen fortsætter ved at implementere de næste udgivelser. For hver udgivelse øges kundeværdien.

Efter udgivelse 5 holder produktejeren op med at implementere brugerhistorier. Feedback fra kunden viste ham, at ABC-produktet er »egnet til formålet«, og han tager Det Agile Manifestos princip om enkelhed i betragtning og stopper den videre udvikling.

Miniwebinar: Iterativ og inkrementel udvikling

Her er et dybdegående webinar om iterativ og inkrementel softwareudvikling.

Afsluttende tanker

Har dit softwareudviklingsteam et klart billede af iterativ og inkrementel udvikling? Hvordan anvender I det i jeres agile metoder eller vandfaldsmetoder?

Fortæl os det i kommentarerne, eller bliv medlem af vores DPM-program og diskuter med andre medlemmer i vores eksklusive forum!

Hvad er forskellen mellem iterativ og inkrementel udvikling?