En studie om parprogrammering i praktiken

Transkript

1 En studie om parprogrammering i praktiken Mia Nyström Karin Wanhainen Johan Rix 29 maj 2002 Sammanfattning Parprogrammering är en av de mest omdiskuterade grundstenarna i Extreme Programming (XP). All produktionskod skall skrivas i par och på detta sätt skall programkodens stabilitet och kvalitet öka. I kursen Inledande programvaruteknik på Lunds Tekniska Högskola (LTH) introducerades XP som utvecklingsmetod för det obligatoriska projektet i andra årskursen. Kursen var teknologernas första kontakt med XP i praktiken. En kvantitativ studie bland teknologerna visade på problem och åsikter om parprogrammering. Studien genomfördes med två enkätundersökningar, en före och en efter projektet. Denna artikel redogör för och jämför de resultat som erhölls från enkätundersökningarna. Artikeln presenterar studenters åsikter om parprogrammering och ger en inblick i hur parprogrammering uppfattas av teknologer med två år kvar till civilingenjörsexamen. Resultaten har även sammanställts i form av riktlinjer för hur man bör agera som coach vad gäller parprogrammering. 1 Inledning 1.1 Parprogrammering Parprogrammering är en av de mest omdiskuterade grundstenarna i Extreme Programming. All produktionskod skall skrivas i par och på detta sätt skall stabiliteten och kvaliteten på koden öka. Det har visat sig att par är 40% mer effektiva än enskilda programmerare (Williams, Kessler, Cunningham, Jeffries, 2000) och att kod producerad av par innehöll ungefär 15 % färre fel än kod producerad av enskilda programmerare (Williams, 2000). Det finns många tänkbara anledningar till dessa förbättringar: Behovet av granskning av koden minskar vid parprogrammering, då detta är något som sköts kontinuerligt under kodningen. Som en följd av den kontinuerliga kodgranskningen minskar även felfrekvensen i koden. Programmerarna uppskattar att samarbeta och tillsammans nå resultat. Möjligheterna att diskutera fram bra lösningar minskar risken att fastna i problemlösningen. Om ett utvecklingsteam byter par ofta, sprids kompetensen och kunskapen, inte bara rörande den aktuella koden utan även om allmänna programmeringsdetaljer, algoritmer och tekniker. 1

2 1.2 Projektbeskrivning I kursen Inledande programvaruteknik på LTH introducerades XP som utvecklingsmetod för det obligatoriska projektet. Kursen var teknologernas första kontakt med XP i praktiken. De flesta av kursdeltagarna hade vid kursens början inte någon erfarenhet av programmering i projekt med tyngre arbetsmetoder, men alla hade programmerat både enskilt och i par tidigare. När kursen Inledande programvaruteknik läses går studenterna minst fjärde terminen på LTH. De har då 5 terminer kvar innan de skall ut på arbetsmarknaden. Den praktiska delen av projektet genomfördes under sex iterationer om åtta timmar vardera. Varje team bestod av 8-10 programmerare samt en eller två coacher. Många av medlemmarna i de olika teamen var inte bekanta med varandra vid projektets början och någon speciell gruppdynamik var inte utarbetad. Uppgiften för varje team var att implementera ett tidtagningssystem för olika typer av motorcykeltävlingar. 2 Undersökningen Undersökningen utfördes genom att studenterna fick svara på två enkäter, en innan projektets start och en efter avslutat projekt. Resultaten från enkäterna har sedan jämförts och sammanställts. 107 studenter har medverkat i studien, varav 16 stycken är kvinnor. Tyvärr gör det låga antalet kvinnor att resultaten vid jämförelser mellan kvinnor och män inte alltid kan ses som självklara fakta. 2.1 Enkät 1 I Bilaga A presenteras den enkät som delades ut under första iterationen. Enkäten delades ut till 107 studenter och besvarades av 102 studenter. Frågorna behandlar allmänna uppfattningar om egen kompetens, parprogrammering i allmänhet, egenskaper hos programmeringspartner samt hur parprogrammering bör genomföras i praktiken. 2.2 Enkät 2 I Bilaga B presenteras den enkät som delades ut under sista iterationen. Enkäten delades ut till 107 studenter och besvarades av 97 studenter. Frågorna var utformade i likhet med den första enkäten för att intressanta jämförelser och eventuella förändringar skulle kunna noteras. Frågor om egenupplevd kompetens, eventuella kompetensförbättringar, egenskaper hos programmeringspartner samt teamets praktiska utförande av parprogrammering behandlades. 2

