Att införa Extreme Programming genom processförbättring Johan Thiborg-EricsonVahagn Baghomian14-02-28

SammanfattningSyftet med denna studie är att studera hur agila metoder uppkommer som en naturlig följd av processförbättringen i ett projekt. Studieobjektet är tio teknologer som implementerar ett program inom ramarna för en kurs i XP. Utvecklingen av gruppens arbetsmetoder undersöktes för att observera detta fenomen. Studien visar att gruppen själv uppfann ett fåtal av teknikerna, men att vissa tekniker var för avancerade för att de skulle tycka att de behövdes.

1.0 BakgrundUnder de senaste två decennierna har många företag gått över från utveckling av programvara enligt vattenfallsmodellen till mer agila metoder. En anledning till detta är att de vill sänka de kostnader som inte är direkt kopplade till programmeringen samt att minska osäkerhet i kostnadsbedömningar. I företaget som beskrivs av James Grenning [2] var själva utvecklarna duktiga och gjorde ett bra arbete, men de stötte på problem. Ledningen på företaget ansåg att för stora mängder administrativt arbete medförde att utvecklingen av mjukvara tog onödigt lång tid, vilket ledde till för höga utvecklingskostnader. Dess utom fanns buggarna kvar och utvecklarna hade problem med att starta nya projekt. När James Grenning [2] skulle introducera XP i detta företag möttes han till en början av skeptisism från utvecklarnas håll. De undrade om koden verkligen kunde vara designen och om man kunde utveckla mjukvara utan att designa allting först med mera. Dessa tillvägagångsätt i XP är inte helt nya utan är snarare en sammanfattning av ackumulerad kunskap från projekten i industrin, lösryckta “goda idéer”. Många programmeringsprojekt arbetade enligt dessa principer långt innan begreppet agil utveckling formulerats. Ett exempel på detta beskrivs av Martin i [5]. Därför borde det rent logiskt gå att införa något som liknar XP genom att bara låta gruppen hitta på egna best practices. Det skulle dock ta väldigt lång tid och därför behöver gruppen provoceras att identifiera problemen och formulera lösningar.

1.1 Problem som kan uppstå när man inför XP

Även om XP är ett bra tillvägagångssätt vid programvaruutveckling, finns det diverse risker som dess utövare kan utsättas för. En av dessa är att utvecklare som tidigare skrivit program på ett annat sätt, inte följer reglerna för XP och återgår till sina föregående arbetssätt. Ett exempel på detta är att de inte skriver testfall innan de implementerar kod, utan implementerar koden direkt. En anledning till detta kan vara tidsbrist. Till exempel kan det ta ganska lång tid att skriva testfall till metoder som är komplexa och vid tidsbrist kan det hända att utvecklarna väljer att implementera koden direkt utan att skriva något testfall först.[2] En mycket informativ text om parprogrammering finns i Martin [4]. Där kan man hitta råd om när man ska byta plats, hur programmeringsparet kan hitta till en enkel design, när det är lämpligt att refaktorisera, i vilken ordning man ska skriva test osv. Processen som projektet resulterar i kommer att jämföras med denna text. Den kommer även användas som expertråd i de diskussioner gällande XP som uppkommer under projektets gång.

1.2 Kursen PVG och ordförklaringarI denna studie används en grupp studenter som går kursen Programvaru-utvecklig i grupp (PVG) där de lär sig om hur man skriver program på ett agilt sätt [12]. Deras kurs är uppdelad i en teoretisk del, som inte är relevant i detta arbete, och en praktisk del. I den senare delen implementerar alla elever i grupper om ca tio personer ett program för tidtagning av en sport. Gruppen som den här studien avser kommer nedan att kallas gruppen. Implementeringen sker under hela måndagen i sex veckors tid på så kallade långlabbar. För att utvärdera hur mycket de lärt sig så får de skriva ner i slutet på varje långlabb vad som gått bra, vad som gått mindre bra och vad de blivit förvånade av under dagen. Under kommande onsdag ägnas det två timmar åt att tillsammans komma på hur tidigare problem ska undvikas i framtiden. Detta möte kallas planeringsmöte, eftersom det också innefattar Planing Game enligt XP.

1.3 Planerat tillvägagångssättI det här projektet planerades att XP skulle införas genom någon form av processförbättring. Ett utmärkt exempel för uppslag är Humphrey [3], där det står om hur ett företags processmognad kan mätas. Insikten kan delas upp i fem steg:

