Håller XP vad det lovar? - Lunds Tekniska Högskola

Håller XP vad det lovar?
Johan Holmberg
D01, Lunds Tekniska Högskola
d01jh@efd.lth.se
24th February 2004
Sammanfattning
Extreme programming har under sin korta livstid fått utstå hård kritik mot sitt
sätt att se på mjukvaruutvecklng, och har anklagats för att vara en ineffektiv och
osäker utvecklingsmodell. Förespråkarna å sin sida, hävdar motsatsen. Hur som
helst, har XP rumstrerat om ordentligt i mjukvaruutvecklingsvärlden. Artikeln
försöker kasta ljus över situationen.
1 Inledning
Extreme programming (XP) utmålas av många som svaret på många av de problem som
traditionellt plågar mjukvaruuveckling. Problem med tungstyrda utvecklingsprocesser,
brister i kravhantering, överarbetad personal och bristande kodkvalitet kan, enligt XPmodellens
förespråkare [embrace], lösas om mjukvaruteam håller sig till modellen.
Samtidigt som många forskare, mjukvaruexperter och utvecklare tror på XP som
modell, förhåller sig många skeptiska till de nya idéerna. Skeptikernas invändningar är
många, i synnerhet när det handlar om större projekt.
Att mjukvaruutveckling enligt XP-modellen kan fungera i en undervisningsmiljö
vet vi [HBM], men hur ser det ut i industrin? Fungerar verkligen de vackra tankarna
om en utvecklardriven utvecklingsprocess?
I denna artikel vill författaren se vad som åstadkommits sedan XP introducerades
för åtta år sedan. Vi kommer att börja med att se över de löften som givits utvecklarna
och kunderna, för att sedan kritiskt granska resultaten. Vi kommer också att titta på
den kritik som finns mot XP-metodiken, och jämföra denna kritik mot vad vi kommit
fram till i artikeln.
2 Bakgrund
Att byta utvecklingsmodell är dyrt och omständigt, och därför tvekar många företag
och institutioner inför att införa XP i sina projekt utan att först ha sett bevis på att
modellen fungerar. Handfasta bevis kan vara svårt att sila fram, men med hjälp av
vittnesmål och undersökningar kan vi skapa oss en uppfattning kring om XP är en
utvecklingsmodell värd att prova på eller ej.
1

3 Vad XP lovar
Genom att anamma XP som utvecklingsmetodik, utlovas utvecklingsteamet en process
som är enkel och tillfredställande att arbeta med. Detta förutsätter dock att utvecklingsteamet
inte är för stort, någonstans mellan två och tolv utvecklare bör man vara
[gentle].
Ur kundens perspektiv, kan det vid första anblicken te sig irrelevant vilken metodik
programvaruleverantören använder sig av. Detta är dock inte helt sant, då XP erbjuder
kunden en rad möjligheter till att kunna påverka utvecklignen under projektets gång.
En aktiv kund är rent av en av förutsättningarna för hela metodiken. Kundens roll
i XP består i att vara med och prioritera fram arbetets inriktning. Utvecklarna kan
också ge kunden information om hur långt arbetet beräknas ha kommit vid en given
tidpunkt. Kunden kan också ändra inriktning under projektets gång, utan att arbetet för
den sakens skull blir ogjort.
XP är en ur kundens synvinkel väldigt transparent process, vilket uppskattas av en
del kunder. I de fall då kunden inte är intresserad av utvecklingsprocessen, kommer
utvecklingsteamet att stöta på en del problem, vilket behandlas i slutsatsen nedan.
Utöver kundkontakten, vågar XP-förespråkarna utlova att kodkvaliteten i ett XPprojekt
är högre än i andra projekt, beroende på metodikens fokus på test-driven utveckling.
Så länge utvecklarna är bra på att göra tester, kommer väldigt få småfel att slinka
igenom test-nätets fina maskor. Även acceptanstester är viktiga, då det är dessa som
avgör om produkten är klar för användning eller ej.
XP-förespråkarna lovar också att en kund som köper in ett XP-projekt kan förvissa
sig om att snabbt få ett fungerande system, även om funktionaliteten i ett inledande
skede är starkt begränsat. På så sätt kan kunden känna att den får något för de pengar
som läggs i projektet.
Eftersom XP är en dokumentfattig process, där koden själv är sin främsta dokumentationsform,
sägs det att ett XP-team enkelt kan ta in nya medarbetare, och att
dessa snabbt sätts in i koden fungerar. Detta beror även på XP-metodikens förkärlek
för parprogrammering. [Lovaasen]
4 Kritiken mot XP
Skeptikernas kritik mot de agila processerna [manifest], inte bara XP, är i många fall
hård, men inte omotiverad. Utvecklingsmodeller som Rational Unified Process (RUP)
och Capability Maturity Model (CMM) är idag välkända och beprövade inom industrin.
Dessa fungerar bra, i synnerhet för större projekt med många medarbetare och lång livscykel.
Skeptikerna framför kritik mot XP-modellens kommunikations- och dokumentationsmodell,
som radikalt skiljer sig från vattenfallsmodellernas mer formellt inriktade
modell med stora mängder dokument. McBreen [McBreen] anmärker avsaknaden
av inledande analys och design inom XP, vilket torde bero på en missuppfattning från
dennes sida, då detta tas upp av Beck [embrace]. McBreen finner "parallels between
undisciplined hacking and XP".
McBreen kritiserar också XP-förespråkarnas syn på deadlines, där utvecklarnas
långsiktiga uthållighet sätts före leverabler uppsatta av ledningen. Att inte ha en fast
deadline för projektet gör det svårt för företag att sälja in projekt hos externa kunder,
något som återigen tas upp av Beck, som istället ser XP:s modell med prioriterade
stories som en möjlighet för kunden att få vara med och välja ut vad som ska utvecklas
till varje given release, vilket alltid har ett fast pris baserat på antalet mantimmar.
2

