En studie om parprogrammering i praktiken - Lunds Tekniska ...

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

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 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 3.5.1 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

arna 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
3.2.1 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

esterande 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.
3.2.2 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

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

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 1.5 - 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

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

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.
3.3.1 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

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.
3.5.1 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

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

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

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

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