1. Att förstå den nuvarande processen2. Att skapa en bild av den process man önskar3. Att identifiera och prioritera stegen som behövs för att nå den önskade processen4. Att skapa en plan för att införa den nya processen5. Att tillföra resurser för att genomföra förändringen

En annan modell som formulerats av den amerikanske affärsmogulen Robert Pozen är att varje

gång ett problem upptäcks så formulerar gruppen hur de ska förbättra processen för att undvika problemet [10]. Modellen formulerar även hur det ska gå att mäta hur väl förbättringen införts. Den här modellen kan vara lämplig i PVG eftersom den skapar en känsla av att gruppen har ansvaret för att lösa problemet, eftersom de själva formulerat lösningen. Det kan vara lämpligt att formulera lösningarna i form av mönster, utökat med en extra sektion för hur man ska mäta att mönstret införts i vår process. Fokus i den här rapporten är inte menat att ligga på processförbättring, men det är ändå en viktig del eftersom det kommer användas som ett verktyg i införandet av XP. Hur ska vi få gruppmedlemmarna att skriva programmet test-first? En lösning kan vara att projektledarna föregår med gott exempel och lär ut test-first programmering till resten av gruppen. Förmodligen kommer gruppen då, eftersom de ser upp till ledarna, förhoppningsvis att följa deras exempel och vara mindre benägna att gå tillbaka till sina föregående sätt att programmera. En annan lösning kan vara att få gruppmedlemmarna att förklara sig inför projektledarna varför de tänker låta bli att skriva tester. Detta kommer att leda till att de verkligen måste ha goda skäl och få klartecken från projektledarna innan de får skriva kod utan testfall. Det gör även att det höjer tröskeln för att paret struntar i att testa först, då det kanske känns mindre omständigt för dem att skriva testfallen än att argumentera med oss. I vissa fall kan det förstås hända att det blir svårt att skriva testfall till en viss funktionalitet och de som implementerar kodsnittet kör fast. Då blir det projektledarnas ansvar att rycka in och hjälpa till efter bästa förmåga och se till att hitta en lösning på problemet. Till exempel kan de be någon annan i gruppen som är bra på att skriva testfall att hjälpa de som kört fast. Detta kommer att motivera gruppmedlemmarna att skriva testfall även om de kör fast och ta hjälp av varandra när det behövs.

1.4 SpelplanenSom en del av utförandet av undersökningen som denna rapport beskriver fick gruppen som gick PVG-kursen använda ett slags flödesschema och en spelpjäs då de programmerade. Dessa kommer att kallas “Spelplanen” nedan. Tanken med spelplanen var att varje väsentlig aktivitet under parprogrammeringen skulle representeras av en ruta. Rutorna var i sin tur förbundna med pilar som motsvarade ordningen i vilken dessa aktiviteter skulle utföras. Den i programmeringsparet som inte skrev kod för tillfället skulle vara ansvarig för att flytta pjäsen till den ruta som motsvarade den aktivitet de just då utförde.

1.5 Dokumentets strukturBeskrivningen under varje rubrik framgår av rubriken eller underrubriken. Sektioner med rubriken iteration är uppdelade i tre delar som beskriver vilken metod som användes just under den iterationen och hur den utfördes, resultaten, analys av resultaten samt jämförelse med andra gruppers arbete. De slutsatser som dras efter dessa sammanställs i slutet av dokumentet under rubriken slutsatser. Sektionen med rubiken projektstartmöte beskriver vad som gjordes och förberedes inför den

första planeringsmötet samt hur denna möte gick till.

2.0 FrågeställningarSkulle man kunna få projektdeltagarna att själva komma fram till XP praktikerna för att lösa sina problem och ta sig fram genom projektet? Genom den här studien hoppas vi kunna se vilka fördelar och problem som finns med XP:s praktiker i PVG-sammanhanget genom att sammanfatta lärdomarna från hur spelplanen utvecklas. Vi ska även ta reda på om modellen med en spelplan är ett lämpligt sätt att införa XP:s utvecklingsstil på. Förutom dessa kommer vi att intervjua projektdeltagarna för att hjälpa dem att formulera hur projektet ska förbättras och hur vi som coacher kan förbättra våra riktlinjer. Med andra ord ta emot förslag på hur vi kan hjälpa dem att införa förändringarna. Resultatet kommer jämföras med litteraturen på området.

