Denne artikel stammer fra det trykte Computerworlds arkiv. Artiklen blev publiceret den CTO d. 5. januar 2007.
følg ånden Udviklingsekspert udpeger ofte forekommende fejltagelser i den populære agile systemudvikling.
Det er vigtigt at følge ånden i metoden og ikke bare slavisk følge en liste over ting, man skal gøre.
For Jutta Eckstein, konsulent med speciale i den såkaldte agile systemudvikling, er det den vigtigste lære af 10 års erfaring med systemudvikling efter en agil skabelon.
- Jeg hørte første gang om systemudvikling baseret på agile principper i 1996. Jeg tænkte, at det var en naturlig måde at udvikle på, siger Jutta Eckstein. Siden har hun anvendt og rådgivet om agile udviklingsmetoder som Extreme Programming og Scrum.
Agile udviklingsmetoder har fokus på at udvikle velfungerende software frem for - som i mere traditionelle systemudviklingsmetoder, eksempelvis Rational Unified Process (RUP) - at producere dokumentation og følge fastlagte processer. En mere pragmatisk tilgang til softwareudvikling.
Metodens ånd
Det er vigtigt at holde fast i ideen bag den agile udvikling og ikke lade en sådan-siger-metoden-holdning overtage udviklingen.
- Folk taler om praksis som par-programmering og stand-up-meetings. De er mere håndgribelige end metodens ånd, der siger, at udviklerne skal have beslutningsdygtighed, og man generelt skal være fleksibel over for de ændringer, som et projekt udsættes for. Praksis som eksempelvis par-programmering kan man krydse af på en tjekliste og sige, at nu har vi gjort det. Det er dog ikke sikkert, at aktiviteten tilfører projektet nogen værdi. En hævdvunden praksis skal ikke altid anvendes i et givent projekt, siger Jutta Eckstein.
I sine egne projekter anvender Jutta Eckstein par-programmering, men projektgrupperne får lov at bestemme, hvor meget de anvender det.
- Jeg lader det være op til de enkelte team, hvor meget de anvender par-programmering. Med en kollega siddende ved siden af er man meget mere fokuseret. Det er ikke muligt at lave par-programmering mere end 70 procent af tiden, da det er meget udmattende. Nogle mener endda, at 70 procent er en meget høj procent. Her er det vigtigt, at man fokuserer på ideen frem for en rigid praksis. Ideen med par-programmering er at opnå bedre kvalitet i koden, sikre videnoverførsel og skabe fokus på test. Det mener jeg, man kan opnå med par-programmering, men hvis det ikke virker, så prøv noget andet, siger Jutta Eckstein.
Planlægning hele tiden
Jutta Eckstein støder ofte på en opfattelse af, at agil udvikling ikke kræver så megen planlægning. Udviklerne skal blot kode uden den store planlægning.
- Det er en helt forkert opfattelse. Der er en meget tæt opfølgning på udviklernes arbejde, ja, der er nærmest planlægning hele tiden, siger Jutta Eckstein.
Ved en agil udviklingsproces deler man projektet op i en række små overskuelige udviklingsforløb kaldet iterationer. Hver iteration fokuserer på udvikling af en bestemt systemfunktionalitet og varer måske en til to uger. For en agil udviklingsproces har man derfor to planer. En overordnet projektplan for hele projektforløbet og en detaljeret projektplan for den næste iteration. Erfaringerne fra iterationerne bruges til at justere den overordnede projektplan.
- Hver iteration giver baggrund for at justere den overordnede projektplan. Efter en iteration har man lært nogle ting - eksempelvis hvor lang tid det tager at anvende en bestemt teknologi til udvikling af skærmbilleder - som kan anvendes til at justere den overordnede plan. Så hvis man har iterationer af to ugers varighed, justerer man sin overordnede projektplan hver fjortende dag. Agil udvikling giver mulighed for at vide præcis, hvor man er, da man arbejder med kørende kode og ikke kun designdokumenter. Det giver et bedre billede af, om den overordnede deadline kan overholdes. Det er bedre end at planlægge seks måneder frem, da man i løbet af seks måneder bliver klogere på mange ting, siger Jutta Eckstein.
Også i store organisationer
Nogle betragter agil systemudvikling som en udviklingsmetode, der er mest velegnet til små udviklingsorganisationer. Jutta Eckstein har dog store virksomheder som Siemens og den schweiziske bank UBS blandt sine kunder, og de anvender agil udvikling.
- De kunder, jeg har, opererer med store projekter. De deler måske en projektgruppe på 100 personer op i 15 team med hver seks til syv personer. Det daglige arbejde i undergrupperne er det samme som ved normal agil udvikling. Det kræver selvfølgelig mere koordinering og kommunikation mellem de forskellige projektgrupper, forklarer Jutta Eckstein.
Til at varetage koordineringen mellem de forskellige team etablerer Jutta Eckstein en såkaldt crossteamservice. Den skal blandt andet sikre, at der udføres integrationstest mellem de forskellige projektgruppers softwarekomponenter.
Faktaboks:
Agil, adræt eller letvægt?
Softwareudviklere og metodefolk mødtes i 2001 i Utah for at diskutere alternativer til mere traditionelle dokumentationstunge udviklingsmetoder.
På det tidspunkt var der en del udviklingsmetoder, der blev betegnet som letvægtsmetoder. De fokuserede på at få udviklet kørende kode frem for at producere en masse analyse- og designdokumentation som mere traditionelle systemudviklingsmetoder gør.
De fremmødte kunne dog ikke lide betegnelsen letvægt, da det kan opfattes negativt. I stedet nåede de frem til betegnelsen agil systemudvikling. I dansk oversættelse svarer det til adræt systemudvikling, men i dag anvendes betegnelsen agil systemudvikling.
ecksteins Ni agile fælder
Fælde 1: Aktiviteter udføres, selvom de ikke tilfører projektet værdi.
Fælde 2: Trædemølle - Iterationer gennemløbes, uden at der laves målinger af projektets fremskridt.
Fælde 3: Manglende resultatorientering.
Fælde 4: Afbrydelser er normen - En stadig strøm af specifikationsændringer, mens en iteration udføres.
Fælde 5: Gentagelse af de samme fejl - Ingen erfaringsopsamling.
Fælde 6: Grupper koordinerer ikke deres arbejde.
Fælde 7: Ingen overordnet plan - Intet samlet overblik over projektstatus.
Fælde 8: Manglende erkendelse om sammenhæng mellem afsat tid, mål, kvalitet og ressourcer.
Fælde 9: Manglende opbakning fra ledelsen. Agil udvikling er ikke kun for udviklere.
Scrum
Scrum er en agil metode for projektledelse. En såkaldt scrummaster sørger for at projektgruppen afholder et dagligt møde - eller scrum (klynge) -hvor projektets fremskridt, problemer og foreliggende opgaver diskuteres. Udviklingsarbejdet består af en række iterationer, såkaldte sprints.
eXtreme Programming (XP)
Extreme Programming er en anden agil softwareudviklingsmetode. Centralt for XP er frembringelsen af brugbar kode. Brugbar kode betyder, at XP lægger stor vægt på test. Når en metode eller en funktion er kodet, skal der udføres en række Unit test for at sikre, at koden er komplet. Unit tests er automatiserede test, der forsøger at tvinge metoden eller funktionen ud i fejlsituationer. XP anvender ofte par-programmering for at fremelske en god kodekvalitet.
Sidehistorie:
Den svære par-programmering
En af de mest banebrydende praksis ved agil systemudvikling er anvendelsen af par-programmering. Extreme Programming (XP) anvender det i stor stil. Ved par-programmering sidder to udviklere foran den samme skærm. Udviklerne diskuterer koden og kommer frem til en bedre kvalitet på den måde, end hvis man sider og koder alene, lyder teorien bag par-programmering.
Jutta Eckstein er fortaler for par-programmeringens gode egenskaber.
- Det giver mange gode resultater. Sidder man alene, er der fare for, at man koder derudad uden at tænke nærmere over, hvad man koder. Par-programmering opfordrer udviklerne til at forklare, hvad de gør, siger Jutta Eckstein.
Hun er dog ikke blind over for de faktorer, som den enkelte udvikler skal overvinde.
- Man skal selvfølgelig vænne sig til det. Det er meget naturligt for en udvikler at tænke, at de andre udviklere vil finde ud af, at jeg ikke er så god. Nogle er bange for at gøre noget dumt og vise, at de eksempelvis ikke kender udviklingsmiljøet så godt. I den anden ende af skalaen er der udviklere, der føler, at den anden person man skal lave par-programmering med, vil sænke udviklingshastigheden, siger Jutta Eckstein. dm
OriginalModTime: 16-02-2007 13:45:36