3 3 Analys av resultat I nedanstående stycken jämförs och analyseras resultat från de två enkätundersökningarna. Vid analys av resultaten gick det att konstatera att inte alla frågor var tillräckligt genomarbetade. Vissa frågor kunde visa på intressanta resultat, men om följdfrågor saknades var det ibland svårt att analysera varför resultaten såg ut på ett visst sätt. Frågor angående den egenupplevda kompetensen visade anmärkningsvärda resultat och tas kort upp i stycke trots den vaga kopplingen till parprogrammering. 3.1 Studenters inställning till parprogrammering Det stora flertalet av studenterna var positiva eller mycket positiva till parprogrammering både före och efter projektet, vilket kan ses i figuren nedan. Som kan ses i figur Figur 1: Studenternas inställning till parprogrammering innan och efter projektet. 3.1 uppgav 73 % innan projektets start att de var positiva eller mycket positiva till parprogrammering. Siffran minskade något under projektets gång och motsvarande siffra efter slutfört projekt var 68 %, vilket dock fortfarande kan betraktas som högt. Man kan se ur diagrammet att antalet mycket positiva har minskat samtidigt som antalet negativa och mycket negativa har ökat. Antalet positiva har dock ökat men det leder ändå till att den sammanlagda attityden har sjunkit något. Att attityden har sjunkit, om än minimalt, kan förklaras av flera anledningar: Coachernas brist på rutin kan i några fall ha lett till en olycklig arbetsfördelning och uppdelning av programmeringspartners. I många fall fick programmerare sitta tillsammans och utföra uppgifter som ansågs vara för enkla, vilket kan ha lett till en känsla av ineffektivitet. Programme- 3

4 rarna kan då ha bildat sig uppfattningen att det just i detta projekt var onödigt med parprogrammering och slöseri med resurser. Datorrummen som användes var dimensionerade för att rymma endast halva antalet personer av de som vistades där, vilket ledde både till dålig luft och obekväma arbetsställningar. Studenterna är vana att arbeta i par med sina kompisar och var inte helt beredda på att parprogrammera med folk de inte kände eller passade ihop med. Siffrorna kanske hade blivit annorlunda om undersökningen gjorts ute i arbetslivet. I arbetslivet är parprogrammering inte ett lika vanligt arbetssätt som under utbildningen och attityden till det, speciellt bland äldre programmerare, är troligtvis inte lika positiv som på högskolan. Den initiala inställningen hade därför troligtvis varit lägre. En fråga i den andra enkäten behandlade frågeställningen om det fanns tillfällen under projektet då det hade varit bättre att programmera ensam. Det stora flertalet av gruppmedlemmarna tyckte att det fanns sådana tillfällen och att det främst skulle vara bättre att vara ensam vid mycket enkel programmering. Resultatet från den frågan stöder alltså teorin som läggs fram i punkt 2 ovan och det skulle kunna vara en möjlig anledning till att attityden har sjunkit något. 3.2 Praktiskt utförande av parbyten Vem ska välja partner? Studenterna fick svara på frågor om hur det praktiskt bör gå till med parbyten under iterationen och vad coachen bör ha för roll i det hela. Resultaten från frågan om vem som bör välja programmeringspartner framgår av figur 2. Vid den första undersök- Figur 2: Vem som bör välja programmeringspartner enligt studenterna. ningen tyckte 78% av studenterna att programmerarna själva ska bestämma med vem i gruppen man ska programmera. 20% tyckte att coachen skulle bestämma partner och 4

