Virtuell parprogrammering i relation till en agil arbetsmetodik

Uppsatsarbete 15hp Handledare: Andreas Ask HT18, 11/1-2019

Virtuell parprogrammering i relation till en

agil arbetsmetodik

Axel Jörgensson Felicia Sjögren

2 Sammanfattning

Denna studie handlar om vilka potentiella problem man kan stöta på vid en implementation av virtuell parprogrammering i relation till en agil arbetsmetodik. Den tidigare klassiska parprogrammeringen som varit begränsad till ett fysiskt utrymme för de båda utvecklarna är nu borta och nya möjligheter finns att utforska. Studiens resultat riktar sig främst till människor som arbetar agilt inom systemutveckling och är intresserade av att lägga till den virtuella aspekten till parprogrammering, men den är även riktad generellt till människor som arbetar agilt inom mjukvaruutvecklingsbranschen. Studien är avgränsad till virtuella maskiner till skillnad från andra lösningar som till exempel skärmdelning eftersom att det idag börjar bli mer och mer populärt med virtuella lösningar. Kommunikation är ett centralt begrepp genomgående i studien eftersom det har visat sig vara grunden för att parprogrammering ska vara optimalt, både virtuellt och klassiskt sett. Studien är en kvalitativ litteraturstudie som syftar till att lägga en grund för vidare forskning inom ämnet men även väcka ett större intresse för virtuella maskiner inom agila arbetsmetodologier. Empiriska data har även samlats in i mindre skala för att styrka de slutsatser som dragits. En konceptuell modell presenteras i slutet av studien för att lyfta argumenten för de identifierade potentiella problemen vid virtuell parprogrammering.

Nyckelord: agil arbetsmetodik, extreme programming, parprogrammering, virtuell maskin, virtuell parprogrammering, kommunikation

3

Innehåll

Begreppslista ... 5

1. Introduktion ... 6

1.1 Bakgrund ... 6

1.2 Syfte & frågeställning ... 7

1.3 Avgränsning ... 7

1.4 Intressenter ... 8

1.5 Disposition ... 8

2. Teori ... 8

2.1 Agil arbetsmetodik ... 8

2.2 Uppdatering av det agila manifestet ... 9

2.3 Extreme Programming ... 10

2.4 Parprogrammering ... 10

2.5 Virtuell parprogrammering ... 11

2.6 Molntjänster ... 12

2.7 Virtuell maskin ... 12

2.7.1 Molnbaserad virtuell maskin ... 12

3. Metod ... 13 3.1 Litteratur ... 13 3.2 Intervju ... 14 3.3 Analysmetod ... 14 3.4 Metodkritik ... 16 3.5 Källkritik ... 16

4. Analys och resultat ... 17

4.1 Agil arbetsmetodik ... 17 4.2 Extreme Programming ... 18 4.3 Parprogrammering ... 18 4.4 Virtuell parprogrammering ... 19 4.5 Resultat av intervju ... 20 4.5.1 Virtuell parprogrammering ... 20 4.5.2 Agil arbetsmetodik ... 21 4.5.3 Parprogrammering ... 21 4.5.4 Virtuell parprogrammering ... 21

4

4.6 Sammanfattning av analys ... 22

5. Diskussion ... 24

6. Slutsats och bidrag ... 26

7. Referenser ... 27

Bilagor ... 30

Bilaga 1 – Intervjumall ... 30

5

Begreppslista

Agil coach: En agil coach är en person som hjälper och vägleder utvecklare att antingen skifta till eller förbättra ett agilt arbetssätt. (Benefield, 2008)

Dator: En dator är ett system av ihopsatta komponenter; hårdvara, som hanterar olika uppgifter men arbetar tillsammans. (Microsoft, 2013)

Hårdvara: Är de fysiska delarna som en dator är uppbyggd av som till exempel moderkort, processor och grafikkort. Även skärm, mus och tangentbord tillhör hårdvara. (Microsoft, 2013) Klassisk parprogrammering: Är en agil systemutvecklings teknik, två personer programmerar tillsammans på en dator. En person kodar, hen brukar kallas för förare. Den andra personen brukar kallas för navigatör, hen granskar koden under tiden föraren kodar. Rollerna skiftar frekvent under perioden man parprogrammerar. (Williams, 2001)

Mjukvara: Mjukvara är program som körs av datorn, det finns olika typer av mjukvara som till exempel applikationsmjukvara, systemmjukvara och operativsystem. Applikationer är program som användaren har direkt nytta av och använder sig av, systemmjukvara är den mjukvara som möjliggör att datorn kan köra applikationer. (TechTarget, 2006)

Objektorienterad programmeringskurs: Är en kurs inom objektorienterad programmering. Objektorienterad programmering är en metod som används vid programmering, program som är utvecklade på detta sätt innehåller en uppsättning av objekt som interagerar med varandra. (Kindler & Krivy, 2011)

Operativsystem: Är det programmet som först körs av en dator vid start, detta program hanterar alla de andra program som sedan körs på datorn. Även hjälpmedel som mus och tangentbord och hur dessa interagerar med datorn styrs av operativsystemet. Alla de största datorplattformarna kräver ett sådant program för att köras. (Nationalencyklopedin, 2019) Scrum: Scrum är ett agilt ramverk för systemutveckling. Designen går ut på att bryta ner arbete i små uppgifter och sätta en tidsram för varje uppgift. Detta gör att man kan se hur lång tid det kan tänkas ta att lösa hela projektet och blir enkelt att få en uppfattning om hur långt man har kommit eller hur långt man har kvar. (Azanha et. al, 2017)

Scrum master: Är en föreståndare inom Scrum som har som ansvar att projektet genomförs med rätt praktiker, värde och regler, samt säkerställer att projektet avancerar i rätt riktning. (Azanha et. al, 2017)

Virtuell parprogrammering: I denna studie definierar vi virtuell parprogrammering som parprogrammering på distans vilken uppnås genom virtuella maskiner.

6

1. Introduktion

Extreme Programming är ett agilt ramverk för mjukvaruutveckling där målet är att producera högkvalitativ kod och skapa ett kvalitativt liv för utvecklingsteamen. Inom ramverket finns en praktik som särskilt syftar till att producera högkvalitativ kod, nämligen parprogrammering. Med parprogrammering kommer många fördelar som till exempel enklare problemlösning och högkvalitativ kod. (Agile Alliance, 2019) Williams och Kessler (2000) uttrycker följande om parprogrammering: ”It is amazing to see how many obvious, yet unnoticed, defects are recognized when another person it watching over a shoulder.” Därför vill vi lyfta frågan: Vad händer när man tar bort den fysiska begränsningen och flyttar över parprogrammering till en virtuell arbetsmiljö? Vilka potentiella problem behöver man ta ställning till?

Virtuella maskiner gör det idag möjligt för två personer att parprogrammera utan att vistas i samma fysiska miljö, utan istället vistas i en virtuell arbetsmiljö. Flor (2006) konstaterar hur företag börjar anställa personal globalt och belyser skillnader mellan klassisk parprogrammering och virtuell parprogrammering. Vi tycker därför att det är intressant att söka och presentera de eventuella problem som kan uppkomma i samband med ett agilt arbetssätt, eftersom det agila manifestet bl.a. betonar hur människor och interaktioner ska värderas över processer och verktyg (Ambler, 2002).

Denna kvalitativa litteraturstudie tar en ansats ur den nuvarande forskningen kring ämnet i syfte att skapa en bas för vidare forskning. Det nuvarande empiriska materialet gällande kontexten av virtuell parprogrammering uppfattas som väldigt tunt enligt Satratzemi et. al (2018) och vi delar denna uppfattningen. Även Aiken (2004) betonar hur ytterligare forskning angående parprogrammering på distans är nödvändig. Den litteratur som bedömts vara relevant av oss och som därmed undersöks under denna studie är därför inte omfattande.

1.1 Bakgrund

