Att införa XP. Daniel Nilsson och Mattias Nordahl Lunds Tekniska Högskola. 27 februari Abstrakt

Transkript

1 Att införa XP Daniel Nilsson och Mattias Nordahl Lunds Tekniska Högskola 27 februari 2012 Abstrakt Genom analys och sammanfattning av tidigare publikationer samt diskussion och reflektion av en högskolekurs där vi coachade yngre högskolestudenter genom ett XP-projekt (extreme Programming) försöker vi i denna artikel belysa ett par saker som är av stor vikt vid införandet av XP. Vi lyfter fram vad som tenderar vara svårt, varför och vad man kan göra åt det och behandlar främst ämnen som parprogrammering, testdriven utveckling, refaktorisering, simpel design, den sociala utvecklingsmiljön och nämner kort interaktionen med andra delar av organisationen, som till exempel kunder och företagsledning. 1

2 1 Inledning Att införa nya arbetsmetoder och tankesätt är inte alltid det lättaste, speciellt inte om befintliga vanor är djupt rotade och upplevs fungera väl. Syftet med denna studie är att lyfta fram de problem man kan stöta på då man försöker att införa nya metoder i ett programvaruutvecklingssammanhang, samt att undersöka vilka tillvägagångssätt det finns för att på bästa sätt hjälpa utvecklare att ta till sig nya arbetssätt. Fokus ligger dock främst på införandet av extreme programming (hädanefter XP), som beskrivet av Beck [1], snarare än metoder i allmänhet. Vi tittar på en del praktiker som tenderar att vara mer problematiska än andra, vilka effekter det kan få, och om det finns några bra sätt att stimulera införandet av dessa praktiker för att minimera potentiella problem. Detta görs genom en analys och sammanfattning av tidigare publikationer inom området i kombination med våra egna erfarenheter ifrån ett praktiskt projekt där vi coachade ett utvecklingsteam omfattande åtta studenter på högskolenivå. Under projektet skulle ett system för tidtagning av enduro-tävlingar (terrängkörning med motorcykel) utvecklas med hjälp av XP. Systemet bestod av två delar: Ett registreringsprogram som används ute i fält för att registrera tider och spara dessa på filer, samt ett sorteringsprogram som sammanställde data från de olika registreringsstationerna. Under utvecklingen tog en utomstående aktör (i vårt fall en doktorand) på sig rollen som kund, och kom med nya stories (små definitioner av ny önskvärd funktionalitet) varje vecka. Dessa tidsestimerades av utvecklarna under planeringsmöten och implementerades under iterationerna. Vi som coacher var vid tillfället själv äldre studenter som hade genomgått kursen tidigare och således hade lite mer erfarenhet än de flesta av utvecklarna. Projektet omfattade sex iterationer om vardera åtta timmar, med ett två timmar långt planeringsmöte innan varje iteration samt tre releaser till kunden. Dessutom hade vi som coacher ett extra möte med övriga coacher samt kursansvarig en gång i veckan, där man kunde få en uppfattning om hur det gick i de andra grupperna och diskutera eventuella problem och tips. Då man kanske inte önskar införa hela XP-processen i ett enda steg var vårt mål även att identifiera vilka principer som tenderar att vara lättast att införa tidigt och hur man kan bygga ut dem efterhand som utvecklarna blir bättre på att använda dem, samt vilka principer som kanske inte är så viktiga till att börja med. Då detta visade sig vara en aning svårt att generalisera ligger fokus mer på att belysa ett antal viktiga praktiker som någon som ämnar införa XP sannolikt inte kan klara sig utan. Men även hur andra aspekter, som den sociala utvecklingsmiljön och interaktionen med personer utanför utvecklingsteamet, skiljer sig från andra metodiker. Slutligen konstaterar vi att det sannolikt är svårt att enbart introducera delar av XP, utan att detta är något som bör göras mer eller mindre i helhet för att uppnå bästa resultat. 2