Något som orsakar debatt är XP-modellens idé om att kunden ska vara på plats
under systemets utveckling. Skeptikerna hävdar att det i praktiken kommer att vara
svårt att finna kunder som är så pass engagerade i sina mjukvaruinköp att de kan avsätta
en medarbetare till att hela tiden vara utvecklingsteamet till hands. Det visar sig att
skeptikerna har rätt i detta påstående, och vi får anledning att åkerkomma till detta
längre fram.
Då XP är en relativt lättarbetad process, ser McBreen ett möjligt problem i fallet
då utvecklarna tappar gnistan, och inte har något annat än varandra att hänga upp sitt
arbete på. Vare sig Manifestet [manifest] eller Beck [embrace] tar upp problemet, men
i [embrace] beskriver Beck vad som händer då en utvecklare väljer att lämna utvecklingen
och ersätts med en ny. Detta är dock ingen lösning på problemet med omotiverade
medarbetare. Att som Beck och Jeffries [Jeffries] hävda att XP per automatik ger motiverade
medarbetare håller inte i längden.
Det som aldrig verkar kritiseras är XP-modellens syn på testning av produktionskoden.
Att använda sig av enhetstester och acceptanstester förespråkas till och med
av McBreen, som annars är allt annat än mild i sin kritik mot XP.
5 XP i praktiken
Eftersom XP är en relativt ny utvecklingsmodell, finns inte många vetenskapliga undersökningar
av modellen. Några undersökningar har gjorts, bland annat en av Münchens
Tekniska Universitet (MTU) [Rumpe], och enligt denna undersökning fungerar modellen
bra. Problem saknas inte, men XP har trots detta klarat sig förvånansvärt väl jämfört
med mer traditionella utvecklingsprocesser. Utvecklarna ska enligt undersökningen
trivas mycket bättre med XP än med mer tungarbetade processer, men framför allt
ökar kvaliteten på den levererade produkten samtidigt som produkten i stor utsträckning
levererats på utsatt tid.
Intressant med undersökningen är att XP verkar ha fungera inom alla de områden
där det används. Det verkar också ha fungerat bra oavsett om det handlade om
nyutveckling eller vidareutveckling och underhåll av äldre system.
Av de tillfrågade sade sig 93,3% vilja använda XP igen, medan resterande 6,7%
ville göra små förändringar i XP innan de använder de igen. Värt att nämna är dock,
att 100% sade att de aktivt skulle propagera för XP i fortsättningen.
Ett varningens finger riktas till läsaren av rapporten, då Rumpe och Schröder misstänker
att undersökningens positiva siffror kan visa sig komma av att endast XPförespråkare
svarat på frågorna.
5.1 Fallstudien Watley
Bortsett från MTU:s undersökning, finns mest fallstudier att tillgå, det mest kända
är Becks eget C3-projekt [embrace]. Huruvida detta var ett lyckat projekt eller ej,
är något oklart. Lovaasen [Lovaasen] beskriver ett projekt på den amerikanska mäklarfirman
Watley, som ska ha varit mycket lyckat. Projektet ska ha följt XP-modellen
väldigt noga. Lovaasen beskriver de få övertramp som gjordes under projektet, och
följderna av dessa. Då man vid ett tillfälle var tvugna att arbeta 60 timmar i veckan,
steg produktivteten med blygsamma 20%, medan felen ökade med alarmerande 200%.
Lösningen på problemet med övertiden blev att i de fall då övertid inte kunde undvikas,
uppmuntrades utvecklarna att ta ut ledighet i början av nästkommande iteration.
Den lediga tiden togs med i beräkningarna inför iterationen, så att tidsåtgången till
3

