Media Richness Theory

Media Richness Theory lades fram 1986 av Richard L. Daft och Robert H. Lengel. Den beskriver hur rikhet kan användas för att jämföra olika kommunikationsmedier. Rikhet avser här ett värde på ett kommunikationsmedies förmåga att förmedla information. I information som skickas över ett medie innefattas även implicit kommunikation såsom kroppsspråk och tonfall. Till exempel videochatt har högre rikhet än e-mail. [44]

Till ärenden som kräver hög social närvaro, till exempel känsliga ämnen såsom avskedanden och konfliktmedling, behövs ett rikt medie.

För ärenden som inte kräver någon social närvaro, till exempel att bekräfta en bokning, be- hövs inte ett rikt medie utan e-mail räcker gott.

C.4

Metod

Teori har insamlats genom att läsa artiklar och annan litteratur. För att hitta sagda artiklar har sökningar gjorts på orden “daily scrum”, “distributed”, “virtual” och “meeting” i olika konstellationer.

För att samla ihop erfarenheter har en enkät skickats ut till samtliga gruppmedlemmar. Enkäten innehöll följande fritextfrågor:

• Vad tycker du om att vi har haft daily Scrum-möten varannan dag istället för varje dag? • Vad tycker du om att vi hållit daily Scrum-mötena virtuellt?

C.5. Resultat

• 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å?

Ingen av frågorna var obligatorisk att svara på.

C.5

Resultat

Enkäten besvarades av sex gruppmedlemmar. En fullständig sammanställning av svaren finns i bilaga 7. Här följer kortare sammanfattningar av de svar som kom in, indelat efter enkätens fyra frågor.

Vad tycker du om att vi har haft daily Scrum-möten varannan dag istället för varje dag?

Alla de som svarade är överens om att daily Scrum-möten varannan dag har varit lagom, med flera kommentarer om att möten varje dag hade varit för ofta.

Vad tycker du om att vi hållit daily Scrum-mötena virtuellt?

Av de som svarat anser alla att det varit praktiskt att daily Scrum-mötena hållits virtuellt, istället för att behöva få ihop ett kort möte med hela gruppen tre gånger i veckan. Hälften av de svarande tar upp det negativa i att inte träffa övriga gruppmedlemmar ansikte mot ansikte, och att de saknat de diskussioner som ofta uppstår i samband med möten.

Hur tycker du Slack och geekbot har fungerat för att sköta daily Scrum-mötena?

Alla som svarat anser att Slack och geekbot har fungerat bra för att hantera daily Scrum- mötena.

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å?

Tre förslag på möjliga förbättringar kom in från de som svarade på rapporten. Ett var att det borde gå att se vilka som ännu inte besvarat sin daily Scrum, ett annat att det vore praktiskt att kunna se en sammanställning av alla sina svar, och det tredje en önskan om att alla till varje daily Scrum skickat en selfie ihop med sina svar.

C.6

Diskussion

Här diskuteras de virtuella, textbaserade daily Scrum-möten som tillämpats utifrån teorin som inhämtats. Efter det följer diskussion kring resultaten som kommit från enkäten, och slutligen ett kort stycke diskussion kring metoden som tillämpats i undersökningen.

C.6.1

Teori

I teorin framgår att flera av fördelarna med daily Scrum-möten går förlorade om inte teammedlemmarna träffas fysiskt för sina möten. De spontana diskussionerna uteblir, likaså möjligheten att snabbt ta upp mindre frågor. Att ersätta daily Scrum-möten med videokon- ferenser ger inte samma effekt, då det är just närheten och möjligheten till oplanerade samtal som är nyckeln.

Det medie som använts för daily Scrum är lågt i rikhet, vilket har lett till att en del former av kommunikation inte har gått att förmedla. En annan fördel med face-to-face-möten som går förlorad är relationsbyggande mellan gruppmedlemmarna.

C.7. Slutsatser

C.6.2

Resultat

Här diskuteras de svar som kommit in, indelade efter de fyra frågor som ställdes i enkäten.

Vad tycker du om att vi har haft daily Scrum-möten varannan dag istället för varje dag?

Det är väldigt tydligt att alla som besvarade enkäten är eniga om att daily Scrum varannan dag istället för varje dag har varit alldeles lagom. Varje dag hade varit för ofta då ingen jobbade heltid med projektet, och därmed inte säkert jobbat med det varje dag. Det stämmer bra överens med motiveringen bakom att bara ha daily Scrum varannan dag, vilken var att projektet gick på halvtid.

Vad tycker du om att vi hållit daily Scrum-mötena virtuellt?

Både nackdelar och fördelar träder fram. Flera svaranden nämner det smidiga i att inte be- höva tid och plats för alla att samlas. Det är också flera som pekar på det tråkiga i att inte ses, och att de har saknat de fria diskussioner som ofta uppstår i samband med möten.

Hur tycker du Slack och geekbot har fungerat för att sköta daily Scrum-mötena?

Här är de svarande enkom positiva. Slack ihop med geekbot har fungerat utmärkt för att organisera virtuella textbaserade daily Scrum-möten.

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å?

En svarande påpekar att det inte tydligt framgår vilka som inte svarat. Där har virtuella textbaserade daily Scrum-möten en klar nackdel gentemot den klassiska varianten. En annan svarande saknar selfies, vilket kan tolkas som en önskan att få träffa de andra i gruppen. Det framgår även att ett par av de svarande nog föredrar den klassika formen av daily Scrum.

C.6.3

Metod

Alla i gruppen hade inte svarat vid sammanställningen, vilket sannolikt beror på att enkäten skickades ut för sent.

