Strengthening the case for pair programming

Den sista källan har som syfte att förstärka argumenten för parprogrammering. Speciellt nämns anekdotiska och subjektiva bevis från parprogrammerings förespråkare som ska stär- kas med kvantifierbara bevis. Författarna baserar sina slutsatser på ett experiment som gjor- des 1999 (artikeln är publicerad 2000) på Utahs universitet. Experimentet gick ut på att dela in deltagarna i två grupper med ungefär samma blandning av hög, medium och lågpresterande studenter. En av grupperna arbetade enskilt och den andra bestod av studenter som skulle testa på att jobba i par. Några studenter i den första gruppen och alla studenter i den andra gruppen hade visat intresse av att pröva på parprogrammering. Grupperna jämfördes med avsende på cykeltid, arbetstimmar och kvalitet. Studenterna i parprogrammeringsgruppen fick extra arbete så att det blev en jämnlik fördelning i arbetsbörda mellan par och solopro- grammerare. Studenterna fick 4 olika uppgifter som gjordes på en period på 6 veckor. Studenterna var inte vana vid att programmera i par och hade därför en invänjningsperiod, hur länge denna period varade varierade mellan grupperna men de flesta hade anpassat sig efter den första uppgiften.

Resultaten för den första uppgiften visade att parstudenterna var både snabbare med att bli färdiga uppnåde högre kvalitet på koden. I arbetstimmar lade de dock 60% mer, i de senare uppgifterna (när invänjningsperioden var över) sjönk detta till enbart 15% mer. Kvaliteten på koden visas i källans första tabell [56]. Och visar en tydlig skillnad i kvalitet mellan grupper- na, speciellt vid uppgift 3 och 4. Paren skiljde sig inte bara åt genom högre kvalitet utan också i att det var mindre varians på kvaliteten mellan grupperna.

I källans första figur visas förhållandet mellan par och solo programmering i arbetstim- mar (på individnivå så för ett par blir värdet det dubbla) [56]. Där syns invänjningsperioden tydligt i den stora skillnaden mellan uppgift 1 och 2. I experimentet blev parprogrammerna färdiga med deras uppgifter 40 till 50% snabbare, vissa av solo programmerarna lämnade inte in sina uppgifter eller lämnade in för sent. Parprogrammerarna lämnade in i tid och författarna menade att det var för att paren satte mer press på varandra. [56]

E.6

Diskussion

De tre källorna var relativt sammaneniga i sina resultat trots att de var skrivna i olika skee- den av parprogrammeringens popularisering (2000, 2007 och 2016). Med det sagt känner jag i efterhand att det troligtvis hade varit bättre att begränsa min sökning till nyare källor, till exempel enbart källor yngre än 10 år. Källorna från 2000 och 2007 var visserligen intressanta men speciellt den från 2000 kändes väldigt utdaterad. Källorna från 2007 och 2016 kändes också starkare då de gjorde meta analyser och sammanställde flera olika studiers resultat. Al- la källor fann att kvaliteten visades öka tydlig för parprogrammering. Detta är förstås inte ett så förvånande resultat då en stor del av poängen med parprogrammering är att två personer ska kunna nå högre kvalitet genom att bolla idéer och snabbt identifiera fel. Även kalendertid visar en fördel för parprogrammeringen vilket också var ganska förväntat, om två personer

E.7. Slutsatser

tog längre tid på sig än en ensam hade det varit ett stort problem för parprogrammering. För arbetstimmar ser det däremot sämre ut för parprogrammering då paren lägger märkbart mer arbetstimmar. Med det sagt är det inte i närheten av så illa som en dubblering, experimentet som publicerades 2000 såg enbart en ökning med 15% när deltagarna väl vant sig med att programmera ihop.

E.7

Slutsatser

Vilka fördelar har parprogrammering?Parprogrammering har en fördel när det gäller kva- litet och kalendertid. Parprogrammering ökar även lärande hos paren speciellt när en av pro- grammerarna är mer erfaren. Vilka nackdelar har parprogrammering? Den stora nackdelen är att parprogrammering kostar mer i arbetstimmar än solo programmering. Vilka typer av

situationer och projekt är parprogrammering mest lämpat för?Parprogrammering lämpar sig bäst för projekt där kvaliteten är väldigt viktig. Parprogrammering är också lämpat för mer komplexa uppgifter, speciellt när programmerarna är relativt oerfarna. Parprogramme- ring är mindre lämpat för enkla uppgifter och projekt där kvantitet är viktigare än kvalitet.

prototyper för utveckling av

webbapplikationer

F.1

Inledning

Att påbörja projekt är inte helt enkelt, det är inte säkert att varje gruppmedlem har samma vision och heller inte samma uppfattning av vad det är kunden vill ha. Att inte ha samma uppfattning av slutprodukt som de andra i gruppen är något de flesta vill undvika. Proto- typer är något som hjälper gruppmedlemmar samla information från varje part och samla dessa på ett ställe för diskussion av flöde och intuitivitet. Det är också ett sätt att framföra idéer till kund på ett praktiskt sätt.

F.1.1

Syfte