Sedan 1950-talet har datasystem utvecklats och mycket av arbetssättet har förändrats på vägen gällande både teknik och metod. Sent på 90-talet medförde internet helt nya krav på hur datasystemlösningar ska byggas och tillhandahållas samtidigt som arbetsmiljöerna blev alltmer varierade. (Wiktorin, 2003) Idag är det till exempel vanligt att en utvecklingsmiljö är virtuell, det vill säga att man inte längre är bunden till en fysisk dator, att man arbetar med minimal dokumentation och har en större flexibilitet i sitt arbete. Vanliga problem inom systemutvecklingsprojekt är att de kostar mycket tid och pengar samt bristande kvalitet (Wiktorin, 2003) men med hjälp av virtuella verktyg kan dessa faktorer kontrolleras på ett nytt sätt än tidigare. Idag är det till exempel vanligt att företag anställer personal på en global nivå där samarbetet endast sker över internet (Flor, 2006). På grund av den hårda konkurrensen inom systemutvecklingsbranschen har fokuset skiftats till arbetsprocessen snarare än på vilket sätt en arbetsuppgift blir utförd på som svar på kraven på förändringar i arbetssätten (Wiktorin, 2003). Att arbeta agilt innebär att skapa och svara på förändring för att vara framgångsrik i en osäker och turbulent miljö. Agil mjukvaruutveckling fungerar som en paraplyterm för en uppsättning metoder och praktiker som baseras på det agila manifestet. En av dessa praktiker är Extreme Programming som fokuserar på bland annat kommunikation, simplicitet och återkoppling. (Agile Alliance, 2019) Inom Extreme Programming utvecklar man kod tillsammans i par

7 (Eiderbäck, 2007) och i enlighet med praktiken bör man sitta tillsammans i samma utrymme eftersom att kommunikation är väldigt viktigt (Agile Alliance, 2019). Zarb och Hughes (2015) påpekar vikten av effektiv kommunikation inom parprogrammering och att den kan ta både verbal och icke-verbal form.

Att vara två användare samtidigt på en dator är idag möjligt och detta kan möjliggöras genom att använda en virtuell maskin. Genom att man skapar olika användare till den virtuella maskinen kan de tillåtas vara inloggade samtidigt. För att göra det möjligt, att tillåta dem vara inloggade samtidigt, måste dock alla användare som vill vara inne samtidigt ha administratörs-åtkomst till den virtuella maskinen, detta ges användarna vid samma tillfälle där man skapar de olika användarna. (wikiHow, 2018) Detta skapar möjligheten att placera en dator i till exempel en molntjänst och därmed parprogrammera via varsin dator men ha koden upp på en virtuell dator i molnet.

1.2 Syfte & frågeställning

Syftet med denna studie är att undersöka och beskriva vilka eventuella problem som kan uppstå vid virtuell parprogrammering i relation till den agila arbetsmetodiken. Frågeställningen blir således:

FF: Vilka potentiella problem kan uppkomma i samband med virtuell parprogrammering och hur påverkas relationen till den agila arbetsmetodiken?

Tidigare forskning tar upp vad som krävs för att fördelar med parprogrammering ska kunna speglas i parprogrammering på distans samt vilka positiva effekter som kan utvinnas ur parprogrammering. Flor och Hutchins (1991) observerar till exempel att kommunikation mellan två samarbetande programmerare signifikant reducerar risken för dålig design på ett mjukvaruprojekt. Däremot så kan kommunikationen inom ett par även vara ett problem i det fall båda programmerarna är nybörjare (Zarb & Hughes, 2015). Flor (2006) påpekar också att par som programmerar tillsammans på distans behöver skapa samma förutsättningar som par vid samma skärm för att kunna ta del av samma egenskaper. Vi har inte funnit tidigare forskning som behandlar vilka potentiella problem som kan uppstå när ett par programmerar i en virtuell miljö samt hur detta eventuellt skulle påverka den agila arbetsmetodiken. Här ser vi ett kunskapsbehov som behöver fyllas eftersom att virtuella arbetsmiljöer blir alltmer populärt samtidigt som parprogrammering är ett effektivt verktyg i skapandet av högkvalitativ kod. Med högkvalitativ kod menas kod som inte behöver vidare granskning eftersom det görs kontinuerligt medan ett par programmerar samt att mindre kod krävs för att utföra uppgiften (Agile Alliance, 2019). Företag anställer till exempel människor över hela världen som arbetar tillsammans endast genom internet och att kunna häva den fysiska begränsningen kan anses som en attraktiv möjlighet eftersom det öppnar upp för nya kombinationer av par för att programmera. Genom att undersöka eventuella problem kan bättre förberedelser göras i det fall en aktör vill applicera ett nytt arbetssätt inom sin organisation.

1.3 Avgränsning

Denna studie fokuserar endast på parprogrammering på distans som möjliggörs genom virtuella maskiner, det vill säga vi avgränsar oss från övriga leverantörer som möjliggör virtuell parprogrammering genom skärmdelning, som till exempel Skype och TeamViewer. Därmed

8 blir virtuell parprogrammering synonymt med parprogrammering på distans i denna studie då olika termer använts för samma sak i olika studier. Vi kommer att titta på parprogrammering endast utifrån Extreme Programming eftersom att det är det mest specifika agila ramverket gällande lämpliga praktiker för mjukvaruutveckling (Agile Alliance, 2019). Med virtuell maskin avser vi både sådan som kan skapas på egen lokal dator samt sådan som kan skapas med hjälp av molntjänster. För att identifiera potentiella problem som kan uppkomma i samband med virtuell parprogrammering och hur relationen påverkas till en agil arbetsmetodik har vi valt att titta på bland annat fördelar, kritiska faktorer och nödvändigheter som behövs för att optimera klassisk samt virtuell parprogrammering för att sedan tolka vad som händer i det fall en faktor tas bort eller inte uppfylls till exempel.

1.4 Intressenter

Denna studie är ämnad för intressenter som arbetar agilt och är intresserade av virtuella arbetsmiljöer i samband med parprogrammering. I synnerhet är den riktad till en målgrupp som är intresserad av parprogrammering som möjliggörs genom virtuella maskiner och vilka eventuella problem man behöver ta i beaktning vid en implementation.

1.5 Disposition

Studiens struktur ser ut på följande sätt.

Teoriavsnittet tar upp tidigare forskning samt teori om utvalda koncept. Metodavsnittet beskriver hur vi gått tillväga i våra litteratursökningar och varför vi valt att även addera en intervju som empiriskt material till studien. Avsnittet resultat och analys sammanställer våra sökningar och även där beskriver vi tidigare forskning. Att tidigare forskning ligger både i teoriavsnittet och resultatavsnittet är ett medvetet val av oss som författare för att det enligt oss ökar läsbarheten. Under diskussion (avsnitt 5) kommer en konceptuell modell att presenteras för att tydligt redogöra vilket resultat som uppnåtts med studien. Vi anser att den lyfter vår diskussion till den nivå vi vill diskutera resultat och analys. Avsnitt 6 (slutsats och bidrag) avslutar vår studie genom att beskriva vad vårt resultat innebär och vad det bidrar till.

2. Teori

2.1 Agil arbetsmetodik

I mitten på 90-talet gällde tung utvecklingsmetodik med innehållande komplett kravdokumentation tillsammans med arkitektur och design följt av kodning och testning vilka baserades på en noggrann testplan för att undvika problem inom mjukvaruutvecklingsprojekt. Tanken med detta var att det skulle bli rätt från första försöket och den gemensamma tron bland ingenjörer inom mjukvaruutveckling var att projekt undviker problem när de strikt håller sig till en metodik. Detta var dock i de flesta fall inte överensstämmande med verkligheten. (Williams, 2012)

Ambler (2002) menar att praktikerna under denna tid handlade om att leverera det mjukvaruutvecklarna själva ville leverera och inte det kunden bad om och orsakerna bakom detta var ett antal problem som behövde åtgärdas. Under samma tid slog sig ett antal andra aktörer inom industrin samman för att överkomma dessa utmaningar (Williams, 2012). Initialt var de en grupp på 17 metodologister vilka tillsammans i februari 2001 formade the Agile

9 Software Development Alliance, som ofta refereras till som den agila alliansen. Denna grupp, sammansatt av aktörer av olika bakgrunder, upprättade en manifest för att uppmuntra till bättre sätt att utveckla mjukvara. Baserat på detta manifest formulerades sedan en samling principer som skulle definiera kriteriet för en agil utvecklingsprocess så som agil modellering. (Ambler, 2002)

Det agila manifestet definieras genom fyra enkla och värdefulla uttalanden:

• Individer och interaktioner framför processer och verktyg

• Fungerande mjukvara framför omfattande dokumentation

• Kundsamarbete framför kontraktsförhandling

• Anpassning till förändring framför att följa en plan