3.0 Iteration 0Innan den första iterationen hade coacherna till uppgift att implementera några stories att ha som mall och för att göra det lättare för projektgruppen att komma igång. Två olika designer togs fram. Den ena designades helt och hållet enligt XP teknikerna, skrevs med test first och utvecklades i enlighet med testfallen. Kodlukter eliminerades så gott det gick. Totalt blev det sju klasser. Den andra implementerades med betydligt färre klasser, bara 3 stycken. Båda uppfyllde samma funktionalitet och tanken var att få projektgruppen att titta igenom de två designerna och välja den som de ville ha. Om de valde den som var implementerad på ett grovt sätt, skulle de få refaktorisera och förenkla den för att lära sig grunderna i XP. Om de å andra sidan skulle välja det andra alternativet, skulle de ha en bra grund och klar bild på hur det är tänkt att utvecklingen ska gå till, men inte få särskilt mycket praktiskt erfarenhet. De valde det alternativet som hade fler klasser. Detta sågs som en nackdel eftersom det fanns risk att de skulle hålla fast vid denna design för länge. Om de hade valt den minimala designen så hade de på ett tidigt stadium tvingats att refaktorisera och på så sätt få känna hur det kändes och inte vara rädda för det. Den initiala spelplanen bestod av tre rutor, ihopkopplade med pilar, som tillsammans bildade en cirkel. Tanken var att, under projektstartsmötet, få projektgruppen att utveckla denna spelplan och sätta in “commit” och “update” rutor och på så sätt få dem tänka till om hur de skulle arbeta.

Figur 1: Den initiala spelplanen

4.0 ProjektstartmöteInför projektstartmötet hade planerats att samla in data på ett annat tillvägagångssätt än den metod som slutligen valdes. Tanken var att låta projektdeltagarna formulera mönster, som de beskrivs av Rising [11], två gånger per Iteration. För att stävja häftiga diskussioner hade det tänkts att separera formuleringen av problemet och formuleringen av lösningen. Med lösningen menas den lösning de kommit överens om över lunchen eller från slutet av en labb till början av en annan. De fick även i uppgift att formulera mönster under uppstartsmötet. För att de skulle ha en tydlig bild av vad som förväntades av dem, fick de veta att de skulle formulera mönster som uppfyllde frågeställningen “Hur kan vi producera kundvärde smartare?” Formuleringen av mönster gick tyvärr så segt att det beslutades att inte använda denna metod mer. Gruppmedlemmarna upplevde mönstren som abstrakta och kunde inte relatera till frågeställningen. Dessutom visade det sig att deras kurs ändå innehöll ett liknande moment (enskild- och gruppreflektion), så därför kändes vår idé överflödig. Under detta möte utvecklades även den initiala spelplanen med flera rutor innehållande nya utvecklingsfaser som projektmedlemmarna själva tagit fram.

Figur 2: Spelplanen efter projektstartmötet

5.0 Iteration 1

5.1 MetodUnder första Iterationen tilläts labbdeltagarna att bara följa spelplanen i den mån de ville för att de skulle få en uppfattning om hur det kändes att arbeta fritt och för att de senare skulle ha något att jämföra med när de senare använde spelplanen.

5.2 ResultatFlera personer tyckte att paren behövde bytas oftare. De andra var inte villiga att införa parbyte som en ruta på planen eftersom de inte ville bli tvingade att byta. Många var dessutom motvilliga att byta par eftersom de ansåg att de skulle störa de andra i gruppen. Därför beslutade vi coacher att tillfälligt hjälpa dem som ville byta par genom att regelbundet fråga om de ville byta par. Många, om inte alla, var även ovana vid Test-first principen och hade därför svårt att skriva kod enligt testfallen och ibland glömde de att skriva testfall först. Därför fortskred utvecklingen ganska segt i början. Detta gjorde att större delen av första halvan av Iterationen gick åt till att skriva testfall istället för kod. Men allt eftersom de lärde sig gick utvecklingen allt snabbare framåt och på eftermiddagen hann gruppen med att implementera de flesta stories. Någon tyckte att vi testar för lite. Dock framgick det inte om han menade att vi testade för lite i förhållande till vad vi borde enligt XP eller i förhållande till vad som skulle vara bra för gruppen. Tre personer upplevde problem med merge konflikter varav två beskrev problemen som stora. En trodde att problemen berodde på att han och hans partner hade uppdaterat för sällan. En av gruppens medlemmar föreslog att vi skulle skaffa ett stort papper för att rita på eftersom white-board:en inte räckte till och för att den satt otillgängligt. Det som alla var överens om var att kommunikationen i gruppen fungerade bra. Det hände att vissa inte vände sig från skärmen när någon i ett annat par tilltallade hela gruppen, men för övrigt fungerade kommunikationen bra. På labben visade det sig att spelplanen saknade väsentliga pilar och detta gjorde att gruppmedlemmarna inte kunde fortsätta med utvecklingen. På grund av detta modifierades spelplanen något.

