Hvad er XP
Et frapperende faktum ved softwareudvikling er, at ganske mange udviklingsprojekter går mere eller mindre i vasken. På den måde adskiller softwareudvikling sig fra mange andre områder, hvor kvalitetsstyring og kontrol med produktudvikling er i fokus.
Software er en underlig størrelse, på den måde at der ikke rigtigt findes standard-metodikker bag udviklingen, og at softwarekvalitet er en blød størrelse, som er svær at måle.
Det betyder ikke, at der ikke forskes i udviklingsmetodikker, men snarere at formaliserede metodikker sjældent tages i anvendelse i udviklingen af softwareprojekter.
I løbet af de sidste par år har programmørerne Kent Beck og Martin Fowler slået på tromme for en metodik, som de kalder Extreme Programming (XP). XP har fået forbavsende mange fans og succeshistorier på bagen i løbet af ganske kort tid, og som det passer sig for en ægte succes har metoden mobiliseret lige så mange kritikere som tilhængere, hvis man skal bedømme ud fra debatten.
Hvad er XP
Extreme Programming bygger på en række best practice-regler inden for projektstyring og udvikling, hvor af en del er kontroversielle, og er kritiseret for ikke at være forskningsmæssigt og empirisk underbygget.
| Kent Beck, en af hovedskikkelserne bag Extreme Programming. |
Sædvanligvis benytter man i software en antagelse om, at ændringer bliver eksponentielt dyrere, jo længere projektet er skredet frem. Det virker temmelig indlysende, at funktionalitet som er tilføjet i design-fasen bliver billigere at implementere, end funktionalitet som tilføjes i slutningen af udviklingsfasen.
I modsætning hertil hævder Beck, at moderne programmeringspraksisser og værktøjer har ændret dette forhold, således at denne kurve flader ud i stedet for at stige eksponentielt. Med andre ord hævder Beck, at prisen for løbende ændringer er konstant igennem udviklingsforløbet.
Dette er et kernepræmis bag mange af Becks argumentationer, og det er det mest kontroversielle aspekt ved XP. Denne påstand kan nemlig ikke dokumenteres, og den synes at være en kende optimistisk.
Det kan XP ikke
Derudover benytter XP elementer, som kan synes banale, og arbejdsmetoder, som virker uøkonomiske. I den mere banale ende forholder XP sig til det faktum, at trætte programmører uværgeligt skriver fejlbehæftet kode. Dette er et almindeligt anerkendt faktum, og metoden har høstet ros for at forbyde overarbejde og længerevarende kode-sessioner som et princip.
XP bygger på par-programmering, hvor al kode udvikles af to programmører, som deler ét tastatur og én skærm. XP har ikke opfundet par-programmering, men benytter konsekvent arbejdsformen. Par-programmering kan se ud som en håbløst uøkonomisk metode, men tilhængerne hævder, at de fordele som man høster ved denne arbejdsform overgår, hvad der overfladisk kan se ud som dobbelte udgifter.
Fordelene er, at antallet af fejl minimeres, samtidig med at det tvinger udviklerne til løbende, linie for linie, at skulle begrunde deres design- og kodevalg over for en ligesindet. At kvaliteten af den producerede kode forbedres, er der vel ingen tvivl om, men der er ingen målinger eller empiriske undersøgelser, som bekræfter den økonomiske fordel.
Et lidt kynisk modargument lyder, at det nok er en bedre idé at hyre bedre kvalificerede programmørkræfter end blot at doble op. Udover par-programmering bygger XP også på en idé om "fælles ejerskab" over den producerede kode, i modsætning til at dele ansvarsområderne op i forhold til moduler.
De øvrige kerneprincipper i XP er heller ikke ganske ukontroversielle. XP lægger mindre vægt på design, og mere vægt på løbende tests. Inden for softwareudvikling har det normalt altid været god latin at betone vigtigheden af et gennemgående design før selve kodningen, men folkene bag XP peger på, at ganske mange projekter skifter sigte undervejs, og at det derfor er bedre at tage højde for dette forhold i sin arbejdsmetode. XP er på mange måder en pragmatisk vinkel på udviklingsmetodik, og det er givetvis også derfor, at metoden har høstet megen ros blandt dem, der praktiserer metoden.
Det kan XP ikke
Det springene punkt ved at benytte XP er, at mange af de præmisser, som metoden bygger på ikke er teoretisk underbygget eller underkastet empiriske undersøgelser. Ikke desto mindre er der masser af succeshistorier omkring XP, og man kan vel hævde, at netop i forbindelse med udviklingsmetodik må vidnesbyrd fra den virkelige verden tælle mest.
Som Beck gør opmærksom på i bogen, kan XP ikke benyttes i alle sammenhænge. Metoden sætter et loft på, hvor store programmørhold den kan anvendes på, og Beck nævner selv ti personer som grænsen. Hertil har kritikerne indvendt, at behovet for udviklingsmetodikker først bliver rigtigt vigtigt ved store projekter.
Becks bog kan hist og her virke lidt løs i kanten, og undertiden føler man sig hensat til den selvhjælpslitteratur, som er så populær i Amerika. Men uanset hvad ens holdning er til fænomenet, så er det givet, at bogen kan sætte tanker i gang hos alle, som arbejder med softwareudvikling.
En række kritiske artikler om XP kan læses på IEEE's websted. Danske succeshistorier om anvendt XP kan læses hos Computerworld Online: "Ekstrem programmering reducerer fejl" og "Extreme Programming udvikler kunden".
| Kent Beck Introduktion til Extreme Programming Oversat fra Extreme Programming Explained: Embrace Change af Lars Thorup IDG Forlag ISBN: 87-7843-509-9 174 sider Kr. 249,00 |