Viktigt att förstå här är att trots det som står till höger ska värderas så ska det som står till vänster värderas ännu mer. Det agila manifestet bör inte ses som något som definierar alternativ utan snarare preferenser och som därmed uppmuntrar ett fokus på vissa områden men samtidigt inte eliminerar andra. (Ambler, 2002) För att bygga mjukvarusystem arbetar människor i team och de behöver arbeta effektivt tillsammans med andra aktörer som till exempel programmerare, testare, projektledare, kunder etc. Detta är något som inte kan möjliggöras med enbart de bästa processerna och verktygen man kan få tag i, utan man behöver beakta de viktigaste faktorerna vilket är människorna och hur de arbetar tillsammans. (Ambler, 2002)

Bakom det agila manifestet finns tolv principer vilka verkar som ledsagande praktiker för arbetsteam som vill vara agila. Princip nummer fyra belyser hur affärsmänniskor och utvecklare dagligen måste arbeta tillsammans under hela dagen och princip nummer sex säger att den mest effektiva och produktiva metoden för att överföra information till och inom ett utvecklingsteam är kommunikation ansikte mot ansikte. Princip nummer fem beskriver hur projekt ska byggas runt motiverade individer och att de ska få den miljö samt tillit de behöver för att uppfylla sina arbetsuppgifter. (Agile Alliance, 2019)

2.2 Uppdatering av det agila manifestet

En av de sju metodologisterna som formade det agila manifestet, Kent Beck, påpekade 2010 att trots det agila manifestet var ett gigantiskt steg framåt under 2001 så behövs en uppdatering (Denning, 2015). Segmentet ”individer och interaktioner framför processer och verktyg” uppdaterar Beck med ”teamvision och disciplin framför individer och interaktioner framför processer och verktyg”. Trots att det var ett stort steg framåt under 2001 att inse att individer och hur de interagerar med varandra är viktigare än att följa en viss process konkluderar Beck att inom nya affärsområden räcker detta inte till. (Denning, 2015) Beck menar att istället för att var enskild individ i ett team ska fundera på hur bra arbete jag utför ska man tänka på hur bra arbete vi utför. Implikationerna för detta är att ibland behöver en individ göra mindre än vad denne tror behövs göras för att teamet ska lyckas bättre i att nå sina mål. I det fall en individ objektivt vet en optimal teknik på en problemlösning, men resten av teamet inte förstår den, kan det vara bättre att denna individ lägger tekniken åt sidan så att teamet i helhet kan bli mer produktivt. Beck tror att teamvision och disciplin som sträcker sig bortom individuell

10 optimering är nödvändig för att vara så produktiva som möjligt tillsammans, eftersom individinteraktion har en tendens att optimera sin egen prestation. (Denning, 2015)

2.3 Extreme Programming

Utveckling av mjukvara är en mänsklig aktivitet och därför måste den mänskliga dimensionen vara i centrum när det diskuteras hur en mjukvara ska göras mer effektivt. Eftersom människor arbetar i team och alla dessa har sin egen dynamik beroende på vilka som ingår i gruppen finns det ett syfte med att skapa medvetenhet kring detta. (Holecombe, 2008) Den bakomliggande anledningen är helt enkelt att det gör teamet mer effektivt eftersom fördelar kan hämtas ur de positiva aspekterna samtidigt som kontrollen ökar på de eventuellt negativa delarna. Människor tänker och känner olika om saker och ting, till exempel deras arbetsmiljö, relationer, förhoppningar och farhågor. Att se människor som egna individer och att respektera detta är en grundpelare vilken Extreme Programming är uppbyggt på. (Holecombe, 2008)

Inom Extreme Programming vill man tänka på värde och dess kostnad i tid och pengar på ett mer holistiskt sätt, det vill säga att helheten är värd mer än delarna tillsammans och ingenting kan beskrivas utan dess kontext (Holecombe, 2008) Dessa kommer att vara kärnan av arbetet och en nyckelmekanism för att hålla dessa tre delar tillsammans är att ta sig framåt i väldigt små steg. Detta innebär att man tydligare kan se hur var och ens arbete går och om man kan kombinera detta med vart man är på väg. (Holecombe, 2008)

Att addera värde och sedan demonstrera detta är vad som bör vara målet genom hela processen. Hur detta uppnås kan ses genom att man upprätthåller en konstant relation med varandra - utvecklare, kunder och chefer - hela tiden. Här är kommunikation nyckeln, man ska prata med varandra, visa vad man gjort, diskutera vart man är på väg, hjälpa varandra, hålla relationerna positiva. (Holecombe, 2008)

Ett övergripande tema är aktivitetsflödet. Man fokuserar på att frekvent släppa små bitar av kod som kan visa ett värde till projektet; man reflekterar över vad som har hänt ofta; man svarar positivt på motgångar som ska förbättra förståelsen av utvecklingsprocessen och av professionella och personliga förmågor; man ska främja diskussion och delandet av perspektiv och kunskap; och man ska försöka förbättra sig själv, teamet och organisationen bit för bit. Dessa fundamentala principer leder till ett antal värden som ska forma basen av Extreme Programming: god kommunikation, simplicitet, återkoppling, mod och respekt. (Holecombe, 2008)

2.4 Parprogrammering

Under programmeringsfasen arbetar man parvis inom Extreme Programming, det vill säga två utvecklare tillsammans. Man arbetar med den ena programmerarens uppgifter tillsammans och man kan när man vill byta plats vid tangentbordet (Eiderbäck, 2007). Den som skriver in koden kan kallas för förare medan den som sitter bredvid kallas för navigatör. Föraren letar upp problemen från ett taktiskt perspektiv medan navigatören tänker strategiskt, ställer frågor och letar efter fel i koden. (Aiken, 2004) Det går även bra att byta partner och/eller arbetsuppgifter. Steg ett är att tillsammans fundera ut på vilket sätt koden ska testas, och det viktigaste är att båda utvecklarna deltar i tankeprocessen. Fördelen med att arbeta i par på detta vis är bl.a. att

11 den som inte sitter och skriver kod får det enklare att fundera på struktur och tester men även helheten. (Eiderbäck, 2007) Fler fördelar med detta sätt att arbeta är:

• man kan komplettera varandra eftersom man har olika erfarenheter och grad av kunskap.

• man kan fundera ut tester bättre och se till att de verkligen genomförs.

• eftersom minst två personer måste förstå sig på koden ökar detta sannolikheten för att koden struktureras väl och blir lättförståelig.

• möjlighet för personer att agera som mentorer inom organisationen och därmed bredda kunskapen.

• ett sätt säkerställa att tester och omstrukturering som process verkligen utförs. (Eiderbäck, 2007)

• koden exponeras konstant för granskning (Aiken, 2004).

Parprogrammering är även en väldigt kommunkationsintensiv process vilken består av både verbal och icke-verbal form av kommunikation. Effektiv kommunikation är av största vikt inom par och för långa perioder av tystnad är en varningssignal. (Zarb & Hughes, 2015) Zarb och Hughes (2015) konstaterar att flera studier har konkluderat att en uppenbar framgång inom parprogrammering handlar om graden av kommunikation som denna arbetsteknik behöver. Inom professionella relationer finns en nödvändighet för konstant kommunikation och denna nödvändighet kan även ses inom parprogrammering (Watzlawick, Bavelas & Jackson, 1967). Flor och Hutchins (1991) observerar att kommunikation som utbytandet av idéer, feedback och konstant diskussion inom ett par signifikant reducerar sannolikheten för en dålig design. Kommunikation betraktas som en avgörande aspekt inom parprogrammering (Lindvall et at., 2002) och enligt Beck (2000) är det första värdet av parprogrammering kommunikation och att standarden inom programmering bör betona detta. Inte mer än en minut av tystnad bör passera medan man parprogrammerar (Aiken, 2004).

Aiken (2004) skriver att det kan vara problematiskt att skapa par inom systemutveckling. I en studie som Williams och Kessler (2003) gjort kommer dem fram till att många utvecklare är mer introverta än extroverta, eftersom att kommunikationen är en så stor och viktig del i parprogrammering kan detta skapa problem. Utvecklare som är vana vid att koda ensamma som blir satta i par och programmerar kan vara rädda för att göra fel och blir mindre kreativa och har då en motsatt effekt än vad parprogrammering är tänkt att ha. Effektiviteten i kodningen blir sämre och skapar dålig stämning. (Aiken 2004)

2.5 Virtuell parprogrammering

