Teori

G.3

Teori

I det här stycket förklaras definitionen av parprogrammering och vad det egentligen innebär. Det presenteras också tidigare undersökningar för framförallt effektiviteten och kvaliteten i jämförelse med att programmera helt individuellt, då resurser till liknade egna undersök- ningar inte finns att tillgå i detta projektarbete.

G.3.1

Parprogrammering

Parprogrammering innebär att medlemmarna i en utvecklingsgrupp arbetar i par under pro- ducerandet av kod. Optimalt fungerar samarbetet som i bilorientering där två personer har olika roller och samarbetar genom de olika ansvarsområdena. Föraren är fokuserad på vägen framför och detaljer. Navigatören däremot läser kartan, kommunicerar ständigt med föraren och har en bra överblick över hela banan. I parprogrammering är föraren den personen som sitter vid tangentbordet, skriver koden och fokuserar på detaljer i koden medan navigatören har bättre överblick över koden och dess helhet. Det krävs kommunikation mellan rollerna för att det skall fungera och i parprogrammering byts helst rollerna ofta så att det blir lättare att förstå varandra. Anledningen till att rollerna är uppdelade på detta sätt är för att en hjär- na inte kan arbeta med både detaljer och intuition/mönstermatchning samtidigt och därför kompletterar föraren och navigatören varandra perfekt[70].

I studien ”The costs and benefits of pair programming”, av datorvetenskapsmannen Alistair Cockburn och doktor Laurie Williams, drar de slutsats att parprogrammering leder till mindre fel, koden blir kortare och att problemen tar kortare tid att lösa. De anser också att man lär sig mer tillsammans då man kan diskuterar och tar åt sig av varandras erfarenheter. Samt så försvinner eventuella nyckelpersoner i projektet då fler personer har kunskap om samma kod[71].

G.3.2

Kombinationer av partners

Viktigt att tänka på när man väljer partner och roll är hur kunskapsklyftorna ser ut inom det område som koden ska skrivas för. Det finns fyra stycken olika kombinationer beroende på om föraren och navigatören är kunnig eller ej. Antingen är både föraren och navigatören kunniga och då fungerar parprogrammering bra, båda kan också vara okunniga och det fun- gerar också bra eftersom både personerna kan lära sig tillsammans. Om däremot navigatören är mer kunnig än föraren så kommer denne att fungera som en guide till föraren och navi- gatören får inte riktigt ut lika mycket utav parprogrammeringen som den hade kunnat. Det värsta fallet dock är när föraren är den som är kunnig men inte navigatören, för då hinner inte navigatören med alls och får inte ut någonting utav samarbetet.[70]

I studien ”Pair programming productivity: Novice–novice vs. expert–expert” av doktor Kim Man Lui och professor Keith C.C Chan utreder de skillnaden i produktivitet för parpro- grammering mellan två programmerare utan erfarenhet och två med erfarenhet mot en in- dividuell programmerare med liknande kunskaper. Här visar sig det att parprogrammering är effektivare än en individuell programmerare om programmet är utmanande och program- merarna inte besitter några större erfarenheter av den typen av programmering. Men när erfarenheten och kunskapen stiger så kommer den individuella programmeraren ifatt och resultaten blir i princip omärkbara om inte den individuella blir något effektivare[72].

G.4

Metod

Det första som utfördes i skapandet av denna utredning var att som kvalitetssamordnare ut- bildade mig själv i parprogrammering och lärde sedan ut till projektgruppen. Detta utfördes för att projektgruppen strikt skulle använda sig av den metod som är definierad som parpro- grammmering.

G.5. Resultat

Efter att gruppen utbildats i observerades arbetet under projektets gång då det funnits tillfällen som projektgruppen arbetat både med och utan parprogrammering. Efter att kon- struktionsfasen var över i projektet utfördes en utvärdering av parprogrammering i gruppen med hjälp av en enkät, se bilaga G.A. Enkäterna utfördes anonymt av medlemmarna i pro- jektgruppen för att eliminera påverkan av varandra och så att svar om samarbeten som inte fungerat inte skulle censureras. Anledning till att enkäten enbart utfördes i projektgruppen var för att observation skett och det var säkert att gruppen arbetat efter den definition pre- senterats i avsnitt G.3.1 ovan. En bredare enkätundersökning i större grupp hade eventuellt minskat kvaliteten på utvärderingen då olika former av parprogrammering kunnat utnyttjas och därför utfördes enkätundersökningen enbart inom projektgruppen.

När resultat tagits fram med hjälp av enkäten jämfördes detta med två stycken studier för att med hjälp av dessa två dra slutsatser om parprogrammering. De studier som användes presenteras i listan nedan.

• Studie 1: ”The costs and benefits of pair programming”[71]

• Studie 2: ”Pair programming productivity: Novice–novice vs. expert–expert”[72] Studie 1 valdes på grund av att den bearbetar parprogrammering från många olika per- spektiv som till exempel effektivitet, kvalitet och kostnad. Skaparna av studien gav också studien hög trovärdighet och var därför lämplig till utredningen.