3 2 Några huvudpraktiker Det är svårt att tala om XP utan att nämna några av de praktiker som formar processen, och införandet av XP kretsar ofta kring införandet av specifika praktiker, som synes i till exempel artiklarna av Rasmusson [4][6], samt Victor och Jacobson [7]. Det är svårt att införa alla XP's praktiker samtidigt, varför det är viktigt att tänka på vilka som bör införas först [2]. Genom litteratursökning, våra tidigare erfarenheter samt observation tidigt i vårt projekt fann vi ett antal praktiker som vi tycker är extra relevanta i det initiala skedet av XP. De 12 praktikerna i XP är som följer: Planeringsspelet (utvecklarna tidsestimerar, kunden prioriterar) Små releaser (kunden får många releaser ofta, och kan påverka utvecklingen) Metaforer (produkten beskrivs med metaforer för förenklad förståelse) Simpel design (produkten innehåller inte onödigt komplexa lösningar) Testdriven utveckling (funktionalitet definieras av testfall innan implementation) Kontinuerlig refaktorisering (refaktorisering sker ofta, i små steg) Parprogrammering (all kod skrivs parvis, ingen arbetar själv) Kollektivt kodägarskap (alla utvecklare kan ändra all kod) Kontinuerlig integrering (ändringar förs in i repositoriet så fort som möjligt) 40-timmars arbetsvecka (ingen övertid) Kund i teamet (utvecklarna har direkt tillgång till kunden för frågor) Kodstandarder (alla utvecklare följer överenskomna kodstandarder) Av dessa har vi valt att fokusera på parprogrammering, testdriven utveckling, kontinuerlig refaktorisering och simpel design. Urvalet är baserat på en subjektiv bedömning av vilka praktiker som verkade vara mest centrala i den litteratur vi läst i kombination med vad de utvecklare vi coachade verkade ha störst problem med. Några av de andra praktikerna var redan givna i kursupplägget - så som planeringsspelet, kollektivt kodägarskap, ingen övertid och kund i teamet - och kunde inte påverkas mycket av oss. Planeringsspelet gjordes under planeringsmötena, då kunden fick prioritera kvarvarande och nya stories, efter att dessa hade (om)estimerats av utvecklarna. Gemensamt ägarskap av koden såg vi inte så mycket som en praktik, utan snarare ett faktum som presenterades för utvecklarna. All kod lagrades i ett repositorie och alla hade rätt att checka ut och ändra vad de ville. Vi kunde inte vid något tillfälle uppmärksamma att någon inte ville ändra i koden för att det inte var deras. Snarare kunde viss försiktighet visas för att de inte var insatta i den delen av koden, men det avhjälptes successivt med hjälp av de övriga praktikerna, genom kommunikation och att få alla utvecklarna insatta i hela systemet. Att jobba övertid för att skynda på projektet leder oftare till mer problem snarare än att tjäna in tid, som berättas av Kobayashi, Kawabata, Sakai och Parkinson [2]. Vi följde denna praktik, och såg till att 3

4 utvecklarna slutade arbeta när dagen var slut, men vi hade troligtvis inte kunnat se några större effekter av att inte följa den eftersom projektet var på en så liten skala. Det är sannolikt ingen svår praktik att införa i någon organisation och bör således kunna införas tidigt. I kursupplägget ingick också att kunden besökte oss under långlabbarna men vi kunde inte se några stora varken positiva eller negativa effekter av denna praktik, eftersom de flesta stories var ganska väldefinierade och utvecklarna sällan hade frågor som krävde kundkontakt. De resterande praktikerna som inte nämnts är små releaser, metaforer, kontinuerlig integrering och kodstandarder. De är sådana praktiker som är svåra att se effekten av i vårt projekt, på grund av dess ringa storlek, och är således svåra att dra några användbara slutsatser ifrån, varför vi har valt att inte diskutera dem vidare. I följande avsnitt presenteras och diskuteras de praktiker vi har valt att fokusera på där vi också jämför med observationer genom vårt projekt. 2.1 Parprogrammering Parprogrammering är kanske den mest kontroversiella av XP's praktiker för den som är van vid de mer traditionella utvecklingsprocesserna och kan tyckas vara onödig; att låta två programmerare samsas om en dator. Många vittnar dock om det motsatta. I [4] och [6] skriver Rasmusson om hur parprogrammering är den mest kraftfulla praktiken och den som bidrog mest till framgången av hans projekt. Han menar att parprogrammering var den praktik som möjliggjorde en effektiv inlärning och applicering av de övriga praktikerna i hela teamet. Det är således viktigt att ta i beaktan inte bara de enskilda praktikerna var för sig, utan även hur olika praktiker påverkar varandra, vilket styrks i andra studier [2]. Alla utvecklare i ett team kommer ta till sig nya arbetssätt olika fort och parprogrammering kan vara ett sätt att införa konsistens i teamet. Det hjälper utvecklarna att kommunicera och sprida information och erfarenhet till varandra för att i slutänden närma sig samma nivå av kunskap och nyttjande av XP's övriga praktiker. Vi upplevde vid flertal tillfällen att utvecklarna i vårt projekt lärde sig nytt av varandra både om koden, utvecklingsverktygen samt arbetssättet och praktikerna inom XP genom att programmera tillsammans och dela med sig av sina färdigheter. Allt eftersom utvecklarna skiftades runt och hamnade i olika par fördes informationen vidare. De vittnade också själva om hur det var enklare att lösa svåra problem när de hela tiden hade någon annan att diskutera med och de upplevde att parprogrammering var ett effektivt arbetssätt. Vi satte från början målet att skifta utvecklare i alla par varannan timme, då vi också hade korta pauser för att diskutera huruvida arbetet flöt på bra eller ifall det fanns frågor och oklarheter som behövde redas ut. Ifall ett par inte hann blev färdiga med det de höll på med under ett tvåtimmarspass och bara hade lite arbete kvar eller kände att just de 4