Inom den agila mjukvaruutvecklingsmetodiken Extreme Programming är parprogrammering en kärnpraktik. Det är viktigt att förstå att fördelarna med parprogrammering härrör ur egenskaper som uppstår när två personer arbetar sida vid sida i nära anslutning till varandra. Par söker alternativ ur ett större utrymme och det är just denna egenskap som gör det möjligt för par att producera mer optimala lösningar i jämförelse med individer som arbetar ensamma. (Flor, 2006) Det finns ett antal egenskaper som ömsesidigt förstärker varandra och som främjar egenskaper som att söka alternativ ur ett större utrymme. Dessa är: effektiv kommunikation;

12 den löpande delningen av mål och planer; förenad produktion av tvetydiga plansegment; återanvändning av systemkunskap; delat minne för gamla planer; och förmågan att dynamiskt införliva nya divisioner av arbete och kollaborativa interaktionssystem. För att lyckas parprogrammera på håll men samtidigt behålla fördelarna som nära anslutna par har behöver de uppvisa dessa egenskaper. (Flor, 2006)

2.6 Molntjänster

Molntjänster är ett lagringsutrymme där åtkomsten sker via internet istället för att vara lagrad i hårdvaran på en lokal dator. Molntjänster används för att lagra både programvara och filer på en extern server. Det som ligger lagrat i molnet blir tillgängligt för användaren via en inloggning, skulle användarens dator sluta fungera går filer som är lagrade i molnet ändå att komma åt. Utrymme för lagring av filer och programvara går genom molntjänster att anpassa efter användarens behov. (Nationalencyklopedin, 2019)

2.7 Virtuell maskin

En virtuell maskin på en dator betyder att det är en simulering av ett datorsystem. En virtuell maskin är baserad på en dators arkitektur och ger samma funktionalitet som en fysisk dator. En implementation av en virtuell maskin kan involvera speciell hårdvara och mjukvara eller en kombination av de båda. (Popek, 1974) Den fysiska datorn när man kör en virtuell maskin kallas generellt för värden, och den simulerade virtuella maskinen kallas för gäst. Värden kan skapa ett flertal gäster med olika ändamål, både ett helt nytt operativsystem eller ett program. Gästerna kan även tilldelas att ta del av olika mycket prestanda från värden. (Smith, 2005)

Det finns olika typer av virtuella maskiner med olika funktioner, till exempel virtuell systemmaskin och virtuell processmaskin. Virtuell systemmaskin kan man även kalla för en full virtuell maskin då den kan användas som ett substitut till en fysisk dator och ger samma funktionalitet som man har i en fysisk dator. (Smith, 2005) När man kör ett helt operativsystem virtuellt på en dator så är det då en virtuell systemmaskin och har alla funktioner som finns inom det simulerade operativsystemet. Det som man åstadkommer med detta är att man möjliggör användning av flertalet olika miljöer, isolerade från varandra, baserat på en hårdvara. Virtuell process maskin är mer fokuserat på att köra specifika program genom en simulering istället för ett helt operativsystem. (Smith, 2005) Huvudsaken med en virtuell process maskin är att man kan skapa en plattform som är oberoende av programmeringsmiljön och på så sätt inte är kopplad till hårdvaran som operativsystemet körs på. Detta tillåter program att köras på samma sätt på olika plattformar, till exempel kan man då köra program som stödjer ett annat operativsystem från en och samma dator med ett annat operativsystem i grunden. (Smith, 2005) 2.7.1 Molnbaserad virtuell maskin

En molnbaserad virtuell maskin är inte limiterad av den fysiska hårdvaran som simuleringen sker på, vilket en virtuell maskin är. Egenskaperna mellan en molnbaserad virtuell maskin och en virtuell maskin är många och de fungerar likadant förutom att den förstnämnda är man kopplad till genom internet. (Yoginath & Perumalla, 2015) Med molnbaserad virtuell maskin så kan företagen som erbjuder denna tjänst göra det möjligt för användaren att själv att välja vilken prestanda som man vill ha och även göra upp- eller nedgraderingar på den om det skulle behövas. Det behövs dock en fysisk hårdvara hos företaget som tillhandahåller tjänsten. Detta gör det enklare för användaren att använda produkten men man får inte glömma att det är en

13 virtuell maskin som fortfarande finns fysiskt på ett lager där företaget har den fysiska hårdvaran. (Yoginath & Perumalla, 2015)

3. Metod

Vår första utgångspunkt inför denna studie var att genomföra en kvalitativ undersökning med hjälp av intervjuer. Målet var att intervjua erfarna programmerare som arbetat eller arbetar agilt och leda en diskussion angående virtuell parprogrammering och vilka eventuella problem man kan stöta på vid en implementering. Vi insåg dock i ett tidigt stadie att det var svårt att hitta tidigare studier inom ämnet samt att de vi var i kontakt med inte hade använt sig av virtuella maskiner när de programmerat i par. Vi kom fram till slutsatsen att det skulle vara svårt för en person att identifiera eventuella problem med virtuell parprogrammering när hen inte arbetat på detta sätt tidigare. Detta ledde oss även fram till slutsatsen att det blir svårt att bedöma vilka eventuella problem som kan uppstå i relation till agil arbetsmetodik när det gäller detta arbetssätt enbart baserat på empiriskt material. På grund av detta valde vi därför att istället genomföra en kvalitativ litteraturstudie och försöka samla ihop den relevanta teori vi kunde finna för att sedan skapa en utgångspunkt inom ämnet istället. Vi har trots detta inte uteslutit intervjuaspekten helt och hållet eftersom vi anser att den bidrar på ett relevant sätt till analysen av denna studie. Dels kan den hjälpa oss förstå vad som är intressant och aktuellt att fundera vidare på gällande virtuell parprogrammering men även styrka eventuella resultat. Av denna anledning kommer en semi-strukturerad intervju genomföras med en person som arbetar med parprogrammering på distans och är engagerad inom agil arbetsmetodik.

Som vi redan nämnt i introduktionen av denna studie uppfattar vi den tidigare forskningen gällande detta ämne som aningen tunn och det är bland annat av den anledningen som vi behandlar ämnet som framväxande. Enligt Webster och Watson (2002) ska en litteraturstudie som syftar till att hantera ett framväxande ämne, vilken skulle dra nytta av att exponeras för en potentiell teoretisk grund, av nödvändighet behandla en mindre mängd av den nuvarande litteraturen. Med detta i tankarna har vi beslutat oss för att göra en konceptcentrerad studie där vi mappar upp de artiklar som varit mest relevanta för studien enligt oss beroende på innehåll. De koncept vi valt att fokusera studien vid är agil arbetsmetodik, Extreme Programming, parprogrammering, virtuell parprogrammering och virtuell maskin.

3.1 Litteratur

En litteraturstudie fokuserar på koncept och täcker relevant litteratur inom ämnet (Webster & Watson, 2002). Av denna anledning har relevanta nyckelord för denna studie använts som sökord på ett antal olika sökmotorer för att matcha våra studiekoncept. Örebro Universitets egen databas har primärt använts för att söka och hämta relevanta artiklar men även Google Scholar och DiVA. De sökord som har använts är agil metodik, parprogrammering, extrem

programmering, molnbaserad virtuell parprogrammering, molnbaserad parprogrammering, virtuell maskin, molnbaserad virtuell maskin, agile methodology, pair programming, extreme programming, cloud based virtual pair programming, cloud based pair programming, distributed pair programming, pair programming benefits, virtual machine, cloud based virtual machine. En asterisk har använts före och/eller efter ord för att utöka sökningsresultaten.

14 För att säkerställa att den litteratur vi använt oss av är pålitlig samt relevant har vi följt de riktlinjer som Webster och Watson (2002) föreslår att man ska göra när man genomför en litteraturstudie. De skriver till exempel att man inte ska använda sig av endast en metod för att söka litteratur och detta har vi undvikt genom att vi använt oss av bland annat sökmotorer som Primo men även Örebro Universitets fysiska bibliotek. Webster och Watson (2002) skriver även att den litteratur man använder sig av helst inte ska vara enbart från en viss geografisk region. Litteraturen vi läst har mestadels varit från USA men även Europa och den litteratur vi faktiskt valt att använda oss av är från bland annat USA, Sverige, Grekland och England. Resultaten vid en sökning är kopplade till det man söker på och de resultat som först kommer upp är ofta de som är mest kopplade till sökordet och det är därför rimligt att läsa dessa först (Webster & Watson, 2002). Vi har utgått från detta men även läst den litteratur som kanske inte har lika stor koppling till sökordet för att få ett större urval av artiklar att utgå ifrån och tittat på dess relevans i relation till vårt syfte och frågeställning. För att hitta ytterligare litteratur som möjligtvis är relevant så skriver Webster och Watson (2002) att man kan titta på de uppsökta artiklarnas källor. Detta hjälpte oss att hitta litteratur som var mer specificerad på ett visst ämne. Att litteraturen är pålitlig styrktes också när vi gjorde detta, eftersom att vi kunde läsa vart hen hade tagit sin fakta från och vad det handlade om.

