• No results found

Parprogrammering i högre utbildning

N/A
N/A
Protected

Academic year: 2022

Share "Parprogrammering i högre utbildning"

Copied!
35
0
0

Loading.... (view fulltext now)

Full text

(1)

INOM

EXAMENSARBETE DATATEKNIK, AVANCERAD NIVÅ, 30 HP STOCKHOLM SVERIGE 2016 ,

Parprogrammering i högre utbildning

Att introducera och mäta parprogrammering MARCUS DICANDER

KTH SKOLAN FÖR DATAVETENSKAP OCH KOMMUNIKATION

(2)

Parprogrammering i högre utbildning

Att introducera och mäta parprogrammering

MARCUS DICANDER

Exjobbsrapport vid CSC

Handledare: Viggo Kann

Examinator: Olle Bälter

(3)
(4)

Referat

Vi har studerat införandet av parprogrammering i sju olika kurser på KTH. Som ett hjälpmedel till denna studie har vi utecklat ett loggverktyg i form av en webbapplikation, Parkour som skulle hålla koll på de olika rollerna i parpro- grammering (förare och navigatör) samt när det var dags att byta roller. Drygt 350 studenter deltog, ungefär hälften på våren 2015 och hälften på hösten 2015.

I de fall då det var obligatoriskt att använda verktyget och att parprogrammera så gjorde studenterna det. När det bara var obligatoriskt att använda verktyget på de första labbarna i kursen så släcktes behovet ut, men enkätunder- sökningarna tyder på att verktyget ändå har hjälpt en del av dem att lära sig parprogrammera och fått dem att par- programmera mer än de skulle ha gjort utan ett verktyg.

En del studenter har även fortsatt med parprogrammering,

fast utan verktyg.

(5)

Abstract

Pair programming in higher education

We have studied the introduction of pair programming into 7 different courses at the Royal Institute of Technology. For this task we developed the web application Parkour which was used to keep track of the different roles (driver and navigator) and keep a count down timer to the next role switch. 350 students participated, about half of them in the spring of 2015 and the other half in the fall.

When the tool was mandatory to use the students used

it. When it was mandatory for the first labs, they used

it there and stopped using it afterwards. If it was never

mandatory the students almost never started using it. A

poll given to the users afterwards implies that the tool has

helped some students learn about pair programming and

that they have tried pair programming to a greater extent

than they would have without the tool.

(6)

Innehåll

Tabeller Figurer

1 Inledning 1

1.1 Bakgrund, frågeställning och syfte . . . . 1

2 Teoretisk bakgrund 3 2.1 Ett särskilt tack till... . . . 4

2.2 Etik, samhälle och hållbarhet . . . . 5

3 Metod 7 3.1 Designprocess för mätverktyget . . . . 7

3.2 Användarbeskrivning . . . . 7

3.3 Användningsscenarier . . . . 8

3.3.1 Första gången . . . . 8

3.3.2 Några gånger senare . . . . 8

3.3.3 Statistiken påverkar . . . . 8

3.3.4 Redovisning . . . . 9

3.4 Design av inloggning och säkerhet . . . . 9

3.5 Design av tidmätning . . . . 9

3.6 Design av huvudsida . . . . 9

3.7 Design av statistiksida . . . 10

3.8 Design av logganalysverktyg . . . 11

3.9 Parkour som pedagogiskt verktyg . . . 12

3.10 Val av verktyg och programspråk . . . 12

3.11 Kurserna och skillnader i hur verktyget infördes . . . 13

3.12 Mätperioderna och hantering av problem . . . 14

3.13 Utvärderingsmetod . . . 14

4 Resultat 15 4.1 Deltagande . . . 15

4.2 Genomsnittliga tider . . . 15

4.3 Andel tid i förarrollen . . . 16

(7)

4.4 Resultat av enkätundersökningar . . . 18

4.4.1 Vårens enkät . . . 18

4.4.2 Höstens enkät . . . 19

4.4.3 Båda enkäterna . . . 21

4.5 Intervju med en kursledare . . . 21

5 Slutsats och diskussion 23 5.1 Slutsats . . . 23

5.2 Diskussion . . . 23

5.3 Vidareutveckling av Parkour . . . 25

Litteraturförteckning 27 Tabeller 4.1 Kurser, användare, tider och fördelningar . . . 17

Figurer 3.1 Inloggningssidan. . . 10

3.2 Huvudsidan med knappar för att ange förare samt paus. . . 10

3.3 Statistik efter två låtsasstudenter (exjobbshandledaren och exjobbaren). 11 4.1 Histogram över alla förarpass sorterade på längd. . . 16

4.2 Histogram över alla labbpass sorterade på längd. . . 18

4.3 Den vanligaste föraren var förare så här stor andel av tiden. . . 19

4.4 Enkätsvar från vårterminen 2015, kurserna oop, prgcl och prgmed. . . . 20

4.5 Skulle studenterna ha parprogrammerat utan Parkour? Enkätsvar från höstterminen 2015, kursen adk. 20 studenter svarade. . . 21

4.6 Enkätsvar från höstterminen 2015, kursen adk. . . 22

(8)

Kapitel 1

Inledning

1.1 Bakgrund, frågeställning och syfte

För att förbättra kvalitén på datalogiundervisningen på Skolan för datavetenskap och kommunikation (CSC) på KTH försöker Cerisegruppen (en grupp didaktiskt in- tresserade programmeringslärare på CSC) att införa olika metoder för att förbättra undervisningen. En av dessa metoder är parprogrammering 1 . 2014 beviljade CSC en ansökan om medel för ett projekt i parprogrammering. Tanken var att parpro- grammering skulle införas i olika grundkurser på Teknis, men med olika krav. I vissa kurser skulle det var frivilligt, i vissa starkt rekommenderat, i vissa kurser obliga- toriskt för vissa laborationer och i andra kurser obligatoriskt för alla laborationer.

För att kunna studera parprogrammering i detalj behövs ett mätverktyg. Att ut- veckla detta mätverktyg, uppmuntra studenter till att parprogrammera, uppmuntra studenter till att använda verktyget och studera parprogrammeringsmönster i olika kurser var uppdraget för detta exjobb.

I det här arbetet används ordet ”vi” i olika betydelser. När det gäller vad som gjorts från skolans sida betyder det lärarlaget som undervisar (där jag ingår som assistent). När det gäller programmeringen av Parkour (ett verktyg som beskrivs utförligt senare) så betyder ordet jag och Rasmus Kaj. När det gäller analys och slutsatser så betyder det jag och exjobbshandledaren. I övriga fall bör betydelsen som avses bör framgå från sammanhanget.

Parprogrammering har införts i tre steg på sju olika kurser på CSC: Vi säger (1) att det ska vara två studenter på en dator och (2) vi sätter namn på de olika rollerna (förare och navigatör). (3) Vi uppmanar dessutom studenterna att mäta hur lång tid de spenderar i respektive roll med hjälp av Parkour, det parprogram- meringsmätverktyg som tagits fram för det här arbetet. Parkour mäter i dagsläget hur studenterna växlar mellan roller och tar pauser men tanken är att verktyget på sikt ska kunna etablera beteendemönster för parprogrammering samt hitta sam- band mellan dessa mönster och studieresultat. Det senare ska uppnås genom att