Spelplanen upptaderades med rutorna “Skriv test”, “Skriv kod”, “Grönt” och “Refaktorisera”. Som uppgift fick projektdeltagarna lägga in rutor för “Update”, “Commit” och “Kör test”. Medvetet valdes att styra dem mot att integrera kod för varje test eftersom det ansågs att det skulle öka möjligheten för parallellt kodskrivande och minska risken för merge-konflikter.

Figur 3: Spelplanen efter modifiering under labb 1

5.3 AnalysEn glad överraskning var att det var så pass många som ville byta par ofta. Enligt oss hade det varit troligare att de hellre skulle vilja sitta i samma par och vara fokuserade hela labben. Anledningen var kanske att parbytena under första labben huvudsakligen drevs av att personer med expertkunskap behövde flyttas runt. Det gjorde att par som inte hade specialkunskaper och inte behövde experthjälp undvek att byta par. Det var mest sådana par som kände för fler parbyten, men de kände att de skulle förstöra för det par de bytte in sig i. Gruppen valde att pröva att byta par oftare, huvudsakligen för att de som ville det skulle bli gladare. Det är förståeligt att test-first principen kunde ställa till med svårigheter. Innan PVG-kursen hade många implementerat kod direkt och inte brytt sig om att skriva testfall och övergången till test-baserad kodutveckling var svårt för dem, eftersom det inte är lätt att byta vanor. Det är intressant att det kan uppkomma merge-konflikter i ett så här litet program där beroendet mellan klasserna är lågt. En förklaring till detta kan vara att gruppenmedlemmarna inte uppdaterade ofta nog eller ändrade i kod de inte skulle ha ändrat i. En intressant fråga som dök upp är om merge-konflikter och mer test-first kan lösas med hjälp av spelplanen. Förslaget om ett extra papper att rita på är extra intressant eftersom det går under praktiken Informative Workspace som formulerades av Kent Beck [1] långt efter att deras kurslitteratur skrivits. Detta kan faktiskt ses som det första riktiga exemplet vi funnit på att XP kan växa fram

av sig självt.

5.4 Övriga gruppers reflektionerFem av åtta grupper upplevde merge-konflikter under den här dagen och vår grupp var en av dem. Två av dem som upplevde problem samt två som inte gjorde det tyckte att paren behövde vänta på andra par när de ville skriva i samma kod. Två grupper hade problem med att koden duplicerades. Två av grupperna som hade problem, föreslog lösningen att uppdatera och integrera oftare. Två andra föreslog att lösa problemet med mer kommunikation. Det första förslaget är extra intressant eftersom litteraturen ger olika riktlinjer på hur ofta kod ska integreras. Enligt Chromatic [7] så ska kod integreras när en story är färdig. Detta stod uppenbarligen i konflikt med gruppernas behov av att få andras kod till sin kodbas så fort som möjligt. Dessutom föreslår Bendix m fl [8] att alla refaktoriseringar ska integreras genast och helst i små steg. Vissa använder tidsangivelser för att indikera hur ofta integration ska ske, t ex Beck och Andres [1]. I den speciella miljön med extremt många programmerare per tusen rader kod anser vi att det är lämpligt att integrera ännu oftare.

6.0 Iteration 2