3.2 Intervju

En semi-strukturerad intervju kommer att genomföras med en person inom det agila området som arbetar med parprogrammering på distans. En semi-strukturerad intervju som metodval är lämplig eftersom informantens tankar och åsikter är intressant för studien. Enligt Oates (2006) möjliggör en semi-strukturerad intervju en öppnare diskussion där intervjuaren fortfarande har kontroll på vilka ämnen och frågor som diskuteras. Detta metodval innebär även att nya följdfrågor kan dyka upp under intervjun eftersom informanten har möjligheten att framföra nya tankar och frågor.

Oates (2006) påpekar vikten av att under en intervju på något sätt spela in vad som sägs och därför kommer intervjun att spelas in som en ljudfil samtidigt som anteckningar tas löpande under tiden för att underlätta transkribering.

Den intervjuade kommer att vara anonym och även underrättas om detta innan intervjun startar. Ett dokument med intervjufrågor kommer även att skickas till informanten en dag innan för att denne ska få tid till att fundera och reflektera över sina svar. Vi har valt att inte hantera personuppgifter eftersom vi inte anser att det tillför något till vårt resultat av den kommande intervjun.

3.3 Analysmetod

Det var viktigt att de utvalda artiklarna för vår analys inte var motsägelsefulla eftersom det då skulle bli svårt att avgöra vad som faktiskt stämmer eller inte. Det mest förekommande temat var kommunikation och samtliga artiklar som behandlade ämnet tryckte på att detta var ett nyckelattribut. Av denna anledningen valde vi dela upp samtliga artiklar i olika faktorer som påverkar kommunikationen inom ett programmeringspar. Även de artiklar som vi valde att inte ta med som underlag för vår analys diskuterade kommunikation som ett av de viktigaste attributen inom parprogrammering vilket är relevant att veta för att utesluta att vi valt bort andra typer av nyckelattribut.

15 Vi analyserade var artikel för sig med fokus på kommunikation inom parprogrammering och hur det skulle optimera detta sätt att arbeta samt vad som var nödvändigt för att det skulle fungera överhuvudtaget som en agil arbetsmetod.

För att på något sätt kunna mäta hur stor påverkningsgrad dessa faktorer hade på parprogrammering valde vi att ställa dem mot varandra, det vill säga jämföra vad olika artiklar säger om samma nödvändiga faktorer. Om till exempel 80% av våra utvalda artiklar säger att det är nödvändigt att man ska prata i realtid med varandra medan man parprogrammerar så har vi bedömt den faktorn som väldigt viktigt. Om till exempel 25% av artiklarna har påstått att det är viktigt att man sitter i samma tidszon så har vi bedömt den faktorn som mindre viktig. Vi har skapat en egen skala på hur mycket en faktor påverkar parprogrammering positivt och/eller är nödvändigt för att det ska fungera så bra som möjligt. Denna skala har vi delat upp i procentenheter och ser ut som följer:

▪ 0-30%: Mindre viktigt ▪ 31-60%: Viktigt

▪ 61-100%: Väldigt viktigt

Denna skala har vi skapat för att vi enklare ska kunna få en förståelse för vilka faktorer som är relevanta för analys och slutsatser av denna studie. Vi har valt att inte diskutera vad som är absolut nödvändigt inom virtuell parprogrammering utifrån denna skala eftersom vi inte bedömer vår studie tillräcklig för sådana typer av slutsatser. Vi analyserar därför utifrån denna skala istället vad som är viktigt och mindre viktigt för att kunna dra slutsatser om vilka typ av eventuella problem som kan uppkomma i det fall en eller flera av dessa faktorer saknas. Med den agila bakgrund vi skapat oss under avsnittet 2. Teori tittar vi sedan på dessa identifierade faktorer för att kunna bedöma vad som blir mindre kontra mer agilt beroende på om faktorerna finns eller saknas under virtuell parprogrammering. Eftersom vi inte visste exakt hur vi skulle gå tillväga för att mäta graden av agilt arbete lyfter vi in vårt resultat av den kvalitativa intervjun vi genomfört för att kunna dra slutsatser om huruvida parprogrammering påverkas rent agilt då en viss faktor saknas till exempel. Vi jämförde därför vårt teoriavsnitt gällande agil arbetsmetodik och parprogrammering med resultatet av vår intervju för att se om det stämde överens med vår uppfattning om vad som egentligen definierar huruvida något är agilt och i vilken utsträckning.

Eftersom vi endast genomförde en intervju blir det svårt att generalisera något resultat vilket är ännu ett argument från vår sida varför vi jämför det med vår framtagna teori angående ämnet. Det blir vidare svårt att lyfta fram olika teman och analysera dessa vilket är varför vi valt att titta på resultatet angående just kommunikation inom virtuell parprogrammering kontra klassisk parprogrammering från intervjun. Detta empiriska material var tänkt att hjälpa oss förstå agilt arbete inom virtuell parprogrammering bättre och har därför ställts mot de undersökta och analyserade artiklarna för att se om det hänger ihop eller är motsägelsefullt på något vis. Valet av en kvalitativ intervju som metod har därför hjälpt oss genom att 1) skapa en bättre aktuell förståelse för vad agilt arbete verkligen innebär och 2) ge oss något att jämföra vår litteraturstudie med. Tillsammans med litteraturstudien har intervjun därför smalnat av vägen

16 mot våra slutsatser så att vi enklare ska kunna se vad som är relevant och inte inom virtuell parprogrammering i relation till agil arbetsmetodik.

Eftersom vår frågeställning behandlar eventuella problem som kan uppkomma vid virtuell parprogrammering i relation till agil arbetsmetodik behandlas intervjun som ett viktigt komplement till vår litteraturstudie eftersom vi genom denna fått en chans att diskutera dessa två områden i relation till varandra. För att besvara vår frågeställning som vi nämnt tidigare ska vi titta på vad som är viktiga faktorer vid klassisk parprogrammering för att se vad som händer vid avsaknaden av dem vid virtuell parprogrammering. Att diskutera detta med en person som har mycket erfarenhet inom området lyfter därför vår analys och argument, de kommer inte endast från resultatet av litteraturstudien.

3.4 Metodkritik

Faktorer som kan påverka resultatet av vår studie är främst: ▪ Antalet intervjuer

Trots att vår studie i första hand är en litteraturstudie är det fullt möjligt att resultatet hade kunnat sett annorlunda ut i det fall vi intervjuat t.ex. 6 personer som arbetar agilt och med parprogrammering på något vis. Vi vill inte dra någon generalisering enbart utifrån intervjun och har därför heller inte gjort det. I det fall vi hade intervjuat flera personer hade vi till exempel även kunnat diskutera deras olika erfarenheter och kunskaper. Vi hade kanske också kunnat ta fram olika teman från intervjuerna för analys men det hade också gett oss en chans att konstruera ett nytt intervjuunderlag för varje ny intervju beroende på vilken information vi fått från den tidigare intervjun.

▪ Val av metod

Med större resurser hade vi kunnat valt en annan metod, till exempel en praktisk sådan där vi kunnat testat hur det faktiskt fungerar med virtuell parprogrammering med flera olika par. Detta tror vi hade gett vår studie ett mer detaljerat och tillförlitligt resultat. Det hade med detta även gjort studien relativt enkel att göra om på nytt. Reliabiliteten hade förmodligen ökat i grad med antal “test-par” för studien.

▪ Antal analyserade artiklar

Vår analys och slutsats grundas ur femton artiklar och givetvis skulle ett större antal artiklar bidra till ett mer detaljerat och grundligt resultat där vi hade kunnat diskutera mindre teman som påverkar den agila graden i virtuell parprogrammering till exempel men även andra teman vi stött på under vårt analyserande av artiklar.

3.5 Källkritik