1

Cerisegruppens beskrivning av och tankar kring parprogrammering finns på

http://www.csc.kth.se/tcs/projects/cerise/parprogrammering/

(9)

KAPITEL 1. INLEDNING koppla ihop det med automatiska rättningssystem och resultatsdatabaser för att dra slutsatser om vilka parprogrammeringsbeteenden som kan förutspå framgång och motgång.

Vi har sökt svar på följande två frågor:

• Kan Parkour användas som ett pedagogiskt verktyg vid införandet av parpro- grammering i datalogiundervisningen och motivera studenterna till parpro- grammering?

• Kan Parkour användas som ett mätverktyg för att studera hur studenterna parprogrammerar?

Syftet med detta arbete är att öka kvalitén på kod i samhället. Vi vill öka kun- skapsspridningen inom organisationer som ägnar sig åt programmering. Vi vill att den parprogrammering som utförs följer en struktur som leder till effektiv kom- munikation och effektiv lösning av problemen. Vi vill också genom att göra ett arbete om parprogrammering minska stereotypifieringen av programmering som ett yrke för ensamvargar. Det vill vi göra genom att utbilda ingenjörer som vet vad parprogrammering är.

2

(10)

Kapitel 2

Teoretisk bakgrund

I rapporten ”The benefits of Collaboration for Student Programmers” (1993) Be- skriver Judith Wilson et al [5] ett experiment där en grupp studenter på Temple University i Philadelphia fick lösa programmeringsproblem i par medan kontroll- gruppen fick lösa problemen individuellt. Man fann att parprogrammerarna (en då ännu inte klart definierad term) skrev mer läslig kod och uppskattade arbetet mer.

Wilson fann att kollaborativ inlärning på ett tidigt stadium kunde hjälpa studenter.

Vid det laget fanns ännu inte Extreme Programming och parprogrammeringsbegrep- pet. I boken ”Extreme Programming Explained: Embrace Change” (sid 81-82) be- skriver Kent Beck [1] sju år senare den moderna parprogrammeringen med en aktiv navigatör som planerar och kommenterar koden som föraren skriver. Två program- merare i par som växlar mellan rollerna som förare och navigatör är mer produktiva än två enskilda och även om de inte är det så är kodkvalitén högre tack vare kom- munikationen mellan dem. Även oerfarna programmerare lär sig snabbt och blir till hjälp med att hitta fel i koden. Han skriver också att parprogrammering inte är för alla och att man inte bör göra det hela tiden.

I rapporten ”In support of Pair Programming in the Introductory Computer Science Course” (2002) beskriver Laurie Williams et al [4] ett experiment där par- programmering ställdes mot soloprogrammering på labbar i en introduktionskurs i programmering. Experimentet gick till så att samma introduktionskurs gavs för två olika grupper där parprogrammeringsgruppen blev tvungna att parprogrammera och en soloprogrammeringsgruppen blev tvungna att lösa sina labbar individuellt.

Kursen hade föreläsningar och laborationer men inga övningstillfällen. Efter expe- rimentet följdes studenterna i ytterligare två år. Det visade sig att parprogramme- ringsgruppen fick högre betyg i den studerade kursen och under den longitudinella studien fick dessa studenter även högre betyg på efterföljande kurser i samma ämne.

I labbarna för parprogrammeringsgruppen kunde studenterna hjälpa varandra med

enkla frågor och assistenterna fick svara på mer avancerade frågor. I soloprogram-

meringsgruppen var det mer tyst. När studenterna pratade med varandra var de på

helt olika ställen i labben och hade svårt att relatera till varandras problem. De fick

(11)

KAPITEL 2. TEORETISK BAKGRUND vänta länge på hjälp och när de väl fick det så låg deras frågor på en låg nivå.

I ”Integrating Pair Programming into a Software Development process” (2001) beskriver Laurie Williams [3] ett experiment i en undervisningssituation där studen- terna själva fick välja om de ville parprogrammera eller lösa uppgifterna individuellt.

Resultatet blev att parprogrammeringsgrupperna blev klara snabbare och hade fär- re fel i sin kod. Det visade sig också att parprogrammerarna utövade ett positivt grupptryck på varandra som fick dem att prestera bättre.

För papperet ”Pair programming productivity: Novice-novice vs expert-expert”

(2006) av Kim Man Lui et al [2] genomfördes experiment i upprepad problemlös- ning. Man ville undersöka varför resultaten från tidigare parprogrammeringsstu- dier var såpass motsägelsefulla och kanske säga någonting om i vilka lägen som en organisation vinner respektive förlorar på parprogrammering. Studien visar att parprogrammering fungerar som bäst när uppgifterna som ska lösas är svåra och ingen av programmerarna har tidigare erfarenhet av problemet. När programme- rarna däremot ska lösa ett problem som liknar ett som de har löst så var vinsterna av parprogrammering små eller obefintliga.

I ”Industry-Inspired Guidelines Improve Students’ Pair Programming Commu- nication” (2013) beskriver Zarb et al [6] hur man studerat professionella parpro- grammerare, dels från videor som hittats på Internet och använts med tillstånd, dels genom att samla in egna videofilmer från olika programvaruföretag som deltog i studien. Parprogrammerarnas kommunikation delades in i tillstånd, valda för att vara enkla att identifiera, men ändå säga någonting om vad som försigår i kommuni- kationen. Tillstånden var (med samma översättning som Cerisegruppen använder) förslag, tyst tänkande, struntprat, förklaring, granskning, kod-diskussion och mutt- rande. Genom att studera tillståndsövergångar under olika faser av programmering- en utformades en serie riktlinjer för hur man bör parprogrammera. Dessa riktlinjer testades i ett experiment på Universitetet i Dundee. En studentgrupp fick riktlinjer för hur de skulle parprogrammera, medans en annan grupp fick agera kontrollgrupp.

Det visade sig att gruppen med riktlinjer presterade bättre än kontrollgruppen.

I uppföljningsstudien ”Evaluating Industry-Inspired Pair Programming Com- munication Guidelines with Undergraduate Students” (2014), även den av Zarb et.

al [7] hittar vi ett experiment med två grupper av studenter där båda parprogram- merar, men bara den ena gruppen (experimentgruppen) får ta del av riktlinjerna för parprogrammering. Kontrollgruppen får själva lista ut hur de ska kommunicera med varandra. Det visade sig att experimentgruppen presterade statistiskt signifi- kant bättre än kontrollgruppen.

2.1 Ett särskilt tack till...

Jag vill rikta ett särskilt tack till Rasmus Kaj som påbörjade ett parallellt examens- arbete en bit in i detta exjobb och hans stora insats för att göra Parkour till vad den är idag. Jag riktar också ett stort tack till min sambo och livskamrat Anna för allt hon är och ger. Tack också till den akademiska dynastin Eriksson för alla råd

4

(12)