C.7

Slutsatser

Utifrån resultatet och teorin kan vissa slutsatser dras.

Utifrån den teori som sammanställts kan slutsatsen dras att virtuella, textbaserade daily Scrum-möten saknar vissa av de positiva effekter som kommer av den klassiska formen på daily Scrum-möten, framförallt direktkontakten mellan teammedlemmar. Vidare kan sägas att daily Scrum-möten gör sig bäst i sin ursprungliga form, och att det ska till starka incitament för att övergå till en virtuell variant.

Följande erfarenheter kan vara av intresse för framtida projekt:

• Även då strukturen kring virtuella textbaserade daily Scrum-möten är felfri, föredrar flera att ha dem på klassiska viset ändå.

• Anpassa frekvensen på daily Scrum-möten efter hur mycket tid de inblandade lägger på projektet.

D

Eric Henziger: En utvärdering av

parprogrammering och

kodgranskning

D.1

Inledning

Under utvecklingen av systemet användes både parprogrammering och kodgranskning. Metoderna hade för syfte att höja kvaliteten på produkten genom att upptäcka och åtgärda buggar och andra felaktigheter i koden tidigt från det att koden skrivits. En ytterligare kon- sekvens är att metoderna kräver interaktion mellan utvecklarna vilket påverkar samarbetet i gruppen.

D.1.1

Syfte

Syftet med den här rapporten är att lyfta fram för- och nackdelar med parprogrammering och kodgranskning. Tidigare jämförelsestudier mellan parprogrammering och kodgranskning har gjorts av Müller [45] där två grupper fick utföra samma uppgift och där den ena gruppen bestod av programmerande par och den andra gruppen bestod av en självständig program- merare vars kod granskades för att sedan korrigeras. Min rapport undersöker effekterna av att använda parprogrammering under utvecklingen av ett mjukvaruprojekt för att sedan även låta koden genomgå en granskningsprocess. Dessutom läggs fokus på hur metoderna påverkar samarbetet i en nyskapad projektgrupp utan tidigare erfarenhet av webbutveckling.

D.1.2

Frågeställning

Jag ämnar besvara följande frågeställningar:

1. Finns det ett värde i att granska parprogrammerad kod? 2. Vilka styrkor och svagheter finns med respektive metod?

3. Vilken påverkan har metoderna för samarbetet inom projektgruppen?

D.2

Bakgrund

Vår projektgrupp bestod av nio civilingenjörsstudenter inom antingen datateknik eller mjukvaruteknik. Samtliga hade god allmän programmeringsvana men ingen hade någon tidigare nämnvärd erfarenhet av webbutveckling. Under projektets förstudie beslutades att utvecklingen skulle om möjligt ske genom parprogrammering. Gruppmedlemmarna hade erfarenhet av parprogrammering från tidigare kurser på universitetet och någon formell

D.3. Teori

introduktion till hur metoden skulle appliceras krävdes inte.

Vidare beslutades att all skriven kod skulle genomgå granskning och godkännas innan den kunde integreras med slutprodukten. De flesta i gruppen saknade tidigare erfarenhet av kod- granskning och ett flertal diskussioner krävdes för att nå konsensus i hur granskningspro- cessen skulle se ut.

D.3

Teori

I en studie av Cockburn och Williams [46] diskuteras kostnaden av parprogrammering, vilken enligt kritikerna fördubblas då den kräver två programmerare för att utföra en ensam programmerares arbete. Studien visade dock att parprogrammering har många pos- itiva effekter på utvecklingsprocessen samtidigt som kostnaden är förhållandevis låg. Den marginella ökningen av utvecklingskostnaden på 15 % vid parprogrammering kompenser- ades av att buggar upptäcktes tidigt i utvecklingsfasen, att färre rader kod skrevs för att utföra samma uppgift och att majoriteten av utvecklarna kände större uppskattning för sitt arbete vid parprogrammering jämfört med soloprogrammering.

I Müllers [45] jämförelsestudie framgick att parprogrammering inte gav kod av högre kvalitet jämfört med soloprogrammerad kod som genomgått granskning. Samtidigt var den ökade kostnaden hos parprogrammering inte av signifikant storlek.

D.4

Metod

Hur gruppen tillämpat parprogrammering och kodgranskning beskrivs i avsnitt 4.5.1 respek- tive 4.5.2. Undersökningen bestod av två delar, en analys av projektets gransknings-commits och en enkät om parprogrammering och kodgranskning.

D.4.1

Analys av gransknings-commits

För utvärderingen av kodgranskningen har en undersökning av projektets gransknings- commits gjorts. Antalet “FIXME”-kommentarer har beräknats per feature och kategoriserats för att belysa vilken typ av fel som fångats med kodgranskning. De sju kategorierna som användes exemplifieras i kodexempel D.1 till D.7.

Kodexempel D.1: Exempel på feedback gällande kommentering.

* An object where the keys are the letters that we wish to count. * The value will be set to the frequency of the letter.

* FIXME: Rephrase to ’The value _of the key_ will be set to the _count_ of * the letter.’

*/

Feedback gällande kommentarer gavs då kommenteringen var otydlig eller otillräcklig. Granskaren verifierade att kommentarerna överensstämde med koden, att kodens syfte gick att förstå utifrån kommentering och att den följde formatet för JSDoc.

Kodexempel D.2: Exempel på ett refaktoreringsförslag.

document.body.addEventListener(’fileChange’, function(e) { /* FIXME: This function is similar to plotGraphs()

* perhaps functionality can be extracted into a common function? */