Agil systemudvikling

Agil systemudvikling er en fællesbetegnelse for en række softwareudviklingsmetodikker, hvor vægten ligger på løbende at levere værdi til kunden gennem iterativ udvikling. Dvs måder at planlægge og kontrollere softwareudvikling, hvor man hurtigt kan levere en ny version af softwaren når der kommer ændringsønsker fra slutbrugerne. Extreme Programming og Scrum er eksempler på agile metodikker mens vandfaldsmodellen er modsætningen til agile metoder. På dansk bruges også ordet adræt udvikling^[1][2] da agil og adræt er synonymer.

Historie

Allerede tilbage i 1957 brugte man iterative metodikker i softwareudvikling. I 1990'erne opstod der kritik af at udviklingsmetoderne var blevet for omfattende og for langsomme til at reagere på ændrede ønsker fra kunderne. Der blev derfor introduceret det der dengang blev kaldt for "lightweight" metodikker bl.a. scrum i 1995, extreme programming i 1996 og feature driven development. De betegnes nu som agile metodikker.

Det agile manifest

I februar 2001 satte 17 softwareudviklere sig sammen for at diskutere hvordan man kunne fremme brugen af agile metoder og kom frem til følgende manifest, som beskriver de grundlæggende værdier i agil udvikling:^[3]

• Individer og interaktioner over processer og værktøjer
• Fungerende software over omfattende dokumentation
• Kundesamarbejde over kontraktforhandling
• Reaktion på ændringer over at følge en plan

Det vil sige, at selv om emnerne i højre side har værdi, har emnerne til venstre større værdi.

Agil projektledelse

Agil projektledelse er den form for projektledelse, der anvendes i agile projekter. Dette gælder ud over systemudvikling også i andre brancher, hvor man har fokus på punkterne i det agile manifest, dvs. hvor man primært arbejder i korte iterationer med fokus på at levere brugbare resultater i hver iteration.

Ledelsen af agile projekter adskiller sig fra traditionel projektledelse, fx i projekter udført efter vandfaldsmetoden, ved, at der er arbejdes med meget korte planlægningshorisonter, og at der bruges så simple metoder som muligt til tidsestimering, planlægning og opfølgning.^[4] Scrum er en af de metoder, der især har fokus på ledelsesaspektet.

Basal set er ledelse i et Scrum-baseret projekt et kollektivt ansvar. Metoden omfatter en rolle, scrum-masteren, der kunne ligne en projektleder, men dennes opgave er ikke at planlægge og lede som sådan; i stedet har han/hun opgaverne med at beskytte projektgruppen mod udefrakommende problemer samt sikre, at metodens principper overholdes.^[5]

Fremdriften i projektet foregår ved, at man anvender korte iterationer, kaldet sprints, hvor målet med hvert sprint er at udvikle en lille del mere af det samlede produkt. Sprintperioden holdes af en fast længde og begynder med, at kunderepræsentanten, kaldet product owner, prioriterer de krav, der ligger i den såkaldte product backlog, hvorpå projektgruppen tidsestimerer de højest prioriterede krav. Derpå ser man på, hvor mange af kravene, der er plads til at udvikle i sprintet, og det egentlige udviklingsarbejde går i gang. Undervejs i en iteration anvender gruppen en burndown-graf til at vise fremdriften, og hvis man når alle kravene, inden sprintet er færdigt, henter man endnu et eller flere krav fra backloggen. Når man ikke alle kravene, kommer de manglende krav med i overvejelserne til næste iteration.^[4]

Kravene, der specificeres i såkaldte user stories (brugerhistorier), beskrives på en måde, så det er let at afgøre, om de er opfyldt. Desuden er der fokus på, at de skal være små, men samtidig hver især kunne give værdi til kunden. Det er product ownerens ansvar at sikre dette.

Opfølgning på arbejdet i et projekt foregår på to niveauer: Der afholdes korte daglige møder (kaldet daily scrums), hvor alle deltagerne mødes og kort gør status ved at besvare tre simple spørgsmål: Hvad lavede du i går? Hvad skal du lave i dag? Har du nogle problemer, der forhindrer dig i at gøre det? Svar på sidstnævnte spørgsmål vil ofte være en opgave for scrum-masteren at løse. Ved afslutningen på en iteration laves en samlet opfølgning på den netop forløbne iteration. Dette sker i to trin. Dels skal gruppen demonstrere sine resultater for kunden (product owner), der skal sige god for dette, dels sker der en procesopfølgning, hvor gruppen drøfter, hvad de har lært i løbet af iterationen og søger at rette til i den næste iteration. Et eksempel på en læring kunne være, at gruppen indser, at de har været for optimistiske, fordi de ikke har nået at udvikle alle de valgte user stories. Tilretningen kan derfor være, at man nedjusterer den hastighed, som man baserer sin estimering på til næste iteration.^[4]

Referencer