2.2. ETIK, SAMHÄLLE OCH HÅLLBARHET

på vägen, främst Viggo Kann som handleder exjobbet.

2.2 Etik, samhälle och hållbarhet

Eftersom studier och experiment visat att studenter tjänar på att parprogrammera så är det inte etiskt att göra ytterligare experiment. I ett reproducerande experi- ment skulle vi i så fall neka grupper av studenter ett bra verktyg för inlärning och utveckling och det är oacceptabelt.

Parprogrammeringen hjälper samhället bli mer hållbart genom att öka kvalitén och läsbarheten på koden. Läsbarheten är viktig eftersom den förenklar underhåll, särskilt när koden ska underhållas av utomstående eller av de som skrev koden, fast för såpass länge sedan att de lika gärna kunde ha varit utomstående. Fler personer i en organisation kommer på kort sikt att vara insatta i hur koden fungerar vilket innebär en mindre förlust för organisationen om en enskild programmerare blir otillgänglig på grund av sjukdom, semester, byte av arbete, byte av arbetsuppgifter eller annat skäl till frånvaro.

I vår undersökning förväntade vi oss att studenterna skulle lägga tid på att sätta

sig in i vårt mätverktyg och använda det under sina laborationer. Vi förväntade oss

också att de skulle svara på en enkät som vi skulle informera om genom att skicka

ut ett mail, vilket kan uppfattas som skräppost av vissa studenter. Det försvarar vi

med att många av de studenter som bidrar med data och fyller i enkäten kommer

att känna sig mer delaktiga i undersökningen och därför vara mer intresserade av

att ta del av och sprida bakgrunden och resultaten.

(13)
(14)

Kapitel 3

Metod

3.1 Designprocess för mätverktyget

Målet med verktyget är dels att mäta studenternas parprogrammering, men ock- så att vara ett pedagogiskt verktyg som motiverar och förklarar delar av parpro- grammeringen för dem. För att mäta studenternas beteende tittade vi på befintliga mätverktyg men fann att de verktyg som fanns var för komplicerade eller saknade den funktionalitet som vi behövde. En skiss och preliminär teknisk beskrivning på mätverktyget presenterades på ett möte med Cerisegruppen. De närvarande med- lemmarna presenterade synpunkter och idéer på ytterligare funktionalitet och efter diskussioner med exjobbshandledare kom vi fram till vad som inkluderas i verktyget för exjobbet och vad som skjuts upp till kommande versioner. Verktyget fick nam- net Parkour. Det diskuterades om verktyget skulle ha en fristående klient eller som det skulle vara en webbapplikation. Vi bestämde oss för att en webbapplikation var bäst eftersom det fungererar med olika operativsystem och är lättare att sätta i drift och uppdatera än en fristående klient. Vi funderade också på om verktyget skulle kräva inloggning eller inte och fann att det är bäst att låta det kräva inloggning.

Dels förbättrar det säkerhet och möjlighet att utkräva ansvar för registrerade klick i databasen, dels leder det till att felstavningar spelar mindre roll i databasen.

3.2 Användarbeskrivning

Användarna är studenter på en teknisk högskola. De förväntas vara vana vid att

använda en modern datormiljö. Deras motiv för att använda verktyget är för det

första att parprogrammering kommer att förbättra deras inlärningsprocess. Verk-

tyget kommer i sin tur att förbättra parprogrammeringsprocessen genom att göra

det lättare att hålla koll på när det är dags att byta förare.

(15)

KAPITEL 3. METOD

3.3 Användningsscenarier

Nedan beskrivs några fiktiva exempel på hur verktyget skulle fungera som har varit vägledande vid designen av Parkour. Dessa har vuxit fram ur anteckningar från ett möte med Cerisegruppen där kursledarna för de berörda kurserna fick uttrycka sina åsikter.

3.3.1 Första gången

Mia och Anna sätter sig vid en dator i en labbsal på KTH. Mia loggar in och startar utvecklingmiljön och en webbläsare. I webbläsaren öppnar hon en separat flik för tidmätningsverktyget. (1) Hon loggar in via KTH:s centrala inloggning och (2) möts av en webbsida där hon uppmanas att mata in sin labbkompis KTH-id.

När hon har gjort det och klickat ”start” så sänds hon till huvudmenyn (3) där hon klickar på sitt eget namn för att markera att hon börjar i rollen som förare.

Mia anger dessutom att de ska byta efter 45 minuter genom att fylla i ett fält och klicka ”starta nedräkning” (4). När 45 minuter har gått börjar webbläsarfliken att blinka (5) för att visa att det är dags att byta roll. Anna och Mia byter roller, men fortsätter använda Mias inloggning, både på datorn och i verktyget. Efter 6 pass och 5 byten är det dags att gå hem, men innan Mia loggar ut så passa hon på att klicka på statistiksidan där hon och kompisen kan se en tabell på hur långa deras skift har varit (6) samt fördelningen av vardera students egna timeslots i ett tårtdiagram.

Slutligen loggar Mia ut från sin dator och därmed också verktyget.

3.3.2 Några gånger senare

Anders och Fernando har länge arbetat tillsammans på olika laborationer i olika kurser. De sätter sig i en av skolans datasalar för att arbeta och Anders loggar först in på datorn och sedan via en webbläsare i tidsmätningsverktyget. Verktyget är redan inställt på att de jobbar tillsammans och dessutom är den kurs och laboration som de senast jobbade med markerad som aktiv i verktygets huvudmeny. Det visar sig dock att senaste gången de arbetade med labben så glömde de att stänga av klockan för sista passet, så Fernandos timer står fortfarande och tickar på. Genom att klicka på knappen ”justera de senaste tiderna” kan de korta av passet till kl 17 igår. Anders klickar sedan på sitt namn och blir därmed förare i dagens första arbetspass.

3.3.3 Statistiken påverkar

Beatrice och Camilla tittar på statistikvyn och upptäcker att Camilla spenderat oproportionerligt mycket tid i förarrollen. Därför får Beatrice börja och sluta i för- arrollen den dagen och efter dagens slut har statistiken utjämnat sig något.

8

(16)

3.4. DESIGN AV INLOGGNING OCH SÄKERHET

3.3.4 Redovisning

Eva och Juan har skrivit klart sin labb i adk och är redo att redovisa. När Olivia som är assistent på kursen kommer fram för att ta redovisningen så går hon igenom sin checklista på vad som ska fungera i labben. Den sista punkten på listan är att titta på statistiken i Parkour. Hon klickar på statistikfliken och ser på tårtdiagrammet att Eva har spenderat 53% av tiden i förrarrollen vilket ligger inom ramarna för rättvis fördelning. Efter att Oliva har ställt en fråga om hur parprogrammeringen har fungerat så får båda godkänt på labben.

3.4 Design av inloggning och säkerhet