5 resterande 2% tyckte att både programmerare och coach bör bestämma ihop. På samma fråga efter projektet svarade färre studenter, 66%, att programmerarna själva borde välja partner. Antalet som tyckte att coachen skulle välja hade dock stigit till 24% och 11% tyckte nu att båda skulle välja tillsammans. Resultaten skulle kunna förklaras med att studenterna föredrar den metod som deras coach har tillämpat i deras egen grupp. Det visade sig nämligen att de flesta som svarade att coachen skulle bestämma partner kommer från grupper där coachen i större utsträckning under projektet har styrt vilka programmerare som ska programmera ihop. Det är i den här frågan även värt att notera att det i enkäterna ej förekom något alternativ båda utan att de enkäter där båda alternativen var ikryssade här har tolkats som ett tredje alternativ. Hade det funnits ett alternativ båda är det möjligt att siffrorna hade sett annorlunda ut Coachens roll En fråga i andra enkäten berörde hur studenterna tyckte att coachen skulle agera och vad han/hon skulle ha för roll vid parbyten. Frågan hade fem förskrivna alternativ: Han/Hon ska se till att det blir gjort. Han/Hon bör se till att de som samarbetar bra får jobba tillsammans. Han/Hon bör se till att sprida och öka kompetensen i gruppen. Han/Hon bör se till att paren byts ifall ett par har kört fast. Han/Hon bör låta utvecklarna sköta det helt själva. Den stora majoriteten, 60% och 59% tyckte att coachens huvuduppgifter var att sprida och öka kompetensen i gruppen samt att se till att paren byts ifall ett par har kört fast. 44% tyckte även att det är coachens uppgift att se till att byten sker överhuvudtaget och 34% tyckte att coachen skulle para ihop de som samarbetar bra tillsammans. Frågan gav även upphov till en del spontana kommentarer. Någon tyckte exempelvis att coachen skulle placera folk på den story de passar bäst för. Resultaten från de båda frågeställningarna ovan visar att parbyten bör baseras på ett samspel mellan programmerare och coach. Coachen bör skaffa sig uppfattning om hur de olika gruppmedlemmarna arbetar tillsammans och kan sedan med fördel föreslå vilka som kan programmera ihop vid nästa byte. Coachen bör även ha koll på ungefär vilka delar av koden de olika programmerarna är insatta i så att någon som är väl insatt i ett visst stycke kod kan arbeta tillsammans med någon som ej är så väl insatt i just den delen av koden och på så sätt sprida kodkännedomen i gruppen. Det yttersta beslutet om vilka som ska programmera ihop måste dock programmerarna själva ansvara för och coahens förslag ska hellre ses som rekommendationer för att på bästa sätt sprida kompetensen i gruppen. 5

6 3.2.3 Hur ofta bör man byta partner? En fråga behandlade hur ofta man bör byta programmeringspartner för att få utvecklingsarbetet effektivt. En fråga om hur ofta grupperna faktiskt hade bytt partners ställdes också. Resultaten från de båda frågorna kan betraktas i figur 3 nedan. Vad som nedan refereras till som en iteration omfattade i detta projektet 8 timmars arbete, och en uppgift som refereras till som en story kunde ta allt från en till åtta timmar. De flesta Figur 3: Hur ofta man bör byta programmeringspartner jämfört med hur ofta studenterna upplevde att de faktiskt bytte programmeringspartner av studenterna, 60%, upplevde att de i deras grupp hade bytt partner ungefär en gång per iteration. Några få, 10%, uppgav att de hade bytt partner efter varje story och 25% hade bytt mindre än en gång per iteration. De som sa sig ha bytt partner efter varje story representerade främst två av de tolv grupperna, men någon enstaka ur de andra grupperna hade också angett det alternativet. Följdfrågan var sedan hur ofta studenterna tycker att man bör byta partner i ett projekt av liknande karaktär. Här visade resultaten att 27% hade velat byta partner efter varje story, 58% en gång per iteration och 8% mindre än en gång per iteration. Till frågan erhölls många spontana kommentarer som visade att det är viktigt att byta när det faller sig naturligt, tex när det är en naturlig paus under iterationen. Med tanke på att en story kan variera ganska kraftigt i tidslängd verkar det alltså som att det inte riktigt är tiden som bör avgöra när ett byte ska ske, utan snarare om det faller sig naturligt eller ej. Om man även tar hänsyn till att en story i detta projektet ofta inte tog längre tid än några få timmar kan resultaten även uppfattas som att studenterna hade velat byta partners lite oftare än vad de faktiskt gjorde under projektet. De vill inte byta partner mitt i en uppgift, men heller inte för sällan. En intressant vidareutveckling av studien hade varit att komplettera med en ordenligt undersökning av coacherna och hur de har lett sina grupper. Många av de avvikande resultaten som har framkommit representerar en eller några speciella grupper av de tolv och det vore då intressant att ta reda på om coachen i detta fallet har agerat annorlunda i jämförelse med de andra coacherna. 6

