Sådan bruger du Agile metode i softwareudvikling
Hvad er Agile, og hvad er det ikke?
Agile er ikke et enkelt værktøj eller en fast skabelon. Det er en samling af principper for, hvordan softwareudvikling tilrettelægges, så teams kan tilpasse sig undervejs frem for at låse sig fast i en plan fra dag ét. Bag det hele ligger Agile Manifesto, et dokument med fire kerneværdier og tolv principper, der prioriterer samarbejde, fungerende software og evnen til at ændre kurs frem for tung dokumentation og stiv planlægning.
Mange forveksler Agile med Scrum, men de er ikke det samme. Scrum er ét konkret framework under Agile-paraplyen. Kanban er et andet. Begge er Agile i praksis, men de fungerer forskelligt og passer til forskellige typer projekter og teams.
Det vigtigste at forstå fra starten: Agile er en tankegang, ikke en tjekliste. Teams der kalder sig Agile, men stadig arbejder med lange fastlagte kravspecifikationer og sjældne leverancer, er ikke rigtig Agile.
De centrale begreber du skal kende
Inden du vælger en Agile-tilgang til dit softwareprojekt, er det værd at have styr på de grundlæggende begreber. Her er de vigtigste:
Sprint
En sprint er en fastlagt periode, typisk to til fire uger, hvor teamet arbejder på et defineret sæt opgaver. Ved sprintens afslutning leveres et fungerende stykke software, som kan vises frem og evalueres. Det er ikke nødvendigvis den færdige løsning, men altid noget konkret og testet.
Backlog
Backloggen er den prioriterede liste over alt, hvad der skal udvikles. Den ejes af en produktejer og opdateres løbende. Øverst i backloggen ligger de vigtigste opgaver, de der har størst værdi for brugerne eller forretningen.
User stories
User stories er korte beskrivelser af en funktion set fra brugerens perspektiv. Formatet er typisk: "Som [bruger] ønsker jeg [funktion], så jeg kan [formål]." Det tvinger teamet til at tænke i brugerværdi frem for tekniske detaljer alene.
Retrospektiv
Efter hver sprint holder teamet et retrospektiv, en struktureret gennemgang af hvad der gik godt, hvad der gik skidt, og hvad der kan gøres anderledes næste gang. Det er Agiles indbyggede forbedringsmekanisme.
Produktejer
Produktejeren er bindeleddet mellem forretningen og udviklingsteamet. Det er denne person, der prioriterer backloggen og sikrer, at teamet arbejder på det rigtige. Uden en engageret produktejer bryder Agile-processen typisk ned.
Scrum versus Kanban, hvornår vælger du hvad?
Scrum fungerer bedst, når projektet har tydelige faser og leverancemål, og når teamet arbejder tæt sammen over en defineret periode. Det kræver faste roller: Scrum Master, produktejer og udviklingsteamet. Scrum passer godt til nyudvikling af mobilapps, backend-systemer og andre projekter med et klart slutmål.
Kanban er mere fleksibelt og egner sig til kontinuerlig drift og vedligehold, hvor opgaver løbende dukker op uden faste sprints. Her styres flowet visuelt på et tavle med kolonner som "Ikke påbegyndt", "I gang" og "Færdig". Kanban sætter grænser for, hvor mange opgaver der må være i gang samtidig, det reducerer flaskehalse og halvfærdigt arbejde.
Mange erfarne teams bruger en kombination kaldet Scrumban, der henter struktur fra Scrum og fleksibilitet fra Kanban. Det er særligt udbredt i teams der både har nyudvikling og løbende support.
Sådan forløber et typisk Agile-projekt
Et Agile-projekt starter ikke med en 80-siders kravspecifikation. I stedet begynder man med at kortlægge de overordnede mål og brugerrejser, opdelt i user stories. Disse prioriteres i backloggen, og de første sprints planlægges.
I sprintplanlægningen vælger teamet de opgaver fra toppen af backloggen, som kan nås inden for sprintens tidsramme. Undervejs holdes korte daglige møder, ofte kaldet daily standups, hvor hvert teammedlem kort fortæller hvad de arbejder på, om der er forhindringer, og hvad de forventer at lave næste dag. Det holder alle orienteret og afslører problemer tidligt.
Når sprinten er afsluttet, vises resultatet frem i en sprint review med relevante interessenter. Herefter følger retrospektivet, og en ny sprint planlægges. Denne cyklus gentages, til produktet er klar til lancering, eller til en ny prioritering ændrer kursen.
Det er netop den løbende justering, der er Agiles styrke. Har kravene ændret sig efter tre sprints? Prioritér om. Er en teknisk løsning viste sig umulig? Find alternativet tidligt frem for sent.
De mest almindelige fejl ved brug af Agile
Agile misbruges ofte, og det er en af grundene til at mange projekter fejler på trods af gode intentioner. Her er de fejl der går igen:
Agile som alibi for ingen planlægning
Agile betyder ikke, at man ikke planlægger. Det betyder, at man planlægger i kortere horisonter og tilpasser løbende. Teams der hopper ind i udvikling uden en klar vision, mål og backlog, bruger Agile som undskyldning for kaos, ikke som en metode til kontrol.
Produktejeren er ikke tilgængelig
Hvis produktejeren kun dukker op til review og ikke er tilgængelig til at besvare spørgsmål undervejs, stopper arbejdet op. Teamet kan ikke træffe de nødvendige valg uden løbende input og prioritering.
Sprints der aldrig afsluttes med noget fungerende
En sprint skal afsluttes med software, der virker og kan vises frem. Leveres der halvfærdige løsninger sprint efter sprint, mister metoden sin vigtigste fordel: tidlig og løbende validering.
Retrospektiver der ikke ændrer noget
Holder teamet retrospektiver, men ingen handlinger følger med, er det spild af tid. Retrospektivet skal resultere i konkrete forbedringer til næste sprint, ellers er det en tom ritual.
Du kan læse mere om klassiske fejl i softwareprojekter i denne gennemgang af de mest almindelige fejl inden for webudvikling og hvordan du undgår dem.
Hvad skal du kigge efter, når du vælger en softwareudvikler der arbejder Agile?
Ikke alle udviklere, der siger de bruger Agile, gør det i praksis. Her er de konkrete spørgsmål og kriterier, du bør bruge, når du vurderer en potentiel samarbejdspartner:
Spørg til deres sprintcyklus og leverancer
Hvad leveres ved afslutningen af hver sprint? Kan du se og teste det? Hvis svaret er vagt, er det et advarselstegn. En god Agile-partner leverer fungerende software hyppigt og involverer dig aktivt i at validere det.
Hvem er produktejeren i samarbejdet?
Afklar fra starten, hvem der ejer backloggen og prioriterer opgaverne. Er det dig som kunde? Er det en person hos bureauet? Og hvordan sikres det, at dine forretningsmæssige prioriteter løbende afspejles i udviklingsarbejdet?
Hvordan håndteres ændringer undervejs?
En ægte Agile-tilgang omfavner ændringer. Spørg konkret: Hvad sker der, hvis I opdager midt i projektet, at en funktion ikke giver mening? Beregnes det som ekstraomkostning fra dag ét, eller arbejdes der med en prioriteringsmodel der tillader justeringer?
Kan du se en backlog og sprinthistorik?
Transparens er centralt i Agile. En erfaren leverandør vil normalt kunne vise dig, hvordan de strukturerer opgaver, estimerer arbejde og dokumenterer fremskridt. Værktøjer som Jira, Linear eller lignende projektstyringsplatforme bruges typisk til dette.
Hvad er kommunikationsrytmen?
Hyppig kommunikation er en forudsætning. Aftal fra starten, hvor ofte der holdes statusmøder, hvem der deltager, og hvordan du som kunde holdes opdateret mellem sprintsene.
Hvis projektet involverer backend-løsninger, er det også værd at sætte sig ind i de tekniske valg der træffes tidligt. Denne guide til at vælge den bedste backend-teknologi til din app giver et godt udgangspunkt.
Agile og fast pris, kan det lade sig gøre?
Det er et af de spørgsmål, der oftest dukker op: Kan man kombinere Agile med en fast pris? Svaret er ja, men det kræver tydelige rammer. Fast pris på Agile-projekter fungerer bedst, når scope er veldefineret på overordnet niveau, og der er enighed om, hvordan ændringer prissættes. Alternativt arbejdes der med tidsbegrænsede aftaler per sprint, så du betaler for den faktiske tid og de leverancer der er aftalt, sprint for sprint.
Undgå aftaler, hvor alt er fast låst fra dag ét, og ændringer kræver store forhandlinger. Det modvirker netop den fleksibilitet, som Agile er sat i verden for at give.
Agile er en investering i bedre software
Brugt rigtigt reducerer Agile risikoen for, at du ender med et softwareprodukt, der ikke passer til de reelle behov. Det sker ved at validere tidligt, justere løbende og inddrage brugerne undervejs. Det kræver til gengæld engagement fra begge parter, en leverandør der holder strukturen og en kunde der er til stede og prioriterer aktivt.
Vil du gå dybere ind i, hvad der sker i den første fase af et appudviklingsprojekt, kan denne guide til at starte med appudvikling hjælpe dig videre.
Hos Sahari arbejdes der med Agile-principper i softwareudvikling og appudvikling. Ønsker du at høre mere om, hvordan det konkret kan se ud for dit projekt, er du velkommen til at tage en uforpligtende snak med teamet.