Studenterna kan komma åt Parkour genom att gå in på dess webbsida. Om studen- ten inte redan är inloggad promptas hen att logga in via KTH:s centrala inloggning och därefter presenteras en välkomstsida där studenten ska välja kurs, labbkamrat och labb. För att undvika att studenten stavar fel på sin labbkompis används Twit- ter typeahead, en form av tabbkomplettering med val från meny för att hitta rätt användare. När alla fält är korrekt ifyllda kan studenten klicka på start för att tas till huvudsidan. För att studenten ska kunna hitta sin labbkompis i databasen så måste labbkompisen ha loggat in i systemet tidigare. Detta står skriftligt på pro- grammets förstasida. Utan inloggning hade Parkour varit enklare att använda, men vi valde att ha inloggning för att minska risken för felaktigt data från obehöriga och samtidigt ha möjlighet att utkräva ansvar. Dessutom läcker Twitter typeahead användarnamn för utomstående så enligt KTH:s regler behöver vi kräva inloggning.

3.5 Design av tidmätning

Parkour är designat enligt principen att klientsidan inte ska kunna göra någon- ting som inte användarna ska kunna göra själva. Det innebär att serversidan aldrig skickar värdet av sin timer till klientsidan utan enbart vilka klick som görs i gräns- snittet. Det innebär att om man vill förfalska Parkour så räcker det inte med att titta på vad som postas och modifiera dessa signaler. Det krävs antingen att man bryter sig in i servern för att editera databasen eller gör ett script som skickar knapptryckningar med lämpliga, lätt varierade mellanrum.

3.6 Design av huvudsida

Huvudsidan är medvetet enkel. Vi vill att studentera ser parprogrammeringen be-

finner sig i ett av tre tillstånd och har tre knappar för studenten där hen kan välja

mellan att sätta sig själv som förare, sin labbkamrat som förare eller pausa sessio-

nen. På huvudsidan finns också en timer som efter ett klick på endera förarknapp

börjar räkna ner från 15 minuter. Denna nedräkningstimer är inte konfigurerbar för

studenten och då räkneverket når 0 så fortsätter den att räkna ner med negativa tal.

(17)

KAPITEL 3. METOD Figur 3.1: Inloggningssidan.

På sidan står det också en uppmaning att klicka paus vid slutet av en labbsession så att systemet inte tror att studenten fortfarande är på skift över lunch eller över helgen. För ett exempel på hur det kan se ut, se figur 3.2.

Figur 3.2: Huvudsidan med knappar för att ange förare samt paus.

3.7 Design av statistiksida

Den tredje sidan i webbgränssnittet är en statistiksida där studenten kan välja kurs och labb för att få varje skift i varje session presenterade som en lista. Här visas också ett tårtdiagram som anger hur stor andel av tiden som studenten och

10

(18)

3.8. DESIGN AV LOGGANALYSVERKTYG

labbkamratenhar spenderat i förarrollen. Den här sidan är tänkt som en feedback där studenterna ska kunna se hur de ligger till och anpassa sin tidsfördelning efter hand. Sidan visas också upp för assistenterna vid examination. För en illustration av hur det kan se ut med fiktiva data, se figur 3.3.

Figur 3.3: Statistik efter två låtsasstudenter (exjobbshandledaren och exjobbaren).

3.8 Design av logganalysverktyg

Serverns databas loggar för varje klick på någon av huvudsidans tre knappar föl- jande data:

• Knapp som klickats på.

• Tidpunkt enligt ISO 8601 1 .

• Inloggad student.

• Labbkamrat till inloggade studenten.

• Kurskod.

• Labbnamn.

1

ISO 8601 är en internationell standard för tidsangivelser. Se

http://www.iso.org/iso/home/standards/iso8601.htm

(19)

KAPITEL 3. METOD Serverns databas kan exporteras till ett analysverktyg som sätter ihop knapptryck- ningarna till förarpass och labbpass. Med förarpass menas datat för en student, hens labbkamrat, vem som är förare och tiden mellan det att förarens knapp trycktes på och en av de andra två knapparna trycktes på (paus eller att den andra studenten är förare). Med labbpass menas en i tid sammanhängande mängd förarpass och kortare pauser för ett par studenter. För att undvika felaktiga data i analysen så gallras alla förarpass som är kortare än 100 sekunder eller längre än två timmar. Vi tror att förarpass som är kortare än 100 sekunder är ett resultat av felklickningar och inte riktiga pass. Förarpass som är längre än två timmar gallras eftersom vi då misstänker att studenterna glömt att klicka i vid byte eller att de glömt verktyget på vid lunch eller fika. Analysverktyget gallrar också knapptryckningar från svartlista- de användare vilket för närvarande bara är lärare och lärarassistenter så att dessa ska kunna testa verktyget i utvärderingssyfte utan att det påverkar mätningar på riktiga kurser.

3.9 Parkour som pedagogiskt verktyg

En av de främsta pedagogiska principerna var att hålla det enkelt. Vi har ett mini- malt antal knappar på varje sida och ett klart syfte för varje delsida som förmedlas med en kort beskrivning. Huvudsidan ger feedback i form av en timer. Så fort man trycker på någon av förarknapparna så startar en nedräkningstimer och så fort man trycker på paus startar en uppräkningstimer. Det här är främst för att vi vill att verktyget ska mana studenterna att byta förare ofta, men det är också ett försök att efterlikna mediespelare där man vet att man har tryckt rätt om någon slags timer börjar ticka ner. För att mana studenterna till att dela på tiderna rättvist så har vi en statistiksida där uppdelningen illustreras grafiskt med ett tårtdiagram. Tanken med det är att studenterna ska se om någon har gjort en mycket större andel av jobbet och anpassa fördelningen därefter.

3.10 Val av verktyg och programspråk

Klienten började utvecklas med Yeomans workflow 2 för webbapplikationer. Tidiga versioner av Parkour använde Angular, men när Rasmus Kaj (den andra exjobbaren som gjorde ett parallellt arbete) kom ombord på projektet kastades det ut till förmån för vanligt javascript och html5 för han arbetar helst utan färdiga ramverk.

Backend skrevs i Google Go 3 , ett nytt språk (2009) med bra concurrency-modell.

2

Yeoman är en uppsättning rekommenderade verktyg för webbapplikationer och återanvändbar exempelkod för att snabbt få igång webbaplikationer. Se http://yeoman.io

3

Google Go är ett modernt språk som används i en grundkurs i parallellprogrammering på KTH.

Det används mest på serversidan och är designat för att vara minimalistiskt. För mer information se https://golang.org/

12

(20)

3.11. KURSERNA OCH SKILLNADER I HUR VERKTYGET INFÖRDES

Tyvärr fanns det inte färdiga bibliotek att tillgå för exempelvis CAS-inloggning 4 så detta fick implementeras separat i språket. Databasen är av typen Mongodb 5

3.11 Kurserna och skillnader i hur verktyget infördes

Parkour har införts med lite olika instruktioner i olika kurser på CSC:

• Algoritmer, datastrukturer och komplexitet (adk) en obligatorisk kurs i års- kurs 3 för studenter på datateknik som är valbar för studenter från andra program. Det var tänkt att Parkour skulle vara obligatoriskt här, vilket stod i labblydelserna. I slutändan blev det valbart år 2014 eftersom Parkour inte var tillräckligt stabilt ännu. Under 2015 var det däremot obligatoriskt. Un- dertecknad arbetade som övningsledare och labbassistent på kursen.