slut skulle jämna ut sig. Teamets största problem ska ha varit att en del medarbetare
motsatte sig övergången till XP. Dessa avskedades senare som ett led i företagets besparingsprogram.
Längre fram anställdes nya utvecklare, och XP-teamet växte från de
ursprungliga fyra till fjorton medlemmar. Lovaasen skriver om nyttan av ett gemensamt
arbetstutrymme, och om hur detta drastiskt förbättrar kommunikationen inom teamet,
men även samhörigheten inom teamet. Genom att introducera stressänkande element
såsom växter, en matplats och en hörna med leksaker, kunde teamet hålla stressen på
en låg nivå, trots den snabba arbetstakten som XP påbjuder. Lovaasen vittnar om en
hög arbetsmoral och hög kunskapsnivå inom teamet. Det senare tillskriver han framförallt
parprogrammeringen. Detta bekräftas av MTU-undersökningen [Rumpe], som
beskriver "immense knowledge transfer between the programmers."
5.2 XP i en akademisk miljö
XP har under några års tid praktiserats i akademisk miljö världen över med blandade resultat.
I Lund har försöket med att använda XP som introduktion till området mjukvaruutveckling
varit lyckat [HBM]. Utbildningen består här av två samarbetande kurser: en
för andraårsstudenter och en för äldre studenter, varav den senare syftar till att träna
studenterna i coaching av programvaruteam. De äldre studenterna agerar coacher för
de yngre, allt medan en representant från institutionen agerar kund. Båda kurserna innehåller
introduktionsdelar till mjukvaruutveckling enligt XP. Utvecklingen sker sedan
i datorsalar i sessioner om åtta timmar. Bortsett från problem med att få studenterna
att ta till sig "Test First" och "Simple Design", har försöken med att lära ut XP till
studenterna varit lyckade.
På andra håll har liknande försök inte slagit lika väl ut. På Santa Clara University,
USA, genomfördes år 2002 en tvådelad kurs, som syftade till att testa om XP
kunde hjälpa studenterna att fokusera på produkten istället för individuella leverabler
[Noll]. Kursdeltagarna, som sattes att utveckla ett webbaserat salbokningssystem, delades
slumpmässigt upp i fyra grupper, två som fick utveckla enligt XP, och två som
fick utveckla produkten enligt en mer traditionell modell. De båda teamen som fick
utveckla enligt XP fick tillgång till en kund, spelad av en övningshandledare, och en
coach, spelad av Noll, läraren. Till skillnad från kursen i Lund, satt teamen aldrig
samlade. Deltagarna i XP-delen fick dessutom bara en halvtimmes träning i XP innan
det första planeringsmötet påbörjades. Experimentet resulterade i att de båda XPteamen
hade betydligt mer robust kod än de båda andra teamen, men till skillnad från
dessa, gick XP-teamens program inte att använda til något. Artikelförfattarna är dock
övertygade om att det inte går att skylla på XP som utvecklingsprocess; istället är de
självkritiska och ställer upp en rad åtgärder som ska testas under en andra omgång av
experimentet.
6 Problemen med XP
Som tidigare nämnts är systemet med kund på plats problematiskt för många XPprojekt.
Enligt MTU:s undersökning saknade vart femte projekt en kund på plats.
Bland de projekt som faktiskt hade kunder, var kunden ofta spelad av någon ur teamet
eller ledningen, eftersom den verkliga kunden saknades. För övrigt uppskattades inte
alltid kunden, eftersom denna inte var på plats så pass mycket som önskades av teamen.
I de projekt där kund-kontakten trots allt fungerade bra med en närvarande och
engagerad kund, blev kunden en viktig del av teamets arbete.
4