5 behövde fortsätta att arbeta tillsammans så lät vi dem fortsätta. Det hände många gånger att ett par trodde sig ha endast lite arbete kvar för att färdigställa sin story eller task och fick således fortsätta att arbeta tillsammans. Nästan alla gånger var det en dålig uppskattning och paret fick fortsätta i ytterligare två timmar, ibland fortfarande utan att bli klara med den aktuella uppgiften. På planeringsmötena efter både första, andra och tredje iterationen bestämdes därför, i enighet med alla utvecklarna att vi som coacher skulle bli hårdare och forcera parbyten efter varje tvåtimmarspass, även om de inte var klara med sin uppgift. Utvecklarna upplevde ibland parbytena som jobbiga, såtillvida att de inte alltid ville lämna uppgiften utan att göra klart den, men också att nettoeffekten av att forcera bytena var övervägande positiv för projektet. Genom att få skifta paren ofta fick alla arbeta med alla och blev mer bekanta med varandra och koden. Vi upplevde att detta stärkte teamets gemenskap och trivsel samt deras förmåga att applicera de övriga praktikerna. Ett problem som kan uppstå är att antalet utvecklare är udda. Detta hände vid ett tillfälle under vårt projekt, och lösningen blev att en navigator (som inte har tangentbordet utan betraktar den kod som skrivs) fick sitta mellan två datorer och övervaka två utvecklare istället för en. Detta medförde dock att det alltid fanns en person som, om än under korta instanser, arbetade själv, även om coachen gick in och hjälpte till ibland. Det har visat sig att detta inte alltid är en bra lösning. Kobayashi, Kawabata, Sakai och Parkinson [2] vittnar om hur soloprogrammering introducerade buggar och missförstånd på ett annat sätt än parprogrammeringen, och rekommenderar istället användandet av trippelprogrammering på något mer komplexa stories. Ett annat alternativ, som nyttjades av coacherna för ett annat team i projektkursen, var att låta den udda personen ta hand om mindre ansvarsområden ensam, så som att producera Javadoc, granska färdiga stories, uppdatera dokumentation eller dylikt. 2.2 Testdriven utveckling I XP sker testning kontinuerligt i takt med utvecklingen, snarare än fram mot slutet. Enligt Beck [1] ska utvecklarna skriva enhetstest minut för minut och alla test ska alltid gå igenom för den kod som finns i repositoriet. Detta ställer krav på utvecklarna att kontinuerligt skriva testfall, vilket ofta inte kommer helt naturligt som synes i artiklarna av Rasmusson [4][6], något som vi själva också kan intyga. Det verkar finnas ett betydligt starkare intresse av att skriva applikationskod snarare än testkod. Flera av de utvecklare som deltog i projektet gav sken av att tycka att testfallen var något nödvändigt ont snarare än något som var av stor nytta för projektet i slutändan. Det krävdes således en del påminnelser och övervakning i början, men det fanns ändå fall då testfallen tillkom i ett betydligt senare skede än vad som var önskat. Vi upplevde också att den testdrivna utvecklingen var svårast för utvecklarna att upprätthålla då de blev stressade, till exempel när en release var nära förestående och en viktig story inte var klar. Det fanns då gruppmedlemmar som slutade skriva tester först, 5

6 i tron att det skulle gå fortare att bli klar, och sedan försökte få ihop några, ofta undermåliga, testfall efteråt. Första gången detta hände blev resultatet att kunden fick en trasig funktion, vilket inte bara resulterade i att storyn behövde göras om, utan även förlorat förtroende från kunden. I detta fallet tror vi att det hade varit klokare att antingen föra en diskussion med kunden om huruvida releasen kunde senareläggas, eller att helt enkelt acceptera att storyn inte kom med i releasen. Även Rasmusson [4][6] vittnar om att den testdrivna utvecklingen inte är något som kommer av sig själv. Han noterade dels att alla inte började skriva testfall först så fort konceptet infördes, men även att de som gjorde det inte omedelbart gjorde det på ett bra sätt. Enhetstestning var något som tog tid att lära sig göra på ett effektivt sätt. Detta var också något vi själva upptäckte under projektets gång, även om det är svårt att avgöra om problemen i vårt fall låg i det nya konceptet, eller den något låga graden av programmeringserfarenhet inom teamet. Stundtals upplevde vi det som svårt att få fram budskapet av den testdrivna utvecklingen till ett par. Ofta berodde detta på att ingen i paret verkade inse fördelarna med arbetssättet. Rasmusson [4][6] beskriver ett tillvägagångssätt för att motverka detta, och pekar på att just parprogrammeringen var den absolut viktigaste aspekten i införandet av den testdrivna utvecklingen. Enligt hans erfarenheter tenderade den testdrivna utvecklingen endast fungera väl då minst en av parmedlemmarna var pigg på att använda det. Om en person i paret var självsäker och hade erfarenhet av arbetssättet var det betydligt lättare att få in den andra på samma spår. De som arbetade själva eller tillsammans med någon som inte hade erfarenhet av testdriven utveckling tenderade att ha svårare att ta till sig arbetssättet. Under vårt projekt hade vi hade ingen som var van vid att arbeta med testdriven utveckling, följaktligen kunde vi inte bilda par som önskat, och en del par gled gärna tillbaka till sina gamla vanor som en följd av detta. Dock har Rasmusson [4][6] också två andra tips på taktiker som kan få utvecklarna att komma in på rätt bana vad gäller den testdrivna utvecklingen. De kanske inte nödvändigtvis får utvecklarna att testa först, men i alla fall att testa väl. Det första av dessa tips är att uppmana utvecklare att skriva enhetstest för varje bugg de rättar till. Detta med motivationen att ett sådant test garanterar att inte samma bugg smyger sig in i koden vid ett senare tillfälle. Som nämnts tidigare hade vår grupp vissa problem med att åstadkomma tillräckligt många och tillräckligt bra testfall under projektets gång, och vi upplevde att detta budskapet om att skriva test för det man rättar till gick fram bättre än att bara tjata om att det behövs fler testfall. Den andra taktiken som förespråkas av Rasmusson [4][6] är att först få utvecklarna att refaktorisera väl, för att sedan förklara för dem att de inte kan refaktorisera på ett tillförlitligt sätt utan bra enhetstester. Detta är ytterligare ett exempel på hur olika praktiker påverkar varandra, och hur en analys av deras samband, såsom gjord av till 6