7 3.2.4 Hur många i en grupp bör man programmera med? Studenterna fick svara på frågan om hur många i en grupp om tio personer de tycker att man bör parprogrammera med. Resultaten kan beskådas i figur 4 nedan. Innan projektet Figur 4: Hur många i en grupp om tio personer man bör parprogrammera med. tyckte 52% att man ska programmera med de flesta i en sådan grupp. 27% tyckte alla och 19% tyckte bara några. Efter projektet tyckte 58% att man ska programmera med de flesta i gruppen och de som tyckte att man skulle programmera med alla hade sjunkit lite i antal. Den minimala minskningen kan eventuellt förklaras med att vissa som inte hade räknat med det har fått uppleva hur det är att programmera med någon de inte alls passar ihop med eller att det har förekommit personer med samarbetssvårigheter i vissa grupper. Slutsatsen bör dock vara att man bör programmera med de allra flesta i en grupp om 10 personer, men inte nödvändigtvis alla om det finns personer i gruppen som inte alls kommer överens med varandra. 3.3 Programmeringspartner Flera av frågorna i båda enkäterna behandlade hur olika personlighetsegenskaper rankades hos partnern. Det är här relativt självklara resultat som presenteras, men det kan vara viktigt att få se vilka egenskaper man bör leta efter när man tillsätter personal till ett XP-projekt och vilka egenskaper som antagligen uppfattas som värst av gruppmedlemmarna. Studenterna fick först ranka de viktigaste egenskaperna hos den de parprogrammerar med på en skala mellan 0 och 3. Resultaten visas i figur 5 på nästa sida. De två absolut viktigaste egenskaperna visade sig vara att ha en partner som är tillmötesgående och lyhörd. Intressant var att sex av de sju absolut högst rankade egenskaperna - de som fick en sammanlagd poäng högre än var egenskaper som endast rörde personligheten, som social, utåtriktad, rolig, lyhörd och tillmötesgående. Huruvida man var en erfaren programmerare eller ej eller snabb på att editera och skriva kod visade sig ha mindre betydelse. Teknisk kompetens var den högst rankade kompetensegenskapen och den kom först på fjärde plats totalt. Resultatet visar alltså att kompetensen inte anses lika viktig som personligheten hos den man parprogrammerar med. 7

8 Figur 5: De viktigaste egenskaperna hos programmeringspartnern rangordnade på en skala mellan 0 och 3 I arbetslivet kan det då vara viktigt att tänka på att personligheten hos medlemmarna i ett XP-projekt spelar lite större roll än i ett projekt där programmerarna sitter och utvecklar enskilt. I frågan om de värsta egenskaperna ombads studenterna nämna de fem egenskaper de tyckte sämst om hos den de parprogrammerar med. De egenskaper som rankades som de värsta visas i figur 6 nedan. Den negativa egenskap som rankades som värst var dominans. Tätt därefter följde egenskaper som dålig ambition, passivitet och ineffektivitet. Först på en femte plats kom den kompetensrelaterade egenskapen att vara en dålig programmerare. Figur 6: De fem värsta egenskaperna hos den man parprogrammerar med. 8

9 Ur resultaten kan det alltså än en gång befästas att det är personligheten i större utsträckning än kompetensen som spelar roll vid parprogrammering. En viktig skillnad noterades mellan de som ansåg sig själva vara över medel och de som ansåg sig själva vara under medel i jämförelse med övriga projektmedlemmar. De som ansåg sig vara över medel programmeringsmässigt ansåg att tekniskt kompentens och humor var de bästa egenskaperna. Som sämsta egenskaper rankades ineffektivitet, dålig programmerare, dålig personlig hygien samt låg ambition. De som ansåg sig själva vara under medel programmeringsmässigt rankade däremot lyhördhet och hög ambition som bästa egenskaper. Ineffektivitet och passivitet ansågs vara de värsta Manligt och kvinnligt Det framgick flera skillnader mellan vad kvinnor och män tyckte var de värsta egenskaperna hos den de parprogrammerar med. Jämförelsen kan ses i figur 7 nedan. Figur 7: De värsta egenskaperna hos partnern enligt män respektive kvinnor. 100% av kvinnorna jämfört med 50% av männen tyckte att dominans var en av de värsta egenskaperna och 84% av kvinnorna jämfört med 48% av männen tyckte att passivitet var en. Männen däremot rankade ineffektivitet samt dålig programmerare som de värsta egenskaperna, vilket för kvinnorna inte alls ligger lika högt rankat. Att dominans fick så höga siffror hos kvinnorna skulle kunna visa på att männen omedvetet tar mer plats än kvinnorna och att kvinnorna därför känner sig överkörda. En spontan kommentar från en kvinna på frågan om kön hos partnern spelar någon roll var: Det har viss betydelse för gruppkänslan, i alla fall för mig som varit ensam tjej. Jag har haft lite prestationsångest faktiskt och blivit uppretad ett antal gånger på grund av alla Förstår du? från vissa personer, men självklart är inte alla så. 9