Studie 2 användes huvudsakligen för att samla information om när parprogrammering inte passar att användas som kvalitetsåtgärd i ett projekt. Även skaparna av denna studie gav hög trovärdighet och gav studien ett pålitligt intryck.

G.5

Resultat

I den utvärdering som utfördes med projektgruppen visades en stor spridning på hur sto- ra programmeringskunskaper de själva ansåg sig besitta. I figur G.1 nedan syns resultatet av frågan ”Hur skicklig programmerare anser du dig själv vara på en skala från 1 till 5?” från enkäten. Figuren visar att av sex personer som svarat så tycker två personer att de be- sitter kunskaper av en 3:a, tre personer tycker att de besitter kunskaper av en 4:a och en person tycker att denne besitter kunskaper av en 5:a. Det är stor spridning av kunskaper i projektgruppen. Trots denna spridning så tyckte fem av sex medlemmar att personen som de parprogrammerade med hade liknande programmeringskunskaper som sig själv. Den sjätte personen tyckte att personen som denne samarbetat med besatt högre kunskaper än sig själv men förklarade sig att det hade gått bra i alla fall då personen hade tagit sig tiden att förklara under arbetets gång. Eftersom resterande tyckte att sina partners hade besuttit liknande pro- grammeringskunskaper tas slutsatsen att den andra personen inte störde sig på detta eller kände sig skickligare. Dock skrev en av medlemmarna att parprogrammering med en person som är sämre än en själv lätt kan leda till frustration om det är den personen som sitter vid tangentbordet och därför inte passa så bra att utnyttja i sådana fall.

G.5. Resultat

Figur G.1: Tabell över hur skicklig varje person ansåg sig vara med antalet personer i Y-led utifrån enkäten.

På frågan i enkäten om man tyckte att parprogrammeringen gjorde arbetet effektivare tidsmässigt blev svaren splittrade femtio femtio mellan att effektiviteten var den samma som om man hade utfört arbetet själv och att det hade varit effektivare att göra arbetet själv istäl- let för att parprogrammera, se figur G.2. Det var ingen som trodde att parprogrammeringen gjorde arbetet effektivare rent tidsmässigt. Men i frågan om man tyckte att kvaliteten på ar- betet ökade med hjälp av parprogrammering var det fyra av sex som höll med. De resterande två personerna tyckte att det inte hade spelat någon roll, se figur G.3. Det var alltså perso- ner som tyckte att effektiviteten minskade men att kvaliteten ökade i arbetet på grund av parprogrammering.

Figur G.2: Diagram över hur projektmedlemmarna tyckte att effektiviteten påverkades av parprogrammering utifrån enkäten

G.5. Resultat

Figur G.3: Diagram över hur projektmedlemmarna tyckte att kvalitén av arbetet påverkades av parprogrammering utifrån enkäten

Enligt enkäten tyckte alla i projektgruppen att parprogrammering bidrog till en produkt av högre kvalitet. Det var mycket åsikter och teorier om varför som det bidrog till ökad kva- litet. Det upplevdes att koden som producerades blev mer noggrann när den producerades i par, att man fick fler synvinklar till problem så att den optimala lösningen lättare kunde hittas och att många fel och buggar kunde hittas redan vid arbetet istället för vid kodgransk- ningen efteråt. Det var som att granska koden medan den skrevs. Det upplevdes även roli- gare/trevligare att arbeta tillsammans med någon och även om antalet kodrader per timme minskade mot om man hade arbetat individuellt ökar kvaliteten markant på grund av par- programmering.

Enligt enkäten var gruppen också generellt positiva till parprogrammering och hittade inte många tillfällen då parprogrammering fungerar dåligt mer än om sin partner skulle vara mindre skicklig än sig själv som nämndes ovan. De observationer som skedde under projektet gav också intrycket att det fungerade bra.

Som kvalitetssamordnare upptäcktes det att de kodgranskningar som användes i projek- tet och varit obligatoriska för all kod i projektet nästan inte behövdes. Istället för att hitta några större fel eller buggar fick granskaren vara petig för att hitta några fel och dessa hade sällan någon påverkan på programmets funktionalitet utan oftast avsaknad av kommenta- rer eller liknande. Det var också sällan någon under kodgranskningen kunde peka på en funktion och se hur den hade kunnat bli annorlunda eller bättre gjord. Med andra ord så upplevdes det alltså som att kvaliteten på lösningarna var högre. Detta stämmer även ihop med studien av Cockburn och Williams som presenterades i avsnitt G.3.1, då de också fick resultatet att det var högre kvalitet på koden samt att den blev mera genomtänkt i form av att det var färre buggar och koden blev generellt kortare med samma funktionalitet.

I observationerna upplevdes det att kommunikationen i gruppen ökade och det blev en öppnare och bättre miljö att arbeta i. Det upplevdes också att det ledde till att kvaliteten på arbetet ökade så att om någon person var frånvarande så gick det fortfarande att arbeta vidare på koden. Parprogrammeringen tog alltså bort mycket utav beroendet utav vissa fåtal personer, även kallade nyckelpersoner, och projektet kunde fortsätta utan dessa. Även detta med nyckelpersoner tar Cockburn och Williams upp i deras studie.