Genomgående av studien har vi varit kritiska till de källor vi valt att använda oss av som stöd för vår analys och diskussion. Det har varit viktigt för oss att det funnits en genomgående variation i vår valda litteratur som till exempel författare, år för publicering, geografisk region och förlag.

17

4. Analys och resultat

I detta avsnitt presenterar vi först en konceptmatris utifrån vår litteraturstudie följt av en sammanfattning per koncept av vårt resultat. Därefter analyserar vi dessa koncept i relation till varandra för att sedan relateras till vilka potentiella problem som skulle kunna uppstå vid virtuell parprogrammering. Som avslutande del i detta avsnitt presenterar vi resultatet från vår semi-strukturerade intervju för att styrka vår analys.

Det har inte funnits en specifik sträng eller specifika strängar som givit oss särskilt många träffar under våra sökningar. Nedan följer en konceptmatris som presenterar vilket och/eller vilka koncept den mest relevanta litteratur vi analyserat behandlar. Vi har i efterhand lagt till ytterligare ett koncept (kommunikation) i matrisen eftersom vi i vårt sökande upptäckte att det var ett nyckelattribut inom samtliga övriga koncept förutom virtuell maskin. Vi bedömde kommunikation vara tillräckligt relevant för att vara en nödvändighet i grunden för vårt analysarbete. Litteratur Koncept AM XP PP VPP VM K 1 X X X X 2 X X X X 3 X 4 X X X X 5 X X X 6 X X X 7 X X 8 X X X X 9 X X X X 10 X X X X 11 X X 12 X X X X X 13 X 14 X 15 X X X

Artiklar: Williams, 2000 (1), Ambler, 2002 (2), Denning, 2015 (3), Holecombe, 2008 (4), Eiderbäck, 2007 (5), Zarb &

Hughes, 2015 (6), Flor & Hutchins, 1991 (7), Beck, 2000 (8), Aiken, 2004 (9), Lindvall et. al, 2002 (10), Williams & Kessler, 2003 (11), Flor, 2006 (12), Popek & Goldberg, 1974 (13), Smith, 2005 (14), Satratzemi et. al, 2018 (15).

Koncept: Agil metodik (AM), Extreme Programming (XP), parprogrammering (PP), virtuell parprogrammering (VPP),

virtuell maskin (VM), kommunikation (K). Tabell 1. Konceptmatris.

Genom att titta på ovanstående matris kan vi notera att majoriteten av litteraturen behandlar två eller fler av de utvalda koncepten för denna studie. Parprogrammering och kommunikation visar sig vara de två mest centrala koncepten inom ramen för vår studie. Anledningen till att endast två artiklar behandlar begreppet virtuell maskin beror på att vi inte ansett oss behöva bredare litteraturbas för detta koncept eftersom det fokuserat på tekniska aspekter snarare än forskning.

4.1 Agil arbetsmetodik

Under utvecklandet av system behöver människor som arbetar i team arbeta effektivt tillsammans med andra aktörer, till exempel programmerare. Ambler (2002) skriver att ens

18 behov av att förstå eller prata om ett problem ofta motiverar en, att diskutera ett problem sänker även barriären för medverkan. Att prata om ett problem kan resultera i att man förstår vad problemet innebär och då kan man bidra med en eventuell lösning, förstår man däremot inte vad problemet är så är det omöjligt att komma på en lösning (Ambler 2002).

I princip alla artiklar som fokuserar på agil metodik tar i olika stor grad upp det agila manifestet och gör kopplingar till det. Det är viktigare att man fokuserar på individer och interaktioner framför processer och verktyg, fungerande mjukvara framför omfattande dokumentation, kundsamarbete framför kontraktsförhandling och anpassning till förändring framför att följa en plan. Dessa saker ses som preferenser och inte som ultimatum som man måste följa, det är som riktlinjer som ska motivera ett fokus på dessa områden men inte utesluta de andra helt och hållet.

Denning (2015) skriver om det agila manifestet och tar upp att Kent Beck, som var en av de sju som formade det agila manifestet att det agila manifestet var ett steg framåt så behövdes det att uppdateras. Mindre fokus ska ligga på hur varje enskild utvecklare arbetar och mer som hur hela teamet arbetar tillsammans. En person ska inte arbeta ensam mot målet, hela teamet ska vara med och förstå samt samverka i utvecklingsprocessen för att bli mer produktiva (Denning 2015).

Lindvall et. al (2002) samlade in och analyserade empiriskt material gällande agil metodologier och konkluderade att de tre viktigaste framgångsfaktorerna är kultur, människor och kommunikation. Team som arbetar från samma fysiska plats och parprogrammering bidrar till snabb kommunikation.

4.2 Extreme Programming

Inom Extreme Programming har man en holistisk syn på värde och dess kostnad i tid och pengar. Helheten är värd mer än delarna tillsammans och ingenting kan beskrivas utan dess kontext. Genomgående i processen är målet lägga till och visa upp värde och för att göra detta kan man upprätthålla en konstant relation med varandra - hela tiden. Även här är kommunikation ett nyckelattribut, precis som inom parprogrammering. Det påpekas även att man ska hålla relationerna positiva. Aktivitetsflödet är ett övergripande tema inom Extreme Programming där bland annat diskussion och delandet av kunskap och perspektiv främjas, men det handlar även om att man ska förbättra sig själv och teamet bit för bit. Tre av fem värden som grundar basen inom Extreme Programming är god kommunikation, simplicitet och återkoppling.

4.3 Parprogrammering

Samtliga artiklar vi studerat angående parprogrammering på distans har alla belyst att det är mest fördelaktigt att sitta i samma rum, helst vid samma skärm, för att parprogrammering ska uppnå optimal effekt. De flesta artiklar vi studerat angående detta har även beskrivit en detaljerad lista på vad som behöver tänkas på för att göra parprogrammering till en trevlig upplevelse för själva paret, till exempel att man behöver tänka på sin hygien, hur mycket utrymme man tar upp och att man kommer överens med den man kodar med.

Återkommande belysta fördelar med parprogrammering är att man i ett par kan komplettera varandra gällande erfarenheter och kunskaper, att man bättre kan fundera ut tester och se till att

19 de verkligen genomförs samt att sannolikheten ökar för att koden ska bli lättförståelig och välstrukturerad.

Kommunikation har bland annat konstaterats vara ett nyckelattribut inom parprogrammering men även som en avgörande aspekt och det “första värdet”. För långa stunder av tystnad bör uppfattas som varningssignaler och inte mer än en minut bör passeras av tystnad. Flertalet studier har nått slutsatsen att det har med graden av kommunikation inom parprogrammering att göra huruvida ett par som programmerar tillsammans är framgångsrika eller inte. I de få fall parprogrammering inte fungerar handlar det oftast om egorelaterade anledningar och dålig kommunikation (Williams & Kessler, 2003).

Enligt Williams (2000) studie var det den kontinuerliga diskussionen som hjälper utvecklarna att reflektera över tankar och idéer med varandra. Som ett resultat av detta så blir utvecklarna bättre på att samarbeta. I det fall man stöter på ett problem så är det normalt att man går till en kollega för att be om hjälp. Med parprogrammering blir detta ännu enklare då man redan sitter med en kollega och kodar tillsammans. En annan aspekt är dock när en av personerna i paret ser sig själv som en perfekt programmerare vilken aldrig gör några misstag. (Williams, 2000) Detta menar Williams (2000) kan leda till att kommunikationen blir ett problem eftersom personen kan känna sig störd i sitt arbete om hens kollega ställer frågor som för denne är helt självklara. Williams (2000) tycker att detta är något som man ska försöka att undvika och att ingen utvecklare är perfekt och att alla kan göra fel.

Även Ambler (2002) belyser vikten av kommunikation inom Extreme Programming som är en av de fyra värderingar som är fundamentala faktorer för en lyckad systemutveckling. För att kommunikationen ska bli optimal måste det komma från båda parterna och uppnås detta kan information både erhållas samt överlämnas inom paret. Många problem inom systemutveckling kan spåras till bristande kommunikation. (Ambler, 2002) Aiken (2004) och Ambler (2002) belyser båda att problem uppstår när kommunikationen misslyckas gällande krav på utvecklingen.

4.4 Virtuell parprogrammering

Angående virtuell parprogrammering har våra sökningar inte givit oss något specifikt resultat. Däremot har vi hittat forskning som beskriver vad som krävs av par som programmerar för att uppnå samma fördelar vid virtuell parprogrammering som vid klassisk parprogrammering. Dessa fördelar är effektiv kommunikation, den löpande delningen av mål och planer, förenad produktion av tvetydiga plansegment och förmågan att dynamiskt införliva nya divisioner av arbete och kollaborativa interaktionssystem.