10 3.4 Samarbetssvårigheter och konflikter Under den första iterationen trodde 24% av studenterna att de skulle få svårt att samarbeta med någon eller några i gruppen, men efter projektet uppgav endast 18% att de hade haft sådana svårigheter. På frågan om hur samarbetsproblemet hade löst sig uppgav hela 90% att problemet inte hade löst sig. Resultatet kan tolkas som att det är personer som har fått jobba ihop som absolut inte passar ihop. Det kan också ha varit så att det är vissa personer som har samarbetssvårigheter och där problemet då inte löser sig oberoende av förslag. Det kommer alltid finnas personer som är svåra att samarbeta med och i ett skolprojekt är det en nödvändighet att dessa människor ändå sitter med i projekten och deltar som de andra. Det blir då coachens uppgift att se till att de som inte alls kan samarbeta slipper parprogrammera med varandra. Istället bör coachen uppmärksamma vilka personer i gruppen som bäst klarar av arbeta med den personen och låta dem arbeta ihop. Väldigt krystade kombinationer av människor bör i alla lägen undvikas då samarbetet i sådana fall säkerligen fungerar dåligt vilket kan få till följd att det produceras dålig kod. I ett projekt i arbetslivet borde problem av detta slaget inte uppkomma speciellt ofta eftersom företagen själva tillsätter sin personal. Studenterna fick en fråga om huruvida de hade råkat ut för konflikter med sin partner någon gång under projektet eller ej. 30% uppgav att de hade haft konflikter och i 84% av fallen berodde konflikten på koden. I några enstaka fall hade konflikterna rört programmeringsordning, personlighet eller partnerns inställning till projektet. I något enstaka fall hade konflikten behövt lösas genom partnerbyte, men de flesta konflikterna, 70%, hade löst sig genom att båda parter hade kompromissat. Under sådana omständigheter kan konflikter ses som något positivt eftersom det vid kompromisser ofta kommer fram den bästa av två eller flera lösningar. I fall där programmerarna själva inte klarar av att lösa konflikten kan coachen kanske hjälpa till genom att ge sin syn på problemet och om möjligt introducera ytterligare ett lösningsförslag. 3.5 Egenupplevd kunskap I båda enkäterna undersöktes studenternas uppfattning om den egna programmeringskompetensen. Frågan är inte helt relevant för just parprogrammering men eftersom den visar intressanta resultat tar vi upp det här ändå. Studenterna fick rangordna sina egna programmeringskunskaper i jämförelse med kurskamraternas på en skala med Under medel, Medel och Över medel. Innan projektet ansåg sig 9% vara Under medel, 70 % Medel och 21% Över medel. Efter projektet hade siffrorna ändrats marginellt och 6% ansåg sig vara Under medel, 76 % Medel och 17% Över medel Manligt och kvinnligt Det visade sig dock ligga en stor skillnad i resultaten mellan män och kvinnor. Ingen av kvinnorna som deltog i studien ansåg sig vara Över medel varken innan eller efter projektet. Däremot ansåg sig hela 25% av kvinnorna ligga under medel innan projektets start. Motsvarande siffra för männen var 6%. För att verifiera resultaten gjordes en förfrågan till Per Holm på Institutionen för Datavetenskap om statistik för kvinnorna i andra årskursen. Det visade sig att ingen av tjejerna i årskursen låg under medel. Däremot låg flera av dem över medel och en kvinna hade genomgående högsta betyg på alla kurser som kan relateras till projektkursen, något som ingen tidigare åstadkommit. 10

