Örebro universitet
Handelshögskolan - Informatik Uppsatsarbete, 15 hp
Handledare: Johan Petersson Examinator: Mathias Hatakka HT 2018/2019-01-11
Mobbprogrammeringens
implementation hos
företag
Hur organisationer tillämpar mobbprogrammering
David Lundholm (1994-03-05)
Gustav Skoglund (1994-01-09)
Henrik Holmström (1992-05-06)
2
Sammanfattning
Mobbprogrammering är en utvecklingsteknik inom systemutveckling. Tekniken utövas av en grupp på fler än två personer, där ändamålet är att tillsammans framställa programkod eller andra produkter inom systemutveckling. Syftet med den här studien är att undersöka skillnader av mobbprogrammeringens implementation hos organisationer samt hur dessa relaterar till implementationen av tekniken i tidigare utförda studier. Uppsatsen sammanställer tidigare studier av mobbprogrammering i en referenstabell och hur företag implementerar och tillämpar tekniken i en ytterligare referenstabell. För att samla in den data som behövts för arbetet skickades en kvalitativ enkät ut till utvalda företag, konsulter och IT-enheter som utför
mobbprogrammering vars svar jämfördes och analyserade emot implementationen av tekniken i de tidigare utförda studierna. Resultatet blev en genomgripande genomgång av olika
implementationer av mobbprogrammering där det kunde urskiljas att implementationen av tekniken var delvis baserad på tidigare definitioner av tekniken, om än oavsiktligt, men även implementerat efter företagets behov.
Nyckelord
3
Innehållsförteckning
1. Introduktion ... 7 1.1 Syfte/problemformulering... 7 1.2 Förtydligande av frågeställning ... 8 1.3 Avgränsning ... 9 2. Tidigare forskning ... 10 2.1 Vad är mobbprogrammering? ... 10 3. Metod ... 11 3.1 Litteraturstudien ... 11 3.2 Enkätundersökningen ... 12 3.2.1 Analysfrågor ... 14 3.3 Referenstabeller ... 14 3.4 Metodkritik ... 15 3.5 Etik ... 16 4. Resultat ... 17 4.1 Litteraturstudien ... 17 4.1.1 Basering ... 17 4.1.2 Aktiviteter ... 17 4.1.3 Setup ... 18 4.1.4 Frekvens ... 19 4.1.5 Roller ... 19 4.1.6 Antal ... 20 4.1.7 Iterationstid ... 20 4.1.8 Referenstabell 1 ... 21 4.2 Enkätsvaren ... 22 4.2.1 Basering ... 22 4.2.2 Aktiviteter ... 23 4.2.3 Setup ... 23 4.2.4 Frekvens ... 24 4.2.5 Roller ... 25 4.2.6 Antal ... 264
4.2.7 Iterationstid ... 26
4.2.8 Referenstabell 2 ... 27
5. Analys ... 28
6. Diskussion ... 30
7. Slutsats och bidrag ... 32
7.1 Slutsats ... 32
7.2 Kunskapsbidrag ... 32
7.3 Förslag till vidare forskning ... 33
8. Litteraturförteckning ... 34
9. Bilagor ... 35
9.1 Mailutskick ... 35
... 35
5
Centrala begrepp
Mobbprogrammering
En teknik som involverar en grupp på fler än två personer indelade i olika roller där programmering utförs tillsammans. Även utanför utvecklingen, bland annat i design och kommunikation med kunder, är arbetssättet applicerbart och liknar då en
systemutvecklingsmetod (Zuill, 2014). Mobbprogrammering används oftast i situationer där flera utvecklare tillsammans med olika roller (förare/pilot, navigatör och berättare) sitter vid en dator, ett tangentbord, en mus och en monitor eller annan skärmtyp (Buchan & Pearl, 2018). Till skillnad från parprogrammering så är arbetssättet inte strukturerat varpå det existerar i flera versioner.
Mobb
Enligt Hohman & Slocum (2001) är mobben de deltagare i teamet som inte innefattar rollen som berättare eller förare. Mobben är personerna som kollar på monitorn och har uppgiften uppgift att komma med förslag, lösningar eller synpunkter till föraren. Zuill (2014) kallar rollen för navigatör, medans Hohman & Slocum (2001) kallar rollen för “the mob”.
Förare
Förare (driver), skrivare (typist) (Buchan & Pearl, 2018) eller pilot (Lilienthal, 2017) är den roll inom mobbprogrammering och parprogrammering som gör det praktiska programmeringen (Zuill, 2014). Enligt Zuill blir föraren instruerad av de andra i gruppen (främst navigatörerna) om vad som ska programmeras och hur det ska göras.
Navigatör
Enligt Zuill (2014) så är navigatör (navigator) en roll som oftast innehas av mer än en person samtidigt inom mobbprogrammeringen som tillsammans diskuterar fram förslag, lösningar på de problem inom programmeringen som ska lösas och instruerar föraren vad som ska skrivas i koden.
Berättare
Berättare (narrator) är rollen inom mobbprogrammering som används när mobben ska uppdatera kod istället för att bygga upp den från grunden. Berättaren är personen eller personerna i teamet som utvecklat den ursprungliga koden som ska utvecklas vidare och har funktionen att förklara kodens syfte och relevans till resten av systemet (Hohman & Slocum, 2001).
Deltagare
Deltagare (participants) är den rollen övriga individer i mobben blir tilldelade som inte tillhör någon av de andra rollerna. Deras arbete är att hjälpa till med att komma med idéer och diskutera nästa steg av programmeringen (Hohman & Slocum, 2001).
6
Iterationstid
Iterationstid (även kallad rotationstid och timer) är den tid som används för att specificera när byten av roller (oftast byten mellan föraren och navigatör) ska ske inom
mobbprogrammeringssessionerna (Boekhout, 2016).
Session
Session inom mobbprogrammering är den tiden då mobbprogrammering utförs.
Programmering, diskussion och andra praktiska aspekter som sker tillsammans i gruppen kan vara inkluderat i detta (Zuill, 2014).
Parprogrammering
Parprogrammering är en teknik där två olika utvecklare med två olika roller (pilot, navigatör) tillsammans programmerar vid en dator (Lilienthal, 2017). Enligt Lilienthal (2017) så
programmerar ena utvecklaren samtidigt som den andra granskar den skrivna koden och diskuterar framtida idéer och lösningar på eventuella kommande problem programmeraren kan stöta på.
Setup
Setup är den term som används inom uppsatsen för att beskriva de verktyg som används inom sessionerna av mobbprogrammering. Här räknas alla fysiska objekt som används för att arbeta med mobbprogrammering in, exempelvis projektorer, monitorer, datorer och annan
7
1. Introduktion
I denna introduktionsdel av arbetet presenteras en kortare bakgrundsbeskrivning av området mobbprogrammering. Dessutom definieras de forskningsfrågor som uppsatsen behandlar samt den kunskapslucka som fylls. För att undvika förvirring kommer namnet på tekniken härmed att alltid benämns som “mobbprogrammering” i studien, även om många andra benämningar existerar på internet och i litteraturen.
“Mob programming is a software development approach where the whole team works on the same thing, at the same time, in the same space, and at the same computer.” - Zuill (2014) Mobbprogrammering är en term som kanske inte ens den mest insatte systemutvecklaren känner till. Tekniken, som i de mer vanligt förekommande konfigurationerna påminner om andra mer erkända tekniker såsom parprogrammering, har trots sitt långvariga existerande inte ännu blivit ett självklart inslag hos vare sig erfarna eller oerfarna utvecklare (Boekhout, 2016). Termen och de grundläggande teknikerna bakom mobbprogrammering skapades runt år 2003 av Moses Hohman och Andrew Slocum (Buchan & Pearl, 2018) som ett slags alternativ och
vidareutveckling av den redan etablerade parprogrammeringstekniken. Succén och ett mer allmänt erkännande uteblev dock, och efter detta låg mobbprogrammeringen och dess potential länge undanskymd tills dess att den återupptäcktes och moderniserades cirka 2013 av Woody Zuill som blivit en auktoritet och ofta citerad individ inom området (Buchan & Pearl, 2018). Att mobbprogrammering är så pass förhållandevis nytt på arbetsmarknaden kan vara en bidragande faktor till att den egentliga implementeringen av mobbprogrammering på
arbetsplatser ser olika ut och inte alltid stämmer överens med de läror som finns citerade i de moderna riktlinjerna, likt hur Boekhout beskriver sin implementation av tekniken i sin studie (Boekhout, 2016). Zuill har trots sin framgång inom området ingen fast definition om hur
mobbprogrammering ska gå till eller vara strukturerad även om generella riktlinjer kan dras från de konferenser och artiklar som framställts genom åren, som exempelvis “A Whole Team Approach” (Zuill, 2014). Vilka medlemmar en mobbprogrammeringsgrupp består av, hur länge den som sitter vid tangentbordet ska sitta där innan någon annan tar över och vilka delar av ett utvecklingsprojekt som ska utvecklas genom mobbprogrammering är exempel på några av de frågor som olika utövare beslutat tackla på olika sätt. Även saker som hur arbetsplatsen ska vara möblerad är något som är upp till var och en av de olika utövarna att, om inte via en coach, lista ut på egen hand efter vad som passar just deras arbetsplats.
1.1 Syfte/problemformulering
Problemet med mobbprogrammering är att de studierna som vi tidigare läst beskriver tekniken endast behandlar deras egen implementation inom författarens organisation utan att förhålla sig till andra företags tillämpningar av tekniken. Syftet med denna uppsats blir att jämföra tidigare studier och se hur de relaterar mot implementationen av mobbprogrammering hos företag. Detta för att se skillnader och likheter över mobbprogrammeringens implementation som kan
8 vara till nytta för organisationer som själva vill tillämpa mobbprogrammering på sin arbetsplats eller som en grund för vidare forskning av tekniken.
För att kunna besvara och lösa detta problem blir den aktuella frågeställningen följande: Hur har företag och IT-enheter valt att implementera mobbprogrammering på sina respektive arbetsplatser i relation mot de beskrivna implementationerna i de undersökta studierna?
För att besvara frågeställningen behöver även dessa två underfrågor besvaras:
Vilka är de beskrivna och testade implementationer av mobbprogrammering som beskrivs i de undersökta studierna?
Vilka är de implementeringar av mobbprogrammering som finns på systemutvecklingsföretag och IT-enheter?
Denna forskningsfråga med tillhörande underfrågor besvaras i denna studie.
1.2 Förtydligande av frågeställning
Frågeställningen ska förklara hur de företag och IT-enheter (enheter inom organisationer och företag som använder sig av informationsteknik) vi undersökt har implementerat
mobbprogrammering i relation till de tidigare studierna om tekniken. Just implementering av tekniken definierar vi utifrån de element som till större del återfinns i samtliga tidigare studier, vilka är följande:
● Basering, vilken tidigare implementation av mobbprogrammering som denna implementation vad baserad på, om någon.
● Aktiviteter, de aktiviteter som utförs under mobbprogrameringssessionerna. Exempelvis enbart programmering, modellering och kundrelationer.
● Setup, den arbetsmiljö och utrustning som mobbprogrammeringsgruppen använder. ● Frekvens, hur ofta mobbprogrammering utförs exempelvis på en vecka (heltid, en gång i
veckan och så vidare).
● Roller, de roller som används inom gruppen. Förare, navigatör och deltagare är exempel på dessa.
● Antal, hur stort antal deltagare som deltog i mobbprogrammeringsgruppen under arbetet.
● Iterationstid, hur ofta den som utförde själva programmeringen, föraren, byttes ut. Vi kommer i denna uppsats utgå ifrån dessa begrepp och skapa två referenstabeller utifrån respondenternas svar och den tidigare litteraturen som senare i uppsatsen används för att jämföra och analysera tekniken. Dessa referensmodeller kommer att besvara uppsatsens underfrågor.
9
1.3 Avgränsning
Ett problem var att hitta en infallsvinkel inom mobbprogrammering som bidrog till ny forskning inom ämnet och även relatera detta till en specifik frågeställning. Uppsatsen fokus blev då en del av mobbprogrammering inom systemutveckling, nämligen implementationen av
tekniken hos organisationer som använder sig av mobbprogrammering.
Avgränsningen till att just implementationen av tekniken valts som fokus görs med det faktum att andra studier gjort liknande undersökningar med annorlunda fokus tidigare. Ett exempel är Anderssons (2017) studie där han gav sig ut för att finna för- och nackdelar med tekniken genom att intervjua praktiker med erfarenhet av mobbprogrammering.
10
2. Tidigare forskning
Detta kapitel beskriver vad mobbprogrammering är och hur det relaterar till den liknande tekniken parprogrammering.
2.1 Vad är mobbprogrammering?
Mobbprogrammering är en teknik som används inom systemutveckling där en grupp minst tre personer utvecklar en programvara tillsammans (Hohman & Slocum, 2001). Tekniken beskrivs som ett arbetssätt där gruppen med olika tilldelade roller tillsammans arbetar med en dator, en mus, ett tangentbord och en eller två monitorer eller två projektorer (Zuill, 2014). Dessa roller som gruppen använder sig av beskrivs som förare (driver), den person som skriver koden och navigatör (navigator), som beskrivs som de i gruppen som diskuterar hur och vad som ska programmeras (Boekhout, 2016). Andra roller som förekommer är berättare (narrator), som beskriver kontexten av koden (Hohman & Slocum, 2001) och deltagare (participants), som är de som inte tillhör någon annan roll i gruppen (Buchan & Pearl, 2018). Mobbprogrammering
använder sig även av en iterationstid som definieras som ett byte mellan föraren och
navigatörer (Zuill, 2014). Denna iterationstid kan sträckas mellan fem minuter (Wilson, 2015), 10 minuter (Buchan & Pearl, 2018) samt 15 minuter (Zuill, 2014), men är även något som kan förändras utifrån gruppens behov (Boekhout, 2016). Tekniken kan även användas dagligen (Buchan & Pearl, 2018) och veckovis (Wilson, 2015).
Till skillnad från parprogrammering så använder man en grupp på fler än två personer och tekniken kan även användas likt en systemutvecklingsmetod, där gruppen tillsammans kan implementera liknande tankesätt på andra aktiviteter inom systemutveckling (Zuill, 2014). Enligt Zuill (2014) så kan tekniken även appliceras på i både programmeringssammanhang och diverse aktiviteter, exempelvis produktdesign, kundmöten och programleverans.
Mobbprogrammeringens uppkom enligt Hohman och Slocum (2001) som en vidareutveckling av parprogrammering, där det enbart är två personer som utvecklar tillsammans vilket då inte skulle vara möjligt att praktisera i större grupper och således behövdes att utvecklas. Denna vidareutveckling av parprogrammering drevs även vidare av Zuill (2014) som fortsatte att utveckla tekniken och även förespråkar mobbprogrammering på olika konferenser (Wilson, 2015).
11
3. Metod
I detta kapitel vad förklaras vilka motiv som fanns bakom de val och ställningstaganden som gjorts under arbetet.
3.1 Litteraturstudien
För att finna olika implementationer av mobbprogrammering utfördes en litteraturstudie. Litteraturstudien utfördes enligt hur Briony J Oates beskriver och rekommenderar i
“Researching Information Systems and Computing” (Oates, 2012) hur en litteraturstudie ska genomföras. Oates menar att litteraturstudien ska visa att vi som undersökare är medvetna om ett flertal olika punkter innan vår egen studie påbörjas. Några av dessa är:
● Att visa att vi är medvetna om vilket arbete som redan skett inom det valda området. ● Att arbetet placeras i samma kontext som tidigare utförda studier.
● Att svagheter/kunskapsluckor pekas ut som den nya studien kan ämna fylla med ny kunskap eller värderingar.
Den litteratur som analyserades för litteraturstudien hämtades via databaser som ansågs pålitliga och som rekommenderats av Örebro Universitet som lämpliga vid informationssökning inom informatikområdet. De databaser som användes var Primo, DiVA samt Google Schoolar. Vid sökningarna i databaserna användes ett flertal kriterier för att den funna litteraturen skulle vara så relevanta som möjligt för studien. En av dessa var att litteraturen skulle vara “Peer-reviewed” för att garantera att den höll en hög akademisk standard (Oates, 2012). Detta visade sig innebära visst krångel under sökningarna då vissa delar av funna artiklar hade sin grund i konferensartiklar som ibland inte var specifikt utmärkt som “Peer-reviewed”. Vid dessa tillfällen fick separata kontroller avgöra om ett fel skett vid registrering av dokumentet i databasen och fältet “Peer-reviewed” då missats.
Diverse sökord användes för att utföra sökningarna i databaserna. Dessa var: “Mob programming”, “Mobprogrammering”, “Tri programing”, “Mobbprogrammering”, “Mobb programmering” och även “Mob architecting”. Orden användes både för sig själva och i
kombination med andra, vilket ledde till en utökad tillgång till artiklar. Noggrannhet utövades när orden formulerades då det insågs att mobbprogrammering går att stava på många olika sätt, både på svenska (som den här uppsatsen är skriven på) och på engelska (som den absoluta majoriteten av artiklarna om mobbprogrammering är skrivna på). Detta visade sig användbart under sökningsarbetet.
Artiklar valdes sedan ut efter en snabb genomläsning som även det baserades på Oates instruktioner om hur vetenskapliga artiklars relevans kan avgöras på kort tid (Oates, 2012). Detta genom att strategiskt först läsa artiklarnas sammanfattning följt av slutsats för att se om de beskrev någon typ av implementation av mobbprogrammering. Processen gick snabbare än först uppskattat då vi fann att antalet artiklar som täcker mobbprogrammering var relativt litet i omfattning. Detta var något som vi även fann reflekterat i andra skribenters
12 litteraturförteckningar där samma grupp artiklar återfanns och citerades gång på gång utan större variation, vilket hjälpte att ytterligare styrka deras tillförlitlighet och relevans inom området.
När ett flertal artiklar hittats som beskrev olika implementationer av mobbprogrammering lästes artiklarna igenom en eller flera gånger till för att finna gemensamma punkter, olika begrepp, som implementationerna kunde jämföras på. Om en artikel visade sig inte innehålla någon eller endast enstaka av begreppen togs den inte med i resultatet. Ett fåtal fall upptäcktes också då en studie inte definierade samtliga begrepp. I dessa fall togs de delar med som mest liknade de saknade begreppen om så ansågs möjligt.
Som beskrevs i “Förtydligande av frågeställning” identifierades följande begrepp som frekvent förekommande och viktiga i artiklarna:
● Basering, vilken tidigare implementation av mobbprogrammering som denna implementation vad baserad på, om någon.
● Aktiviteter, de aktiviteter som utförs under mobbprogrameringssessionerna. Exempelvis enbart programmering, modellering och kundrelationer.
● Setup, den arbetsmiljö och utrustning som mobbprogrammeringsgruppen använder. ● Frekvens, hur ofta mobbprogrammering utförs exempelvis på en vecka (heltid, en gång i
veckan och så vidare).
● Roller, de roller som används inom gruppen. Förare, navigatör och deltagare är exempel på dessa.
● Antal, hur stort antal deltagare som deltog i mobbprogrammeringsgruppen under arbetet.
● Iterationstid, hur ofta den som utförde själva programmeringen, föraren, byttes ut. Begreppen användes för att få en teoretisk grund att jämföra olika implementationer på, både i resultatet och i de båda tabeller som beskrivs i kapitel 4.3.
3.2 Enkätundersökningen
En enkätundersökning utfördes för att få reda på hur mobbprogrammering implementerats på olika arbetsplatser. Det diskuterades tidigt i arbetet att intervjuer skulle vara den primära informationsinsamlingsmetoden via telefon, beroende på vad som fungerade bäst för den som skulle bli intervjuad, men i slutändan skedde det i form av en kvalitativ enkät som skickades via mail. Anledningen till detta var att det ansågs i början av arbetet att intervjuer inte skulle gynna uppsatsen. Detta utvecklas i underrubriken metodkritik, kapitel 4.4.
Lämpliga kandidater för att svara på enkäten hittades via sökningar på Google efter IT-enheter och företag som utförde systemutveckling inom Sveriges gränser. Detta för att försäkra att faktorer som språk och tidszoner inte skulle bli ett problem. Inte alla företag annonserar på sin hemsida att mobbprogrammering utförs där, varpå vissa gissningar gjordes med förhoppningar att tekniken användes där. Resultatet på denna genomsökning blev en lista med möjliga företag
13 med tillhörande kontaktnummer och epost-adresser där individer eventuellt fanns tillgängliga för svar.
En efter en kontaktades de olika företagen över telefon eller mail för att få kontakt med någon som kunde vara relevant för undersökningen. Fjorton företag eller IT-enheter kontaktades sammanlagt. 11 av samtalen resulterade i en mailadress tillhörandes någon som kunde vara rätt person att svara på enkäten. Detta ledde till att de personer som svarade på enkäten eventuellt inte valdes ut av oss som undersökare personligen, utan av en tredje mellanhand (den som svarade i telefonen eller på mail). Vi ser inte det här som ett större problem då det inte ses som relevant vilken position respondenter har inom IT-utvecklingen så länge som de vet hur implementationen av mobbprogrammeringen skedde, hur det arbetas med och är villiga att berätta om det.
I det mail som skickades ut till dessa mailadresser beskrev vi att vi är tre studenter som skriver en C-uppsats om ämnet mobbprogrammering och eftersökte anställda som arbetar eller hade erfarenhet av mobbprogrammering. Mailet som skickades ut finns bifogat under rubriken “Bilagor” längst ner i dokumentet.
De frågor som enkäten innehöll formulerades enligt hur Oates (2012) rekommenderar att frågor som ska besvaras i mail eller på blanketter formuleras för att uppnå ett gott första intryck hos respondenter. Oates förklarar att första intrycket och en överlag god kvalité är viktigt då man vid enkätutskick har få möjligheter att följa upp med följdfrågor om svaret som tas emot inte är av tillfredsställande karaktär på grund av att respondenten missuppfattat en fråga av någon anledning. Reglerna som beskrivs och följdes till stor del (mer om detta nedan) var att frågorna skulle:
● Vara 20 ord eller kortare.
● Vara relevanta för den typen av svar som vi vill få ut.
● Inte vara otydliga eller tvetydiga samt att inte vara ledande för att påverka respondentens svar.
Frågorna formulerades så att de i största möjliga mån skulle skapa svar som var relevanta gentemot den frågeställning som uppsatsen besvarar. Detta betyder att frågorna menades skapa svar som var möjliga att jämföra mot de tidigare undersökta implementationer som beskrivs utifrån den litteraturstudie som gjordes utan att vara ledande i största möjliga mån. Den kvalitativa enkäten bestod slutligen av 17 frågor och skapades i Google Forms för att underlätta redigering och tillgänglighet från många enheter samtidigt. Då forms är
internetbaserad och alltid tillgänglig för redigering var det händigt att alltid ha möjlighet att göra mindre justeringar i enkäten vid upptäckta stavfel och dylikt. Utskicket, som gick ut till 11 stycken mottagare, resulterade i att vi fick nio sammanställda enkätsvar från sju olika företag eller IT-enheter. Den kvalitativa enkäten finns bifogad under rubriken “Bilagor” längst ner i dokumentet.
14 I likhet med vad som utfördes i litteraturstudien lästes enkätsvaren igenom för att finna
information om de huvudbegrepp som tidigare identifierats. Svaren placerades i tabell 2 för enkätsvar utan att större tolkningar behövde göras.
3.2.1 Analysfrågor
I enkäten ställdes finns 17 frågor. Till studiens resultat och analys så använde vi svaren från sju av frågorna. Anledningen till att vi endast använde dessa sju frågor i studien var för att svaren från dessa utvalda frågor var mest beskrivande för respondenternas implementation av mobbprogrammering, medan övriga svar inte behandlade just implementationen, och var därmed inte intressanta för vår studie.
De utvalda frågorna är följande:
● Vad baserade ni er mobbprogramming på? Vilken beskrivning av arbetssättet var mallen? Moses Hohmans, Woody Zuill eller någon annan?
● Används mobbprogrammering inom andra delar eller aktiviteter i systemutveckling? För modellering eller liknande runt om programmeringen?
● Hur ofta kör ni mobbprogrammering i teamet? Om inte på heltid, hur väljer ni ut vad som ska utvecklas med mobbprogrammering (t.ex speciella user stories eller liknande)? ● Delar ni in deltagarna i olika roller, i så fall vilka roller använder ni (t.ex. Driver,
navigator)?
● Hur många deltagare är det i mobbprogrammeringsgruppen?
● Hur satte ni upp miljön för mobbprogrammeringspassen (t.ex. Möbler, arbetsstationer, monitors och tangentbord)?
● Hur lång tid är varje iteration (byte av driver, den som sitter vid tangentbordet)?
3.3 Referenstabeller
För att strukturera huvudbegrppen och för att underlätta jämförelser mellan resultatet från litteraturstudien med de enkätsvar vi tagit emot skapades två “referensmallar” i form av tabeller. I en tabell strukturerades alla de begrepp upp som under litteraturstudien identifierats som viktiga punkter där de olika inkluderade implementationerna skiljde sig åt, tillsammans med vilken studie respektive implementation tillhörde. I den andra tabellen samlades svaren från enkätundersökningen under samma struktur, med skillnaden att varje implementation tillskrivs en respondent istället för en studie. Data i dessa tabeller jämförs i analysdelen för att senare diskuteras i diskussionsdelen.
15 För att i resultatdelen och framåt göra det lättare att få en överblick över vilka svar som kommit från vilken respondent gavs varje respondent ett påhittat namn. Namnen reflekterar inget hos respektive respondent då ingen information som kan användas för identifiering tagits emot. Användningen av han/hon i texten är således enbart bildligt. Mer om detta under rubriken “Etik”.
3.4 Metodkritik
Att vi inte använder oss av praktiska intervjuer då vi istället använde oss av kvalitativa enkäter kan lätt kritiseras. Anledningen till att vi inte gjorde praktiska intervjuer var att det i början av arbetet ansågs av gruppen att informationen vi eftersöker är av ren observativ status utan större inblandning av personliga tankar och idéer. Tankebanorna som gick var att detta skulle göra att intervjuer “face 2 face” (ansikte mot ansikte) och de fördelar som beskrivs till den metoden (observera ansiktsuttryck, ställa mer personliga frågor (Oates, 2012) inte skulle bidra med något extra till studien utöver de resultat och slutsatser som studien beskriver. Med facit i hand skulle möjligheten att ställa följdfrågor ha kunnat skapa med användbara data och färre ställda frågor som i slutändan visade sig inte vara speciellt användbara. Orelevanta frågor hade i sig kunnat undvikas om frågorna i enkäten formulerats när uppsatsens frågeställning var mer säkrad än vad den var i denna uppsatsens fall. Då hade eventuellt fler frågor varit användbara än de 7 av 17 som blev fallet här.
Detta upptäcktes när svaren på enkäten tagits emot från några av mottagarna och analyserats. Anledningen var att frågeställningar och andra variabler justerats inom tidsspannet mellan att enkäten skickades ut och de första svaren rullade in. Utöver detta var även frågan “Hur lång tid brukar ett mobbprogrammeringspass ta? Planeras raster varje timme exempelvis?”
uppenbarligen svår för respondenterna att förstå, vilket anses bero på en mindre bra frågeformulering. Svaren som gavs på frågan var av så pass varierande kvalitet och ofokuserade eftersom vissa respondenter trodde att vi syftade på hur en arbetsdag var uppbyggd och andra hur långt ett arbetspass är. Därför beslöt vi att frågan och de relaterade områdena i artiklarna inte skulle tas med i resultatet och analysen.
Ytterligare kritik kan riktas mot hur vissa frågor i enkäten var formulerade. När exempel på svar som kan ges på en fråga (exempelvis frågan: Vad baserade ni er mobbprogrammering på? Vilken beskrivning av arbetssättet var mallen? Moses Hohmans, Woody Zuill eller någon annan?) kan detta leda respondenten till att svara på ett visst sätt som den inte skulle svara på annars. Frågan kunde uppfattas som ledande.
Vi insåg även att det antal respondenter vi har kommit i kontakt med eventuellt inte var tillräckligt för att få in tillräckliga data för att kalla studien vetenskaplig, utan visar enbart hur tekniken implementeras i ett fåtal organisationer och enstaka tidigare studier. Detta är en brist på vår insamling av respondentdata.
En viss subjektivitet kan ha påverkat urvalet av vilka konferenser och artiklar som utgavs för att vara “pålitliga” eller ej. Generellt ansågs en konferensartikel pålitlig och relevant om någon av de tre förespråkarna Hohman, Slocum och Zuill varit den grundläggande inspiration som arbetet
16 baserats på. Likt hur Oates (2012) rekommenderade kontrollerades även referenslistor i arbeten för att finna vilka artiklar som refererats till flertalet gånger.
Viss tolkning av den insamlade datan skedde för att den skulle få plats i och vara i rätt form för de båda tabellerna. Att tolka data betyder att datan kan få en annan form eller betydelse än sin originella form (Oates, 2012), vilket vi är medvetna om och har gjort vårt bästa för att motverka.
3.5 Etik
När en insamling av data från respondenter på olika företag utförs behövs det tas hänsyn till den del etiska aspekter kring detta. Enligt Oates (2012) så bör man tänka efter på hur
forskningen både är rättslig och etisk, samt försäkra sig om att alla respondenter och deltagare i undersökningen inte upplever skadliga konsekvenser av uppsatsen.
För att förhålla sig till dessa ställningstaganden inom insamling av persondata har vi inte tagit med någon information om användarna som skulle kunna användas för att skapa ett samband mellan vem som har svarat och de resultaten i studien som beskrivs. Vi valde att inte fråga om personliga egenskaper (kön, ålder, namn, företag etc.) i enkäten då dessa skapar en möjlighet att dra ett samband mellan individen och svaren. Den kvalitativa enkäten är således anonym och resultaten av enkäten går ej att spåra till de respondenter som deltagit.
17
4. Resultat
4.1 Litteraturstudien
Detta kapitel är sorterat efter de huvudbegrepp som beskrivits i metoden. I texten framgår hur respektive studieupphovsman valt att uppfatta och anpassa respektive huvudbegrepp, sorterat efter begreppen. Begreppen ordnades sedan in i en av de tidigare nämnda referenstabellerna. Tabellen (tabell 1) är placerad i slutet av kapitel 5.1.7.
4.1.1 Basering
Hohman och Slocum menar att mobbprogrammering utvecklades utifrån parprogrammering, då tekniken enbart omfattade två personer och behövdes då förändras för att fungera inom ett större team (Hohman & Slocum, 2001).
Zuills uppfattning om hans mobbprogrammerings basering är i stora drag likt Hohman och Slocums tidigare definitioner men utvecklades samtidigt som ett nytt koncept, där Zuills tidigare erfarenheter och implementationer förändrade tekniken (Zuill, 2014). Zuill benämner termen som en egenutvecklad programmeringsteknik, vilket kan appliceras utöver den redan existerande programmeringen.
Wilson beskriver hur Zuill under den årliga JavaOne konferensen 2014 höll föredrag om
mobbprogrammering där Wilsons och hans utvecklarteam var med. Teamet inspirerades då att börja utveckla med hjälp av mobbprogrammering och baserade således konceptet på Zuills definition (Wilson, 2015).
Enligt Buchan och Pearl (2018) började de använda mobbprogrammering när deras blivande utvecklingsledare som hade tidigare erfarenhet av tekniken blev anställd på företaget. Det är oklart om något annat legat bakom denna persons kunskaper utöver dess egna erfarenheter. Boekhout (2016) blev inspirerad av Zuill när han höll ett föredrag om mobbprogrammering vid eventet XP2015 (en internationell eXtreme programming konferens placerat i Helsingfors, Finland) och bestämde sig därefter att dela upp sin avdelning i två olika grupper av tidigare erfarna utvecklare och juniorutvecklare med syfte att utveckla avdelningens kompetens. Till en början så hölls ett möte där Zuills video “A Day of Mob Programming” (2012) visades för att teamet skulle få en förståelse till vad mobbprogrammering handlade om (Boekhout, 2016).
4.1.2 Aktiviteter
Hohman och Slocum förklarar att i början av mobbprogrammeringssessionerna så beskriver berättaren (the narrator) hur koden är strukturerad och dess kontext så samtliga utvecklare i gruppen kan förstå koden nog för att kunna ge förslag på hur vidareutveckling av koden ska utföras. Teamet diskuterar sedan hur kod ska utvecklas för att lösa de uppgifter som finns och föraren skriver sedan in den koden som arbetats fram. De förklarar vidare att tekniken enbart
18 används inom programmeringssammanhang och utfört således inte utanför programmering (Hohman & Slocum, 2001).
Zuills mobbprogrammering sprider sig däremot utöver bara programmering genom att även använda samma mentalitet och arbetssätt inom andra arbetsmoment som utvecklare utövar, bland annat produktdesign, hantering av user stories, kundmöten, telefonsamtal och
programleverans (Zuill, 2014).
När Wilsons team implementerade mobbprogrammering var de mitt i att utveckla viktiga prestandauppdateringar för deras system. Det arbetet inkluderade att förbättra kod som var fundamental för systemets uppbyggnad, och det var just i dessa fall som teamet upplevde att mobbprogrammeringen var som mest effektiv. Därmed användes tekniken enbart i
programmeringssyfte (Wilson, 2015).
Buchan och Pearl förklarar att teamet tidigare använde sig av parprogrammering, men beslöt sig sedan att kontinuerligt skifta mellan parprogrammering och mobbprogrammering efter behov (Buchan & Pearl, 2018). Tekniken användes således enbart i programmeringsammanhang. Enligt Boekhout (2016) är huvudaktiviteten enbart programmering, men att slutet på sessionen består av en förlängd diskussion där man ser tillbaka på hur sessionen och de sista timmarna har fungerat, exempelvis kommunikationen mellan medlemmarna. Dagen avslutas sedan med avstämningsrapport innehållande dagens arbetsmiljö, hur saker har gått och en städning av rummet efter sessionens avslut (Boekhout, 2016).
4.1.3 Setup
Hohman och Slocum (2001) beskriver hur mobben sitter tillsammans med en projektor, en laptop och ett tangentbord för att programmera, diskutera lösningar på framkomna problem och leta efter annan information.
Zuill har en annan synvinkel på hur kodsessionernas setup ska se ut. Här använder han istället två projektorer, diverse tangentbord och möss för att få en så pass bra översikt och kontroll på koden som möjligt samtidigt som föraren har möjlighet att välja vilka av dessa som ska
användas (Zuill, 2014).
Wilson (2015) beskriver hur ett konferensrum användes med en öppen planlösning med whiteboardtavlor som väggar, vilket skärmade av teamet från övriga utvecklare på kontoret. Whiteboardtavlorna användes även för att diskutera idéer och potentiella lösningar. De satte även upp stora monitorer vid arbetsstationerna men införskaffade sig dessutom en extra stor monitor som speglade arbetsstationen som föraren arbetar vid, så att mobben effektivt kunde få översyn av programmeringen.
Buchan och Pearl (2018) berättar att deras team nyttjade ett vanligt mötesrum till en början som inte tillhörde teamets normala arbetsplats. De berättar även att teamet tog även med sig sina tangentbord och en laptop till mobbprogrammeringssessionerna. Rummet bestod av en
19 dedikerad arbetsstation, en 60” Monitor, ett runt skrivbord som deltagarna satt omkring och även en form av ljudisolering för att blockera ut störande ljud (Buchan & Pearl, 2018).
Enligt Boekhout (2016) användes ett grupprum för mobbprogrammeringen innehållande en stor monitor, ett tangentbord, en mus och en laptop.
4.1.4 Frekvens
Hohman och Slocum beskriver frekvensen av mobbprogrammeringen som veckovis. Zuill (2014) beskriver hur mobbprogrammeringssessionerna sker veckovis inom teamet. Teamet arbetar vanligtvis med parprogrammering men valde att prova implementera mobbprogrammering som komplement för parprogrammeringen en gång i veckan (Wilson, 2015).
Buchan och Pearl (2018) förklarar att teamet använde sig av daglig mobbprogrammering. Boekhout bestämde sig även för att strukturera upp dagen med ett tankesätt med sloganen “sprint in a day” som skulle hjälpa utvecklingen då resultaten av det tidigare
mobbprogrammeringssessionerna oftast inte var tillräckligt kompletta och tvingades att fortsättas utvecklas utöver sessionerna (Boekhout, 2016). Man valde då att fokusera mer på dessa sessioner och att ha en fullständig förståelse över det valda målet för dagen samt arbetade då med en daglig mobbprogrammeringssession (Boekhout, 2016).
4.1.5 Roller
Hohman och Slocum beskriver hur tekniken innehåller tre olika roller: förare, berättare och deltagare (Hohman & Slocum, 2001).
Zuill använder sig av rollerna förare och navigatörer, där föraren skriver koden och navigatörerna uttrycker sina idéer och förslag på ett lugnt och sansat sätt (Zuill, 2014). Wilson (2015) beskriver rollerna i mobben som förare och navigatörer.
Buchan och Pearl (2018) beskriver rollerna inom mobbprogrammering som skrivare och deltagare. Skrivaren programmerar koden och de övriga i mobben (deltagarna) hjälper till att guida föraren i utvecklandet.
20
4.1.6 Antal
Hohman och Slocum specificerar inget maxantal medlemmar i en mobb mer än att den består av minst tre personer (Hohman & Slocum, 2001).
Zuill (2014) definierar en gruppstorlek på fem till sex personer i mobben.
Wilson (2015) förklarar att antalet medlemmar i mobben varierade mellan 3–7 personer. Buchan och Pearl (2018) berättar vidare hur de använde sig av en systemutvecklingsmetod av Kanban-stil (en agil systemutvecklingsmetod) där teamet innehöll nio personer.
Boekhout (2016) beskriver hur antalet individer i gruppen vid mobbprogrammeringstillfällena var nio personer.
4.1.7 Iterationstid
Hohman och Slocum (2001) beskriver ingen iterationstid för mobbprogrammeringspassen. Zuill (2014) anger att byte av roller sker efter en iterationstid mellan 10 till 15 minuter. Wilson (2015) beskriver att föraren byttes ut var femte minut.
Buchan och Pearl (2018) beskriver att när mobbprogrammeringssessionerna fortfarande en nyhet för utvecklarna följde teamet en cykel på 10 minuter för förarbyte. När teamet senare blev vanare med tekniken så bytte de förare när föraren så önskade eller när någon annan i teamet ville ta över. Därmed slutade de att strikt följa 10 minuters cyklarna (Buchan & Pearl, 2018). Buchan och Pearl (2018) berättar vidare att de mindre erfarna utvecklarna föredrog att vara förare då dom kunde identifiera sina kunskapsluckor som teamet sedan kunde adressera. Boekhout (2016) beslutade att börja mobbprogrammeringen med en iterationstid på 10 minuter för varje byte av förare samt navigatör efter Zuills tidigare nämnda video. Dock så märkte grupperna snabbt att bytena av roller tog längre tid än väntat och blev då istället ett avbrott på utvecklandet än ett gynnande tillägg för arbetssättet (Boekhout, 2016). Enligt Boekhout så provade ena gruppen olika iterationstider och kom tillslut fram till att en tid på fem minuter var det mest optimalaste sättet att arbeta på.
21
4.1.8 Referenstabell 1
Nedanför finns en tabell strukturerad efter de författare vi undersökt i litteraturstudien tillsammans med de element som återfinns inom mobbprogrammering.
22
4.2 Enkätsvaren
Även enkätsvaren från respondenterna sorteras in i en referenstabell likadant designad som referenstabell 1 ovan. De kompletta svaren återfinns i enkäten i slutet av dokumentet. Tabellen är placerad i slutet av kapitel 5.2.
4.2.1 Basering
Basering är det elementet som respondenternas använde som grund för
mobbprogrammeringen inom organisationen. Dessa svar förklarar vem eller vad denna basering var hämtad från.
Svaren vi fick angående vad respondenternas mobbprogrammering var baserades på var varierande. Tre av svaren berättade att de inte visste vad deras mobbprogrammering baserades på.
“Lennart Fridén kom och faciliterade en session” - Glenn
Glenn beskrev även hur de hade hämtat sina kunskaper från den externa utvecklaren och mobbprogrammeraren Lennart Fridén.
“Heuristiskt, dvs jag lärde mig av mina kollegor. De läste säkert något från början med sedan har vi utvecklat det själva” - Erik
Till skillnad från de andra respondenterna så lärde sig Erik utifrån sina kollegor inom organisationen som tyder på att implementationen av tekniken redan var gjord innan
respondenten började sin tjänst. Baseringen av tekniken blir således en blandning av en okänd basering och en vidareutveckling av tekniken inom företaget.
“Jag var inte med i teamet när de började med mobbprogrammering, men vet att vi hämtar mycket inspiration från Woody Zuill och vi har även varit på workshop med honom.” - Viktor Viktor och Neo var de två respondenter som använt sig av Zuills definition av
mobbprogrammering som grund för hur de applicerade tekniken. En av dessa, Viktor, hade dessutom varit på en workshop med Zuill och fick således förstahandsinformation om hur mobbprogrammering ska fungera i praktiken.
“Vår egen.” - Lena
Slutligen svarade en respondent, Lena, att deras grund för mobbprogrammeringen var deras egen basering, vilket tyder på att företaget själva har skapat en egen definition av tekniken.
23
4.2.2 Aktiviteter
Aktiviteter är det elementet som beskriver de aktiviteter inom mobbprogrammering som utförs utöver programmering. Dessa svar förklarar vad mobbprogrammering inom organisationen används till.
Respondenterna inom den här frågan var till större delen överens om att mobbprogrammering används utöver programmeringen där aktiviteter som bland annat design även görs tillsammans i gruppen. Här hade vi enbart två respondenter, som menade på att mobbprogrammering endast användes vid programmering.
“Jag har coachat ett par team i mobbarbete generellt, allt från Discoveryarbete (exempelvis UX:intervjuer, användningstest, m.m., men då görs själva människa-människa-kontakten
separat, men all planering och analys görs tillsammans i mobbformat) till redaktörsarbete (skriva artiklar alltså).” - Neo
Svaret från Neo beskriver att de tidigare grupper han har arbetat med vanligtvis använde sig av tekniken i andra sammanhang som planering och analys.
“Ja, “modellering” eller snarare designfasen görs ofta i grupp, speciellt när det är komplexa problem som ska lösas” - Camilla
“Design, mockups, utveckling” - Glenn
Vi fick dessutom svar från tre olika respondenter som menade på att mobbprogrammering även användes i samband med design som då verkade vara en generell användning av tekniken. “Vi har mobbutvecklat presentationer/workshops för andra team. Annars blir det oftast programmering och testning.” - Viktor
Slutligen så berättade Viktor att de även använde mobbprogrammering i samband med presentationer och workshops inom organisationen.
4.2.3 Setup
Setup är det element som ska beskriva hur teamet satte upp miljön för mobbprogrammeringssessionerna, den kringutrustning som användes.
“Till en början hade vi en mob-station med en stor tv, för navigatörer. Monitor, mus, tangentbord samt dockningsstation för dator för förare...” - Glenn
“vi har en mobbstation men vi använder den inte. Helst sitter vi vid någon kollegas station...” - Erik
24 Alla respondenter svarade att de använde minst en TV eller monitor av det större slaget. Flera respondenter (tre av nio) nämner också att de använder eller tidigare använt en mobbstation. “Vi har en stor tv-skärm med ett skrivbord, en dedikerad mobb-dator och ett par olika
tangentbord. Vi har isolerat mobbstationen med lite skärmar både för vår egen arbetsro men kanske ännu mer för andra team eftersom vi diskuterar väldigt mycket när vi jobbar...” - Viktor Hos Viktor var det viktigt att isolera teamet från övriga team för att inte störa eller distrahera och skärmade därför av mobbstationen.
“De satte upp det med tangentbord, tv-apparater och högtalare för de som jobbade hemifrån” - Omar
“... ibland är någon deltagare remote och då använder vi vs-codes remote extension som fungerar ypperligt i kombination med slack.” - Erik
Erik och Omar nämner att de hade stöd för remote work, vilket menas med att deltagare i mobben kunde vara deltagande trots att de inte var på plats i kontoret.
“Vi använde en dator me stor skärm och ett gäng stolar runt en person som satt i mitten och kodade med ett tangentbord” - Camilla
Hos Camilla använde man inte en dedikerad TV för deltagarna utan de fick istället sitta runt föraren och kolla över axeln.
“Alla har sin egen stol och det går att ansluta till eller lämna mobbstationen när man vill. Alla i teamet har sitt eget skrivbord och sina egna datorer att sitta med när man vill jobba ensam.” - Viktor
Det var endast Viktor som nämner att deltagarna tog med sig sina datorer och även sina skrivbord till mobbstationen.
4.2.4 Frekvens
Frekvens är det elementet som beskriver när mobbprogrammering utförs i organisation. Hur ofta mobbprogrammering utförs på arbetsplatsen.
Den övergripande frekvensen för respondenterna var dagligen. Här berättar de flesta att mobbprogrammeringen sker på heltid medans andra beskriver teknikens frekvens som mer spontana och oregelbundna.
“Heltid helst, men om det finns olika typer av begränsningar för teamet (ex. Introverta som det suger energi för) så ser man till att göra kritiska saker, allt från viktiga/avgörande beslut/analys till produktionskritisk kod.” - Neo
25 Neo berättar att de helst mobbprogrammerar på heltid, men också hur olika problem uppstår som begränsar heltidsanvändning av tekniken.
“Vi går på känsla. Ibland vill vissa sitta själva och ibland vill man sitt ihop” - Ivar
Ivar beskriver frekvensen som mer spontan där deltagarna själva får välja när arbetet ska utföras i en mobb.
“Speciella stories” - Carl
“Minst en dag i veckan. Brukar vara nästa PBI som körs på.” - Glenn
Här berättar respondenterna hur de enbart använder tekniken för att programmera utifrån speciella nedskrivna uppgifter som ska göras. Glenn beskriver även att de oftast
mobbprogrammerar utifrån deras product backlog item.
“Varje dag kör några en mobb-session. Om man jobbar på något specifikt eller isolerat kör man ensam och då är det antagligen några andra som går ihop och kör en session.” - Erik
Slutligen så berättar Erik att de använder sig av mobbprogrammering dagligen, men att deltagarna har möjlighet att gå ifrån mobben och arbeta avskilt från gruppen med andra uppgifter som ska utföras samt skapa en egen mobb utöver den första mobben.
4.2.5 Roller
Roller är det elementet som beskriver vilka roller som respondenterna använder inom mobbprogrammeringen.
I frågan om de roller som mobbprogrammeringsarbetet eventuellt delas in i är flera av svaren relativt liknande varandra:
“Driver och navigatörer, ja. :)” - Neo
“Vi har en driver och resten av teamet agerar som navigatörer...” - Viktor
Rollerna “driver” och “navigator” är vanligt förekommande även om det inte kan garanteras att deras roller är detsamma i samtliga situationer.
“Nej.” (Ingen rollindelning görs) - Lena, Ivar och Camilla
Dessa tre respondenter nekade helt till att de använder sig av rollindelning.
“...Den som vet mest om lösningen på ett problem byter ofta bort från driver-rollen och agerar navigatör i stället” - Viktor
26 Viktor specificerar att de byter förare när föraren själv känner att den har mest kunskap i
sammanhanget. Detta expanderas på under rubriken “Iterationstid”.
4.2.6 Antal
Antal är det elementet som beskriver den storleken på gruppen som respondenter mobbprogrammerar i.
Storleken på respondenternas grupper var varierande. De flesta deltagarna i enkäten använde sig av en gruppstorlek på minst två deltagare och som högst åtta.
“2–4 st” - Lena
Två av respondenterna hade även en gruppstorlek på färre än tre personer, vilket var färre än väntat då mobbprogrammering oftast innehåller fler än två deltagare.
“5–7 ungefär” - Neo
Neos mobbprogrammeringsgrupp hade det högsta minimiantalet deltagare av respondenterna. “3–8” - Glenn
Slutligen hade Glenn en väldigt varierande gruppstorlek som sträcker sig från tre till åtta deltagare.
4.2.7 Iterationstid
Iterationstid är det elementet där förarbytet sker inom respondenternas
mobbprogrammeringssessioner. Dessa svar förklarar hur länge deltagarna i mobben programmerar tills bytet sker.
De flesta svaren från respondenterna beskrev en iterationstid på mellan sju minuter och 15 minuter, där tre respondenter använder sig av en iterationstid på sju minuter samtidigt som andra respondenter arbetade med en iterationstid på 15 minuter.
“Om vi kör timer så brukar vi ha 12 min, men ibland kör vi utan klocka” - Ivar
Ivar, Erik och Lena beskrev en iterationstid på 12 minuter. Ivar beskrev hur de använde sig av en timer för att veta när förarbytet skulle ske men att de även varierade med att inte köra med timer.
“Vi bytte nyligen till 7 min, innan dess hade vi 10min.” - Viktor
Viktor beskrev hur de gick från 10 minuter till sju minuter och anpassade således iterationstiden efter gruppens behov.
27
4.2.8 Referenstabell 2
Nedanför finns resultatet av enkätsvaren som är strukturerade efter de pseudonym som vi använt oss av tillsammans med de element som återfinns inom mobbprogrammering. Ett streck förklarar att respondenten antingen inte visste svaret på frågan eller valde att inte besvara den.
28
5. Analys
Det går att finna ett flertal liknelser och skillnader mellan hur företag och IT-enheter valt att implementera mobbprogrammering på sina arbetsplatser och de implementationer som beskrivs i de analyserade tidigare studierna.
Respondenternas svar om vad deras mobbprogrammering var baserad på var till delvis otillräcklig då de flesta respondenterna inte hade kunskap om vad just deras
mobbprogrammering var baserad på. Neo och Viktor svarade att tekniken var baserad på Zuills (2014) beskrivning på hur mobbprogrammering används inom organisationer, vilket stämmer överens med litteraturstudien där Boekhout (2016), Buchan och Pearl (2018) samt Wilson (2015) beskriver att de använder Zuill (2014) som basering. Glenn beskrev även att deras mobbprogrammering var baserad på Lennart Fridén (Twitter, 2018), som är en extern mobbprogrammerare och utvecklare.
I frågan angående vilken frekvens mobbprogrammering används så svarade som beskrivet i resultatet majoriteten av respondenterna att tekniken utövas i mångt och mycket på heltid, liknande hur Buchan och Pearl (2018) beskriver hur de lade upp arbetet. I kontrast mot detta finns de respondenter och de studier som exempelvis Hohman och Slocum (2001) och Zuill (2014), som beskriver hur mobbprogrammering enbart används vid speciella arbetsuppgifter eller på specificerade tider. Ivar beskrev hur de “...går på känsla...” och Carl menar att de använder sig av mobbprogrammering under ”...speciella stories”. Båda dessa kan relateras till hur Wilson (2015) använde sig av mobbprogrammering där tekniken mer var ett komplement till redan existerande tekniker, exempelvis parprogrammering i Wilsons fall (se tabell 1).
Som det går att se i tabell 2 var iterationstiderna inom mobbprogrammeringen på de olika företagen och IT-enheterna varierade och svåra att exakt relatera till någon av de tidigare studierna. Viktor beskrev dock att de i likhet med Boekhout (2016) började mobbprogrammera med en iterationstid på 10-minuter men att de nyligen bytt till en kortare tid på sju minuter. Även Buchan och Pearl (2018) utgick från 10-minuters perioder till en början men valde sen att
variera iterationstiden efter behov vilket kunde innebära att tiderna blev både längre och kortare. Ivar svarade i likhet med detta att även de ibland struntade i att använda sig av en klocka för iterationerna. Glenn var den enda som specifikt svarade att han fortfarande använde sig av 10-minutersiterationer, vilket tillsammans med bland andra Lena, Erik, Camilla och Carl passar in i den tidsramen på 10–15 minuter som Zuill (2014) specificerar i sin studie, vilket kan skådas i tabell.
Vid frågan om vad respondenterna körde för setup så svarade Glenn, Erik och Viktor att de använder sig av en mobbstation. Mobbstation är därmed ett begrepp som verkar användas ofta hos företag som tillämpar mobbprogrammering. Vår tolkning av mobbstation är att det är en beskrivning av en arbetsstation dedikerad för just mobbprogrammering. Viktor förklarar vidare att de skärmar av deras mobbstation från övriga kollegor som inte ingår i
mobbprogrammeringsteamet. Att skärma av arbetsplatsen där mobbprogrammeringen äger rum är också något Wilson (2015) gjorde under deras implementation, också med syftet att inte
29 störa övriga medarbetare på kontoret. Utifrån resultat kan även man se att det är en stor
variation av utrustning bland respondenterna. Man verkar anpassa miljön och utrustningen efter vad som passar teamet och arbetsplatsen. Om några deltagare jobbar hemifrån eller från annan plats så finns det stöd för dem att delta i passen genom utrustning och mjukvaruteknik. De flesta respondenter använder sig av monitorer, vilket stämmer överens med vår referenstabell där alla författare förutom Zuill som använder två projektorer (se tabell 2).
I respondenternas svar om hur roller används inom tekniken så beskrev fyra av respondenterna att roller inte var något som nyttjades inom mobbprogrameringen. Dessa svar visar att
respondenterna i fråga inte har använt sig av någon definition av roller från den litteratur om mobbprogrammering som har undersökts, utan arbetar istället helt utan roller. Fyra andra respondenter beskrev hur de använde sig av rollerna förare och navigatör vilket stämmer överens med Zuills (2014), Boekhouts (2016), Buchans och Pearls (2018) samt Wilsons (2015) definitioner av vilka roller som ska användas inom mobbprogrammering. Slutligen så svarade även en respondent ett enkelt “ja” på frågan som visar på att organisationen använder sig av roller men inte vilka slags roller som används.
Respondenternas svar om hur många deltagare mobbprogrammeringsgrupperna innehåller visar på en stor skillnad kring gruppstorlek hos organisationerna. Erik och Lena berättade här att de använde sig av en gruppstorlek som var mindre än tre personer, vilket inte går att relatera till litteraturstudien (se tabell 1) där alla praktikanter förespråkar en gruppstorlek på minst tre personer i gruppen. Carl, Camilla och Ivar hade även en bestämd gruppstorlek på tre personer som stämmer överens med Wilson (2015) som förespråkar en gruppstorlek på 3-7 personer. Slutligen så beskrev Neo en gruppstorlek på 5-7 personer och och Omar och Viktor berättade om en gruppstorlek på 4-5 och 4-6 som närmast går att relatera till Zuills (2014) gruppstorlek som sträcker sig mellan 5-6 personer.
Inom vilka aktiviteter som gjordes hos respondenterna vid mobbprogrammering så svarade fyra respondenter att de enbart använde tekniken för att utveckla. Denna applicering av
mobbprogrammering kan relateras till Hohmans och Slocums (2001), Buchans och Pearls (2018) samt Wilsons (2015) definitioner av hur tekniken enbart ska användas inom
programmering. Resterande fem respondenter svarade att de istället använde tekniken utöver programmering som i bland annat design, planering, testning och workshops vilket relaterar till Zuill (2014) som använder tekniken utöver programmering och förespråkar att använda
30
6. Diskussion
I detta kapitel diskuteras de delar av analysen och resultatet som ansågs intressanta med reflektioner och funderingar.
Vad de olika implementationerna av mobbprogrammering var baserade på blir det första som diskuteras. Fem av respondenterna hade inte möjlighet att svara på från vad deras
implementation av mobbprogrammeringen var baserad på, som kan ses i tabell 2. Det kan tyda på att dessa respondenter inte själva har studerat mobbprogrammering utan har istället blivit tilldelad information om hur de ska arbeta med mobbprogrammering från en tredje part. Det blir därför svårt för dem att besvara den frågan. Två andra respondenter nämnde däremot Zuill (2014) som en inspiration och som en grund för deras mobbprogrammering, vilket stämmer överens med litteraturstudien där Zuill benämns som en bas för deras egna praktiserande av mobbprogrammering (se tabell 1) i ett flertal studier. Man kan tydligt observera att Zuill ses som en huvudpelare inom mobbprogrammeringen rent generellt och är en inspirationskälla för organisationer som utövar tekniken. Respondenten Lena berättade att de skapade en egen variant av mobbprogrammering. Detta svar var intressant då denna basering skulle kunna vara ett helt egenutvecklat koncept som skulle vara spännande att analysera i en framtida studie. Respondenten Glenn hämtade sin basering av tekniken från Lennart Fridén som visade sig vara en svensk utvecklare, konsult och entusiast inom mobbprogrammering efter en sökning på namnet på internet. Sett från svaren Glenn och Lena lämnat i övrigt verkar det inte som att vare sig Lennarts eller Lenas implementationer av mobbprogrammering skiljer sig märkvärdigt från de andra implementationer som beskrivs. En djupare frågestund med Lena eller Glenn skulle kunna vara intressant för att reda ut dessa saker.
Aktivitetsmässigt ser man generellt hur respondenterna utgår ifrån Zuills definition av aktiviteter (Zuill, 2014), medans större delen av litteraturstudien (se tabell 1) beskriver att tekniken enbart används i programmeringssyfte. Samtidigt så följer tre av respondenterna inte denna definition då de inte använder sig av mobben utöver själva programmeringen (se tabell 2). Alternativt kan en del av respondenterna kalla dessa aktiviteter för något annat än just mobbprogrammering, vilket är logiskt då de inte utför ren programmering under dessa aktiviteter.
Frågan om roller blev en intressant sådan. Erik, Neo och Viktor berättar att samma rollindelning som observerats i både Boukhouts (2016), Zuills (2014) och Wilsons (2015) studier användes, det vill säga förare och navigatör. Svaren om de roller som arbetet delas in i under
mobbprogrammeringen var en del av enkäten där vi inte förväntade oss många överraskningar jämfört med de som tidigare hittats i artiklarna. Så var inte heller fallet, delvis, då antalet roller aldrig var fler än de tre som var maxantalet tidigare observerat och de fyllde även liknande funktioner. Fyra andra respondenter svarade oväntat att inga roller har observerats under arbetet, vilket inte går att relatera till någon av de tidigare studiernas rollindelningar. Dessa (förutom Lena) svarade som tidigare nämnt att de inte har någon koll på vad deras
mobbprogrammering är baserad på, vilket kan uppfattas som att de helt enkelt inte är särskilt insatta i tekniken. Zuill (2014) förklarar hur han och andra ser rollindelningen som en kraftfull
31 komponent av både mobb- och parprogrammering, så hur just dessa respondenter organiserar sitt arbete kan vara en intressant sak att analysera i ett framtida arbete.
Respondenterna Ivar, Camilla och Carl svarade att de inte använder sig av någon typ av rollindelning har inte heller koll på vem eller vilken mobbprogrammeingsteknik som låg bakom deras egen implementation. Detta skulle kunna tyda på att inspirationen åtminstone inte var Woody Zuill, som anser att rollindelningen är en viktig komponent i mobbprogrammeringen (Zuill, 2014) och därmed inte är något som kan plockas bort eller ignoreras. Dessa
respondenter svarade i en annan fråga att de använder sig av iterationstider likt många andra respondenter med följd av att någon typ av rollindelning, även om den är omedveten,
exempelvis måste ske för att skilja på de som sitter vid tangentbordet och inte.
Frågan om antal gav även den upphov till intressanta reflektioner. I likhet med Hohman och Slocums (2001) tester har flertalet respondenters arbetsplatser valt att anamma ett upplägg av mobbprogrammering med något färre medlemmar i mobben jämfört med andra analyserade studier, exempelvis Buchan och Pearls (2018) studie där en mobb på nio personer med varierande arbetsuppgifter ansågs optimalt för att arbetet skulle fortskrida med den önskade effektiviteten. Det är anmärkningsvärt att respondenterna Erik och Lena beskriver att de kan utföra mobbprogrammering med minst två deltagare. Det kan antyda på att de blandar ihop mobbprogrammering med parprogrammering eller helt enkelt ser parprogrammering som en typ av mobbprogrammering. Det kan ha sin grund i deras basering av mobbprogrammering
kommer från kollegor respektive deras egen basering, och det kan förklara deras unika syn på hur många deltagare en mobb kan bestå av.
Ännu en sak som är intressant att nämna är att flera respondenter nämner att de i början av sitt mobbprogrammerande använde sig av en iterationstid på 10 minuter, en tid som Woody Zuill specificerar i sin studie, men att de sedan ändrade detta till kortare tider, något som går att observera i tabell 2. Eftersom Zuill i flertalet av de studier som ingick i litteraturstudien samt i de svar som togs emot via enkäten ofta beskrivs som en av grundarna eller som
huvudinspirationen bakom mobbprogrammering känns det naturligt att de flesta som provar på tekniken utgår från hans riktlinjer för hur arbetet ska fortskrida. Varför de sen valt att korta ner tiden är även det något som kan vara värt att undersöka en annan studie av liknande slag. Slutligen valde respondenten Ivar att berättar att de ibland kör sina iterationer utan “klocka” och byter på så sätt förare när det känns lämpligt för gruppen. Detta kan ses som en stor skillnad mellan respondenterna och den tidigare litteraturen där enbart Hohman och Slocum (2001) inte definierar ett spann minuter för iterationstiden. Ivars grupp följer på så sätt ingen av de tidigare definitionerna av iterationstider inom mobbprogrammering. Eventuella problem som skulle kunna uppstå vid “timerlös” programmering är att föraren vid tangentbordet känner att han eller hon vill avsluta det den håller på med innan ett rollbyte sker, varpå konflikter kan uppstå i gruppen. Förmodligen har detta problem undvikits på Ivars arbetsplats, kanske genom att hans arbetsgrupp har god erfarenhet av att arbeta med varandra och känner till hur arbetet ska utföras konfliktfritt.
32
7. Slutsats och bidrag
I detta kapitel besvaras den frågeställning som fastslagits och de kunskapsbidrag som skapats samt förslag på ytterligare forskning som kan utföras.
7.1 Slutsats
Hur har företag och IT-enheter valt att implementera mobbprogrammering på sina respektive arbetsplatser i relation mot de beskrivna metoderna i de undersökta studierna?
Efter sammanslagningen och jämförelsen mellan litteraturstudien och svar från enkäten som analyserats är det lätt att se flertalet samband mellan de data som struktureras i
referenstabellerna. Trots att det, som det beskrivs i inledningen, inte är helt enkelt att finna en fast definition om hur mobbprogrammering faktiskt ska implementeras på en arbetsplats där olika förhållanden kan gälla när det handlar om antal anställda, tillgång till utrustning, arbetsyta och arbetsuppgifter går det att observera att respondenternas arbetsmetoder liknar vissa av studierna mer än andra. I de fall där respondenterna inte angav en explicit inspirationskälla som grund för sin implementation av mobbprogrammering är det ändå observerbart att dessa
implementationer relaterar till implementationerna i litteraturstudien, även om det var oavsiktligt. Möbleringen och uppsättningen av skärmar, tangentbord med mera är ett exempel på en sådan fråga där det var lätt att finna liknande uppsättningar mellan respondenter och studier då flera svar beskriver arbetsstationer som till stor del återspeglar de som nämns i studierna.
Som slutsats konstateras det att det finns tydliga relationer mellan implementationerna i litteraturstudien och hos respondenterna. Man kan se likheter både i resultatet av
respondenternas svar och den insamlade litteraturen. Typen av slutsats blir därmed jämförande.
7.2 Kunskapsbidrag
Vi anser att studien har uppfyllt det syfte som den är avsedd att uppnå. Det betyder att det anses att studien bidrar med en ökad kunskap om hur mobbprogrammering implementeras inom organisationer och hur dessa skiljer sig från tidigare utförda implementationer. Studien bidrar med teoretisk kunskap för framtida studier om mobbprogrammering genom vår
litteraturstudie och våra referenstabeller. Tabellerna kan användas för att se samband mellan olika implementationer, skillnader på dessa och vilka studier som faktiskt är gjorda på
mobbprogrammering. Studien bidrar med praktisk kunskap för organisationer som vill
implementera tekniken då de kan använda sig av våra referenstabeller för att få en förståelse om hur tekniken kan användas på olika sätt. Tabellerna och litteraturstudien visar olika implementationer av tekniken som kan hjälpa organisationen att välja hur deras
implementationen av tekniken ska se ut. Dessa kan då vara ett hjälpmedel eller en referens för hur tekniken fungerar i praktiken och är då både ett praktiskt samt teoretiskt kunskapsbidrag.
33
7.3 Förslag till vidare forskning
Då denna studie enbart visar och jämför de skillnader som implementationer av
mobbprogrammering inom ett fåtal företag så skulle en mer omfattande studie vara mer
givande. En mer övergripande kvalitativ studie av mobbprogrammering skulle ge en större insikt om hur tekniken kan implementeras på olika företag och hur mobbprogrammering används i praktiken. Det finns även andra aspekter än just implementationen av tekniken som kan vara intressant att studera, t.ex. hur mobbprogrammeringen påverkar systemutvecklares
produktivitet, skillnader mellan olika länders implementation av tekniken eller om
mobbprogrammeringen har en effekt på det utvecklade systemets kvalité. De i diskussionen tidigare nämnda punkterna värda att följa upp med sina egna studier är även de lämpliga utgångspunkter för framtida studier.
34
8. Litteraturförteckning
Andersson, R. (2017). För- och nackdelar med mobprogrammering : En fallstudie
(Kandidatuppsats). Borlänge: Akademin Industri och samhälle Högskolan Dalarna. Informatik. Hämtad den 28/11–18 från http://urn.kb.se/resolve?urn=urn:nbn:se:du-26442
Boekhout, B. (2016, 05). Mob programming: Find fun faster. Presenterades vid XP 2019: International Conference on Agile Software Development, Edinburgh.
Buchan, J. & Pearl, M. (2018, 06). Leveraging the Mob Mentality: An Experience Report on Mob Programming. Presenterades vid EASE'18: 22nd International Conference on Evaluation and Assessment in Software Engineering 2018, Christchurch.
Fitzgerald, B., Russo, N. & Stolterman, E. (2002). Information Systems Development. New York City: McGraw-Hill.
Hohman, M. & Slocum, A. (2001, 07). Mob programming and the transition to XP. Presenterades vid XP2001: XP Universe Conference, Raleigh.
Lilienthal C. (2017, 01). From Pair Programming to Mob Programming to Mob Architecting. Presenterades vid SWQD 2017: Complexity and Challenges of Software Engineering in Emerging Technologies: 9th International Conference, Vienna.
Oates, B. (2012). Researching information systems and computing. Los Angeles: SAGE Publishing.
Twitter. (2018). Lennart Fridén. Hämtad 2018-12-19, från https://twitter.com/devlcsc
Wilson A. (2015, 05). Mob Programming - What Works, What Doesn’t. Presenterades vid XP 2015: 16th International Conference, Helsinki.
Zuill, W. (2012, 11). A day of Mob Programming [Videofil]. Hämtad 2018-12-14 från https://www.youtube.com/watch?v=a7m1E5nIRqg
Zuill, W. (2014). Mob Programming - A Whole Team Approach [Erfarenhetsrapport]. Hämtad den 2018-11-27, från https://www.agilealliance.org/resources/experience-reports/mob-programming-agile2014/
35
9. Bilagor
36