7 exempel Kobayashi, Kawabata, Sakai och Parkinson [2], kan vara av intresse när man försöker integrera dem. Våra egna erfarenheter från projektet var att utvecklarna mycket riktigt tog till sig budskapet om kontinuerlig refaktorisering på ett bättre sätt än den testdrivna utvecklingen. Således uppstod efter ett tag ett läge där delar av testningen gled in under refaktoriseringen. När utvecklarna upptäckte ett behov av fler enhetstester under refaktoriseringen blev de mer motiverade att skriva dem. Detta ledde till en förbättring av testprocessen som helhet, men faktumet kvarstår, att det var fortfarande svårt att motivera dem att faktiskt skriva testfall innan de började skriva produktkod. Men Rasmusson [4][6] förespråkar också försiktighet vad gäller den testdrivna utvecklingen. Han pekar speciellt på att man måste vara vaksam mot duplicering, och att testa allt som överhuvudtaget kan gå sönder är något som behöver appliceras med försiktighet. Efter en diskussion med utvecklarna ett par iterationer in i vårt projekt märkte vi effekter av detta, då de förklarade att de började hitta allt fler redundanta testfall i takt med att systemet växte. Som coach är detta inte nödvändigtvis något man har god uppsikt över, men genom att uppdaga problemet och föra fram det till diskussion kunde vi göra alla uppmärksamma på det och börja motarbeta problemet innan det blev för utbrett. 2.3 Refaktorisering Beck [1] beskriver refaktorisering som en kontinuerlig utveckling av den befintliga designen i små steg som hela tiden håller systemet i ett läge där alla testfall går igenom. Vi tolkar detta som ett idealläge där det inte uppstår situationer som kräver stora fundamentala ändringar av koden i ett enda steg. Refaktorisering är således något som ska göras kontinuerligt som en del av utvecklingen, och designen ska därmed vara under ständig granskning för att se om den uppfyller de ständigt tillkommande kraven i form av nya stories. Vi menar då att det, till exempel, inte ska behöva uppstå lägen där övrig utveckling stannar upp som en följd av att kodbasen skakats om efter en stor refaktorisering. Detta visade sig dock vara betydligt svårare att upprätthålla än vad man kanske tror vid första anblick. I ett tidigt läge förklarade vi för utvecklarna vikten av kontinuerlig refaktorisering i små steg. Deras reaktion på detta var att de ville ha en förhållandevis genomtänkt grunddesign innan de började skriva kod, för att på så sätt lättare kunna upprätthålla det önskade läget med endast små förändringar. Vi lät dem göra detta, vilket resulterade i en hel del inledande designdiskussioner i början av den första iterationen, vilket verkar spegla de utvecklarna i artikeln av Kobayashi, Kawabata, Sakai och Parkinson [2] som kände behovet av en ny praktik: Gemensam modellering. Följden av detta var att våra utvecklare inte färdigställde så många av de skattade tidsenheterna arbete som önskat. Men nöjda med en god grund fortsatte sedan den andra och tredje iterationen, vilka såg tillskott av ny funktionalitet och ledde (som förväntat) till ändringar av den grundläggande designen. Utvecklarna upplevde det som att de refaktoriserade 7

8 kontinuerligt, och ändrade design och annan kod relaterad till deras story när behov uppstod. Trots detta stod det klart efter tredje iterationen att någonting uppenbarligen hade brustit på vägen. Koden hade efterhand blivit mer och mer resistent mot förändringar i takt med att vissa klasser och metoder växte, och de refaktoriseringar som gjordes gick inte tillräckligt djupt för att motverka detta. De köpte endast en aning mer tid innan de grundläggande problemen blev tydliga igen. Som följd av detta befann sig koden i sinom tid i ett läge där de förespråkade små kontinuerliga refaktoriseringarna inte längre var tillämpbara, utan krävde direkt åtgärd. Rasmusson [4][6] beskriver en liknande situation där han i ett läge betraktade ett utvecklingsteam som sköt fram all refaktorisering till slutet av en tre veckor lång iteration. Han vittnar om hur det blev allt svårare att införa ny funktionalitet efterhand som tiden gick, och hur utvecklarna när de blev tillfrågade om varför det tog så lång tid svarade att det berodde på att de behövde refaktorisera så mycket. Detta resulterade bland annat i missade deadlines. Kobayashi, Kawabata, Sakai och Parkinson [2] beskriver också hur de, under den andra iterationen, gjorde kraftig refaktorisering och slängde bort nästan all kod från den tidigare iterationen, något som till viss grad kanske hade behövts även i vårt projekt, men som inte uppfattades. Även om slutresultatet blev ungefär detsamma i början av vårt projekt (de första två releaserna) som i den situation Rasmusson [4][6] beskriver fanns en viktig skillnad: Vi var medvetna om vilka problem en bristande refaktorisering sannolikt skulle medföra, och försökte aktivt motverka detta redan från början. Trots detta höll det inte i längden. Utifrån granskning av oss själva och diskussioner med utvecklarna har vi kommit fram till ett par hypoteser om varför det inte gick vägen: Budskapet gick inte fram fullt ut. Vi som coacher hade liten erfarenhet om hur man på ett bra sätt för fram ett budskap, och följde sannolikt inte upp det vi sagt så ofta som det skulle behövts. Vi förklarade att refaktorisering skulle ske kontinuerligt, och upplyste utvecklarna vid ett antal tillfällen om vad följderna skulle bli om de inte refaktoriserade väl. Men sannolikt skulle vi ha lagt ännu mer vikt vid att gå runt bland utvecklarna då de programmerade och fråga om det fanns något som de kände behövde refaktoriseras, och verkligen trycka på att de i så fall skulle göra det just där och då, och inte vänta för länge. Utvecklarna hade lite erfarenhet av att arbeta i en så stor grupp (ett av syftena med kursen var just att de skulle lära sig detta). Därför hade majoriteten av dem inga egna erfarenheter att falla tillbaka på, utan fick lita på det vi sa gällande att dålig refaktorisering skulle ställa till problem i framtiden. De flesta tar nog i regel inte ett sådant meddelande på allvar förrän man själv får uppleva konsekvenserna. 8