6.1 MetodUnder Iteration två formulerades en intervju vars syfte var att se om gruppen skulle “återuppfinna” XP som det hade antagits. Under Iteration 1 hade en av gruppmedlemmarna uttryckt att han kände sig mycket upprymd över gruppens framgångar. Då resonerades det fram att om det går bra för gruppen, så kommer paren att uppleva just en sådan upprymdhetskänsla. I ett försök att göra intervjun generell så bestämdes att helt enkelt fråga hur glad den intervjuade var. Sedan skulle eventuella hinder identifieras genom att fråga hur personen skulle kunna bli gladare. Vi utgick från att om en person samtidigt kände att han producerade programkod snabbt, att kunden skulle ha nytta av funktionaliteten och att koden producerades på ett långsiktigt hållbart sätt, så skulle han uppleva det som roligt. Genom att identifiera störande moment för glädjen så skulle hinder i processen kunna identifieras och elimineras.

6.2 ResultatDet visade sig att denna intervju knappast gav någonting, då svaren var likartade och ofta speglade det vi uppmanat dem att fokusera på inför labben. De var oförmögna att komma på egna förslag på hur processen skulle förbättras. Det är också möjligt att närvaron av resten av gruppen gjorde att de formulerade sig försiktigt. Så gott som alla svarade åtta på en skala på ett till tio när de blev tillfrågade hur glada de var.

Gruppen tyckte att spelplanen hjälpte dem att komma ihåg att testa och att uppdatera och release:a koden när de arbetade med avancerade uppgifter. Däremot var planen mest i vägen vid enklare uppgifter. Problemen med merge-konflikter hade minskat markant i förhållande till förra gången, enligt gruppens reflektioner. När paren tillfrågades vilken ruta de var på så hände det ofta att de sa att de bara pratade. Vid närmare efterfrågningar så visade det sig att de oftast diskuterade vad nästa test skulle vara. Därför ändrade vi rutan Skriv test till Skriv test och prata.

Figur 4: Spelplanens utseende efter labb 2

6.3 AnalysSyftet med den första intervjun var att få dem att fundera på hur de skulle kunna arbeta på ett långsiktigt sätt, men de flesta kunde inte komma på något svar. Detta pga att de inte visste vilka problem som skulle dyka upp. Iteration 2 karaktäriserades av lågt tempo. Det var svårt att sätta fingret på vad som sinkade oss. Det kunde ha varit att vi uppmanat dem att fokusera mycket på design. Det låga tempot ledde oss dock fram till idén att låta intervjun fråga efter hur fort det gick istället för att fråga hur roligt de hade. Denna fråga hoppades kunna ge en bättre bild över hur projektet framskred. Intervjuns syfte var att få gruppen att reflektera över hur deras handlande skulle påverka deras framtida produktivitet Det visade sig att många hade svårt att föreställa sig det. Därför valdes att fokusera på dagens problem istället(genom att fråga om hur fort det gick just då) och där i efterhand analysera vad de gjort fel tidigare. Utifrån detta skulle de sedan komma fram till hur de skulle undvika att göra om samma misstag.

Det minskade antalet merge-konflikter skulle kunna bero på en ökad användning av spelplanen, men det kan också ha berott på den lägre produktiviteten Dock borde det uppvägas av att de gjorde många stora refaktoriseringar. En intressant händelse var när ett par skadeglatt sa efter en integrering: nu kommer ni få merge-konflikter! Ändå var det ingen som fick det.

6.4 Övriga gruppers reflektionerVår grupp borträknat så hade alla grupper utom en större uppdaterings- och integrations-relaterade problem denna veckan än förra. Detta kan bero på att de olika delarna i programmet behövde kommunicera mer andra labben.

7.0 Iteration 3

7.1 MetodEftersom intervjun som formulerades under lab 2 inte gav något resultat, formulerades en ny, där det väsentliga handlade om vad den intervjuade arbetade med, hur fort det gick, vad som tog längst tid att göra, varför det gjorde det och vad som skulle kunna göras för att göra processen snabbare i framtiden. Vi gick från person till person och frågade. Beroende på vad personen ifråga håll på med, blev svaren annorlunda.

7.2 ResultatÄven under denna labb utfördes mycket refaktoriseringar. Gruppen kom överens om att det inte var hållbart att göra så kallade Big Bang refaktoriseringar, utan att vi behövde mindre sådana i slutet av varje uppgift. För att kunna refaktorisera, var gruppmedlemmarna tvungna att förstå samt sätta sig i koden. Refaktorisering ledde till att designen förbättrades och gjorde det lättare att se hur allt i programmet hänger ihop, vilket i sin tur gjorde det enklare att förenkla designen och ta bort onödigt kod. För att se till att refaktoriseringen går till så smidigt som möjligt ska man avsluta det man håller på med innan man börjar med något nytt. Refaktoriseringen försvårades av att testerna var svåra att tolka. För att paret skulle hitta felet de infört var det ofta nödvändigt att följa långa stack trace. Enkel design tog en bra tag att genomföra. Ibland fick man göra en och samma sak flera gånger eftersom det simpla inte alltid fungerade när man skulle ha med mer komplexa saker och man spenderade mer tid på att ändra i gammal kod än skriva ny. Tyvärr så finns det inte något konkret sätt på vilket man kan komma underfund med enkel design, utan man får anpassa varje simplifiering efter behov.

