1
P ARPROGRAMMERING
Mikael Möller, dt07mm5@student.lth.se 2011-02-28
Abstrakt
Parprogrammering är ett arbetssätt där två programmerare arbetar tillsammans vid en dator med en uppgift. Studien behandlar frågor och svar huruvida parprogrammering är bra för ett team. Några av de aspekter som tas upp är om programmering i par bidrar till högre effektivitet, bättre kodkvalitet samt ökad samhörighet inom projektgruppen. Undersökningen görs på andra årets dataingenjörer vid Lunds Tekniska Högskola.
1. Inledning
Av författarens erfarenhet har det upplevts som om parprogrammering (Williams & Kessler, 2002) underlättar och förbättrar ett teams produktivitet och kodkvalitet. Varför blir det högre produktivitet och bättre kodkvalitet? Om man arbetar i par, får varje programmerare en lust av att jobba effektivare och mer fokuserat?
Under ett projekt är det viktigt att teammedlemmarna litar på varandra och jobbar mot samma mål, tillsammans. För att uppnå detta används diverse teambuildings redskap. Men hjälper även parprogrammeringen till att svetsa ihop teamet?
Kan en enskild programmerares utveckling gynnas vid parprogrammering? Finns det negativa aspekter angående då en skicklig och rask programmerare blir hindrad av en sämre programmerare.
För att få fram statistik och åsikter har utvecklare, som precis blivit introducerade till parprogrammering, fått svara på enkäter och blivit intervjuade. Resultatet var positivt, man jobbar effektivare och mer fokuserat. Det råder konstant utbyte av kunskap inom parprogrammerings paren.
Upplägg: Studien lägger först en bakgrund och beskriver parprogrammering. I avsnitt 3 beskrivs hur undersökningen utfördes. I avsnitt 4 presenteras resultatet av denna undersökning, samt slutsatser och lösningar med hjälp av annan litteratur och studier.
Avslutningsvis sammanfattas de viktigast slutsatserna.
2. Bakgrund
I detta avsnitt beskrivs vart parprogrammering appliceras, hur det ska fungera och även i vilket projekt det introduceras i.
2.1 Agila mjukvaruutvecklings metoder
Det finns tre stycken agila metoder vid mjukvaruproduktion som är mer kända än andra, Lean, Scrum och Extreme Programming (XP). I stora drag är skillnaden mellan de agila metoderna följande. Lean kommer från Toyota bilindustri och är en övergripande metod för hur en organisation ska skötas (Poppendieck & Poppendieck, 2003). Man fokuserar på att maximera kundvärdet och minimera slösandet med tid. Scrum går mer in på detalj då den
2 behandlar vad som ska utvecklas men inte hur man programmerar (Schwaber & Beedle, 2001). Till sist är XP en programvaru utvecklings metod som beskriver riktlinjer och metoder för utvecklarnas arbete under utvecklingen. XP fokuserar på enkelhet, feedback, mod och kommunikation (Beck, 1999). Många företag kombinerar de olika agila metoderna för att få ett skräddarsydd metod som passar just dem.
Principen för XP är att ett team sitter och programmerar mot en och samma kod, ett repository som alla får förbättra men med kravet att det ska fungera (Beck & Andres, 2004, s.66). Med hjälp av detta repository kan man när som helst få fram en release av den funktionalitet som är implementerad vid just det tillfället. Denna release kan man visa för kunden och på så sätt kan denne känna ett förtroende om att arbetet går framåt. För att hjälp utvecklarna att uppfylla detta finns det 12 st practices in om XP (Beck, 1999, s.71). Några av dem är Simple Design, Refactoring, Collective Code Ownership, Test Driven Development (TDD), Release Regularly och Pair Programming.
2.2 Parprogrammering
Parprogrammering går ut på att två utvecklare sitter och programmerar tillsammans vid en dator (Williams & Kessler, 2002). Paret är uppdelat som en driver och en navigator. Arbetet ihop går ut på att drivern och navigatorn diskuterar tillsammans fram en lösning till en implementation av en story1. Vidare är driverns huvuduppgift att implementera själv lösningen. Samtidigt gör navigatorns sina arbetsuppgifter, som är att granska koden som driven skriver samt notera fel och idéer om vad som ska göras där näst på en todo-lista. Den listan hjälper paret att komma ihåg vad som ska göras samt att den även hjälper dem att komma ihåg vad dom har gjort. Continous Integration betyder att så fort det finns ny funktionalitet till systemet, så skall det göras en commit2 så att resten av teamet kan ta del av den nya funktionaliteten. Vid commits är det viktigt att kommentera var någonstans något har lagts till eller ändrats. Till sin hjälp har då paren sin todo-lista som kan hjälpa dem att komma ihåg vad de gjort.
Navigatorn och drivern skall byta roller ofta och man ska försöka vara lika mycket driver som navigator.
2.3 Projektbeskrivning
Denna studie gjordes samtidigt som projektet och kursen (EDA260) utfördes. Kursen ges under första läsperioden på vårterminen för de som går andra året på Civilingenjörsprogrammet - Datateknik vid Lunds Tekniska Högskola. I kursen är studenterna uppdelade i team om 8-12 studenter. Under 7 veckor har teamen 6 stycken så kallade långlabbar och 6 stycken planeringsmöten. Under två timmar varje onsdag i vecka 1-6 planeras arbetet som ska göras under näst följande långlabb. Långlabbarna var mellan 8:15 till 17:00 varje måndag i vecka 2-7. System som skulle utvecklas var ett tidsregistrering och resultatgenererings program för Enduro race. Författaren var coach till ett team om 12 utvecklare som skulle för första gången jobba enligt XP modellen, och då även första gången som parprogrammerare. Många av utvecklarna hade i tidigare programmerings kurser programmerat i par under laborationer, men då inte enligt de normer som finns inom XP. I stort sätt kände inte utvecklarna i teamet varandra sedan tidigare. Det fanns enstaka bekantskaper, men ingen hade parprogrammerat med någon annan sedan tidigare.
1En story är en beskrvining av funktionalitet som kunden vill ha implementerad.
2 Lägga till ny funktionalitet i det gemensamma repository.
3
3. Undersökning
Genom två enkäter och individuella intervjuer fanns förhoppningen om att få fram de positiva och negativa åsikterna som utvecklarna hade om parprogrammering.
3.1 Enkät 1
Den första enkäten delades ut efter den första lång labben till ett team, det team som främst var under granskning. Den var uppdelade i ett två avsnitt, ett där man på en skala skulle markera hur mycket man man höll med om ett påstående. Och den andra delen skulle man i egna ord kommentera påståendena och några ytterligare frågor. På påståendena kunde man välja från att “Jag tar helt avstånd från påståendet” till “Jag instämmer helt i påståendet”, “Ej svar” var även ett alternativ. Nedan följer påståendena som var på enkät 1:
1. Navigatorns todo-lista används.
2. Byte inom paren görs? Dvs man var lika mycket driver som navigator.
3. Känner du att du jobbar effektivare och mer fokuserat än när du programmerar själv?
4. Anser du att produktiviteten och kodkvalitén är högre än när du programmerar själv?
5. Har din egen utveckling, som programmerare, gynnats av parprogrammeringen?
6. Känner du att parprogrammeringen har hjälpt dig att lära känna dina teammedlemmar snabbare?
7. Om du anser att du var den bättre programmeraren i paret vid något tillfälle, kände du dig hindrad och tyckte att det gick för långsamt? (Om du inte känt av detta svara “Ej svar”)
Vidare följde tre stycken frågor där utvecklarna skulle svara med egna ord:
1. Kommentarer till frågorna i tabellen. Tex om man svarat en 1:a på “Todo-listan användes”, vad var det då som inte fungerade?
2. Påtvingad rotation. Bra/dåligt? Kommentar?
3. Din allmänna uppfattning om parprogrammeringen.
Den första enkäten hade som syfte att undersöka huruvida utvecklarna tyckte om parprogrammeringen eller ej. Vidare skulle resultat från en annan enkät, som delades ut 2 veckor efter, jämföras. Detta för att se skillnader då utvecklarna hade fått arbetat mer som parprogrammerare.
3.2 Enkät 2
Den andra enkäten delades ut efter den tredje lång labben. Den var likadan som den första enkäten förutom att två frågor, där utvecklarna skulle svara med egna ord, hade lagts till. De frågorna var:
• Är det någon du inte passar ihop med/passar mindre ihop med? Varför är det så?
(Inga namn)
• Vad hade kunnat vara bättre? (tex arbetslokal?)
Dessa två frågor blev fråga 3 respektive 4, det vill säga att “Din allmänna uppfattning om parprogrammeringen” blev fråga 5. Som nämndes tidigare skulle svaren från denna enkäten jämföras med resultaten från enkät 1.
4
3.3 Intervjuer
Intervjuerna användes för att kunna få bättre feedback från utvecklarna då det fanns risk för att kommentarerna från enkäterna inte skulle vara tillräckligt tillfredsställande. En teori var att om utvecklarna i tal fick diskutera påståendena och frågorna skulle mer information komma fram. I ett enskilt rum fick tre stycken utvecklare (en åt gången) tillsammans med författaren kommentera påståendena och frågorna på enkät 2, detta antecknades.
4. Resultat från undersökning och jämförelse med andra studier
Enkät 1 skickades ut och blev besvarad av ett team, team 6 med 12 st studenter. På grund av sämre deltagande i enkät 2 och ett intresse om andra teams åsikter, skickades enkät 2 även ut till två andra team. Enkät 2 besvarades av 17 studenter. Det var inga större skillnader på svaren från de olika team. Det intressanta var de konsekventa åsikterna i vissa frågor samt svar från vissa individer som stack ut från mängden.
I samtliga figurerna under avsnitt 4 är en ”1” lika med “Jag tar helt avstånd från påståendet”
och en ”5” lika med “Jag instämmer helt i påståendet”.
4.1 Användningen av navigatorns todo-lista
Figur 1. Fråga: Navigatorns todo-lista används.
Som grafen (fig. 1) visar så var det högre användning av todo-listan då den introducerades än vid tiden då enkät 2 besvarades. Många av utvecklarna kommenterar detta med att det som diskuteras implementeras direkt så att man behöver inte skriva ner något. En kommentar säger:
- Kändes nästan aldrig lämpligt att skriva ner något i listan. Det som diskuterades var oftast det som hände precis då.
Vissa påpekar att det säkert är en bra sak att göra, men att det glöms bort. Detta är förståeligt då det är en mängd andra moment och rutiner som är nytt. Däremot verkar det finnas en tendens till att båda i paret blir driver, vilket inte är bra.
- Båda blir driver för att lösa problemet.
0%
10%
20%
30%
40%
50%
60%
70%
1 2 3 4 5 Ej svar
Enkät 1 Enkät 2
5 Kommentaren styrker detta och visar på att man förmodligen inte blir klar med diskussionen om lösningen inom paret. I andra ord att man fortsätter diskussionen samtidigt som man börjar implementerar lösningen. Detta leder in på om bytet inom paret sköttes?
4.2 Lika mycket driver som navigator
Problemet att navigator rollen inte alltid uppfylls återstår. Granskning av koden görs, men i några fall tänker man inte över om vad som ska göras där näst.
Figur 2. Fråga: Byte inom paren sköttes? Dvs man var lika mycket driver som navigator.
När parprogrammeringen introducerades så var teamet väldigt måna om att byta ofta inom paret. Som grafen (fig. 2) visar så har det gått från bra till lite sämre. En faktor är att i de par där kompetensskillnaden är större, känner den sämre programmeraren att det är säkrare om den bättre programmeraren är driver. En utvecklare säger:
- Om man har sämre kompetens låter man den andra ta rodret. Men man tar över lite i alla fall.
Men i de par där kompetensen är på samma nivå sker bytet automatiskt.
- Det man tittar på i förväg, gör att man byter.
För att förtydliga. Samtidigt som drivern implementerar, upptäcker navigatorn något som måste göras. Då görs bytet när drivern har blivit klar med det den arbetade med. Navigatorn som nu har blivit driver förklarar och kan sedan börjar implementera om inget annat ska diskuteras. Under intervjuerna kom några av utvecklarna fram till en insikt om att todo-listan är förmodligen en väldigt bra idé. Men att det har varit svårt att applicera detta då man inte riktigt är van vid arbetssättet.
- Man vill inte avbryta drivern, så en todo-lista hade varit bra. Kommer nog efter ett tag.
4.3 Effektivare och mer fokuserat arbete
När utvecklare jobbar i par känner merparten att de inte vill svika sin partner och då jobbare hårdare och mer motiverat (Williams & Kessler, 2002, s.21-23). När man programmerar enskilt kan man ta det lugnt ibland, läsa e-mails, prata i telefon etc. I parprogrammering blir detta bortkastad tid för sin partner, så att undermedvetet håller man varandra fokuserade på uppgiften (Williams, 2001, s.33). Grafen (fig. 3) samt vissa kommentarer visar tydligt att utvecklarna tycker likadant.
- Helt klart, man känner ett större ansvar till den andra också.
0%
20%
40%
60%
80%
1 2 3 4 5 Ej svar
Enkät 1 Enkät 2
6 - Prestationskrav inom paret, man ville inte vara den som sölar ner.
Figur 3. Fråga: Kände du att du jobbade effektivare och mer fokuserat än när du programmerar själv?
Enstaka utvecklare väljer att svara att det varit både mindre effektivt och mindre fokuserat.
Kompatibilitet inom vissa par, se avsnitt 4.7, kan ha varit dålig och gett upphov till detta resultat.
4.4 Högre produktivitet och bättre kodkvalitet
Båda programmerarna i ett par bidrar med olika, om än liten, information och kunskap. Detta leder till att bättre beslut, t.ex. beslut om design, tas (Chong m.fl., 2005). Utöver designbeslut löser paret tillsammans problem snabbare och resultatet, koden, blir kortare (Cockburn &
Williams, 2001). Som nämnts tidigare känner utvecklarna hängivenhet gentemot varandra vilket resulterar i bättre coding standards.
Figur 4. Fråga: Anser du att produktiviteten och kodkvalitén var högre än när du programmerar själv?
Grafen (fig 4) tyder på att utvecklarna märker en positiv skillnad av produktivitet och kodkvalitet gentemot då man arbetar själv. Dagen då enkät två delades ut hade omfattande refaktoriseringar gjorts, vilket kan kan ha påverkat åsikten gällande om det är högre kodkvalitet eller ej.
- Man fastnade nästan aldrig, körde man fast så var det oftast ganska lätt att diskutera fram en lämplig lösning. Samt att fler misstag upptäcktes eftersom en person hela tiden
granskade koden.
0%
10%
20%
30%
40%
50%
1 2 3 4 5 Ej svar
Enkät 1 Enkät 2
0%
10%
20%
30%
40%
50%
60%
70%
1 2 3 4 5 Ej svar
Enkät 1 Enkät 2
7 Williams och Kessler tar upp pair courage vilket innebär att paret skapar ett självförtroende inför sina resultat och lösningar (Williams & Kessler, 2002, s.26-27). Detta uppkommer som ett resultat av kontinuerliga diskussioner mellan varandra. De kommer även ha lättare för att erkänna om de inte förstår något och kan då be om hjälp från ett annat par. Dock påpekar några utvecklare att då man vill få fram ett resultat snabbare, vid deadlines, påverkas lösningarna.
- Får lösningar som funkar men är inte lika snyggt, resultat lite snabbare. Refaktorisera sen!
Detta är inte bra och ska absolut undvikas. Det är viktigt att uppfylla XP’s grundstenar, kommunikation i detta fallet. Det är viktigt att samtala med kunden om att man stöter på problem och att resultatet ska stå i centrum, inte kvantiteten. En dålig lösning kan ställa till problem senare och kan vid det tillfället ta ännu längre tid att lösa än om man löst det från första början.
4.5 Studenternas utveckling gynnas av parprogrammering
Vid parprogrammering byts konstant kunskap mellan programmerarna. Man lär sig om programmerings regler för design, användning av verktyg och allmänt om programmerings språket. Tillsammans med rotation av paren lär sig varje programmerare om flera delar av systemet. Detta gynnar hela projektet då det är flera som har kännedom om system när det är avslutat (Cockburn & Williams, 2001).
Utvecklare, som jobbar enligt parprogrammering, har en positivare attityd, samt lär sig om samarbete, lagarbete och skapar goda kommunikations färdigheter vilket de kommer ha nytta av i deras framtida arbetsliv (Nagappan, 2003)(Williams, 2007).
Större delen av studenterna har märkt att de lära sig många nya saker genom sin parprogrammerings partner (illustreras i fig. 5), men även genom egna och teamkamraters spikes3.
- Man lär sig något nytt hela tiden och kan utbytta kunskaper.
- Lär sig väldigt mycket om eclipse4, alla kan vissa tricks.
Figur 5. Fråga: Har din egen utveckling, som programmerare, gynnats av parprogrammeringen?
Några utvecklare har jobbat för fokuserat på en viss del av koden, vilket resulterat i att de inte har haft en fullständig uppfattning om hur hela systemet har fungerat. Detta kan man
3Spikes är hemuppgifter som delas ut då team har bestämt att de behöver kunskap inom ett område eller verktyg.
Spikesen sammanfattas så att alla i team kan dra lärdom av varandras hemarbeten.
4Eclipse är ett program som programmerare använder sig av för implementering av system vid programvaruutveckling.
0%
10%
20%
30%
40%
50%
1 2 3 4 5 Ej svar
Enkät 1 Enkät 2
8 lösa genom att man tvingar sig själv till arbete med andra uppgifter vid rotation av paren (Williams & Kessler, 2002, s.77-81).
Ett resultat av en studie vid North Carolina State University markerar att parprogrammering inte påverkar studenters prestation negativt (Nagappan, 2003). Vidare visar en studie ifrån University of California UC-Santa Cruz att fler studenter blir godkända på kurser då de parprogrammerat under kursens gång (McDowell, 2002).
4.6 Parprogrammering = teambuilding
De konstanta diskussionerna inom paren, tillsammans med rotering av medarbetare gör att studenterna får tillfälle att på kortare tid lära känna flera i teamet (Williams & Kessler, 2002, s.77). Resultatet blir att fler litar på varandra och man har lättare för att kommunicera och dela med sig av problem (Williams & Kessler, 2002, s.30)(Cockburn & Williams, 2001). En ökning av kommunikationen är positivt för projektet då informations flödet ökar inom teamet.
Figur 6. Fråga: Känner du att parprogrammeringen har hjälpt dig att lära känna dina teammedlemmar snabbare?
Grafen (fig 6) visar på att sådant är även fallet i de teamen som varit med i undersökningen.
- Det är lättare att komma in och bli en grupp när man programmerar i par, känns som att det är lättare att diskutera med andra gruppmedlemmar när man är två också.
En studie vid Unversity of Wales visar på att studenter med låg självsäkerhet är de som gillar parprogrammering mest (Thomas, Ratcliffe & Robertson, 2003). Tillsammans med en kommentar från en utvecklare stärks detta påstående.
- Ingen är rädd för att ta för sig. Tror att vissa är blyga annars, men tar för sig i det här teamet.
4.7 Kompatibilitet - vem passar ihop med vem?
Det finns två signifikanta resultat av parning, båda är på samma kunskapsnivå respektive en är bättre än den andra. Studier visar att över 90% av paren tycker att ens samarbete har varit kompatibelt under arbetet (Katira m.fl., 2004)(Williams m.fl., 2006). Varierande personligheter och olik självsäkerhet är ingen kritisk faktor för kompatibiliteten då par ska sättas ihop (Katira, Williams & Osborne Towards, 2005). I fallet där båda besitter liknande kunskaper blir det sällan problem och det är även den parningen man uppskattar mest som utvecklare (Williams, 2007)(Williams m.fl., 2006).
Mestadels funkar det bra då en duktig och en sämre programmerare har paras ihop. Den bättre hjälper att höja den svaga partnerns kunskapsnivå (Williams & Kessler, 2002, s.61).
Men tyvärr funkar inte alltid detta. T.ex. kommenterar en utvecklare från ett annat team:
0%
10%
20%
30%
40%
50%
60%
70%
1 2 3 4 5 Ej svar
Enkät 1 Enkät 2
9 - Jag klarar inte av att programmera med vissa i gruppen som kan väldigt mycket om programmering, men inte bryr sig speciellt mycket om XP-programmering. För mig är det viktigt att den jag programmerar med är social och kan prata och berätta mycket, eftersom
jag oftast inte är riktigt lika duktig på att programmera.
Av kommentaren verkar det som om några duktiga programmerarna inte har tillämpat XP helt och hållet än. Brist på kommunikation verkar även vara en faktor. En teknik för att lösa det är att ta ifrån tangentbordet från den duktige programmeraren, med andra ord tvinga den att bli navigator. På så sätt måste denne förklara och förmedla, genom kommunikation och diskussion, problemen och lösningar till den nya drivern (Williams & Kessler, 2002, s.155).
Det finns en del duktiga programmerare som alltid vill jobba ensamma, då de tycker att det går för långsamt när de programmerare med någon som är sämre än dem själva (Williams, 2007). Från enkät svar ha det inte förekommit att någon hellre vill arbeta ensam. Som grafen (fig 7) visar är det >50% som besitter liknande kompetens (de som svarat ”Ej svar”). Däremot finns det några duktiga programmerare som upplevt att det gått långsamt, samtidigt som vissa duktiga programmerare tycker det är bra att bli avbruten och bli tvungen att förklara.
Följande kommentarer speglar detta tydligt.
- När detta händer är det tråkigt.
- Jag anser inte att man blir tillbakahållen om man är bättre än sin partner, utan snarare att man får tillfälle att verkligen försöka visa för sig själv att man förstår och kan förklara.
Figur 7. Fråga: Om du anser att du var den bättre programmeraren i paret vid något tillfälle, kände du dig hindrad och tyckte att det gick för långsamt? (Om du inte känt av detta svara “Ej svar”)
Vidare finns problem då den svaga programmeraren har brist på motivation, arbetsmoral och vilja att bli bättre. Detta är ytterst frustrerande för dennes partner. I slut ändan måste alla i teamet vara lagspelare för att teamet ska fungera. Och om en person bara bidrar negativt till teamet, skall denne tas bort (Williams & Kessler, 2002, s.61).
Personer med för dålig självsäkerhet märks tydligt och bör hanteras direkt. T.ex kan man genom parprogrammering och hjälp från teammedlemmar hjälpa denne att bygga upp ett bra självförtroende och god självsäkerhet. Ifall personen inte blir bättre, och att den tynger ner teamet genom att de tvingas jobba övertid, bör denna personen bli omplacerad (Williams &
Kessler, 2002, s.163-165).
Med stor talang kommer ofta ett stort ego. Williams och Kessler tar upp expert-expert problemet, där dåligt samarbete blir ett resultat på grund av två egocentriska individer. Om båda har en “my way or the highway”-inställning kommer problem uppstå. Om man lyckas para två experter kan de lösa de allra största svårigheter och då definitivt vara en tillgång till teamet (Williams & Kessler, 2002, s.99).
0,00%
10,00%
20,00%
30,00%
40,00%
50,00%
60,00%
1 2 3 4 5 Ej svar
Enkät 1 Enkät 2
10
4.8 Rotation
Som vi nämnt tidigare lär sig utvecklarna av varandra, då är det även viktigt att rotera runt mellan paren så att kunskap sprids ännu mer (William & Kessler, 2002, s.81). Frågan är när det är lämpligt att byta partner? Vissa team tycker det är bra att byta varje timme och vid svårigheter efter varje halvtimme (Beck & Andres, 2004). De flesta studenterna som besvarade enkäterna tyckte att det kändes naturligt att göra rotation efter varje story, alternativt efter varje task5 om det var en stor story. Några tyckte det var bra att bli avbruten för att tvingas rotera. Detta i direkt motsats till andra som tyckte det var jobbigt när de var mitt uppe i problemlösandet och var tvungen att lämna något man påbörjat. Det verkar inte finns någon gyllene regel för när man ska rotera, men en kombination av de ovannämnda förslagen är det som teamet, som främst varit under granskning, föredrar.
4.9 Arbetsmiljö
Det har klagats på att laborationslokalen har haft för dålig ventilation och man har efterfrågat större skärmar. Enstaka programmerare påpekar att det hade varit skönt med tillgång till ett litet tyst rum om man behövde koncentrerar sig extra mycket över ett svårt problem. De flesta tycker att det inte varit något problem att sitta tillsammans vid en dator och programmera. Men en person uttrycker sig enligt:
- Arbetsplatsen är inte anpassat. Man måste flytta tangentbord/mus och sträcka sig.
Vid North Carolina State University har man anpassa och byggt upp laborationslokalen för att passa parprogrammeringen perfekt. Den signifikanta skillnaden är att varje dator har två skärmar, två möss och två tangentbord. Detta leder till bättre parprogrammering då paret inte behöver byta plats vid bytet mellan driver och navigator(Williams, 2007).
Sammanfattning
Alla som svarade på enkäterna och deltog i intervjuer var positiva till parprogrammering. Man tycker det är roligare att jobba och kan med hjälp av sin partner lättare hålla sig fokuserad på uppgiften. Arbetet görs effektivare och produkten resulterar i högre kvalité. På grund av samtidig introduktion av många andra XP praktiker har det varit svårt att följa driver och navigator rollerna till fullo. Man har lätt för att kommunicera och diskutera programmerings svårigheter som ställs inför teamet. I och med konsekvent rotation mellan paren lär sig utvecklarna mer om hela systemet och kan på kortare tid bekanta sig med sina teammedlemmar. Kompatibilitet i parprogrammerings paren har inte alltid varit perfekt. Det som främst orsakar detta är då det finns en ansenlig skillnad i kunskapsnivå inom paret.
5Om teamet anser att en story är stor och kräver flera implementations moment, kan denna delas upp i mindre tasks för att underlätta arbetet.
11
Källförteckning
Beck, K., 1999, Embracing Change with Extreme Programming. Computer - Volume 32 Issue 10, October 1999. Los Alamitos, CA: IEEE Computer Society Press. sid. 70-77.
Beck, K. & Andres C., 2004, Extreme Programming Explained: Embrace Change (2nd Edition). Boston, MA: Addison-Wesley Professional.
Chong J. m.fl., 2005, Pair Programming: When and Why it Works. 17th Workshop of the Psychology of Programming Interest Group, Sussex University, June 2005.
Cockburn A. & Williams L., 2001, The Costs and Benefits of Pair Programming. Extreme programming examined 2001.
Katira N. m.fl., 2004, On Understanding Compatibility of Student Pair Programmers, SIGCSE '04 Proceedings of the 35th SIGCSE technical symposium on Computer science education 2004.
Katira N., Williams L. & Osborne Towards J., 2005, Increasing the Compatibility of Student Pair Programmers. ICSE '05 Proceedings of the 27th international conference on Software Engineering 2005.
McDowell C. m.fl., 2002, The effects of pair-programming on performance in an introductory programming course. ACM SIGCSE Bulletin Volume 34 Issue 1, March 2002- Inroads:
paving the way towards excellence in computing education.
Nagappan N. m.fl., 2003, Improving the CS1 Experience with Pair Programming. SIGCSE '03 Proceedings of the 34th SIGCSE technical symposium on Computer science education 2003.
Schwaber K. & Beedle M., 2001, Agile Software Development with Scrum. Upper Saddle River, NJ, USA: Pearson Education, Inc.
Thomas L., Ratcliffe M. & Robertson A., 2003, Code Warriors and Code-a-Phobes:
A Study in Attitude and Pair Programming. ACM SIGCSE Bulletin - Volume 35 Issue 1, January 2003.
Poppendieck M. & Poppendieck T., 2003, Lean Software Development: An Agile Toolkit.
Boston, MA: Addison-Wesley Inc.
Williams L., 2001, Integrating Pair Programming into a Software Development Process.
CSEET '01 Proceedings of the 14th Conference on Software Engineering Education and Training 2001. s.27-36.
Williams L. & Kessler R., 2002. Pair Programming Illuminated. Boston, MA: Pearson Education, Inc.
Williams L. m.fl., 2006, Examining the Compatibility of Student Pair Programmers.
Proceedings of AGILE 2006 Conference (AGILE'06).
Williams L., December 2007, Lessons Learned from Seven Years of Pair Programming at North Carolina State University. ACM SIGCSE Bulletin Volume 39 Issue 4.