9 Utvecklarna hade varierande, men överlag liten erfarenhet av programmering. Då projektet genomfördes gick majoriteten av dem sitt andra år på högskolan, och det kan ha medfört att de inte såg behovet av refaktorisering förrän det hade vuxit sig för stort. Utvecklarna var medvetna, men prioriterade annat. Såvitt vi kunde se fallerade refaktoriseringen tydligast då utvecklarna blev stressade i takt med att releaser närmade sig. De prioriterade då att få funktionalitet på plats snabbt i ett försök att rädda releasen, och inte att se till att koden var i ett läge som tillät enkel vidareutveckling. Huruvida vi hade kunnat förhindra att detta problem uppstod genom en bättre coachingtaktik kan vi inte svara på. Men det står klart att det inte räcker att känna till hur refaktorisering ska genomföras för att faktiskt lyckas. Rasmusson [4][6] är medveten om detta, och förklarar att utvecklare som är ovana vid refaktorisering ibland är osäkra på när de ska refaktorisera, och hur mycket. Han påpekar också att det bästa sättet att få folk att refaktorisera effektivt i hans projekt var att para ihop de med liten refaktoriseringsvana med de som hade stor refaktoriseringsvana, vilket var något vi inte hade möjlighet att göra då vi inte hade tillräckligt många personer med stor erfarenhet av refaktorisering. Rasmusson [4][6] menar att ett team måste refaktorisera hela tiden, fullt ut, om inte koden ska börja bli klumpig och sakta ner teamet. Både han och vi har erfarenhet av vad som händer när detta inte sker. Men hur gör man då när det är uppenbart att det av någon anledning behövs en stor refaktorisering för att få tillbaka projektet på rätt bana? I vårt fall kunde vi förlita oss på en simpel lösning; nämligen att förlägga den på spike-tid, hemarbete som utförs av ett fåtal personer utanför de ordinarie iterationerna, och därför inte påverkar pågående arbete (detta förutsätter att ingen utvecklare sitter på halvfärdigt arbete på sin lokala arbetsplats). Men vi tror inte att det är en rimlig lösning i ett verkligt projekt. När man står inför stora refaktoriseringar förespråkar Rasmusson [4][6] istället att man har stående möten där utvecklarna kan dela sina insikter om systemet och vilka designmål som är önskade under tiden som refaktoriseringen genomförs. Han pekar också på att det kan vara bra att lägga in varningskommentarer i koden, om man som utvecklare är i ett läge där man medvetet har använt sig av en dålig design av en eller annan anledning, för att förhindra att andra bygger vidare på det. Vidare trycker Kobayashi, Kawabata, Sakai och Parkinson [2] också på vikten av det kollektiva ägarskapet av all kod då man står inför refaktoriseringar, vilket vi håller med om då vi märkte att vissa utvecklare ibland drog sig för att ändra i kod de inte var insatta i, vilket var exakt vad som beskrivs i [2]. 9

