Bilaga 5 Enkät: Utvärdering av parprogrammering och kodgranskning
5.2 Sammanställning av fritextfrågor
˝ Negativ ˝ Neutral ˝ Positiv ˝ Mycket positiv
2. Hur många granskningar har du utfört under projektet? ˝ 0
˝ 1 ˝ 2 ˝ ... ˝ 10+
3. Vilka positiva effekter har kodgranskning haft på samarbetet i gruppen? 4. Vilka negativa effekter har kodgranskning haft på samarbetet i gruppen? 5. Vilka fördelar har du sett med kodgranskning i det här projektet? 6. Vilka nackdelar har du sett med kodgranskning i det här projektet?
Avslutande frågor
1. Vilken av metoderna parprogrammering och kodgranskning skulle du välja att an- vända till ett framtida projekt om du bara kunde välja en av dem?
˝ Parprogrammering ˝ Kodgranskning ˝ Vet ej/Kan inte välja
2. Har du några övriga kommentarer kring parprogrammering eller kodgranskning som du vill lyfta fram?
5.2
Sammanställning av fritextfrågor
Här redovisas svaren från enkätens fritextfrågor. Vid tillfällen då flera personer har givit samma eller snarlika svar redovisas dessa svar som ett svar med suffixet “(X st.)” där X anger antalet personer.
Parprogrammering
1. Vilka positiva effekter har parprogrammering haft på samarbetet i gruppen? • Man lär känna varandra bättre. (3 st.)
• Man tvingas umgås med varandra. (2 st.) • Det skapar en öppenhet i gruppen. (2 st.)
• Koden blir aldrig personlig eftersom två personer skapat den. (2 st.) • Jag tror att det har bidragit till kompetensspridning. (2 st.)
• Gruppen får en mer enhetlig bild av projektet.
• Jag tror att om ett par sitter och diskuterar lösningsgångar, problem och idéer så känns det naturligare att blanda in flera personer i diskussionen än om en person satt själv och aldrig hade diskuterat sin kod.
5.2. Sammanställning av fritextfrågor
• Givande diskussioner kring problem samt informationsspridning inom gruppen. • Det blir lättare att samarbeta ju mer man parprogrammerat.
• Det känns som att vi är ett team.
• Parprogrammering hjälper till med kommunikation, sådan man kanske inte haft annars.
• Parprogrammeringen har också gjort att det funnits minst 2 personer som kan säga “dra in och jobba?” som kan ge positiva känslor i fall man inte känner sig så sugen på att göra något alls.
2. Vilka negativa effekter har parprogrammering haft på samarbetet i gruppen? • Det är svårt att hitta tider där båda kan jobba. (4 st.)
• Inga (3 st.)
• Om man är en av de som har svårt att jobba under kontorstid kan man ha känt sig utanför.
• Ibland förstår man inte riktigt varandra och blir då nästan låst på grund av det. • Ibland har det känts tråkigt, till exempel när enhetstest som varit självklara behövt
skrivas (med copy paste), har stundvis känts som man inte är till hjälp. 3. Vilka fördelar har du sett med parprogrammering i det här projektet?
• Bättre kod. (4 st.)
• Mer genomtänkta och generella lösningar. (4 st.)
• Kunskapsspridningen ökas vilket förhindrar att en person blir kritisk för projektet. (2 st.)
• Lärorikt. (2 st.)
• När man kört fast tar man sig snabbare ur det. • Bra då många var osäkra på HTML/JavaScript.
• Personer som inte känt sig så säkra programmeringsmässigt har ändå fått vara med i utvecklingsarbetet samt kanske också fått större självförtroende gällande utvecklingsarbetet.
• Bättre liv.
4. Vilka nackdelar har du sett med parprogrammering i det här projektet? • Tidskrävande. (2 st.)
• Inga.
• Om den ena är lite nere kan den göra att även den andra blir lite nere. • Små saker kan förstoras till större problem i onödan.
• Vissa uppgifter har varit förhållandevis triviala och har kanske bäst lämpat sig att utföras av en utvecklare lite snabbt, men eftersom vi inte påtvingat parprogram- mering så har detta inte varit ett praktiskt problem egentligen.
• Bestämma plats. Två personer måste kunna deltaga samtidigt, kan vara krabbigt att hitta tid som passar för båda två.
• Förmodligen mer åtgångna timmar då mycket av kodandet kostat dubbla timmar.
Kodgranskning
5.2. Sammanställning av fritextfrågor
• Det gör att det är naturligt att andra sätter sig in och kommenterar din kod. Det blir inget påhopp och det känns inte konstigt om någon kommer med kritik eller synpunkter.
• Fler har tittat på koden.
• Granskaren lär sig mer om och av de som skrivit koden och vice versa.
• Det leder till diskussion mellan gruppmedlemmar samt spridning av kompetens. • Det har känts att den som granskar försöker hjälpa en
• Bättre kommunikation mellan berörda parter.
• Snacket efter granskningen har gjort att man lärt känna varandra genom att höra varandras synpunkter på t.ex. en viss lösning vilket ökar tilliten vilket är en grund- sten för samarbete!
• Mer pratande mellan gruppmedlemmar -> bekvämare stämning. 2. Vilka negativa effekter har kodgranskning haft på samarbetet i gruppen?
• Inga (2 st.)
• Ibland kan det kännas som om kodgranskarens ord är lag trots att det handlar om smak och eget tycke i vissa frågor.
• Det ökar mängden kritik inom gruppen.
• De som har lite egen “stil” i sitt kodskrivande kan lätt bli överkörda då vi vill att kodstilen ska vara enhetlig.
• Ibland svårt att få personer till att reviewa sitt arbete. • Kan kännas lite jobbigt om det är mycket negativt att ta upp.
• Personer är olika i hur man vill ha feedback, en risk vid kodgranskning är att man uttrycker sig slarvigt vilket gör att review:n får en negativ klang.
3. Vilka fördelar har du sett med kodgranskning i det här projektet? • Bättre kod. (6 st.)
• Det blir naturligt att dela med sig och visa sin kod. • Man lär sig mycket både av att granska och bli granskad.
• Om granskaren förstår utan att ha varit involverad i lösningen borde den vara tillräckligt välkommenterad och i och med det ökar även underhållbarheten. • Det gör så att fler projektmedlemmar är bekanta med en större del av kodbasen. • Mycket fel i stil har eliminerats innan den kommit upp på dev, hjälpt att undvika
parallellt arbete på develop.
• Lärdomar, olika sätt att lösa ett och samma problem på. Tips och idéer flyger runt efter en granskning.
• Det har gett intressanta diskussioner om tekniska lösningar. • Vi har undvikit olämpliga kodkommentarer och onödiga småfel. 4. Vilka nackdelar har du sett med kodgranskning i det här projektet?
• Tidskrävande. (4 st.)
• Funktionalitet som hade varit praktisk att snabbt mergea in i develop får ligga och vänta på grund av att granskningen dröjer.
5.2. Sammanställning av fritextfrågor
• Ibland sker kodgranskningen formellt (med request - review push -merge) trots att det kanske handlar om någon eller en rad kod som blivit skriven. Det kan då ta onödigt lång tid för vissa saker att komma in på develop. Det blir i vissa fall en onödigt flaskhals.
• Det är inte speciellt roligt. • Inga.
• Ibland har det blockat en från att merga in till dev, vilket resulterat i fler merge- konflikter
• Kan ta tid att gå vidare (få någon att granska), men har vi haft dependencies så har det gått fort.
• Review tas negativt av vissa.
• Dröjt innan saker kommit in på develop.
Övrigt
1. Har du några övriga kommentarer kring parprogrammering eller kodgranskning som du vill lyfta fram?
• Parprogrammering fungerar bäst för att komma igång med en uppgift eller när man känner sig osäker på hur ett problem kan lösas. Allra bäst tycker jag det fungerar om man sitter tillsammans men arbetar enskilt, så att man lätt kan ta hjälp av varandra så fort man kör fast, men det blir mer produktivt än att två personer sitter vid samma dator och kodar.
• Alla klarar inte alltid att samarbeta, vissa gillar bäst att koda själv. Kombinationen parprogrammering och kodgranskning lämpar sig i alla fall för projekt i mindre skala, om kodgranskningsprocessen inte är så extensiv.
• Kodgranskning är guld värt, både att få veta bättre sätt att lösa något på, men samtidigt kunna få feedback på saker man löst på ett bra sätt.
Bilaga 6
Enhetstestning - Datainsamling
Datainsamling
Introduktion
Välkommen till den här datainsamlingen. Idag ska vi undersöka om och hur enhetstestning kan påverka programmeringsprocessen och tidsåtgången. Det du ska göra är att lösa några programmeringsuppgifter med olika förhållningssätt till enhetstestning.
Uppgifterna, utvecklingsmiljön och enhetstesterna ska efterlikna det riktiga projektet i största möjliga mån.
Miljö
Allting kommer ske i samma utvecklingsmiljö, testramverk och programmeringsspråk som det du är van vid från projektarbetet, nämligen:
• Utvecklingsmiljö:WebStorm • Testkörare: Karma • Testramverk: QUnit • Programmeringsspråk: JavaScript
Upplägg
UppvärmningDatainsamlingen börjar med att du utför uppvärmningsuppgiften. Under den här uppgiften får du skriva enhetstester precis hur och när du vill, det viktiga är att några godtyckliga enhetstester faktiskt skrivs. Tanken med den här uppgiften är dels att värma upp dig som deltagare men även för att se att miljön, språket och testerna fungerar som tänkt, så att detta inte tar tid eller saboterar annan data under de andra uppgifterna.
Uppgifterna
Du kommer utföra 3 olika uppgifter. Idén till uppgifterna kommer från diverse tävlingspro- grammeringsuppgifter. Dessa uppgifter framställdes eftersom de går fort att lösa och i nån
mån representerar problem du stött på under projektet.
I den här datainsamlingen ska du genom dina testfall försäkra dig om att din kod fungerar som du tänkt. Därför ska du inte lägga tid på att analysera om ditt slutgiltiga svar är rimligt. Om dina testfall går igenom anger du svaret du har fått och går vidare.
Testdriven utveckling
Tanken bakom testdriven utveckling är att testerna ska utforma koden. Du kan tänka på det som att “tänka först, programmera sen”.
För att lösa den givna uppgiften med testdriven design ska du börja med att skriva en- hetstester. Då är det bra att tänka igenom vilka funktioner din kod behöver. För att göra testvänlig kod är det klokt att bryta upp din kod i många, mindre funktioner. Sträva emot att en funktion endast ska utföra en enda uppgift.
När du har bestämt vilka funktioner du behöver skriva och har skrivit testfall för dessa har du nästan ett komplett kodskelett. Nu gäller det bara att börja skriva den faktiska koden. När alla testfall godkännes så ska din kod vara färdig och fungerande.
Skriva testfall under programmeringen
Nu ska du testa på hur det är att skriva testfall omlott med kodskrivandet. Ett sätt att göra detta kan vara att skriva testfall efter du har kodat en ny funktionalitet. Till exempel om ditt program kommer bestå av tre funktioner kan du skriva testfall för varje funktion precis efter du har skrivit klart den.
Försök integrera testskrivandet i kodskrivandet i största möjliga mån. Det viktigaste är att du inte skriver alla testfall före eller efter kodandet. Lycka till!
Skriva testfall efter kodandet
Nu ska du prova att skriva alla testfall efter du har skrivit klart programmet. Du kan tänka på det som “gör först, tänk sen”.
Koda tills du känner dig klar, programmet borde fungera. Skriv sedan testfall som du känner är lämpliga. Kontrollera att alla testfall körs och blir godkända.
Uppvärmning
17 är större än 4. Likaså är 3 större än 2.
Skriv en funktion som tar in två tal och returnerar det talet som är störst.
Skriv några lämpliga testfall och se att allting fungerar som det är tänkt innan du tar dig an de riktiga uppgifterna.
Uppgift 1
Förhållningssätt du ska använda dig av:
Kvadraten av summan av de första tio naturliga talen är: (1+2+...+10)2=552=3025
Summan av kvadraten av de första tio naturliga talen är: 12+22+...+102=385
Skillanden mellan summan av kvadraten och kvadraten av summan för de tio första naturliga talen är:
3025 ´ 385=2640
Vad är skillanden mellan summan av kvadraten och kvadraten av summan för de första 100 naturliga talen?
Tips: xnkan skrivas som Math.pow(x, n) i JavaScript.
Svar:
Tidsåtgång för att koda och testa: Antal funktioner:
Uppgift 2
Förhållningssätt du ska använda dig av:
Kent har köpt en pizza.
Kent älskar ost. Kent tycker att hans pizza har för lite ost. Kent blir förargad.
Kents pizza är rund och har en radie på 10 cm. Den yttre kanten av deg är 2 cm och har ingen ost på sig. Hur många procent av Kents pizza har ost på sig?
Tips 1: Arean för en cirkel: A=Radien ˚ Radien ˚ π Tips 2: π kan i denna uppgift betraktas som 3.14
Svar:
Tidsåtgång för att koda och testa: Antal funktioner:
Uppgift 3
Förhållningssätt du ska använda dig av:
2520 är det minsta talet som är jämnt delbart med alla tal från 1 till 10. Hitta det minsta talet som är jämnt delbart med alla tal från 1 till 20.
Tips: Kom ihåg att man kan använda modulo (%) för beräkna restprodukten av en divi- sion.
Svar:
Tidsåtgång för att koda och testa: Antal funktioner:
Enkät
Enhetstestning under projektet
1. Har du använt dig av enhetstestning under projektets gång? Om du svarar "Nej": gå vidare till nästa kapitel som behandlar datainsamlingen.
˝ Ja
˝ Nej, varför?
2. Tycker du att den här datainsamlingen är representativ för motsvara att enhetstestandet under projektet?
˝ Ja
˝ Nej, varför?
3. Vilken av de tre förhållningssättet som använts under denna datainsamling represen- terar bäst hur du har använt dig av enhetstestning under projektetsgång?
˝ Testdriven design, det vill säga testfall före kodande ˝ Testfall kontinerligt under kodandet
˝ Testfall först efter att koden var färdigskriven
4. Vilket av följande påståenden skulle du säga passar bäst in på dig i ditt arbete med enhetstestning?
˝ Jag tycker att enhetstestningen har varit till stor hjälp för att lösa problem under projektets gång.
˝ Jag tycker att enhetstestningen har varit till någon hjälp för att lösa problem under projektets gång.
˝ Jag tycker att enhetstestningen varken har varit till nytta eller något hinder när jag löste uppgifterna under projektets gång.
˝ Jag tycker att enhetstestning har varit ett jobbigt moment som bara måste göras ˝ Jag tycker att enhetstestning har varit ett hinder under projektets gång
Om datainsamlingen
5. Om du skulle uppskatta svårighetsgraden av uppgifterna på en skala 1-5, där 1 är väldigt enkel och 5 är väldigt svår:
˝ Uppvärmningsuppgift: ˝ Uppgift 1:
˝ Uppgift 2: ˝ Uppgift 3:
6. Uppfattade du att något förhållningssätt till enhetstestning underlättade vid lösning av någon uppgift? I så fall vilket förhållningssätt (Du kan välja flera förhållningssätt):
˝ Nej.
˝ Ja, skriva testfallen först.
˝ Ja, skriva testfallen kontinuerligt under kodandets gång. ˝ Ja, skriva testfallen efter kodandet.
˝ Ja, alla förhållningsätt bidrog.
7. Uppfattade du att något förhållningssätt till enhetstestning försvårade lösningen av nå- gon uppgift? I så fall vilket förhållningssätt? (Du kan välja flera alternativ):
˝ Nej.
˝ Ja, skriva testfallen först.
˝ Ja, skriva testfallen kontinuerligt under kodandets gång. ˝ Ja, skriva testfallen efter kodandet.
˝ Ja, alla förhållningssätt bidrog. 8. Övriga kommentarer:
Bilaga 7
Resultat från enkät om daily
Scrum
Vad tycker du om att vi har haft daily Scrum-möten varannan dag istället för varje dag?
• Tycker det passar bra eftersom vi inte jobbar heltid med projektet och man då ibland har vissa dagar då man inte gör nånting.
• Bra! I och med att det inte hinner hända så mycket på två dagar så räcker det.
• Jag tycker det varit rimligt i förhållande till den mängd arbete vi lagt ner i projektet, åtminstone tidigare. Det är möjligt att det varit bättre att ha alla dagar nu på slutet när det arbetas intensivt.
• bra sett till hur ofta det finns något att uppdatera. känns som om varannan dag har gjort att det inte riktigt känns integrerat
• Tillräckligt med varannan dag, blir lite tjatigt annars och händer inte så mycket mellan varje gång
• Bra! Varannan dag borde man ha saker att skriva. Efter varje dag skulle det bara bli massa upprepningar.
Vad tycker du om att vi hållit daily Scrum-mötena virtuellt?
• Enkelt och smidigt. Skönt att inte behöva vänta på folk för att kunna rapportera. • Bra. Det hade varit väldigt jobbigt att hitta en tid då alla hade kunnat vara med. • Det har fungerat bra. Saknar dock diskussion bland medlemmar som kan uppstå efter
avslutat möte, känns som att en del information går förlorad eftersom kommunikatio- nen sker i textform och inte face-to-face.
• praktiskt. men kommer förespråka face-to-face eller skype för framtida projekt
• Har fungerat jättebra, skönt att själv kunna bestämma när man ska skriva/läsa. Skulle ha känts onödigt att samla alla för 15min varje dag när läsa går lika bra, även om man kanske missar lite det trevliga med att träffas ansikte mot ansikte.
• Mycket bra! Jag tycker om när man gör saker så enkla som möjligt. Skulle vara jobbigt att behöva ta sig till skolan om man egentligen vill sitta hemma.
Hur tycker du Slack och geekbot har fungerat för att sköta daily Scrum-mötena?
• Hur bra som helst! • Fantastiskt.
• Tycker att det har fungerat bra, känner inte till någon lösning jag tror skulle fungerat bättre när vi valt att ha virtuella möten.
• geekbot och slack har fungerat väldigt bra! slackbot kritik: borde kunna fråga om hjälp under en pågående report
• Geekbot har fungerat bra, skönt att få en påminnelse automatiskt. Han ställer alltid rätt frågor!
• Exemplariskt!
Finns det något i vår variant av daily Scrum som du tror hade fungerat bättre på något annat sätt? Om ja, hur då?
• Om det hade varit tydligare vilka som inte gjort scrum, som det är nu kan folk glömmas bort.
• Nej.
• Jag tror vi hade fått ut mer av mötena om vi haft fysiska sådana, men samtidigt så hade det blivit svårt i praktiken. Så mitt svar blir nej.
• ställer mig tveksam till att hålla dem virtuellt
• Om alla hade postat en selfie tillsammans med sin uppdatering!
• Det hade varit spännande att på ett enkelt sätt få ut en sammanfattningen över sina egna daily scrum under en lång period. Detta för att leta efter mönster i sitt arbete.