Satratzemi et. al (2018) genomförde en studie på studenters produktivitet inom virtuell parprogrammering i en objektorienterad programmeringskurs under 2016–17 och konkluderade att en students produktivitet är associerad med deras erfarenhet och självförtroende för programmering till skillnad från hur bekväma de kände sig under själva sessionen av programmering. Inom studien benämner de vad vi i denna studie kallar för virtuell parprogrammering som distribuerad parprogrammering. Vi nämnde tidigare i introduktionen av denna litteraturstudie att författarna påpekar hur tunt det är med empiriska studier angående just virtuell parprogrammering och detta är ett av argumenten bakom deras studie. Satratzemi

20 et. al (2018) noterar även att det verkar som att deras upptäckter angående studenters attityder mot virtuell parprogrammering överensstämmer med de flesta studier om parprogrammering, vilket de menar är en uppmuntrande tanke eftersom virtuell parprogrammering är mer krävande än klassisk parprogrammering.

Flor (2006) påpekar, som vi nämnt tidigare i studien, att virtuella par kan nå samma fördelar som klassiska par genom att skapa en infrastruktur för informationen inom deras korsade arbetsplats som är likadan som för de klassiska parens arbetsplats. Han förklarar att virtuella par har potentialen att uppnå detta och att utmaningen är huruvida man räknar ut vad som är det lämpligaste informationssystemet för den korsade arbetsplatsen samt hur man ska ge detta par samma tillgänglighet till detta informationssystem som klassiska par har. Nedan följer två figurer som representerar informationskanalerna inom klassiska samt virtuella par.

Figur 1: Visuella- audio- och manuella informationskanaler när man programmerar nära varandra. Källa: Flor (2006).

Figur 2: Par som arbetar på distans. De rätta visuella- audio- och manuella informationskanalerna för den korsade arbetsytan behöver räknas med. Källa: Flor (2006).

4.5 Resultat av intervju

Avsnittet nedan är en sammanställning av en personlig intervju genomförd 21 december 2018 av oss båda författare till denna studie. All information nedan är endast personlig kommunikation sammanställd och därmed icke tolkad av oss.

4.5.1 Virtuell parprogrammering

Den person (kallas från och med nu informant) vi intervjuade arbetar som utvecklingschef på en verksamhet med ungefär 30 personer som arbetar med mjukvaruutveckling på sin avdelning. Informanten har verkat på denna arbetsplats i cirka ett år och var innan dess agil coach och scrum master i ungefär tre år. Utöver detta arbetade hen som utvecklare sedan tidigare men har även arbetat som scrum master vid sidan av i över tio år. Informanten har arbetat med flertalet agila metoder varav en av dessa är Extreme Programming, hen har dessutom enligt sig själv arbetat med ungefär alla praktiker som finns inom metodiken. Informanten berättade att de har

21 team som parprogrammerar offshore, det vill säga att två personer som parprogrammerar tillsammans sitter i varsitt land. Just nu har de fyra indier och tre svenskar i varje team. Anledningen till varför de arbetar på detta sätt är för att dels sprida kunskap inom arbetsteamen men även för att få ett bättre flyt och förståelse i utvecklingen. De använder sig av Skype och skärmdelning för att möjliggöra deras virtuella parprogrammering där det också är möjligt att skifta förare och navigatör.

4.5.2 Agil arbetsmetodik

Vi ställde frågan varför det är enligt informanten viktigt att arbeta agilt och fick det simpla svaret ”för att få något gjort” (personlig kommunikation, 21 december 2018). Ytterligare förklaring till varför det är viktigt att arbeta agilt var bland annat för att kunna realisera sitt värde fort, för att personalen ska må bra och eftersom det är roligare att arbeta när man ser resultat. En annan anledning var att man får feedback. De agila värderingarna i det agila manifestet betonade informanten vara grundläggande eftersom man inte kan tolka och anpassa då man inte förstå bakgrunden till arbetsmetodiken. Hen nämnde även att det stora misstaget många gör är att man börjar arbeta med till exempel Scrum som är en agil arbetsmetodik eftersom att ”alla andra gör det” utan att egentligen veta något om dess bakgrund. Hen påpekar då att man inte får ut något av det när man inte vet något om det. De agila värderingarna och de agila teknikerna är lika viktiga enligt informanten och man kan därmed inte ha det ena utan det andra. För att kunna kalla sig agil i sitt arbete menar hen att det räcker med att ha förstått och håller med om det agila manifestet.

4.5.3 Parprogrammering

Vi ställde frågan på vilket sätt som parprogrammering bidrar till ett agilt arbetssätt och informanten svarade bland annat med att det bidrar till att man arbetar i team vilket är viktigt.

”Man kan inte vara team utan att man jobbar tillsammans för att lösa en uppgift och då måste man parprogrammera. Och då ser man också man får feedback av andra, man producerar högre kvalitet för att man får ett par ögon till på koden.” (personlig kommunikation, 21

december 2018).

Vidare nämner informanten att man heller inte fastnar särskilt mycket i sina problem utan att man kan prata med en annan person samtidigt som kunskap då sprids inom teamet. Hen menar också att man bidrar till att kunna fokusera på problemlösning för att leverera och sedan ta sig an nästa uppgift. Enligt informanten är det optimalt att man parprogrammerar mellan 30 och 50 procent av tiden, men att det beror även lite på vad man arbetar med. Det är bättre att fokusera på parprogrammering när man behöver ta in någon ny i teamet eller tänka till lite till exempel, dels för kunskapsspridning och problemlösning.

Enligt informantens uppfattning används parprogrammering som ett verktyg för att utveckla mjukvara för lite.

4.5.4 Virtuell parprogrammering

Det fungerar enligt informanten inte lika bra att parprogrammera från olika fysiska platser som klassisk parprogrammering. Det är lättare med det klassiska sättet eftersom man har en annan kommunikation då man sitter i samma rum. En annan aspekt som lyftes fram vid parprogrammering på distans var tidszoner som kan skilja sig åt väldigt mycket när man bor i

22 olika länder och därmed kan den möjliga arbetstiden för paren under dagen variera. Dåliga telefonlinjer och internetuppkoppling var två andra aspekter värda att nämna. Det handlar både om tekniken och den fysiska närvaron som gör det mindre optimalt att inte sitta i samma rum. Enligt informanten vore det enklare om man skulle sitta i samma tidszon när man parprogrammerar på distans. Sitter man till exempel i Stockholm och Malmö så menar informanten att de flesta kontoren har en bra internetuppkoppling. Vi ställde frågan ifall hen såg några säkerhetsrisker med att parprogrammera över internet och det gjorde hen inte. 4.5.5 Molnbaserad virtuell parprogrammering

Vi ville veta ifall projektets storlek på något sätt påverkar nyttan av molnbaserad virtuell parprogrammering och detta tror informanten inte spelar någon större roll. Hen konstaterar att det blir i vilket fall bättre kvalitet på koden vid parprogrammering på distans än om man sitter och kodar en och en. Potentiella problem/risker med molnbaserad virtuell parprogrammering ser inte informanten direkt. Hen nämner dock att det alltid finns tekniska aspekter att tänka på, saker och ting kan sluta fungera. Den egna lokala datorn upphör oftast inte att fungera, men har man en maskin i molnet så måste man ha två internetuppkopplingar och det är mycket som kan krångla på vägen som till exempel störningar vilket kan vara frustrerande. Informanten ser ingen anledning till varför man skulle vilja använda en maskin i molnet för att parprogrammera på. Hen tycker att det räcker med skärmdelning där man släpper in den andra personen på sin egna lokala dator. Hen ser inga fördelar med att ha en dator i molnet.

4.6 Sammanfattning av analys

Sammanfattningsvis kan vi dra slutsatsen att kommunikation är den centrala aspekten bakom framgångsrik parprogrammering, gällande både klassisk och virtuell sådan. Kommunikation verkar även vara ett nyckelattribut inom agil arbetsmetodik och Extreme Programming. Det agila manifestet är grundläggande när det kommer till att arbeta agilt och en av de fyra värderingarna uttrycker hur individer och interaktioner ska värderas över processer och verktyg. En uppdatering av det agila manifestet adderar teamvision och disciplin som en ytterligare aspekt att värdera framför individer och interaktioner. Detta är intressant eftersom team är ett återkommande begrepp gällande parprogrammering och i synnerhet inom ramen för Extreme Programming. Nedan presenterar vi de viktiga aspekter vi funnit inom parprogrammering för att sedan gå vidare till identifiering av potentiella problem med virtuell parprogrammering i relation till agil arbetsmetodik för att besvara vårt syfte och frågeställning i denna studie. Viktiga aspekter inom parprogrammering:

▪ Kommunikation: Att parprogrammera utan kommunikation saknar mening. Kommunikation är det som möjliggör alla fördelar med parprogrammering eftersom det är två människor som interagerar tillsammans samtidigt som de producerar kod. Flertalet fördelar identifieras när god och konsekvent kommunikation upprätthålls som till exempel direkt granskning, kunskapsspridning, problemlösning och idébollande. (Lindvall et. al, 2002; Beck, 2000; Aiken, 2004)

▪ Informationskanaler: En informationsinfrastruktur är något som ofta tas för givet när man arbetar i nära anslutning till varandra. Denna infrastruktur består av både visuella- och audiokanaler som skickar information fram och tillbaka. (Flor, 2006)

23 ▪ Teamarbete/samarbete: För att bli mer produktiva och effektiva i arbetet ska man arbeta som ett team i helhet och därmed ska en enskild individ inte ensam arbeta mot målet (Denning, 2015).

▪ Kunskapsspridning: Parprogrammering anses vara en fördelaktig arbetsmetod eftersom att det bidrar till att sprida kunskap inom verksamheter samt möjliggör mentorskap då två personer som programmerar tillsammans kan utbyta kunskap och erfarenheter (Eiderbäck, 2007).

▪ Problemlösning: Att lösa problem är väsentligt när man ska koda och utveckla mjukvara, därför anser vi att problemlösning är en viktig aspekt inom parprogrammering.

▪ Byte av förare och navigatör: Man bör byta plats på förare och navigatör när man parprogrammerar eftersom att det möjliggör kunskapsspridning.

▪ Positiva relationer: Man uppmanas inom Extreme Programming att hålla relationerna positiva eftersom det bidrar till effektivitet och värdeskapande processer (Holecombe, 2008).

Identifiering av potentiella problem:

▪ Bristande kommunikation: Kommunikationen som är den centrala delen i framgångsrik parprogrammering är även den faktor som kan leda till potentiella problem. I det fall kommunikationen är bristande mellan paren eller nästan obefintlig kommer detta ha en negativ effekt på programmeringen eftersom det är kommunikationen som möjliggör utbytandet av idéer, direkt återkoppling och gemensam problemlösning (Williams, 2000). Människor och hur de arbetar tillsammans är de viktigaste faktorerna inom agila arbetsmetodiker (Ambler, 2002) och det är därför viktigt att tänka på hur man på bästa sätt som ett par kan upprätthålla god kommunikation med varandra genom hela processen.

▪ Dålig eller avbruten internetuppkoppling: Eftersom ett samarbete via virtuella maskiner kräver internetuppkoppling från två punkter är det kritiskt huruvida det finns en uppkoppling eller inte samt hur stabil den är. Klassiska par kan fortfarande koda tillsammans oavsett internetuppkoppling när de sitter vid samma skärm, något som blir omöjligt för det virtuella paret. I det fall internetuppkopplingen avbryts kan bara den ena fortsätta parprogrammera och sett ur ett agilt perspektiv är det inte optimalt eftersom parprogrammering i sig är en agil arbetsteknik.

▪ Olika tidszoner: I det fall man parprogrammerar med någon som bor i en helt annan tidszon kan det skapa problem ur ett agilt perspektiv eftersom individerna ska må bra i sitt arbete och arbeta effektivt (Ambler, 2002). Att till exempel endast vara anträffbar för parprogrammering tre till fyra timmar per dag (och alltid samma timmar varje vardag) begränsar paren från att parprogrammera under dagen där det passar dem bäst beroende på var de är i sina processer. De blir istället mer eller mindre tvungna att utnyttja den enda överlappningen av tidszonerna som förefaller under deras arbetstider. Detta kanske inte är optimalt för deras enskilda arbetsdagar och arbetsprocesser. ▪ Bristande informationsinfrastruktur: Uppnår informationsinfrastrukturen inte den

nivå som krävs för att ett virtuellt par enkelt ska nå samma möjligheter som ett klassiskt par skapar detta problem ur ett agilt perspektiv eftersom att kommunikationen är

24 väsentlig och därför bör vara lättåtkomlig för att möjliggöra de goda egenskaper som kan utvinnas ur parprogrammering.

▪ Inget byte av förare och navigatör: Det kanske inte blir lika självklart att man ska byta plats på förare och navigatör då man parprogrammerar virtuellt eftersom man inte har den direkta fysiska kontakten inom paren.

5. Diskussion

Flor (2006) menar att det är möjligt för par som programmerar på distans att uppnå samma fördelar som par som programmerar i samma fysiska utrymme så länge samma egenskaper uppnås som i klassisk parprogrammering. Vi håller med Flor (2006) om detta baserat på vårt resultat och analys av det undersökta materialet gällande effektiv kommunikation. Övriga egenskaper Flor (2006) pratar om har vi inte haft resurser till att undersöka i denna studie. Den tidigare forskning vi undersökt har inte tagit upp virtuella maskiner i samband med parprogrammering och ur vårt empiriska material kan vi konstatera att det inte verkar finnas ett intresse för det heller. Vår informant kunde inte förstå vilket syfte som skulle finnas med det. Detta är dock endast utifrån en intervju och det är svårt att säga vad ett större antal intervjuer skulle resultera i.

Vårt resultat och vår analys liknar flera resultat vi funnit angående parprogrammering på distans i olika studier. Det verkar uppenbart att det är just kommunikation som är grundpelaren för en framgångsrik parprogrammering, oavsett om det gäller klassisk eller virtuell sådan.

Nedan har vi skapat en konceptuell modell över vad vi funnit vara de viktigaste kraven för att virtuell parprogrammering ska hålla sig agilt. När vi skapade denna modell hade vi Flors (2006) figurer (se figur 1 och 2) i åtanke och justerade det efter vad vi kommit fram till. Eftersom syftet med denna studie är att identifiera eventuella problem menar vi att problem kan uppstå i det fall en eller fler faktorer inom denna modell inte uppnås eller finns med i beräkningen av en virtuell parprogrammering.

25 Figur 3. Konceptuell modell: Virtuell parprogrammering i relation till agil arbetsmetodik.

Modellen ovan beskriver hur virtuell parprogrammering i relation till agil arbetsmetodik behöver se ut för att fungera optimalt. En kommunikationskanal är kritisk mellan de två programmerarna som sitter på olika fysiska platser samt en varsin informationskanal till den gemensamma virtuella maskinen som de programmerar på tillsammans.

Denna virtuella maskin finns endast tillgänglig för båda programmerarna genom internet. En programmerare kan till exempel ha en virtuell maskin på sin dator där den andra programmeraren får tillgång, men denne måste då ha åtkomst till internet. Eftersom att denna tillgång kan möjliggöras på olika sätt, till exempel genom att den virtuella maskinen finns helt och hållet i en molntjänst och båda programmerarna därmed behöver ha åtkomst till internet har vi valt att presentera detta genom att internetåtkomst är en nödvändighet i samtliga fall då virtuell parprogrammering genomförs (vilket är anledningen till varför en pil dras från båda programmerarna).

En informationskanal innebär här att båda programmerarna ska ha tillgång till vad som sker på den virtuella maskinen i realtid, de ska kunna både hämta och ladda upp information som till exempel kod och kommentarer. Det handlar i grund och botten om att båda samtidigt ska se en och samma skärm där koden utvecklas för att sedan kunna utnyttja kommunikationskanalen för att ta del av de agila faktorer som krävs för att kunna uppnå en agil virtuell parprogrammering, som till exempel utbytandet av idéer och problemlösning, till och med höra en suck eller två. Kommunikationskanalen bör alltid vara av minst röstkommunikation men för att stärka denna kanal kan man till exempel använda sig av videodelning för att få en visuell bild av den man programmerar med för att kunna läsa av kroppsspråk och så vidare.

Utöver kommunikationskanal, informationskanal och internetuppkoppling finns ett antal listade krav som komplement till denna modell. Dessa krav beskriver i kronologisk ordning vad som