10 2.4 Simpel design Simpel design är nära kopplat till refaktorisering och är ett centralt och viktigt begrepp inom XP. Det innebär att man som utvecklare inte ska försöka planera för framtida behov och förbereda för funktionalitet som antagligen kommer behövas senare. De flesta gånger är antagandena fel och dyrbar tid kan komma att spenderas i onödan. XP bygger på kontinuerlig förändring, både i koden, kraven och de förutsättningar som finns. Det är således viktigt att hela tiden implementera det enklast möjliga som löser problemet och bibehålla koden enkel att förstå och ändra i [2]. Kerievsky [8] skriver om XP och mönster och menar exempelvis att appliceringen av mönster för tidigt kan införa onödig komplexitet. Det bättre tillvägagångssättet är att börja simpelt och låta koden ta form och avslöja ifall ett mönster är passande för situationen, vilket i så fall tas om hand om med hjälp av refaktorisering. I vårt projekt försökte vi redan från början trycka lite extra på denna praktik för att få utvecklarna att inse dess vikt. Flera gånger upptäckte vi dock att de hade svårt att låta bli att tänka för långt i förväg, att de försökte förutse vad som skulle behöva göras senare. Givetvis får och bör man göra vissa antaganden och tänka framåt i tiden, men inte längre än sin aktuella story eller task. Man behöver veta vad som behöver ändras eller läggas till i koden för att lösa sin aktuella uppgift men inte spekulera om vad det får för inverkningar för framtida stories. I vårt fall var det ett någorlunda milt problem eftersom projektet och dess stories var ganska väldefinierade och tydliga. Utvecklarna kunde således ofta göra spekulationer och smarta designval med framtida stories i baktanke ganska väl. Dock inte alltid, vilket ledde till fler refaktoriseringsbehov. En annan svårighet med simpel design som vi upptäckte och som även diskuteras av Rasmusson [4][6] och Chromatic [9] är den svåra definitionen av vad simpel egentligen betyder. Det kan vara svårt, särskilt för utvecklarna i vårt projekt som hade begränsad kunskap och erfarenhet, att veta vad som är simpelt och hur koden kan eller bör ändras för att uppnå det. Den simplaste lösningen kan exempelvis vara att använda ett bibliotek eller återanvända kod i en annan del av systemet, eller att refaktorisera och bryta ut en klass som kan återanvändas. Vi upplevde att våra utvecklare inte alltid visste vad det egentligen innebar att hålla koden enkel. 3 Sociala aspekter En sak som, i vår mening, tenderar att skilja XP från andra metodiker är att det är ett betydligt mer socialt sätt att programmera, vilket också styrks av Rasmusson [4][6]. XP bygger på god kommunikation inom teamet för att fungera, eftersom alla delar ett gemensamt ägarskap av all kod. Detta medför att det ställs krav på programmerare och arbetsplats som kanske inte förekommer annars. Till exempel menar Rasmusson [4][6] att det är mycket viktigt att ha folk som är bra på att kommunicera och samarbeta med andra placerade på nyckelpositioner i projektet, för att införandet av XP ska ha goda 10

11 möjligheter att lyckas. Under vårt projekt märkte vi tidigt att det fanns programmerare som gärna tog upp saker till diskussion, medan andra endast uttryckte åsikter om de blev tillfrågade. De som kommunicerade väl, och dessutom var goda programmerare, blev snart goda verktyg för oss att föra fram budskap och hjälpte till att upprätthålla XPmetodiken när de flyttade runt inom teamet. Rasmusson [4][6] nämner också att det var till stor hjälp att ha en tillräckligt stor del, ungefär halva teamet, som hade tidigare erfarenhet av XP. Dessa personer kunde demonstrera de olika praktikerna, och hjälpte till att föra in den agila andan i teamet. Vi hade inte tillgång till folk med tidigare erfarenhet av XP, och kan därmed inte direkt yttra oss om dess effekt. Vad vi kan säga, baserat på vårt eget projekt, är dock att olika programmerare tog till sig XP olika fort, och de som var snabba på att anamma metodiken sedan blev goda hjälpmedel för att få in de andra på samma bana. Rasmusson [4][6] påpekar också att stora öppna ytor med bord där utvecklare kunde sitta bredvid varandra och parprogrammera var av stor vikt. Att samla programmerarna på en plats är ett enkelt men effektivt sätt att främja god kommunikation. I vårt projekt var utvecklarna placerade vid fyra närbelagda datorer som var vända bort från varandra. Detta hade fördelen att utvecklarna satt så nära varandra att de endast behövde vända sig om, eller luta sig till höger eller vänster, för att komma inom en meter ifrån ett annat par. Vi upplevde att detta främjade kommunikationen oerhört. Det var så väldigt enkelt att fråga någon annan angående koden, och de behövde bara vända sig om för att kunna se varandras skärmar. Vi fick känslan av att detta gjorde att det inte alls upplevdes som något besvärligt att hjälpa varandra. Ett par kunde vända sig om, peta på ett annat par, ställa en fråga. Det andra paret vände sig om, såg det första parets skärm, fick en inblick i problemet och kunde svara på frågan. Victor och Jacobson [7] beskriver också hur en sådan närbelägen placering medförde stora förbättringar för kommunikationen. Att kunna vinka på någon för att få deras uppmärksamhet visade sig göra en enorm skillnad jämfört med det tidigare läget där folk satt isolerade och inte ville bli störda. Vi vill också påpeka att småsaker inte är att förringa när man försöker främja god kommunikation. En så enkel sak som att resa sig och gå till andra sidan rummet för att prata med någon kan medföra att en fråga inte blir ställd som hade blivit ställd om personerna i fråga hade suttit bredvid varandra. Precis som Victor och Jacobson [7] förklarar så är vi övertygade om att minsta barriär som har möjlighet att försämra kommunikationen är en indikation om ett potentiellt problem, och vi ställer oss bakom deras påstående om att ju mer man interagerar, desto bättre utvecklar man. Kobayashi, Kawabata, Sakai och Parkinson [2] fann också att dagliga stående möten om projektets utveckling, med storykort uppklistrade på väggen för överblick, var mycket givande. Det tillät en god överblick utan behov av överflödiga dokument. I vårt projekt använde vi ett liknande system där kortens placering motsvarade vilket stadie av utvecklingen som storyn befann sig i. På korten skrevs också vilka som arbetat med 11