• Numeriska metoder (nump) Numeriska metoder är en obligatorisk kurs för Design och Produktframställning. Att använda Parkour var frivilligt och un- dertecknad arbetade inte på kursen.

• Programmeringsteknik för samhällsbyggnad (prgs) är en obligatorisk kurs för studenter i årskurs 1 på Samhällsbyggnad. Att använda Parkour var valfritt och undertecknad arbetade inte på kursen.

• Tillämpad datalogi (tilda) är en obligatorisk kurs för civilingenjörsutbildning- arna Industriell ekonomi (årskurs 2) och medieteknik (årskurs 2). Att använda Parkour var valfritt och undertecknad arbetade bara enstaka labbpass på kur- sen.

• Programmeringsteknik för civilingenjör och lärare (prgcl) är en obligatorisk kurs för årskurs 1 på programmet Civilingenjör och lärare. Att använda Parkour var obligatoriskt och undertecknad arbetade på kursen som labbassistent och övningsledare.

• Objektorienterad programmering är en obligatorisk kurs för årskurs 1 på Stockholms universitets kandidatprogram i datalogi. Att använda Parkour var obligatoriskt på de första 2 labbarna och frivilligt på de senare 2. Under- tecknad arbetade på kursen.

• Programmeringsteknik och matlab för media (prgmed) är en obligatorisk kurs för årskurs 1 på civilingenjörsutbildningen i medieteknik. Det har dels varit krav på att Parkour används på samtliga labbar och att det ställdes som krav att ingen uppdelningen mellan studenterna fick vara högst 67% mot 33%. Med andra ord fick ingen student spendera mer än dubbelt så lång tid i förarrollen än sin labbkompis. Undertecknad arbetade som labbassistent på kursen.

4

Central Authentication Service. För mer information om hur det fungerar på KTH, se:

https://www.kth.se/social/group/cas/page/kth-specifik-information/

5

Mongodb är en enkel databas som i princip bara är en persistent hashtabell. Information om

den finns på https://www.mongodb.org/

(21)

KAPITEL 3. METOD

3.12 Mätperioderna och hantering av problem

Den första perioden av mätningar ägde rum mellan 2014-11-03 och 2015-04-08.

Vid kursstarterna vid slutet av januari fick vi in rapporter om att Parkour inte registrerade vissa användare. När vi studerade problemet i detalj konstaterade vi att buggen berodde på ett teckenkodningsproblem för specialtecken i namn (till exempel ”å”, ”ä”, ”ö”, ”é” och ”ü”). Problemet var löst 2015-01-25 och därefter fick vi inga fler rapporter om buggen och resultaten i databasen tyder på att det fungerar. Ett annat problem var att när Parkour-servern startas om så startar inte själva tjänsten upp automatiskt. Det här har under mätperioden stundtals lett till att Parkour blivit otillgängligt och användarna bara presenterats med en sida som berättar att tjänsten är otillgänglig. Vår temporära lagning är att när servern startas om för kärnuppdatering eller liknande så loggar en av oss med access in på servern och startar om den manuellt. Den sista mätperioden ägde rum i period 1 HT 2015.

Vid det här laget var Parkour stabil med bra uptime men vår inloggning stängde ute ett antal studenter från Kista som inte fanns i den LDAP-databas där det görs användaruppslagningar. Vi hade ingen tid att göra en separat användardatabas för dessa studenter så lösningen blev att låta dessa studenter slippa rapportera i Parkour.

3.13 Utvärderingsmetod

För att utvärdera Parkour har vi genomfört två webbenkäter via Google forms.

Enkäten bestod av sju frågor varav två var flervalsfrågor och fem var öppna frågor.

För att få studenterna att fylla i enkäten så skickade vi ut ett massutskick av mail i början av juni under tentaperioden/början av sommarlovet.

Efter den andra testperioden genomfördes en andra enkätundersökning för adk- kursen i period 1. Den här gången med en ny fråga om hur verktyget har påverkat hur studenternas parprogrammering sett ut under perioden.

Vi valde vid båda tillfällena att skicka ut mailen till de mailadresser som vi hittat i Parkours loggar för respektive kurs. Vi har alltså inte mailat studenter som inte har använt Parkour och alla mail har skickats till studenternas KTH-mail.

Vi har också genomfört en intervju med en av kursledarna.

14

(22)

Kapitel 4

Resultat

Vi redogör först för logganalyser från Parkour, fortsätter med svaren från online- enkäterna och avslutar med en intervju med en kursledare.

4.1 Deltagande

Det deltagande vi sett i Parkours loggar presenteras i tabell 4.1. Kurserna och labbarna där Parkour var obligatoriskt att använda är stjärnmarkerade. Alla som har använt Parkour till att logga minst ett pass räknas som användare, men inte de som är registrerade på kursen och har gått in på sidan utan att klicka i någon förare. Av resultaten följer att när det är valfritt att använda Parkour så har en liten minoritet deltagit. Då det har varit obligatoriskt har majoriteten av de kursaktiva deltagit, men när det slutar vara obligatoriskt har deltagandet avtagit kraftigt. Det är svårt att hitta ett bra mått på hur många som faktiskt har gått kursen så jag valde antal registreringar. För kurserna adk och cprog innebär det en betydligt högre siffra än de faktiskt kursaktiva eftersom de kurserna har många omregistrerade studenter.

Parkour tillåter att studenter byter labbkamrat mellan labbar (och inom samma labb). Inget par har loggdata från flera olika kurser.

4.2 Genomsnittliga tider

Det finns 2981 förarpass i Parkour som är längre än 100 sekunder. Den vanligaste

enskilda längden på ett förarpass är strax över 15 minuter. 10% av alla förarpass är

mellan 15 och 16 minuter. Motsvarande siffror för 14-15 minuter är 4.2% och för 16-

17 minuter 5.4%. Överrepresentationen av 15-minuters förarpass hänger antagligen

ihop med att Parkours webbgränssnitt startar en timer som räknar ner från 15

minuter varje gång man påbörjar ett nytt förarpass och studenterna har försökt

hålla den tiden. Medelvärdet för förarpassen hamnar på 25 minuter och 25 sekunder

och standardavvikelsen är 19 minuter. Se figur 4.1.

(23)

Figur 4.1: Histogram över alla förarpass sorterade på längd.

15 30 45 60 75 90 105 120

förarpassens längd (minuter) 0

50 100 150 200 250 300 350

antal förarpass

Alla förarpass i Parkour

Nästa observation om förarpassen är de långa pass där tiderna är längre än en timme. Det är inte rimligt att det är resultatet av parprogrammering utan snarare av att studenterna glömt bort verktyget. Det är möjligt att vi skulle ha färre långa pass om vi tillät studenterna att redigera sina loggar och plocka bort eller åtminstone markera felinmatade pass.