Något som vållade problem i de utvärderade projekten var bruket av metaforer.
Detta har, enligt Rumpe och Schröder, att göra med att begreppet metaforer är svårt att
förstå och ta till sig, vilket är olyckligt, då metaforerna som bekant är de arkitekturbärande
delarna i ett XP-projekt.
Det visar sig att XP har en inlärningskurva för de utvecklare som kommer från en
vattenfallsbaserad miljö, som är relativt brant och lång. En del utvecklare klarar inte
av att ta till sig delar av XP:s tolv principer, och väljer då att stå utanför när resten
av utvecklingsteamet [Lovaasen] bestämmer sig för att prova på XP. Speciellt parprogrammering
hade en del svårt att ta till sig, men när det väl arbetats in, blev det ett
mycket uppskattat element av XP-modellen [Rumpe].
7 Anpassning av XP till större projekt
Mycket av kritiken mot XP går ut på att det kan vara svårt att använda XP till större
projekt, som behöver en i förväg upplagd design för att möta de krav som ställs på den
färdiga produkten. Frågan är om det går att anpassa XP till ett större projekt utan att
för den sakens skull tappa fördelarna med den agila process som XP trots allt är. Vi
ska snart se att det till viss del kan fungera, även om delar av det som normalt ses som
utmärkande för XP förändras för att passa in i sin nya miljö.
7.1 Fallstudien FinApp
Cao mfl. [CMXR] beskriver utvecklingen av en finansiell applikation de kallar Finapp.
Fallstudien baserar sig på en verklig utvecklingssituation på ett större icke namngivet
mjukvaruföretag. Systemet som utvecklades var ett större system avsett för banker,
försäkringsbolag och liknande finansbolag. Kraven på tillförlitlighet var därför väldigt
högt ställda. Utvecklingsteamet var relativt stort, tjugotvå utvecklare var sysselsatta
med projektet. Det beslutades tidigt att man skulle välja en agil process för att kunna
möta eventuella förändringar i kraven på systemet. Valet föll på XP, som med några
viktiga förändringar skulle visa sig passa väl till det aktuella problemet.
Då domänen som applikationen tillhör är välkänd och väldefinierad, beslutade man
sig för att dra upp riktlinjer för mjukvaran i förhand. Detta gjordes med hjälp av
metaforer och några få patterns. Den stora fördelen med att designa i förhand är enligt
författarna att applikationen kunde vila på en stabil och säker stomme, till vilken
utvecklarna senare skulle kunna lägga ett flertal olika tjänster på ett enkelt sätt. Till
detta tillkom kraven på att applikationen skulle klara av de hårt ställda krav som tidigare
nämnts längre upp i avsnitten. Med en väl definierad stomme, var detta inget
problem. En bieffekt av att designa i förhand, viade sig vara att nya utvecklare kunde
lära sig systemet på bara några dagar, något som inte var fallet med utvecklingsgruppens
tidigare processmodell.
Då stommen inte kunde utvecklas enligt XP-modellen, fick man även förändra iterationsprocessen
något. Istället för att använda sig av traditionella iterationer, fortlöpte
sex månader innan en första release kunde släppas. Av praktiska skäl lät man iterationerna
baseras på ett antal stories istället för en fix tidsrymd, som är normalfallet i
XP.
Likt många andra XP-projekt, hade man även på FinApp problem med att få en
kund på plats, då kunderna i regel var storbanker. Man löste detta genom att låta
områdeskunniga chefer på mellannivå agera kund, vilket fungerade betydligt bättre
än att ha en riktig kund, som var närvarande sporadiskt.
5