Syftet med detta bidrag till rapporten är att utforska vad skillnaden är mellan temporära och evolutionära prototyper. Hur prototyper kan användas för utveckling av en webb-baserad applikation och att applicera detta på en agil arbetsmetod som Scrum.

F.1.2

Frågeställning

Denna studie kommer att besvara följande frågor:

1. Vad är syftet med temporära och evolutionära prototyper? 2. Hur användes prototyper i vårt projekt?

3. Hur fungerar det att använda prototyper i samband med agila metoder så som Scrum?

F.2

Avgränsningar

Denna delrapport avgränsas till frontendutveckling. Det betyder att när designrelaterade be- nämningar görs så hänvisas alltså inte detta till någon form av backendutveckling. Resultatet och diskussionen baseras endast från erfarenheter inom projektet och den litteraturstudie som gjorts.

F.3. Bakgrund

F.3

Bakgrund

Projektarbetet går ut på att skapa en webbapplikation som innehåller ett chattfönster och diverse funktioner så som att överstryka text, navigera mellan olika konversationer och ka- tegorisera problem. Målet med projektet ur ett grafiskt perspektiv är att göra det intuitivt för användare. Personer från många olika åldersgrupper och bakgrunder ska lätt kunna komma in i hur applikationen fungerar och dessutom bibehålla en hög standard på användarupple- velse.

F.4

Teori

I detta kapitel förklaras innebörden med prototyper och den agila metoden Scrum.

F.4.1

Prototyper

Prototyper skapas ofta syftet med att utforska olika idéer och få olika perspektiv av en pro- dukt i experimentellt syfte. De skapas ofta i början av utvecklingsprocessen då både kund och utvecklare har en oklar bild av slutprodukten. En prototyp behöver inte fokusera på en enskild lösning utan kan kombinera olika lösningar för att jämföra olika koncept med olika fördelar. Prototyper fungerar oftast som koncept där varje projektmedlem delar idéer.[8][57]

F.4.2

Scrum

Scrum består av att arbetsgruppen jobbar på de olika prototyperna i sprintar. Sprintarna är of- tast från två veckor till två månader långa beroende på hur stort projektet och projektgruppen är. En annan faktor är hur lång tid det tar att implementera något och reflektera över. Under sprintarna utvecklas prototypen i mindre leveranser som diskuteras och värderas under kor- ta möten. Dessa möten är till för att kontrollera förändringarna som gjorts på prototypen. Den agila metoden bygger på att projektgruppens medlemmar har bra kommunikation med varandra och från kunden får aktiv feedback som evalueras och implementeras. Efter varje sprint reflekteras arbetsmetoden om något behöver justeras och nya mål sätts upp.[8]

F.5

Metod

I detta kapitel presenteras metoden för att besvara de frågeställningar som ställts.

F.5.1

Litteraturstudie

För att besvara frågeställningen kommer projektets prototyper studeras och en litteraturstu- die att göras. Det primära verktyget som kommer användas för att hitta dessa källor är Goog- le Scholar. Specifika sökord som används för att hitta dessa rapporter är ”Paper prototype”, ”Prototyping techniques”, ”Graphical user interface”, ”GUI”. En del av litteraturen kommer även komma från diverse inlägg från olika artiklar, forum och studiematerial. Källorna vär- derades efter relevans och träffsäkerhet till ämnet. Vissa källor som var i utforskningssyfte valdes bort.

F.6

Resultat

Här framförs resultatet av litteraturstudien och de prototyper som skapades i projektet

F.6.1

Resultat Litteraturstudie

Det som undersöktes i litteraturstudien var användningsområden och syfte med temporära och evolutionära prototyper.

F.6.1.1 Temporära prototyper

En del prototyper kastas ofta bort efter de testats. Dessa prototyper kallas för temporära pro- totyper. Eftersom de är temporära så kommer de inte att användas till slutprodukten och därför måste inte lika mycket resurser läggas ner på dessa[8]

Ett exempel på temporära prototyper är en pappersprototyp. En pappersprototyp ska vara något som är snabbt ihopsatt och inte så välarbetat, så att kunden eller användarna lätt ska kunna komma med kritiska kommentarer innan arbetsprocessen börjar. Det som i huvudsak testas med hjälp av pappersprototyper är det övergripande konceptet och flödet av produkten. Detta innebär att designval i anknytning till utseende så som färgval inte är intressant.[8][57]

I en studie av Sefelin, Tscheligi och Giller [50] undersöks pappersprototyper och evalueras som temporära prototyper. I denna studie nämns att pappersprototyper eventuellt föredras när:

• När prototypverktygen inte stöder komponenterna och idéer som ska implementeras. • När projektgruppen inte vill utesluta medlemmar i designteam utan tillräcklig mjukva-

rufärdighet.

• När testerna bör leda till många ritningar, vilka sedan kan diskuteras i designteamet. [50]

F.6.1.2 Evolutionära prototyper

Det finns även evolutionära prototyper. Dessa skapas med syftet att byggas vidare på. En evolutionär prototyp kastas därför inte bort vilket leder till att mer resurser läggs på förfining och funktionalitet.[8]