12 varje story, vilket gjorde det lätt för utvecklarna att hitta rätt personer att diskutera relaterade förändringar med. Victor och Jacobson [7] tar även upp en annan punkt gällande gruppmedlemmarnas samspel. Med filosofin att testen ska driva utvecklingen gjorde de ingen gruppdesign innan storyimplementationen, utan lämnade det upp till var och en att avgöra hur just deras story skulle implementeras. Detta visade sig skapa motsättningar inom teamet, när olika uppfattningar om hur saker skulle göras, eller borde göras, kolliderade med varandra. Detta problem visade sig dock ha en enkel lösning; nämligen att diskutera stories under planeringsmötena. Ur denna diskussion uppstod en grundläggande design som utvecklarna var mer överens om. Under vårt projekt uppstod dessa designdiskussioner spontant under planeringsmötena, speciellt gällande mer komplexa stories. Vi uppfattade dem som konstruktiva och ett bra sätt att sprida kunskap och idéer mellan utvecklarna, vilket förhoppningsvis gjorde att den slutgiltiga implementationen oftast var något alla accepterade. Dock har vi inga definitiva bevis för att så var fallet. Ofta visade sig tyvärr planeringsmötena vara en aning korta (2 timmar) för vissa av dessa diskussioner, och om man ämnar att utnyttja detta till fullo rekommenderar vi att avsätta tillräckligt med tid. Victor och Jacobson [7] behandlar också detta ämne, och beskriver hur de inte hann med att diskutera viktiga ämnen på de få och korta möten de hade. Detta med effekten att vissa gruppmedlemmar började känna att deras influens över projektet var mycket begränsad. De trycker då på hur viktigt det var med en coach som höll välplanerade och fokuserade möten, vilket i deras fall visade sig förbättra produktiviteten trots att de överlag spenderade mer tid i möten än tidigare. 4 Var börjar man? Kobayashi, Kawabata, Sakai och Parkinson [2] trycker som tidigare nämnt på att många av XP-praktikerna är mer eller mindre starkt beroende av varandra, och Deias, Mugheddu och Murru [5] menar att det är just en samverkan mellan alla XPpraktikerna som gör att en utvecklare kan släppa taget om de inrotade vanorna. Men enligt Rasmusson [4][6] är många av dagens utvecklare inte vana vid varken parprogrammering eller att skriva testfall innan man börjar implementera lösningar i koden. Han menar att detta inte är något som kommer naturligt för den stora massan av utvecklare, och noterar att många som har försökt att införa XP i sina projekt har fört fram kommentarer om hur svårt det var att få utvecklare att faktiskt använda dessa två viktiga praktiker. Baserat på våra egna, om än väldigt begränsade, erfarenheter kan vi inte annat än att hålla med. Samtidigt är det viktigt att notera att Rasmusson [4][6] också trycker på att just parprogrammering, som många tycker är svårt att motivera och införa, var en av de viktigaste verktygen för inlärning och förbättrad kommunikation, vilket också styrks av Deias, Mugheddu och Murru [5]. Även Kobayashi, Kawabata, Sakai och Parkinson [2] menar att just parprogrammering och testdriven utveckling, tillsammans med kontinuerlig integrering och kodstandarder (som vi inte har behandlat i 12

13 denna studie) är starkt beroende av varandra. Deras studie är fokuserad på just hur olika praktiker beror av varandra samt vilka effekter de har. Det är god läsning om man vill göra en djupare analys av vilka praktiker man vill införa och i vilken ordning, vilket vi endast behandlar ytligt. De nämner bland annat att refaktorisering och parprogrammering sannolikt är svåra att introducera utan att också behandla flera andra praktiker, medan till exempel testdriven utveckling inte tenderar att vara speciellt beroende av andra praktiker. Testdriven utveckling kan därmed sannolikt introduceras med enbart ett par andra praktiker, och ändå ha en betydande positiv effekt. Dock nämner de också att introduktionen av kontinuerlig refaktorisering, även om det är en aning svårare att genomföra, sannolikt har mycket stora positiva effekter. Deias, Mugheddu och Murru [5] vittnar också om att många utvecklare hade svårt att ta till sig praktiker som till exempel simpel design, testdriven utveckling och kodstandarder, och menar liksom Rasmusson [4][6] att parprogrammering var väldigt viktigt för att effektivt introducera dessa förändringar. Enligt Deias, Mugheddu och Murru [5] är det sannolikt också av intresse att försöka implementera XP-processen som helhet. Detta eftersom gruppens fokus då koncentreras på just helheten, och folk då har lättare att acceptera enskilda aspekter som de inte gillar. 5 Bortom utvecklarna I vårt projekt var det inte så mycket fokus på andra aktiviteter i utvecklingsprocessen annat än just utvecklingen. I ett företag tillkommer dock andra faktorer, behov och roller så som projekt- och företagsledare och riktiga kunder. XP och andra agila metoder är fortfarande en relativt ny trend och för många organisationer handlar det om en övergång från de äldre planbaserade processerna snarare än upplärning av utvecklare helt utan tidigare erfarenhet, som i vårt fall. Deias, Mugheddu och Murru [5] skriver om hur eventuella motstånd och motvilja att införa XP i ett företag i regel inte kommer från de som aktivt utövar processen utan från marknads- och personalansvariga. De menar att de som vanligtvis interagerar med kunderna och får dem att skriva under kontrakt, upplever det som svårt att få kunder att skriva under något som inte lovar fixt datum för leveranser och formella dokumentationer för krav och kostnader. Cohn och Ford [3] tar upp många intressanta exempel på vanliga fallgropar och hur de genom erfarenhet har lärt sig att hantera dem. De skriver bland annat att alla ledare och chefer som oroar sig över att förlora kontroll och för att inte ha garantier för leveransdatum, funktionalitet, kostnader etc. måste börja med att inse att alla projektplaner de tidigare haft som inkluderade sådana garantier var antingen fel, kraftigt överestimerade eller både och. Cohn och Ford [3] skriver också om micromanagement, vilket innebär att utvecklare som är vana vid planbaserade processer och vanligtvis träffar sina projektledare och chefer relativt sällan, uppfattar den mer frekventa kommunikationen som agila metoder förespråkar som ett sätt för projektledarna att hålla koll och trycka på datum och missade deadlines oftare och mer intensivt. Cohn och Ford [3] menar att det är viktigt 13