Enligt författarna skulle parprogrammering inte fungera särskilt bra i ett stort projekt,
och därför begränsade man parprogrammeringen till analys, design och framtagning
och implementation av tester. Som orsak till detta, anger författarna motstånd mot
parprogrammering hos utvecklarna. Man gjorde valet att skippa parprogrammeringen
till förmån för högre arbetsmoral. Huruvida detta leder till ett bättre resultat eller ej
framgår inte. Trots detta verkar man ha fått del av de fördelar som parprogrammering
erbjuder i form av kodkvalitet, förkortad utvecklingstid och en kollaborativ arbetsmiljö
för utvecklarna.
Författarna anser projektet som lyckat, och pekar på XP och agila processer som ett
bra svar på kravet att kunna leverera produkter i en snabbare takt än vad vi varit vana
vid tidigare.
8 Slutsats
Utifrån vad som skrivts ovan, kan vi konstatera att utvecklarna i stor utsträckning är
nöjda med XP. Även om detta är viktigt, säger det ingenting om resultatet av deras
arbete. Går vi igenom de olika fallstudierna och undersökningarna, finner vi dock
att XP har fungerat bra i alla fall utom ett. Om detta har att göra med att XP är en
bra utvecklingsprocess eller om det beror på att XP-skeptikerna inte skriver artiklar,
förtäljer inte materialet, men med tanke på den överväldigande positiva feedback som
XP har fått under de senaste åren, kan vi i alla fall sluta oss till att XP inte längre kan
negligeras.
Vi har sett att kundens engagemang är av största vikt för om ett projekt ska lyckas
eller ej. Kund-aspekten måste alltså tas med när man beslutar om att starta upp ett XPprojekt
eller ej. Visar kunden lågt intresse för att vara delaktig i processen, bör man
kanske tänka om och välja en traditionell utvecklingsmetod istället.
Vi har också sett att teamets storlek är av stor betydelse för huruvida projektet ska
bli framgångsrikt eller inte. I de fall då ett större utvecklingsteam varit iblandat, kan vi
se att man varit tvungen att förändra XP:s spelregler för att projektet ska fungera. Vi
kan därför sluta oss till att XP-projekt bör bestå av ett mindre antal människor.
Vidare kan vi konstatera att metafor-begreppet ibland missförstås, och tappar därför
sin stora betydelse. I dessa fall har projektet fortfarande fallit väl ut, men kanske inte
så bra som det skulle kunna ha gjort.
9 Framåtblick
Vi har sett hur XP fungerar i medelstora och stora projekt, och även i akademiska
miljöer. Vi får nog vänja oss vid tanken på att XP kommer att få en betydligt större
plats inom mjukvaruutvecklingen i framtiden. Huruvida det blir en dominerande processmodell
eller ett exotiskt alternativ till de traditionella utvecklingsmodellerna återstår
att se. Författaren ser personligen fram emot en framtid med fler utvecklingsmöjligheter
än de traditionella, trögflytande processerna. För en lätthanterlig och spännande
framtid!
6

10 Referenser
Embrace Kent Beck: Embracing Change with Extreme Programming, IEEE Computer
32(10): 70-77 (1999)
HBM Görel Hedin, Lars Bendix, Boris Magnusson: Teaching Extreme Programming
to Large Groups of Students, Lund Institute of Technology, Journal of Systems
and Software, forthcoming 2003.
manifest Kent Beck et al.: Manifesto for Agile Software Development, 2001; agilemanifesto.org
McBreen Pete McBreen: Questioning Extreme programming, Addison-Wesley, 2003; ISBN
0201844575
Rumpe Bernhard Rumpe, Astrid Schröder: Quantitative Survey on Extreme Programming
Projects, Munich University of Technology, 2001
Lovaasen Grant Lovaasen: Brokering with eXtreme Programming, Thinkspark, 2001;
www.agileuniverse.com/2001/pdfs/EP201.pdf
Noll John Noll, Darren C. Atkinson: Comparing Extreme Programming to Traditional
Development for Student Projects: A Case Study, Department of Computer Engineering
Santa Clara University, 2003
CMXR Lan Cao, Kannan Mohan, Peng Xu, Balasubramaniam Ramesh: How Extreme
does Extreme Programming Have to be? Adapting XP Practices to Large-scale
Projects, Proceedings of the 37th Hawaii International Conference on System
Sciences, 2004
Jeffries Ron Jeffries et al.: Extreme Programming Installed, Addison-Wesley, 2001;
ISBN 0201708426
gentle Extreme Programming: A gentle introduction, 2003;
http://www.extremeprogramming.org/
7