11 Efter projektet ändrade sig statistiken något och nu ansåg sig bara 8% av kvinnorna vara Under medel. För männen var siffran fortfarande 6%. Det var dock ingen kvinna som uppgav sig ligga Över medel heller efter projektet jämfört med 20% av männen. De något nedslående resultaten kan enklast förklaras med att kvinnorna har en mer försiktig attityd och ett sämre självförtroende vad gäller programmering än vad killarna har. Kvinnorna torde därför ha svårare att hävda sig i en grupp med en majoritet av män och det är därför viktigt att coachen uppmärksammar alla i gruppen, även de killar som kan tänkas ha sämre självförtroende. 3.6 Ergonomi och lokaler Eftersom två programmerare sitter vid en och samma arbetsstation då de parprogrammerar blev studenterna tillfrågade om de upplevde att parprogrammering var jobbigare ur ergonomisk synvinkel än enskild programmering, dvs om de har upplevt mer nackstelhet, axelvärk etc. 33% av de tillfrågade svarade ja på frågan, vilket är en ganska hög siffra i ett så kort projekt. Endast sex iterationer om vardera åtta timmar har genomförts. Att arbetsställningen är sämre vid parprogrammering är förståeligt då två människor samtidigt vill sitta så nära skärmen som möjligt, men siffrorna torde också vara direkt beroende av de lokaler som användes under just detta projektet. Ett stort antal programmerare satt i en datasal som är avsedd för hälften av de människor som vistades där.de ordentliga arbetsstolarna har inte räckt till och många har suttit på hårda, oinställbara stolar, vilket inte direkt främjar rygg och nacke. Lösningen i detta projektet skulle vara att ha färre studenter i datasalarna under iterationerna, men i allmänhet är det viktigt att se till så att alla programmerare har tillgång till bra stolar och att de som parprogrammerar kontinuerligt byter driver, vilket varierar arbetsställningen mer. Det vore även klokt att lägga in korta bensträckare flera gånger under dagen. Ett annat problem som framkom och som direkt går att relatera till lokalerna under just detta projektet var den dåliga luftkonditioneringen. Studenterna upplevde den dåliga luften som tröttande och varken ventilationssystemet eller vidöppna fönster var tillräckligt för det antalet människor som befann sig i salen. 3.7 Föredrar parprogrammering Den slutgiltiga frågan var ifall projektmedlemmarna ansåg sig ha blivit bättre programmeringsmässigt under projektet och om de i så fall ansåg att det var parprogrammeringens förtjänst. Hela 62% tyckte att de hade blivit bättre och av dem tyckte hela 92% att det berodde på parprogrammeringen. Innan projektet uppgav 10% av studenterna att de hellre hade använt enskild programmering i projektet. Efter projektet ställdes frågan om studenterna föredrar parprogrammering framför enskild programmering i skolan eller på jobbet. 77% uppgav att de föredrar parprogrammering i skolan och 69% föredrog parprogrammering även i arbetslivet. Frågan om vad som föredras i arbetslivet uppfattades dock av många som lite svår eftersom inte alla varit ute i arbetslivet ännu. Resultaten visar dock att parprogrammering borde vara mycket väl lämpat i utbildningssyfte då studenterna tvingas samarbeta, kompromissa och lösa konflikter. 11