Den största skillnaden mellan de två studierna som valdes att inkluderas i undersökning- en är att de ser på parprogrammeringen från effektivitet eller kvalitet. Om två personer inte

G.6. Diskussion

än att arbeta själv enligt Lui och Chan. Men om erfarenheten är stor och utmaning är liten är parprogrammering inte effektivare än individuell programmering. Dock tar den studien inte hänsyn till om det ändå kan vara värt att använda sig av parprogrammering för kvalitetens skull vilket upplevts under projektet. Enligt Cockburn och Williams är beslutet om parpro- grammering ska utnyttjas rent resursmässigt i tid och lönekostnader. Dessa resurser har dock inte varit något problem inom projektet.

G.6

Diskussion

Det är intressant hur näst intill alla medlemmar tyckte att personen man arbetade med besatt liknande kunskaper som en själv medan alla personer satte sig själva så spritt i intervallet 1-5 på hur skicklig man ansåg sig vara på programmering. Det skulle kunna bero på att man underskattar sig själv när man skall sätta betyg på sig själv. Det skulle även kunna bero på att man inte märker av mindre skillnaderna så mycket. Utifrån utvärderingen skulle man också kunna tro att den som ansåg sig vara en 5:a på skalan förmodligen inte arbetat med någon utav de personerna som ansett sig vara en 3:a, då detta förmodligen hade påverkat samarbetet mer enligt de kombinationer som nämns i teoriavsnittet G.3 ovan. Det är därför svårt att dra för stora slutsatser om när parprogrammering inte passar i projektet utifrån projektgruppens erfarenheter.

Eftersom gruppen inte tyckte att arbetet blev något effektivare beror detta förmodligen på att programmeringen inte var utmanande nog för att höja effektiviteten. Eftersom vi dock inte hade några större begränsningar i projektet resursmässigt tror jag att detta är anledningen till att det aldrig upplevdes som att parprogrammeringen var överflödig eller onödig att utnyttja och utvärderings svar var så positiva.

Det finns inte mycket att argumentera emot att parprogrammering leder till en produkt av högre kvalitet då både resultaten från enkäten och observationer samt enligt ”The costs and benefits of pair programming” enbart visade positiva sidor. Jag tror att det till störta del beror på att koden hela tiden granskas under skrivandet och att paret diskuterar lösningarna ihop.

Anledningen till att alla projektmedlemmar inte höll med om att arbetet ökade i kvalitet var förmodligen av anledningen att de även tyckte att parprogrammeringen tog lite mer tid eller lika mycket som att arbeta individuellt. Eftersom ingen tyckte att arbetet blev effektivare jag tror jag att det var det sociala samt kommunikationen som gjorde att det fortfarande var vissa projektmedlemmar tyckte att arbetet ökade i kvalitet. Samt att nyckelpersoner elimine- rades.

De som tyckte att det det både ökade och minskade kvaliteten på arbetet tror jag beror på att det ibland blev mindre fokuserat och tillfälle gavs att istället prata om saker som är oväsentligt för projektet. Anledningen till att projektmedlemmarna tyckte att parprogram- meringen inte var effektivare kan också vara, på grund av det som nämdes tidigare, att pro- grammeringen inte var utmanande nog för att parprogrammeringen skulle hjälpa med tanke på det resultat som Lui och Chan presenterade.

G.7

Slutsats

Parprogrammering passar inte att använda som kvalitetsåtgärd i ett utvecklingsprojekt om personen man arbetar med är föraren och besitter lägre kunskaper än sig själv då det leder till frustration. Det är också mindre lämpligt att använda om det finns brist på resurser så som tid och lönekostnader samt om programmeringen inte är utmanande nog.

Parprogrammering leder till högre kvalitet på produkten genom att metoden producerar mer genomtänkta lösningar till problem då två personer kan diskutera och se problem från olika synvinklar. Koden granskas samtidigt som den skrivs då enbart en person kan sitta

G.7. Slutsats

vid tangentbordet åt gången vilket leder till att färre buggar följer med så långt som till den färdiga produkten.

Parprogrammering leder även till högre kvalitet på arbetet i en projektgrupp genom att paren inte har något annat val än att samarbeta, vilket stimulerar och höjer kommunikationen inom projektgruppen. Det tar även bort beroende av vissa nyckelpersoner då det alltid finns minst två personer som kan och förstår sig på samma kod och därför så drabbas inte arbetet lika mycket om någon person skulle vara frånvarande. Dock så kräver parprogrammering lite mera tid än att programmera individuellt om programmeringen inte är så svår men mycket av detta sparas in i granskning, testning och att leta buggar i systemet då produkten är av högre kvalitet.

Slutsatsen som man kan dras utifrån detta är att så länge kvalitet är ett viktigt attribut att uppnå så är parprogrammering något att rekommendera till i stort sätt alla projektarbeten. Det är även en bra metod till en projektgrupp där personerna inte känner varandra från början då det öppnar upp för kommunikation. Men bör undvika mellan personer som har alldeles för stora kunskapsklyftor eller till projekt där bara enklare prototyper skall skapas och kvalitet inte är det högsta målet.