De flesta sessioner var kortare än två timmar eftersom det är den vanligaste längden på labbpass. Kursen oop hade enstaka labbpass som var fyra timmar men vi räknar med att alla sessioner som är längre än så är felinmatningar där studenterna glömt att klicka på stopp och sedan inte haft redigeringsmöjligheter. Se figur 4.2.

4.3 Andel tid i förarrollen

Hur stor andel av den loggade labbtiden spenderade en student i förrarollen? Vi har räknat ihop alla sessioner med samma par och undersökt hur stor andel av tiden som varje student tillbringat i förarrollen. I figur 4.3 presenteras de studenter i varje par som spenderade mest tid i förarrollen. Totalt av 200 par har vi ett medel på 59% med en standardavvikelse på 11%.

Om vi begränsar datat till de kurser där Parkour var obligatoriskt så ligger me- delfördelningen i paren mellan 50%-53% för varje kurs. Vi hade förväntat oss att prgmed skulle ha en rättvisare fördelning än de andra eftersom den hade examina- tionskrav på det, men datat styrker inget sådant.

För att mäta om enskilda studenter tenderade att spendera mer tid i förarrollen

än sin labbkamrat så mätte vi om olika förare hade högre genomsnittliga förarpass-

(24)

Kurs Anv. Reg. Genomsnittlig förarpasslängd Främsta förarens andel

adk* 195 313 25 min. 34 sek. 50%

cprog 3 280 27 min. 22 sek. 94%

nump 6 263 34 min. 2 sek. 59%

oop* 31 44 29 min. 30 sek. 52%

prgcl* 53 80 21 min. 54 sek. 53%

prgmed* 66 81 25 min. 23 sek. 51%

prgs 8 173 26 min. 23 sek. 61%

tilda 2 221 24 min. 7 sek. 59%

adk:labb1* 192 313 25 min. 23 sek. 51%

adk:labb2 17 313 32 min. 30 sek. 52%

adk:labb3 0 313

adk:labb4 4 313 23 min. 33 sek. 58%

cprog:labb1 3 280 27 min. 22 sek. 94%

nump:labb2 2 263 34 min. 10 sek. 62%

nump:labb3 5 263 29 min. 56 sek. 68%

nump:labb4 4 263 38 min. 25 sek. 53%

oop:labb1* 29 44 26 min. 0 sek. 50%

oop:labb2* 19 44 30 min. 31 sek. 51%

oop:labb3 10 44 40 min. 15 sek. 59%

oop:labb4 2 44 1 tim. 32 min. 12 sek. 100%

prgcl:labb1* 39 80 20 min. 54 sek. 57%

prgcl:labb2* 34 80 19 min. 12 sek. 51%

prgcl:labb3* 29 80 23 min. 51 sek. 53%

prgcl:labb4* 40 80 22 min. 57 sek. 51%

prgcl:labb5* 25 80 22 min. 59 sek. 56%

prgmed:labb1* 17 81 19 min. 48 sek. 54%

prgmed:labb2* 20 81 22 min. 28 sek. 52%

prgmed:labb3* 19 81 42 min. 31 sek. 51%

prgmed:labb4* 22 81 24 min. 15 sek. 53%

prgmed:labb5* 45 81 22 min. 56 sek. 56%

prgmed:labb6* 37 81 27 min. 25 sek. 52%

prgmed:labb7* 18 81 27 min. 50 sek. 54%

prgs:labb1 1 173 1 tim. 13 min. 48 sek. 100%

prgs:labb3 4 173 20 min. 9 sek. 54%

prgs:labb4 2 173 23 min. 54 sek. 67%

prgs:labb5 2 173 23 min. 35 sek. 65%

prgs:labb6 3 173 29 min. 40 sek. 50%

tilda:labb6 2 221 24 min. 7 sek. 59%

Tabell 4.1: Från vänster: kursens förkortning där en asterisk betyder att parkour var

obligatoriskt att använda på vissa moment i kursen (om det är en kursförkortning)

eller på hela labben (om det är en labb), antal studenter med registrerade förarpass

i Parkour, antal registrerade studenter (inklusive omregistreringar och inaktiva stu-

(25)

KAPITEL 4. RESULTAT Figur 4.2: Histogram över alla labbpass sorterade på längd.

1 2 3 4 5 6 7 8 9 10

sessionernas längd (timmar) 0

10 20 30 40 50 60 70 80

antal sessioner

Alla sessioner i Parkour

tider i första respektive sista halvan av deras samlade förarpass. I 40% av fallen hade paret bytt främsta förare under andra halvan. Vi hade förväntat oss en högre förändring i prgmed där fördelningskrav var en del av examinationen, men den höll sig på samma 40% som resten av kurserna. Se figur 4.3 och tabell 4.1.

4.4 Resultat av enkätundersökningar

Vi genomförde två enkätundersökningar under 2015 en på våren och en på hösten.

4.4.1 Vårens enkät

Vi skickade ut mail till de 150 studenter som hade tider registrerade i Parkour från de tre kurser som fått flest aktiva användare (studenter med tider registrerade i Parkour) nämligen oop, prgcl och prgmed. Vi fick totalt 25 svar varav 3 från oop och 11 från vardera prgcl och prgmed.

På frågan om studenterna stört sig på krascher svarade samtliga 3 från oop ja.

Av studenteran från prgcl så svarade 2 att Parkour hade haft svårt att hitta deras namn i början men att det löste sig senare.

På frågan om Parkour var lätt att använda när det väl fungerade så svarade 2/3 oop-studenter och 9/11 prgs och prgcl-studenter ja. En student efterlyste en

18

(26)

4.4. RESULTAT AV ENKÄTUNDERSÖKNINGAR

Figur 4.3: Den vanligaste föraren var förare så här stor andel av tiden.

50 60 70 80 90 100

Andel av labbtiden (procent) 0

5 10 15

Antal par

Den vanligaste förarens andel av totala tiden

manual. En annan student svarade att det tog lite för lång tid att vänja sig vid det, men efter det så fungerade det bra.

Frågan som skillde de olika kurserna åt var:

”Har Parkour bidragit till att du lärt dig parprogrammera” De tre studenterna från oop svarade alla ”Neutralt”. Av 11 studenter från prgcl så svarade fem ”Neutralt”, fem ”Ja, troligen” och en ”Ja, definitivt!”. Av 11 studenter från prgmed svarade fem

”Neutralt” och sex ”Nej, tvärtom är det förvirrande.”

Se figur 4.4

Vanligaste efterfrågade förbättringen var att lägga till någon form av notifikation när det är dags att byta.

4.4.2 Höstens enkät

Vi skickade ut mail till de 195 studenter som hade tider registrerade i Parkour för adk höstterminen 2015 och fick in 20 svar. Frågorna var samma som på våren fast frågan om vilken kurs studenten följt var utbytt mot:

”Skulle du ha parprogrammerat i labb 1 lika mycket även utan loggverktyget Parkour?”

Svaren på den frågan återfinns i figur 4.5 och här kan vi se att 60% svarar ja defini-

(27)

KAPITEL 4. RESULTAT

Figur 4.4: Enkätsvar från vårterminen 2015, kurserna oop, prgcl och prgmed.

Har Parkour bidragit till att du lärt dig parprogrammera?

Ja, definitiv t! : 1 Ja, definitiv t! : 1

Ja, troligen : 5 Ja, troligen : 5

Neutralt : 13 Neutralt : 13 Nej , tv ärtom är det förv irrande : 6

Nej , tv ärtom är det förv irrande : 6

Ja, definitivt! Ja, troligen Neutralt Nej, tvärtom är det förvirrande

meta-chart.com

tivt eller ja troligen på frågan om Parkour har lärt dem parprogrammera. Här ser vi också att hela 80% anser att de har parprogrammerat mer på grund av verktyget Parkour. Vi ställde återigen frågan om Parkour har lärt studenterna parprogram- mera och resultatet finns i figur 4.6.

På frågan om de stört sig på buggar så svarade nio småsaker som att man behövde trycka på knapparna två gånger för att få timern att gå igång medan bara en klagade på att Parkour inte varit tillgängligt.

På frågan om Parkour varit lätt att använda så svarade 18/20 ja. En student tyckte att det tog ett tag att vänja sig och att statistiksidan var svår att hitta.

En annan student förstod inte varför man behövde logga in två gånger innan man kunde börja använda systemet.

Det framgår klart från enkätsvaren att det varit jobbigt att logga tider och att de flesta studenter var glada att slippa, men att det ändå kunde ha varit ett bra verktyg för att komma igång med parprogrammering.

På den friare frågan i slutet skrev en student ”Bra verktyg som jag tror även framtida kursomgångar skulle ha nytta av! :)”