14 för projektledare att visa att de vill hjälpa till att ta bort eventuella hinder för utvecklarna och inte klaga på att en uppgift tar för lång tid. Ytterligare en viktigt punkt som Cohn och Ford [3] tar upp är vikten av att informera företagsledningen om eventuella ändringar i arbetsprocessen. De berättar exempelvis om ett företag där två utvecklare klagade på införandet av parprogrammering till ledningen, som inte hade fått reda på något om det, varefter de fick förklara och övertyga ledningen om varför parprogrammering var en bra idé. 6 Sammanfattning och slutsatser Vi kan konstatera att parprogrammering verkar vara en fundamental del av XPprocessen, och ett kraftigt verktyg som hjälper till att införa andra praktiker på ett effektivt sätt. Därmed drar vi slutsatsen att detta är något som bör ha högsta prioritet vid införandet av XP. Även om det kan uppstå motsättningar till arbetssättet är det av intresse att försöka övertyga skeptikerna, eftersom det har en så god inverkan på andra delar av processen, och sprider kunskap till hela teamet. Den testdrivna utvecklingen som kanske verkar simpel på papper är inte något som kommer av sig själv. Vi menar därför att man inte kan förvänta sig att denna praktik ska visa sin fulla potential direkt vid införandet, utan är något som utvecklarna behöver lära sig genom övning och erfarenhet. Detta gäller även den kontinuerliga refaktoriseringen. XP är även ett mer socialt sätt att programmera, och detta är något man inte får förbise. Att samla alla utvecklare i en gemensam lokal, och eliminera alla hinder för kommunikationen är viktigt om man ska ha något hopp om att lyckas väl med XP. Men att bara skapa förutsättningar för kommunikation räcker inte, man behöver också styra kommunikationen med väl förberedda och fokuserade möten, och främja det gemensamma ägarskapet av koden. Att ha folk med tidigare erfarenhet av XP är också en fördel då det, tillsammans med parprogrammeringen, gör att andra praktiker lättare tas upp av teamet som helhet. Det verkar också vara svårt att enbart delvis införa XP. Även om vissa praktiker är av större vikt än andra, samverkar många med varandra, och genom att stryka vissa av dem kan man göra det svårare att införa de man vill lägga fokus på än vad man kanske tänkt. 14

15 Referenser [1] Titel: Embracing Change With Extreme Programming Författare: Kent Beck Journal: Computer, volym 32, 10:e utgåvan, oktober 1999 Sidor: Utgivare: IEEE Computer Society Press [2] Titel: Analysis of the interaction between practices for introducing XP effectively Författare: Kobayashi, Osamu och Kawabata, Mitsuyoshi och Sakai, Makoto och Parkinson, Eddy Konferens: Proceedings of the 28th international conference on Software engineering År: 2006 Sidor: Utgivare: ACM [3] Titel: Introducing an Agile Process to an Organization Författare: Cohn, Mike and Ford, Doris Journal: Computer, volym 36, 6:e utgåvan, juni 2003 Sidor: Utgivare: IEEE Computer Society Press [4] Titel: Introducing XP into Greenfield Projects: Lessons Learned Författare: Rasmusson, Jonathan Journal: IEEE Software, volym 20, 3:e utgåvan, maj 2003 Sidor: Utgivare: IEEE Computer Society Press [5] Titel: Introducing XP in a start-up Författare: Deias, R. and Mugheddu, G. and Murru, O. Konferens: Proc. 3rd International Conference on extreme Programming and Agile Processes in Software Engineering-XP2002 År: 2002 Sidor: [6] Titel: Strategies for introducing XP to new client sites Författare: Rasmusson, J. Konferens: Extreme Programming and Agile Methods XP/Agile Universe 2002 Sidor: År: 2002 Utgivare: Springer 15

16 [7] Titel: We Didn t Quite Get It Författare: Victor, B.; Jacobson, N.; Utgivare: Abraxas Applic., Reston, VA, USA Konferens: Agile Conference, AGILE '09. Sidor: ISBN: Url: [8] Titel: Patterns and XP Författare: Kerievsky, J. Konferens: Extreme programming examined Sidor: År: 2001 Utgivare: Addison-Wesley [9] Titel: Extreme Programming Pocket Guide Författare: Chromatic År: 2003 Utgivare: O Reilly Media ISBN: (tryck), (e-bok) 16