Efter parbyten, refaktoriseringar och förenklingar, hände det att man spenderade ganska mycket tid på att sätta sig i kod som andra skrivit. Det förslag som de flesta kom upp med för att i framtiden slippa spendera tid på att läsa kod istället för att skriva, var helt enkelt att man bör fråga personen som skrivit koden om vad den gör. Några hade även problem med att komma underfund med inbyggda klasser, särskilt de som hade med det grafiska att göra, nämligen SWING. Deras förslag på hur man kan åtgärda detta kunde sammanfattas i att man bör sätta sig in i hur SWING fungerar innan man börjar koda. Under denna labb undergick spelplanen stora förändringar. Många nya moment och pilar lades till. Det var gruppmedlemmarna som kände att planen behövde utvecklas yterliggare, vilket tyder på mognad från XP perspektiv. Under förra labben hade det utförts många stora refaktoriseringar. Eftersom den vanliga planen inte kunde användas under refaktoriseringar, bads gruppen att utforma en speciell refaktoriserings-loop, se figur 5 och 6. Gruppen hade vid ett tidigare tillfälle kommit fram till att det var svårt att själv se om kod var enkel. Därför beslutade de att det skulle ske ett obligatoriskt parbyte innan refaktoriseringsfasen.

Figur 5: Nya moment i spelplanen Figur 6: Spelplanen efter modifieringar under labb 3

7.3 AnalysMetoden att göra en medelstor refaktorisering i slutet av varje task är ett utmärkt exempel på hur “Klar klar” kan användas [9]. Det stämmer även bra överens med hur parprogrammering beskrivs av Martin i [4] där det tar nästan en tredjedel av programmeringstiden att refaktorisera efter att en task är färdig. Problemet med test som hittar fel efter många metodanrop lokaliserades även i Martin och Newkirk [5], men där löstes problemet med att skriva enhetstest direkt för den trasiga metoden. De i gruppen som har stött på problemet har inte tyckt att detta hade varit nödvändigt. Det kan bero på att de var trötta på att refaktorisera och ville komma vidare, men det kan också vara ett uttryck för i hur stor utsträckning programmering är ett hantverk. De hade kanske inte tillräcklig med erfarenhet för att inse fördelarna med att snabbt kunna förstå varför ett test blivit rött.

7.4 Övriga gruppers reflektionerTre av tio grupper la den stora refaktoriseringen som vi påbörjade förra veckan i den här veckan. En refaktoriserade ungefär lika mycket och övriga uttryckte inga problem med refaktoriseringar. Det är svårt att avgöra om vår grupp uppmärksammade problemen så tidigt för att vi coacher hade skrämt dem så mycket med problemen de annars skulle få, eller om det berodde på att vårt team var extra intresserade av objektorienterad design.

8.0 Iteration 4

8.1 MetodUnder denna labb utfördes inga intervjuer, endast planen utvecklades. Som tur var, bestod en story av att göra UML-diagram, så gruppen fick äntligen den chans till överblick som vi coacher hoppats på.

8.2 Resultat Eftersom flera par tyckte att det gått långsamt när de funderade över vad som skulle implementeras och under själva implementationen så beslutade vi att lägga in frivilliga parbytesrutor vid dessa rutor (Skriv test och Grönt->nej efter Skriv kod). På förmiddagen föreslog ett par att lägga till en Grönt-ruta innan skriv kod för att man skulle märka snabbt om röd kod fanns i repositoriet.

Figur 7: Spelplanens utseende vid början av labb 4 Figur 8: Extra Grönt ruta innan Skriv kod

Tyvärr fick inte UML-diagrammet det genomslag som vi hoppats på. Upplevde teamet att designen blev tydligare ändå, på grund av alla refaktoriseringar.

