Kritik av Extrem Programmering Markus Borggren d01mbo@efd.lth.se Martin Persson d01mp@efd.lth.se D01, Lunds Tekniska Högskola 15 februari, 2004 Abstract I denna djupstudie kommer vi att försöka, på ett objektivt sätt, ge en bild av en agila metodiken Extrem Programmering. Målet är att reda ut dess för och nackdelar, samt ge lite riktlinjer om passande användningsområden. Målgruppen är personer med grundläggande erfarenhet om Extrem Programmering.
Innehållsförteckning Inledning 2 Extrem Programmering 3 Enkel design 3 Refaktorisering 4 Test-driven Development 5 Parprogrammering 5 Kollektivt kodägande 6 Gemensamt utvecklingsrum 7 Kund i teamet 8 Slutord 9 Referenslista 10 1
Inledning I hela våra liv präglas vi av hur vårt samhälle är uppbyggt. Redan i unga år hade vi bra koll på hur det gick till när man t.ex. skulle bygga hus. Man började med en ide och utvecklade sedan denna till en ritning. Huset på ritningen blev sedan, efter lite experthjälp, ett hus och till sist flyttade man in. Detta arbetssätt, som har arbetsnamnet vattenfallsmetoden, återfinnes i alla möjliga projekt i vårt samhälle. Vi har levt med den och sett hur bra den fungerar på flera tillämpningar, varpå vi, som en kniv i bröstet, får reda på av lärda män i kavaj att detta inte alls är ett bra sätt att arbeta fram en bra programvara. Vad händer? Jo vi måste ändra hela vårt tankesätt, som vi använt oss av i årtionden. Fastän de agila metoderna låter bra så finnes alltid en rädsla eller ett motstånd mot förändring. Vi ska inte designa i förväg utan istället för att planera hela vårt arbete skall vi bara planera en liten bit fram. Vad händer då med vårt slutliga mål? Kommer vi någonsin nå dit? Förvirringen kan tyckas löjlig för vissa, men för de flesta är detta nog en omställning som inte går av sig självt. 2
Extrem Programmering Vid genomgång av för och nackdelar med XP I har vi lite olika källor. Den erfarenhet vi själva har som programmerare och coacher, vårt team som vi coachar och sist men inte minst litteratur och Internet. Här nedan kommer vi att gå igenom de mest centrala delarna av XP och för var och en ge er våra och våra källors åsikter och funderingar. Enkel design Vid programmering enligt vattenfallsmodellen ges ofta "Implementera för idag, designa för imorgon" som råd. Tanken är att en god design kommer löna sig i längden. XP däremot har en helt annan ståndpunkt. Att designa för morgondagen är, enligt XP, en gissningslek som inte är motiverbar. En av de slogans som XP använder sig utav är Do the simplest thing that could possibly work, vars innebörd mycket väl speglar XP: s ställningstagande. Detta kontroversiella synsätt har väckt många diskussioner mellan förespråkare och motståndare till XP. Tanken med XP är, som Kent Beck bland annat beskriver i sin bok Extreme Programming Explained: Embrace Change 1, att morgondagen är så osäker inom programvaruutveckling att design för morgondagen kommer med för stor sannolikhet kosta mer än nödvändigt. Ian Alexander skriver följande i The Limits of extreme Programming 2 : "Maxims like, do the simplest thing that could possibly work, do not necessarily lead to optimal solutions. Vem som rätt eller fel kan ingen direkt svara på då båda har mycket bra åsikter. Vad vi kan erbjuda er är dock våra egna erfarenheter samt rekommendation att läsa vad Ian och Kent skriver. Våra egna erfarenheter inom detta arbetssätt är relativt goda. Vi hade inga större problem att jobba fram en bra produkt utan att designa mycket i förväg. Dock skall ju tilläggas att projektet endast var några tusen rader kod vilket säkerligen var en starkt bidragande faktor. I XP är förkortning av Extrem Programmering 3
Under vårt arbete som coacher har vi däremot mött ett starkare motstånd ibland våra programmerare. De känner att en större vikt på designen i börjar hade underlättat projektet avsevärt. Vid diskussion med de andra coacherna har vi erhållit erfarenheter från en grupp som har haft en programmerare med stor erfarenhet inom design. De märkte att hans arbete tog lite längre tid än de andras, men resultatet var för gruppen en stor tidsvinst i slutet. Hans sätt att tumma på regeln om enkel design ledde till att gruppens program blev bättre. Refaktorisering Refaktorisering innebär att man ändrar och snyggar till koden utan att ändra funktionaliteten. I XP görs detta främst för att lättare kunna göra ändringar och för att upprätthålla enkel design. Man kan refaktorisera antingen för hand eller med hjälp av något verktyg. I vårt projekt användes Eclipse II. Att göra mindre ändringar likt att byta namn på klasser och variabler fungerade bra, men under samtliga långlaborationer var det någon som refaktoriserade så att det blev små konflikter inom gruppen. Att andra går in och ändrar ens kod uppskattas inte alltid! Clifford Shelley menar på i sin artikel Our Collision with XP: What We Picked Up 3 att refaktoriseringar kostar allt för mycket. Resultatet är inte garanterat bättre, det tar väldigt lång tid och leder till fel som våra tester kanske inte klarar av att detektera. Våra egna erfarenheter säger att man behöver refaktorisera, speciellt tidigt i projektet så man får en bra struktur och design. Sen stämmer det som Clifford skriver att det tar väldigt lång tid och att det är en källa till fel men i ett mindre projekt, som XP riktar sig till, så tycker vi att fördelarna väger över gentemot nackdelarna. II http://www.eclipse.org/ 4
Test-driven Development En stöttepelare inom XP är dess tester, eller som Beck själv skriver i Extreme Programming Explained: Embrace Change 4 : If you re not testing, it isn t extreme. Att skriva tester innan man skriver koden enligt test-first principen är betydligt lättare sagt än gjort. Under båda projekten som vi har följt har det brustit på denna punkt. Förklaringen till detta handlar nog främst om att man vill ta sig snabbare framåt. Ofta känner man även att man inte riktigt vet hur man ska implementera så det går inte att skriva testerna förrän efter man har skrivit koden. Att man har stor nytta av att ha tester som man hela tiden kan köra och testa så att all gammal funktionalitet fortfarande fungerar uppfattas dock som väldigt bra och tryggt. Mark Paulk tar i XP from a CMM Perspective 5 upp att många av XP metodiker är allmänna för all programmering. Bland annat menar han på att man länge har ansett det som en bra programmeringsrutin att tänka på testfall tidigt men att det sällan används. Parprogrammering Att använda sig av parprogrammering är en av de stora sakerna inom XP. Förespråkare för XP anser att detta leder till mindre fel i koden samt högre effektivitet. I sin artikel Comments on extreme Programming 6 pekar Watts Humphrey dock på att så inte riktigt är fallet. Enligt Humphrey finner man ungefär 10-25 % av felen i sin egen kod. Använder sig av parprogrammering kommer man upp till 20-40 %. Skulle man däremot använda sig av PSP III och TSP IV kan upp till 60-80 % av felen hittas. Detta visar, enligt Humphrey, att man kan få bättre kvalité och kortare testningstid med dessa metoder. III PSP Personal Software Process. PSP ger specifik vägledning om hur enskilda ingenjörer kontinuerligt kan förbättra deras prestationer, http://www.sei.cmu.edu/tsp/ IV TSP Team Software Process. TSP ger specifik vägledning om hur PSP-utbildade ingenjörer på ett effektivt sätt kan jobba i ett effektivt team, http://www.sei.cmu.edu/tsp/ 5
Enligt egna erfarenheter fungerar parprogrammering väldigt bra. För en inte alltför van programmerare är det skönt att kunna diskutera olika lösningar direkt med någon på samma nivå som en själv jämfört med att behöver springa till chefen/kursansvarig vid problem. Sitter man ensam sjunker koncentrationen också betydligt fortare och man har lättare för att förvilla bort sig från det riktiga programmeringsproblemet. Då man är två personer med all kod och kör kontinuerliga partnerbyten så blir man insatt i fler delar av koden också. Detta påpekar Ian Alexander och menar att detta tillsammans med en god kommunikation gör det möjligt att använda sig av så pass lite dokumentation som XP förespråkar. Deltagarna i vårt coachade team ansåg även att parprogrammering hjälpte till väldigt mycket med att lära känna gruppen och skapa en trevlig arbetsmiljö. Kollektivt kodägande Att man tillåter alla programmerare att ändra i koden, som i XP, skapar självklart problem. I vårt projekt använde vi oss av Eclipse, vilket gör att man kan sitta och jobba i samma klasser samtidigt. Det leder till att man får mergekonflikter V, vilket med detta arbetssätt är svåra att komma ifrån. Vad Eclipse inte löser är att någon i teamet kan gå in och ändra i den kod du skrivit, vilket kan leda till både förvirring och lite irritation. Redan på 70 talet skrev Jerry Weinberg om ego-less programming i Handbook of Walkthroughs, Inspections, and Technical Reviews 7 och den innehåller något man måste tänka på i en situation som denna; Att uppskatta om någon snyggar till ens kod och inte se det som personlig kritik. Dessa problem är alla relaterade till hur stort projektet är. Med ett projekt på 10 personer går det att lösa sådana konflikter medan om man blir fler blir det genast svårare. Mark Paulk tar även upp detta problem och pekar på att kommunikationen är väsentlig även här för att komma runt problem. Vid ett större projekt behövs mer riktlinjer för att upprätthålla att alla pratar och informerar om ändringar samt eventuella lösningar. Här kan man tänka sig att om man delar upp ett större projekt i undergrupper, så kan dessa grupper köra XP inom gruppen medan man har en större organisation i bakgrunden. V Merge, Två versioner av kod visas och en av dem skall väljas och en tas bort. 6
Vad vi märkte och även vad gruppen tog upp på denna punkt var att man måste sätta sig in i koden om och om igen på grund av att alla gör ändringar överallt, samt att man känner mindre ansvar över koden när man inte är ansvarig för något speciellt, utan att alla har koll på allt. Gemensamt utvecklingsrum Det kollektiva ägandet av all kod kräver kommunikation i gruppen. När man sitter i samma rum och programmerar blir det bättre kommunikation och sammanhållning i gruppen. Detta underlättar även väsentligt för kunden då XP bygger på att kunden skall vara i teamet under utvecklingen. Här märks tydligt en av XP: s svagheter; gruppens storleksbegränsning! Om bra kommunikation skall erhållas får inte gruppen bli för stor. Vi kan fastslå att en begränsning av användarområdet är nådd, men det är inte allt! Många projekt i dagens näringsliv börjar som små satsningar som senare växer sig större än förväntat. Det som började som ett bra projekt för XPmetodiken på några tusen rader kod utvecklas då till ett storskaligt projekt. Fastän de som påbörjade projektet var väl medvetna om XP: s begränsade användningsområde, befinner de sig nu i ett läge där metodiken har en av sina stora svagheter. Ponera att de som jobbar med projektet kommer fram till att expanderingen kommer att fortsätta. Då finns det risk att XP-metodiken måste överges vilket kommer att resultera i omstrukturering och kanske till och med en stor ekonomisk kostnad. Så fastän det är ett litet projekt som skall påbörjas måste detta scenario tas med i riskanalyserna. 7
Kund i teamet Att ha en kund i teamet innebär att antingen kunden, eller någon som representerar kunden, finns på plats i teamet och följer projektet hela tiden. I vårt projekt hade vi en kund som tittade in två gånger per långlaboration samt en gång under planeringsmötet. Det var mycket märkbart hur programmerarnas relation förbättrades ju fler gånger de talat med kunden. Efter ett tag lärde man sig kundens nivå i kunnande och kunde då på ett bättre sätt förklara problem och utveckling. Fördelarna med att ha en kund på plats är att man kan väldigt snabbt få svar på frågor om utformning samt prioriteringar från kunden. Man tvekar inte heller att ställa frågor lika mycket som när man måste ringa eller skriva e- mail till kunden, vilket inte bara tar tid utan även gör det mycket svårare att förklara eventuella problem. Kunden kan även förklara stories vilket leder till att dom inte behöver vara så exakta som de annars hade behövt vara. Förutom nackdelen med att en full lön till måste betalas så finns det några saker till att ta upp. Eftersom att kunden inte alltid är insatt i de tekniska svårigheterna kan det t.ex. vara svårt att övertyga kunden om att vissa tekniska prioriteringar måste göras. Ofta är fallet så att det inte finns någon kund när projektet skapas och då går inte denna del av XP metodiken att genomföra. 8
Slutord Vi hoppades att med denna djupstudie erbjuda ett lite bättre underlag för en objektiv syn på XP än det kurserna Programvaruutveckling i grupp 8 och Coachning av programvaruteam 9 ger. Vi menar intet illa om kurserna i sig, utan hoppas enbart att denna djupstudie kan bidraga med ett lite objektivare betraktelsesätt på XP. Våra tankar om XP före denna djupstudie var enbart positiva. Vi hade i programvaruutvecklingskursen arbetat enligt metodiken och hade inte mycket att invända mot arbetssättet. Vad vi erfarit under vår coachning av programvaruteam, som använder sig utav XP, är att de som programmerat mycket innan oftast har svårare att anpassa sig till metodiken. Det var även dessa personer som bidrog med den mest givande kritiken mot XP. Vad vi inser är att begränsningen, tidsmässigt lika väl som storleksmässigt, i vårt projekt bidrog avsevärt till vår syn på XP. Vi hade mycket gärna velat erfara ett projekt som sträcker sig över en längre tidsperiod, så att problem likt dålig kommunikation i gruppen och liknande tonas bort. Vi kan ju i det stadie vi befinner oss i nu enbart läsa oss till och spekulera i hur ett verkligt projekt artar sig. Under så korta projekt hinner man heller inte på ett korrekt sätt komma in i rytmen med att testa, koda och sen refaktorisera, utan refaktorisering blev nästan en stående spike. Med mer tid hade vi säkerligen kommit i XP: s metodik bättre och resultaten och arbetssättet hade förbättrats. Någon slutsats om huruvida XP är bra eller inte har vi inget intresse av att gå in på då djupstudien gick ut på att få er som läsare att tänka till lite själva, se för och nackdelarna, varpå ni sedan kan skapa er en egen uppfattning. 9
Referenslista 1 Kent Beck, Kent Beck, extreme Programming explained, 1999 2 Ian Alexander, "The Limits of extreme Programming", http://www.computer.org/seweb/dynabook/alexandercom.htm 3 Clifford Shelley, Our Collision with XP: What We Picked Up, http://www.computer.org/seweb/dynabook/shelleycom.htm?smsession=no 4 Kent Beck, Extreme Programming Explained: Embrace Change 5 Mark Paulk, XP from a CMM Perspective, http://www.computer.org/seweb/dynabook/paulkcom.htm 6 "Comments on extreme Programming" Watts Humphrey, http://www.computer.org/seweb/dynabook/humphreycom.htm 7 Daniel Freedman och Jerry Weinberg, Handbook of Walkthroughs, Inspections, and Technical Reviews, 3rd edition 8 Lunds Tekniska Högskola, kurskod EDA260, http://www.cs.lth.se/education/courses/eda260/ 9 Lunds Tekniska Högskola, kurskod EDA270, http://www.cs.lth.se/education/courses/eda270/ 10