12 4 Råd och riktlinjer Resultaten av enkätundersökningarna har resulterat i nedanstående lista över de saker coach och projektledare bör tänka på vid parprogrammering. Att välja partner - Parbyten bör baseras på ett samspel mellan programmerare och coach. Coachen bör skaffa sig uppfattning om hur de olika gruppmedlemmarna arbetar tillsammans och kan sedan med fördel föreslå vilka som kan programmera ihop vid nästa byte. Coachen bör kunna avgöra vilka stories som lämpar sig för vilka programmerare och föreslå par därefter. Det yttersta beslutet om vilka som ska programmera ihop måste dock programmerarna själva ansvara för och coahens förslag ska hellre ses som rekommendationer för att på bästa sätt sprida kompetensen i gruppen. Coachens roll vid parbyte - Coachens roll i projektet vad gäller parbyten bör vara att se till att kompetensen i gruppen sprids på bästa sätt och att de som kör fast snabbt avhjälps genom antingen parbyte eller om möjligt alternativa lösningsförslag från coachen eller andra gruppmedlemmar. Coachen bör även ha koll på ungefär vilka delar av koden de olika programmerarna är insatta i så att någon som är väl insatt i ett stycke kod kan arbeta tillsammans med någon som ej är så väl insatt i just den kodbiten och på så sätt sprida kodkunskapen i gruppen. Hur ofta man bör byta partner - Parbyte bör ske vid naturliga avbrott i utvecklingen, antingen vid pauser, då i alla fall en liten del av storyn har avslutats eller om det är korta stories, då en ny story påbörjas. Mer än fyra timmar bör ett par inte programmera ihop vid projekt liknande det då studien har utförts. I arbetslivet med längre iterationer kan man nog tänka sig en längre period mellan bytena då uppgifterna kan antas vara mer komplicerade och tidskrävande än de uppgifter som har behandlats i detta projekt och då det tar längre tid för programmerarna att sätta sig in i kod. Hur många man bör programmera med - I skolprojekt som detta bör gruppmedlemmarna programmera med så många som möjligt i gruppen. Om det finns personer som inte fungerar bra ihop bör coachen se till att just de personerna inte behöver arbeta ihop, speciellt inte med mer komplicerade uppgifter. Uppstår ändå konstlade par kan de kanske få enklare uppgifter att lösa för att inte riskera att det dåliga samarbetet går ut över koden i allt för stor utsträckning. Att tillsätta personal - Vid tillsättning av personal till ett projekt där parprogrammering ska användas bör man tänka på att det är personlighet i större utsträckning än kompetens som kommer avgöra hur gruppen arbetar ihop. Självklart måste man även ta hänsyn till gruppmedlemmarnas kompetens för att få ett bra team och en bra produkt, men högsta kompetens bör inte vara högsta prioritet. Konflikter - Konflikter verkar ofta lösa sig genom kompromisser mellan programmerarna, men om coachen upptäcker att en konflikt inte kan redas ut kan han/hon gå in som tredje part och försöka hjälpa till att reda ut konflikten. Eftersom konflikterna oftast rör koden kan det vara bra med flera åsikter om hur problemet ska lösas och eventuellt kan det avhjälpa med ett möte inom gruppen för att få fram en bra lösning på problemet. 12

13 Samarbetssvårigheter - Det kommer alltid att finnas människor som har svårt för att samarbeta och i ett skolprojekt som detta är det nödvändigt att de personerna ändå tvingas samarbeta med andra eftersom det är en nödvändighet inför arbetslivet. Coachen kan underlätta situationen genom att styra så att den eller de personer som går bäst ihop med personen i fråga oftare får programmera ihop. Manligt och kvinnligt - Eftersom studien visar att kvinnor i större utsträckning än män är osäkra på sina egna kunskaper är det viktigt att uppmärksamma dem på samma sätt som de som hävdar sig mest i gruppen. Förhoppningsvis jämnar siffrorna ut sig under de sista åren på högskolan, men det kommer alltid finnas personer i gruppen med sämre självförtroende än andra och det är då viktigt att coachen försöker uppmärksamma alla olika individers åsikter och är lyhörd, även för de som kan verka osäkra. Ergonomi - För att inte få ökade problem med rygg och nacke under parprogrammering bör det finnas bra stolar att tillgå för alla programmerare i gruppen. Coachen kan även påminna paren om att byta driver då och då så att kroppsställningen ändras ofta, vilket annars lätt glöms bort. Lokaler - Eftersom det vid parprogrammering ofta finns dubbelt så många personer som det finns arbetsstationer och alltså långt fler personer än vad ytan är menad för, så är det viktigt att se till att det finns tillräckligt med utrymme för alla i gruppen och att luftventileringen räcker till. Ett tips är att låta alla programmerare ha varsin arbetsstation fastän kodningen endast sker vid en av dem. Därmed används lokalytan endast av så många personer som den är anpassad för. 5 Slutdiskussion Studenterna som har deltagit i studien har visat sig ha en mycket positiv inställning till parprogrammeing. Parprogrammering har bidragit till ökade programmeringskunskaper hos studenterna och kan anses vara en mycket bra metod i utbildningssyfte. Parprogrammering ger övning i samarbete och konfliktlösning och innebär en mer given delaktighet i utvecklingsarbetet för alla i gruppen. Det kommer tyvärr alltid finnas människor som är svårare än andra att samarbeta med, men i skolan är det nödvändigt även för dem att försöka vänja sig vid och lära sig att samarbeta, eftersom det är en nödvändighet i arbetslivet. Förhoppningsvis kan parprogrammering ge personerna i fråga övning i samarbete, vilket de kanske annars helst väljer bort till förmån för enskild programmering. 13

14 Referenser Laurie Williams, Robert R. Kessler, Ward Cunningham och Ron Jeffries. Strengthening the Case for Pair programming. IEEE Software, July/August Laurie Williams. The Costs and Benefits of Pair Programming. University of Utah Computer Science,