Håller XP vad det lovar?

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