20

(28)

4.5. INTERVJU MED EN KURSLEDARE

Figur 4.5: Skulle studenterna ha parprogrammerat utan Parkour? Enkätsvar från höstterminen 2015, kursen adk. 20 studenter svarade.

Skulle du ha parprogrammerat i labb 1 lika mycket även utan loggverktyget Parkour?

1 1

9 9

6 6

3

3 1

1

Nej, jag skulle inte ha gjort parprogrammering alls.

Jag skulle ha testat parprogrammering, men inte mycket mer.

Jag skulle ha parprogrammerat nästan lika mycket utan loggverktyg.

Jag skulle ha parprogrammerat lika mycket utan loggverktyg.

Jag skulle ha parprogrammerat mera om jag inte hade haft ett loggverktyg.

meta-chart.com

4.4.3 Båda enkäterna

Den enskilt mest efterfrågade funktionen var en ljudeffekt eller notifiering då det är dags att byta förare.

4.5 Intervju med en kursledare

En av kurserna hade Parkour som obligatoriskt hjälpmedel på samtliga labbar, prgmed. Från en intervju med kursledaren framgick att parprogrammeringen hade införts genom att länka till de skriftliga instruktionerna och att skriva på varje labblydelse att parprogrammering med Parkour är obligatoriskt samt att beskriva parprogrammering och prata om dess värde under introduktionsföreläsningen.

I början blev det mycket klagomål på att Parkour kraschade (innan vi fick det stabilt) och det blev problematiskt eftersom det var obligatoriskt. De löste det då genom annan rapportering (papper och penna).

Kursledaren berättade också att Medias studentrepresentant berättat att me-

diastudenter utbrett förfalskar Parkour. De sitter och programmerar på samma

uppgift över instant messaging separat och klickar om i Parkour när det känns

lämpligt. Dvs det är inte parprogrammering alls utan en annan uppdelning av ar-

(29)

KAPITEL 4. RESULTAT

Figur 4.6: Enkätsvar från höstterminen 2015, kursen adk.

Har Parkour bidragit till att du lärt dig parprogrammera?

Ja, definitiv t! : 6 Ja, definitiv t! : 6

Ja, troligen : 7 Ja, troligen : 7 Neutralt : 6

Neutralt : 6

Nej , tv ärtom är det förv irrande : 2 Nej , tv ärtom är det förv irrande : 2

Ja, definitivt! Ja, troligen Neutralt Nej, tvärtom är det förvirrande

meta-chart.com

betsuppgifter med fejkade loggar. Kursledarens kommentar om detta ”Det har varit ett perfekt exempel på ’folk följer de incentiv [sic] ni sätter upp’, Jag bestämde mig tidigt i kursen att jag s****r fullständigt i hurpass väl de verkligen följer parpro- grammeringsidealen. En av de främsta anledningarna till det är att jag inte såg något kursvärde i att göra parprogrammering viktigare än objektorientering eller kodkommentarer.”

Angående att ha det i en grundkurs för årskurs 1 så sa han ”På det här sättet får de kontakt med att det finns projektplaneringsstrukturer. Det här med att par- programmering finns kommer inte att vara okänt för dem. Kursen handlar inte om projektplaneringsstrukturer och det är orimligt att examinera studenter som ald- rig har sett programmering före den här kursen på huruvida de klarar av en strikt parprogrammeringsmetod.”

22

(30)

Kapitel 5

Slutsats och diskussion

5.1 Slutsats

Parkour har lyckats motivera studenterna att börja med parprogrammering. Det styrks av enkäterna, särskilt höstenkäten. Se figur 4.6

Examinationen av labbarna visar att studenterna vet vad de olika rollerna (förare och navigatör) innebär.

Vill man ha loggar och många studenter som har provat på parprogrammering så ska man se till att göra det obligatoriskt att logga. Det visar höstenkäten samt loggarna i Parkour. Den enda skillnaden vi märkt mellan de olika sätten att införa Parkour på är att om det är obligatoriskt så får vi mycket data.

Parkour kan ge kursledarna data om studenternas beteende, men bara om det är obligatoriskt att använda verktyget.

Typvärdet för ett förarpass ligger på 15 minuter men medelvärdet ligger på det betydligt högre 25 minuter och 25 sekunder.

Att införa parprogrammering kan möta motstånd från kursledare. Det visar intervjun.

Vi märkte ingen större skillnad i rättvis fördelning mellan förarrollerna om det var examinationskrav på högst 67% av förartiden för den förare som spenderade mest tid i förarrollen. Det visar tabell 4.1

5.2 Diskussion

Vad gäller de uppmätta medeltiderna så har de förskjutits uppåt en hel del av studenternas glömska och begränsade editeringsmöjligheter, samt nedåt på grund av den hårdkodade 15-minuterstimern i Parkour.

Från enkätundersökningarna framgick att studenterna parprogrammerade mer eftersom verktyget fanns och den mest intressanta och glädjande kommentaren från höstens enkät var:

”Jag använde Parkour i labb 1 i ADK:n och det är ett bra verktyg för att börja

parprogrammera. Men i labb 2 och labb 3 har jag och min labbpartner parprogram-

(31)

KAPITEL 5. SLUTSATS OCH DISKUSSION merat men inte loggat tiden, jag tycker att det var något besvärligt. Jag tycker att vi har fått en känsla för hur det är att parprogrammera och behöver inget verktyg för att logga tiden för att kunna parprogrammera. Det jag försöker säga är att det är ett bra verktyg för att börja parprogrammera, men jag skulle inte vara intresserad av att använda Parkour i framtiden för varken parprogrammering eller något annat användningsområde.”