8.3 AnalysInnan kursen hade börjat så hade coacherna gjort en egen version av planen. Den innehöll Grönt-ruta precis innan Skriv kod, men av helt annan anledning (som visat sig felaktig)

8.4 Övriga gruppers reflektioner

9.0 Slutsatser

9.1 ParprogrammeringParprogrammeringen i detta projekt var ganska påtvingad och gruppmedlemmarna var vana vid att programera i par sedan tidigare. Vad de däremot inte kunde sedan tidigare var att byta par. Det var därför glädjande att se hur många som aktivt förespråkade fler parbyten. I början var det huvudsakligen gruppmedlemmar med mindre programmeringserfarenhet som förespråkade detta, då de upplevde det som svårt att själva initiera parbyten. Senare förespråkade även vissa mer erfarna programmerare detta, dock inte alla. De identifierade att kunskapen om kodens design skulle bli bättre då, helt i linje med vad XP förutsäger.

9.2 RefaktoriseringGruppen har verkligen ansträngt sig för att refaktorisera så mycket det går och att hålla designen enkelt. De hade lite svårt att komma igång med dessa “practices”, men allt efterhand började det gå allt bättre. Vid vissa fall var det svårt att förenkla designen pga. att det ställde till problem när man senare skulle ha med mer komplexa saker med i systemet.

9.3 Test FirstVid projektets början var det svårt för projektdeltagarna att skriva kod baserad på test-first. Det största orsaken till detta var att de inte var van vid detta sätt att utveckla kod. Detta ledde till att projektets skred fram ganska segt i början och gruppen hann inte med att utveckla alla stories enligt planering. Denna modell ställde även till med en hel del besvär när någorlunda komplicerade uppgifter skulle implementeras. Men allteftersom utvecklingen gick framåt, blev gruppen bättre på att utveckla kod baserad på test-first modellen.

9.4 SpelplanenDet finns många olika sätt att lära ut XP och i detta projekt valde vi att göra det med en spelplan. Vissa gruppmedlemmar hade det lätt att följa spelplanen och andra hade det svårare. Vissa följde den inte alls. De som inte följde den, gjorde det pga att de blev för fokuserade på själva implementeringen och glömde bort planen helt. När gruppmedlemmarna följde spelplanen och upptäckte att det saknades pilar eller rutor som de ansåg behövdes, lade de dit dem själva.

9.5 Framtida arbeteI det här arbetet har vi fokuserat huvudsakligen på hur spelplanen påverkar i hur stor utsträckning parprogrammerarna kommer ihåg att följa XP:s praktiker tidigt i inlärningsprocessen. En framtida studie skulle kunna undersöka i vilken grad de som använt planen blir beroende av den, dvs om en grupp som inte använt planen blir bättre på att komma ihåg praktikerna utan hjälp än de som använt den.

Referenslitteratur1: Kent Beck, Cynthia Andres. Extreme Programming Explained 2nd Edition - Embrace Change, ADDISON-WESLEY, 20042: James Grenning. Launching Extreme Programming at a Process-Intensive Company, IEEE Software, 20013: Watts S. Humphrey. Characterizing the Software Process: A Maturity Framework, IEEE

Software, 19884: Robert C. Martin. Agile Software Development: Principles, Patterns, and Practices, Prentice Hall, 2002 5: Robert C. Martin, James Newkirk. Extreme Programming in Practice, Addison Wesley, 20016: D. Roberts & R. Johnson. Evolving Frameworks. A pattern language for developing object-oriented frameworks. Pattern Languages of Program Design 3, Addison-Wesley, 1996.7: Chromatic. Extreme Programming Pocket Guide, O’Reilly Media, 20038: L. Bendix, T. Ekman. Software Configuration Management in Agile Development. Agile Software Development Quality Assurance, Information Science Reference, Feb 2007.9: J. Shore, S. Warden. The Art of Agile Development, O'Reilly, 2008.10: Elisabeth Vene. Ny Teknik, Gör-det-INTE-själv ett vinnande koncept. 22 november 201011: Linda Rising: Design Patterns, Elements of Reusable Architectures http://members.cox.net/risingl1/Articles/architectures.html åtkommet 2011-02-2712: Programvaruutveckling i grupp – Projekt, Kursplan för läsåret 2010/2011, Lunds Tekniska Högskola, http://www.ka.lth.se/kursplaner/arets/EDA260.html åtkommet 2011-02-27