Från enkäterna framgick också att den mest efterfrågade funktionen i Parkour var en ljudeffekt då det var dags att byta förare. Vi hade avfärdat den funktionen eftersom verktyget bara är en prototyp med begränsad funktionalitet, datasalarnas labbdatorer har ändå inga högtalare och om studenterna trots allt loggade in med egna laptopar det fanns risk att ljudeffekten skulle bli störande och förvirrande för andra i samma labbsal. Man kan tänka sig att var 15:e minut under ett labbpass så börjar det plinga vid en massa datorer och alla undrar om det är just dem det gäller. Med lite förskjutningar av att folk kommer vid olika tider eller väljer olika längder på förarpass så kan plingandet bli konstant och störande. Nu i efterhand med loggar och enkäter verkar det ha varit en bättre ide att inkludera funktionen trots att den kan vara störande. Andra idéer som popupfönster som stjäl fokus har avfärdats med att det skulle vara störande om verktyget plötsligt avbröt då föraren är i mitten av en rad. Moderna webbläsare kan skicka desktop notifications vid byte. Det är ett mindre störande alternativ, men den kan studenterna lätt missa om båda tittar på ett UML-diagram eller läser någon annan pappersdokumentation när den dyker upp på deras skärm.

Vi ville inte ge studenterna obegränsade editeringsmöjligheter i Parkour eftersom vi fruktade att det skulle leda till förfalskade loggar. I slutändan var vi för strikta åt andra hållet och förbjöd studenteditering helt och hållet. Det har lett till att vi måste gå igenom loggarna och försöka gissa vad som är felinmatningar och bort- glömda klick. Det är lätt när man ser förarpass på 10 timmar, men omöjligt med ett förarpass på 40 minuter.

Studenter vill gärna inför examinatorer framställa sig själva som ambitiösa (log- ga mer tid), produktiva (logga mindre tid) och rättvisa (logga lika mycket tid). Vi har inget sätt att upptäcka om studenterna har loggat för mycket tid eftersom stu- dentpar är olika produktiva. Om vi har studenter som spenderat orättvist mycket tid i förarrollen så har det inte alls synts i loggarna. Är det då så att studenterna faktiskt har fördelat tiden mer rättvist, att vi har haft en sammanblandning av rollerna där navigatören dikterar för föraren istället för att vara navigatör, att flera kurser än prgmed har förfalskat sina loggar i någon större utsträckning?

Studenter är vana vid att inte få tiden loggad av ett automatiskt verktyg och det kan ses som att en sån här undersökning är ett intrång i deras privata sfär. Om det är så och det dessutom är utbrett så kan vi aldrig räkna med att kunna utforma ett verktyg som manar dem att fortsätta. Som intervjun antydde skulle det kunna förändras om det fanns ett alternativ att köra Parkour utan loggar, anonymt eller med loggar som endast visas för studenterna själva.

24

(32)

5.3. VIDAREUTVECKLING AV PARKOUR

5.3 Vidareutveckling av Parkour

Nedan följer de tre bästa idéerna för att göra om Parkour för att få fler studenter att använda verktyget, fortsätta använda det och ge oss bättre loggar.

• Lägg till en signal då det är dags att byta. Det innebär att studenterna inte själva behöver hålla koll på tiden utan kan fokusera på annat. Detta var studenternas mest efterfrågade funktion.

• Ge studenterna begränsade editeringsmöjligheter över de registrerade tiderna.

Studenterna vet nog bäst när de har glömt att stoppa timern i Parkour och fick gärna märka ut de pass då timern har dragit över. Det här följer av märkbart bortglömda igångtryckningar av Parkour i loggarna.

• Ge studenterna möjlighet att annotera sina loggar. Här kan studenterna ge mer information som kan vara intressant för oss (och dem själva).

För den som vill arbeta vidare på Parkour så finns källkoden tillgänglig under MIT- licens på:

http://www.github.com/kaj/parkour

Loggarna från alla kurser och studenter under 2014-2015 har anonymiserats och gjorts tillgängliga på:

https://gits-15.sys.kth.se/dicander/parkour_logs

(33)
(34)

Litteraturförteckning

[1] Kent Beck. Extreme Programming Explained: Embrace Change. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 2000.

[2] Kim Man Lui and Keith C. C. Chan. Pair programming productivity: Novice- novice vs. expert-expert. Int. J. Hum.-Comput. Stud., 64(9):915–925, September 2006.

[3] Laurie Williams. Integrating pair programming into a software development process. CSEET ’01 Proceedings of the 14th Conference on Software Engineering Education and Training , 2001.

[4] Laurie Williams, Eric Wiebe, Kai Yang, Miriam Ferzli, and Carol Miller. In support of pair programming in the introductory computer science course. Com- puter Science Education , 2002.

[5] Judith D. Wilson, Nathan Hoskin, and John T. Nosek. The benefits of collabo- ration for student programmers. In Proceedings of the Twenty-fourth SIGCSE Technical Symposium on Computer Science Education , SIGCSE ’93, pages 160–

164, New York, NY, USA, 1993. ACM.

[6] Mark Zarb, Janet Hughes, and John Richards. Industry-inspired guidelines improve students’ pair programming communication. In Proceedings of the 18th ACM Conference on Innovation and Technology in Computer Science Education , ITiCSE ’13, pages 135–140, New York, NY, USA, 2013. ACM.

[7] Mark Zarb, Janet Hughes, and John Richards. Evaluating industry-inspired pair

programming communication guidelines with undergraduate students. In Pro-

ceedings of the 45th ACM Technical Symposium on Computer Science Education ,

SIGCSE ’14, pages 361–366, New York, NY, USA, 2014. ACM.

(35)

www.kth.se

References

Related documents

Åldrandeprocesser påverkas av olika faktorer till exempel klimat, förstörelse, slitage och smuts (Johansson 2007, s.24). Vid val av material är det viktigt att tänka

När en student har läs- och skrivsvårigheter och vill ha tillgång till det stöd som högskolorna erbjuder, behöver studenten förmodligen visa upp ett intyg på

84 Sista meningen i första stycket ska lyda: Studenten behöver därför appropriera stöd som kan fungera som medierande artefakt i studentens kommande aktiviteter som anställd..

Despite the fact that she takes care of the children’s laundry, prepares dinner for her children, and helps them with their home- work, she still wants to spend more time with

The GEE models showed that higher prevalence of depression (model 1), hypertension and/or increased levels of homocysteine (model 2) were associated with greater risk for all types of

Hans insatser just i fallet Nordenskiölds japanska bibliotek har däremot varit höljda i dun- kel, bland annat därför att hans och hans japanska medhjälpares insatser är

Brevsam ­ lingarna till Elis Strömgren i Lund, belysande Strindbergs naturvetenskapliga experimenterande 1893-1894, till redaktör Vult von Steijern, m ed icke

Därför är det intressant att intervjua lärare för att kunna beskriva deras upplevelse av elevers läs- och skrivsvårigheter, elevers psykiska ohälsa, kopplingen mellan dessa