Praktiker som knäcker koden

Transkript

1 Örebro universitet Handelshögskolan Kurs: Informatik med systemvetenskaplig inriktning C Handledare: Ann-Sofie Hellberg Examinator: Johan Aderud Datum: HT-16/ Praktiker som knäcker koden En kvalitativ undersökning om användandet av extreme Programmings primära praktiker i verkligheten. Kim Dahlberg Linus Ivarsson

2 Sammanfattning Extreme Programming (XP) är en agil systemutvecklingsmetod som innefattar ett antal olika praktiker som beskriver hur man bör arbeta för att följa metoden. Metoden är omfattande och har ibland varit svår att implementera och har delvis blivit synonymt med några få praktiker så som till exempel parprogrammering och test-driven utveckling. Denna rapport har med hjälp av intervjuade utvecklare undersökt hur implementationen av XP skett hos företagen de arbetar på. Frågeställningen som undersökningen bygger på är: - Hur ser den praktiska tillämpningen av XPs primära praktiker ut i förhållande till den teoretiska beskrivningen? o Vilka praktiker används på företagen som undersöks? o Hur och om modifieras praktikerna för att passa respektive företag? Med hjälp av intervjuerna kunde vi se svårigheter kring implementationen av flera praktiker. I skillnad från tidigare forskning presenterad i rapporten såg vi framgångsrik implementation av praktikerna Whole Team och Sit Together medans Parprogrammering och Test-driven utveckling användes väldigt lite eller inte alls. Som svar på huvudfrågan så såg vi även stora modifikationer i flera praktiker och att dessa modifikationer även såg olika ut på de olika företagen. Vi ser ett behov av fler undersökningar i ämnet då vi inte kunnat styrka den tidigare forskning som presenterats. Nyckelord: Systemutveckling, Informatik, Extreme Programming, XP, Metodanpassning, Agila metoder, Praktiker 2

3 Innehållsförteckning Sammanfattning... 2 Innehållsförteckning... 3 Begreppslista... 4 Introduktion... 5 Bakgrund till ämnesområde... 5 Syfte och forskningsfråga... 6 Avgränsning... 6 Teori... 8 Teori... 8 Metod Litteratursökning Kvalitativ studie Ramverk Intervjuplanering Urval Genomförande av intervju Analys av intervjudata Metodkritik Analys och Resultat Sit Together Whole Team Informative Workspace Energized Work Pair programming Stories Weekly Cycle / Quarterly Cycle Slack Ten-Minute Build Continuous Integration Resultat Test-First Programming Incremental Design Tabell Diskussion Slutsats och bidrag Källförteckning

4 Begreppslista Agil Metod SCRUM Refaktorering Utvecklare Utvecklingsföretag Utvecklingsteam Utvecklingsprocess Lagkänsla Git Synkronisera kod Ordet betyder lättrörlig och innebär att man är flexibel för förändring. En ritning över hur man kan ta sig an ett problem. En agil systemutvecklings-metod som kan användas vid utveckling av system där man arbetar i omgångar. Omstrukturering av kod i syfte att göra den mer lättläst, lättare att underhålla och lättare att vidare utveckla. En person som arbetar med att utveckla system som har i syfte att förenkla eller ge stöd åt en eller flera användare. Ett företag som specifikt arbetar med utveckling av system. En grupp utvecklare som jobbar tillsammans. Den process som pågår under utveckling av system, från början till slut. Vi pratar om lagkänsla en hel del och kan uppfattats diffust, specifikt handlar det om en gemenskap där utvecklarna känner sig delaktiga och trygga. Versionshanteringsystem som bland annat ger möjlighet för fler personer att arbeta med samma projekt i flera olika förgreningar som sedan sammanfogas i en huvudgren. Sammanfoga kod från flera utvecklare till ett projekt. 4

5 Introduktion Bakgrund till ämnesområde Att utveckla system är en komplex process och hur man går tillväga för att hantera detta har förändrats genom systemutvecklingens relativa korta historia. I slutet på 60-talet växte ett strukturerat tillvägagångsätt vid systemutveckling fram. Ett så kallat top-down synsätt användes som syftade till att sätta sig in och förstå problematiken innan programmeringen kunde börja (El-Haik & Shaout, 2010). Detta förhållningssätt hade stor inverkan på systemutvecklingsmetoder under årtionden och ligger till grund för flera metoder där dokumentation och förförståelse finns i fokus. I en ansats att bryta trenden med tungt dokumentationsdrivna metoder skapades ett så kallat agilt manifest där den utvecklade programmeringskoden och funktionaliteten sattes i fokus istället för dokumentation (Agilemanifesto, 2001). Manifestet skrevs av 17 programmerare 2001 och en av dem, Kent Beck stod även som grundare av den agila utvecklingsmetoden Extreme Programming (Schwarber & Beedle, 2002). Även om man kom överens om ett manifest för det nya tänket med agil utveckling så fanns det olika åsikter om hur man bäst applicerar detta till en faktisk utvecklingsmetod. Kent Beck hade redan 1996, alltså innan skapandet av agila manifestet, under sin tid på företaget Chrysler börjat förfina en egen metod som han senare presenterade i boken Extreme Programming Explained 1999 (Beck & Andres, 2005). I metoden förespråkas korta utvecklingscykler med fokus på högkvalitativ programmeringskod. Beck skriver själv- Utan kod, ingen fungerande produkt och beskriver i flera steg hur man uppnår kod med den höga kvalité som eftersträvas i ett projekt. Extreme Programming som Kent Beck valde att kalla sin metod blev under tidigt 2000-tal en av de mest populära agila utvecklingsmetoderna men var långt ifrån den enda (Lindstrom & Jeffries, 2004). Andra agila metoder så som SCRUM började användas i större utsträckning i utvecklingsmiljöer på företag och andra organisationer. För de som valde att arbeta med Extreme Programming uppstod vissa utmaningar då man uppmanades att förändra sättet man arbetat på tidigare genom att följa de uppmaningar och praktiker Kent Beck beskrivit. Eftersom metoden består av många olika värderingar och praktiker blev hela konceptet ofta synonymt med bara några få praktiker så som till exempel parprogrammering (Erickson et al. 2015). Vi ställer oss därför frågan, hur ser metodimplementationen av XP ut idag? Vilka praktiker ser utvecklare nytta av? Hur anpassar man det som XP uppmanar till så det passar sin egen verksamhet? Det är några av sakerna vi med hjälp av tidigare forskning och intervjuer på It-företag vill ta reda på i denna uppsats. Inom ämnet XP har man tidigare forskat en hel del och i en vetenskaplig artikel hävdar Erickson et al. (2005) något intressant. De flesta inom olika utvecklingsmiljöer upplever generell framgång med hjälp av XP där praktiken parprogrammering verkar sättas i specifik fokus. De har dock ställt sig frågandes till denna omfattande ström av jakande för parprogrammering, som de hävdar har varit den bidragande effekten till förstärkande av XP. Deras artikel är en granskning av det aktuella forskningsläget inom XP och agila metoder där de som slutsats rekommenderar, eller snarare ställer krav, på områden som skulle behöva ytterligare undersökas. De hävdar att eftersom större mängden empirisk forskning fokuserats på parprogrammering skulle en djupare undersökning behöva göras i de andra relativt ostuderade primära praktikerna från XP. 5

6 Sfetsos et al. (2006) har undersökt fördelarna och svårigheterna med att implementera XP som ett helhetssystem på 15 stycken grekiska företag. Under en sex månaders period samlades data in med hjälp av enkäter och intervjuer från 30 chefer och utvecklare. Därefter har varje praktik, utifrån insamlade data, analyserats individuellt där resultatet har visat att dessa företag har haft problem med att implementera XPs praktiker. Företag har då föredragit att implementera sina egna anpassade versioner som fungerat för deras egen utvecklingsprocess. Parprogrammering och Test Driven Development har upplevts som de mest signifikanta framgångsfaktorerna. Deras artikel kan ses som ett bidrag till det forskningsgapet som tidigare nämnda artikel hävdar saknas men att de egentligen landar i en slutsats som styrker den centrala roll som parprogrammering har inom XP. Tolfo et al. (2008) har anammade ett annat perspektiv genom att undersöka hur den kulturella kontexten formas inom utvecklingsföretag när de tillämpar XP. Deras artikel syftar till att identifiera dem organisatoriska och kulturella aspekter som kan påverka användningen av XP positivt samt negativt. För att identifiera detta har de analyserat de dimensionerna av organisationskultur med hjälp av alla XPs praktiker och värderingar som perspektiv. De positiva och negativa aspekter har sedan resulterat i parametrar som kan användas för att uppskatta kompatibiliteten av XP hos företag. De föreslår även att deras parametrar kan ge förklaringar till varför företag inte implementerar XP helt ut och avgränsar sig till vissa praktiker. Tidigare forskning visar tydligt att det inte bara är att tillämpa XP i praktiken, många olika faktorer spelar roll och för att förstå hur man placerar bitarna i praktiken behövs vidare undersökning av denna metodtillämpning som Erickson et al. (2005) nämner. Vi ser att forskning har gjorts på ämnet men trots detta efterfrågas vidare undersökningar inom ämnet då ett kunskapsgap kring den faktiska implementationen av XPs praktiker kvarstår. Syfte och forskningsfråga Även om Kent Beck tydligt presenterar hur och när XP ska användas, samt ger tydliga motiv till varför, så är en utvecklingsmetod aldrig statisk utan anpassar för den miljön den ska användas i (Fitzgerald et al 2002). En anpassning kan ske både genom att förändra delar eller helt enkelt selektivt välja de delar som passar den kontext som verksamheten man befinner sig i (ibid). Med denna studie undersöker vi hur metodanpassningen av XP har skett på utvalda företag. Uppsatsen belyser hur XPs praktiker upplevs och används i verkligheten samt vilken nytta och vilka svårigheter som upplevs av utvecklarna själva. Målgruppen är både de som planerar att implementera XP i ett utvecklingsteam samt de som redan använder metoden men söker ytterligare kunskap om hur metoden har anpassas. Och med detta i åtanke har denna forskningsfråga legat till grund för studien: - Hur ser den praktiska tillämpningen av XPs primära praktiker ut i förhållande till den teoretiska beskrivningen? o Vilka praktiker används på företagen som undersöks? o Hur och om modifieras praktikerna för att passa respektive företag? Avgränsning I vår studie har vi valt att avgränsat oss till utvecklare och hur de arbetar i praktiken på företag som själv uttalar sig använda sig av XP. Vi kollar inte på ledning eller företag som inte vet vad XP är, detta för att fokusera på den praktiska tillämpningen hos utvecklare. Vi beskriver XP grundligt men har valt att fokusera på de primära praktiker och undersöker inte de sekundära som beskrivs i teorin, 6

7 eftersom de är svåra att uppnå innan man har tillämpat de primära, därav skulle studien bli för omfattande (Beck & Andres, 2005). Vi har heller inte någon avsikt att generalisera utan undersöker bara dessa två företag vi haft möjlighet att besöka i Örebro Län. Vi är alltså bara intresserade av de primära praktikernas tillämpningar på två företag vi träffat och detta kan vi få svar på genom våra intervjuer. 7

8 Teori I det här avsnittet beskriver vi grundligt vad XP är och hur man praktiskt använder sig av det. Därefter presenteras vårt ramverk som är framtagen utifrån beskrivna teorier som grund (Beck & Andres, 2005). Teori XP är en agil utvecklingsmetod skapad av Kent Beck som även var en av 17 ursprungliga författare till det agila manifestet (Schwarber & Beedle, 2002). Som en agil metod förespråkar XP korta utvecklingscykler och täta leveranser vilket ska underlätta kontakten med kund och ge möjlighet att tillgodose förändrade kravbilder. Målen med XP är att utveckla mjukvara till mindre kostnader med mindre fel samt underlätta bättre produktivitet i utvecklingsteamet och på så sätt få högre avkastning på sin investering (Beck & Andres, 2005). För att uppnå dessa mål menar Beck att ett utvecklingsteam som arbetar utifrån XP måste dela vissa värderingar. I den senaste upplagan av hans bok pekar Beck på fem stycken värderingar han anser nödvändiga för att framgångsrikt kunna arbeta med metoden. Dessa värderingar är communcation, simplicity, feedback, courage och respect (Ibid). Communication Kommunikationen är viktig både inom utvecklingsteamet och med kunden. Till skillnad mot mer formella metoder där mycket av kommunikation består av dokumentation uppmuntras istället frekvent dialog mellan alla parter i syfte att hela utvecklingsteamet samt kunden ska ha samma bild av vad som behöver göras och hur utvecklingsarbetet fortgår. När ett problem uppstår menar Beck att man ska fråga sig själv om problemet uppstod på grund av dålig kommunikation, och i så fall fundera över hur man ska kommunicera bättre för att inte upprepa samma problem i framtiden. Simplicity XP uppmuntrar sina utövare att fokusera på den enklaste lösningen först. Man menar att man inte bör ta hänsyn till eventuell extra funktionalitet som kan behövas senare utan istället lösa dagens problem på bästa möjliga sätt. Undviker man att skriva funktionalitet som kanske aldrig kommer användas kan man undvika tidsbrist för projektets vitala delar. Enkelhet inom XP syftar också till att skriva kod på enklast möjliga sätt så att alla programmerare ska ha möjlighet att förstå, och på så sätt kunna bidra. Feedback XP-team uppmanas att söka så mycket återkoppling som möjligt inom ramen för vad man kan hantera. Återkopplingen kan sökas på flera olika sätt. Att kommunicera både internt och externt mot kund kan hela tiden säkerställa att arbetet man utför går åt rätt håll. Man kan även ta hjälp av tekniska hjälpmedel så som enhetstester för att få återkoppling på hur systemet står sig mot eventuella krav. Courage XP uppmuntrar till mod gällande förändring av egen och andras kod. En utvecklare ska alltså ha mod nog att ändra eller ta bort en kollegas kod om det visar sig nödvändigt, utan att ta hänsyn till hur mycket arbete som krävts för att skapa den ursprungliga versionen. Denna uppmuntran ligger till grund för att den slutliga koden ska bli så bra som den gemensamt kan bli. 8

9 XP pekar också på att mod även kan innebära uthållighet när det gäller problemlösning. Som programmerare ska du våga fundera och försöka lösa problem även om det tar lång tid. Beck menar att med tillräcklig uthållighet kan en lösning presentera sig när man minst anar det. Respect Värderingen som uppmanar till respekt lades till i andra upplagan av boken Extreme Programming Explained 2004 och genomsyrar de andra fyra värderingarna. Beck menar att man genom att följa det som är beskrivet under de andra värderingarna vinner respekt hos sina kollegor. Man pekar också på respekt mot sig själv genom att alltid eftersträva god kvalité på den kod man skapar och alltid försöka nå den bästa lösningen genom refaktorering. Dessa värderingar ligger till grund för de praktiker som inom XP mer konkret beskriver hur utvecklingsarbetet kan utföras. Beck beskriver 13 praktiker som primära och med det menar han att man genom att implementera någon av dessa direkt får ett värde, respektive primär praktik kan alltså utövas var för sig (Beck & Andres, 2005). Utöver de primära praktikerna listar Beck ytterligare 11 sekundära praktiker som han menar är svårare att implementera i ett utvecklingsteam om man inte först bemästrat de primära praktikerna. Primära praktiker Sit Together Sit together är en praktik som innebär att man inom utvecklingsteamet sitter tillsammans och arbetare istället för att dela upp sig. Det kan exempelvis vara att man placerar utvecklare nära varandra eller att man aktivt träffas en längre stund och arbetar tillsammans. Poängen bygger på att öppna upp för mer samarbeten och inte stänga in sig i varsitt kontorsbås, detta för att öka produktiviteten och den sociala arbetsmiljö som är viktig för att underlätta problemlösning. Whole Team Begreppet Whole Team menar Beck är dynamiskt. Han skriver dels att människor behöver en viss lagkänsla för att känna behörighet men också att teamets alla resurser ska finnas tillgängliga för att gruppen ska kunna lyckas. Vikten av att ta in och plocka bort personer i ett team beskrivs också. En person med spetskompetens inom till exempel databaser kan vara väldigt viktig i början av ett projekt men kan kanske flyttas till ett annat team när väl databaserna är på plats. Informative Workspace Att forma arbetsplatsen utifrån det arbete som görs är något som öppnar upp för att information blir mer tillgänglig för utvecklingsteamet och andra intressenter. Detta är vad Informative Workspace handlar om och kan uppnås genom att exempelvis sätta upp stories, som är ytterligare en praktik som vi senare förklarar mer ingående, eller grafer relaterade till utvecklingsprocessen. Beck hävdar att detta bidrar till att utvecklarna får en känsla över vilket skede projektet befinner sig inom, samt att andra intressenter snabbt kan skapa sig en bild av projektet utan att störa utvecklingsteamet. Energized Work Som riktlinje inom XP uppmanas utövarna att arbeta 40-timmarsveckor. Det viktigaste menar Beck är dock att arbeta så många timmar som man kan vara produktiv. Han menar att det aldrig är värt att bränna ut sig en dag om det innebär att det minskar produktiviteten och kreativiteten de två nästkommande dagarna. 9

10 Liknande ser han på vikten av att stanna hemma och kurera sig vid sjukdom. Att komma till jobbet trots sjukdom är inte respekt gentemot sina kollegor utan tvärtom. Att istället stanna hemma och vila sig frisk så fort som möjligt visar respekt både mot sin egen och sina kollegors förmågor och kompetens. Sammanfattningsvis skriver han att mjukvaruutveckling handlar om insikt, och insikt kommer till den som är förberedd, utvilad och avslappnad. Pair Programming Denna praktik innebär att man utvecklar i par där en person kodar medan den andra observerar och bidrar med synpunkter. Ett ytterligare perspektiv öppnas upp för den observerande utvecklaren och kan se problemlösningen från en annan vinkel, den ser då en större helhetsbild och kan bidra till att man håller varandra i rätt riktning, klargör idéer och minskar frustration. Parprogrammeringen ska ske kontinuerligt och på så sätt säkerställa en hög kodkvalité. Stories Stories innefattar korta och koncisa beskrivningar över vad system ska kunna göra för att tydliggöra utvecklingsteamets uppgifter. En story skall fånga behoven vem, vad och varför på en kort sammanfattat text som oftast skrivs ner på en post-it. Dessa kan tas fram i början utav utvecklingsfasen och syftar till att snabbt skapa sig en uppskattning över hur mycket resurser som behövs. Weekly Cycle Inom XP uppmanas planering veckovis. I praktiken betyder det att man i början av varje arbetsvecka håller ett möte där man går igenom hur förra veckans arbete gick i förhållande till de förväntningarna man hade. För nuvarande vecka ber man kunden välja stories som motsvarar en uppskattad arbetsvecka. Dessa stories bryts sedan ner till mindre bitar och delas ut bland utvecklarna i teamet. Det praktiska arbetet kan sedan börja med att man skriver automatiserade test som ska passeras när alla stories är färdiga. Märker man under veckan att man inte kommer hinna slutföra alla stories så fokuserar man helt enkelt på de viktigaste och tar med det i beräkningen under nästa veckas planeringsmöte. Quarterly Cycle Utöver veckoplaneringen bör utvecklingsteamet också ha en plan för ett helt kvartal. I denna planering är det viktigt att man identifierar eventuella flaskhalsar, speciellt de som inte kan bli påverkade från teamet själva. Man tittar efter eventuella mönster på vad som ska göras och skapar stories som matchar dessa. Fokus ska ligga på helhetsbilden och hur projektet passar in i den övriga organisationen. Slack Slack praktiken innebär att man skall inkludera mindre viktiga eller lättare arbetsuppgifter i sin planering för att skapa utrymme för att projektet ska kunna gå smidigt. Detta utrymme kan fungera som ett andningsutrymme i utvecklingsprocessen, eftersom man har möjlighet om man hamnar efter i utvecklingsprocessen att släppa dessa arbetsuppgifter. Ten-Minute Build När man bygger ihop sitt system för att, exempelvis prova ny funktionalitet och leta efter fel, så är det viktigt att det inte tar längre tid än tio minuter. Detta är kritiskt för systemets kvalité då en längre byggtid kan resultera i att systemet inte testas lika ofta och resultera i att man missar chanser för felsökning. 10

11 Continuous Integration Beck hävdar att desto längre man väntar med att interagera systemets olika delar desto större och oförutsägbara blir kostnaderna. Att alltid utveckla utifrån den senaste versionen av systemet är något som förhindrar detta. Tanken är att utvecklare jobbar med olika delar i ett och samma projekt och att slås ihop till en och samma huvudprojekt flera gånger om dagen. Test-First Programming När man utvecklar och skriver kod handlar denna praktik om att göra det hela bakvänt. Man börjar med att skapa ett test, som från början fallerar. Därefter bygger man vidare och utvecklar tills testet inte längre fallerar. På så vis sätter man testning i fokus redan från början vilket leder till att testning körs kontinuerligt, vilket i sin tur resultera i att det tar kortare tid att upptäcka fel. Incremental Design Istället för att göra ett stort designarbete innan utvecklingen drar igång så bör designen av systemet evolveras under utvecklingstiden. Enligt Beck är denna praktik inte en motsägelse till förarbete med design utan snarare implikation till att design skall utvecklas i samband med att det används, då detta sätt är mer effektivt. Detta resulterar även i att utveckling av system kan börja smått och över tiden växa utan extrema kostnader. Sekundära praktiker Lyckas man implementera och få värde från dessa praktiker har man kommit långt och som tidigare nämnt erbjuder XP ytterligare sekundära praktiker som kan utveckla arbetet. En av dessa praktiker Real Customer Involvement som syftar till att inkludera folk som kommer använda systemet i utvecklingsteamet. De uppmanas att delta i vecko- samt kvartalsplaneringen och få så sätt säkerhetsställa att utvecklingen går i en riktning som korrelerar med verkligheten. Incremental Deployment pekar på vikten att gradvis ersätta äldre system med nyutvecklad mjukvara. Beck skriver att arbeta mot en så kallad D-Day där ett helt system ska bytas ut sällan fungerar och även om det mot förmodan skulle göra det så kommer hela utvecklingsteamet vara utarbetad under lång tid därefter. Att teams som fungerat bra ihop ska fortsätta få arbeta är en del av XP som kallas Team Continuity. Det kan kanske ses som självklart men Beck menar att det är vanligt i större organisationer att man ser utvecklare som komponenter som ska kan flyttas runt hur som helst. När utvecklingsteam växer i kompetens ska arbetsbördan fortsätta vara konstant genom att man gradvis minskar ner antalet personer i teamet för samma uppgift. Inom XP kallas detta Shrinking Teams och ger möjlighet att starta nya teams och på så sätt öka produktiviteten. Root-Cause Analysis beskriver hur man ska arbeta när ett fel upptäcks vid utvecklingen. Målet är inte bara att eliminera felet och dess orsak utan att också se till att teamet aldrig gör samma sorts fel igen. Detta ska ske via enhetstester där man ställer sig ett antal frågor om varför felet kunde uppstå. Utöver detta så skapas enhetstester där felet replikeras och lagas. XP uppmanar till att ha en gemensam kodbas, så kallad Shared Code. Vem som helst i teamet ska kunna förbättra alla delar av koden även om den är skriven av någon annan. Om man upptäcker ett fel så ska man alltså istället för att kontakta den ursprungliga utvecklaren av stycket helt enkelt reparera eller förbättra koden direkt. Utvecklare ska fokusera på det som har ett värde för kunden. Inom XP beskrivs det som Code and Tests. Kunden betalar för vad systemet kan göra idag och vad utvecklarna kan få systemet att göra 11

12 imorgon. Beck menar att fokus tidigare under årtionden varit det motsatta. Processor, planer och andra artefakter har fått för stor plats. Inom XP bör man istället vara fråga sig Vad ska vi göra? och Hur ska vi göra det?. Single Code Base uppmanar till att bara arbeta och underhålla en kodbas. Beck menar att det är okej att utveckla i tillfälliga förgreningar men att deras livslängd högst bör vara några timmar. Negotiated Scope Contract, innebär att när man skriver kontrakt med kund är det viktigt att tänka på att arbeta med korta sekvenser av kontrakt istället för ett långt. Daily Deployment handlar om att få ut projektet i drift dagligen för att minska gapet av vad som finns på utvecklarens skrivbord och när det skall användas, för att motverka att utvecklare inte hamnar ur synk. Avslutningsvis så bör man inom XP ta betalt per användning av systemet snarare än schablonbelopp eller specifika prissättningar. Detta kallas inom XP Pay-Per-Use och ger väldig tydlig feedback på hur väl mottaget systemet här hos användarna. 12

13 Metod För att nå den kunskap vi eftersträvade genomfördes intervjuer med utvecklare på företag. I detta kapitel kommer utförandet av hela processen beskrivas: planering, intervjuer och analys av insamlade data. Litteratursökning Arbetet inleddes med sökande av relevant litteratur och forskning i ämnet. Både beskrivande litteratur av XP så som vetenskapliga artiklar om utövande i praktik gicks igenom. De databaser vi använde för att hitta artiklar var Google Scholar och Summon. Nedan följer en tabell där vi sammanställt de sökord, databas och resultat som visar en tydlig bild över vår litteratursökning. Utöver användandet av dessa sökord har vi även filtrerat resultaten efter vetenskapligt granskade artiklar. Vi filtrerade även utifrån årtal för att hitta så aktuell forskning som möjligt. Hittade vi inga träffar mot vårat ämne relevant gick vi bakåt i tiden för att få fler resultat. Databas Sökord Resultat (st) Filtrering Google Scholar extreme programming practices Google Scholar extreme programming practices reality Summon "extreme programming" 575 Enbart vetenskapligt granskade tidskrifter inom området computer science. Publicerat efter år Summon Extreme programming practices 2654 Enbart vetenskapligt granskade tidskrifter inom området computer science. Publicerat efter år Viktigt att poängtera är att vi inte läste igenom alla resultat som presenteras i tabellen. Istället läste vi rubrikerna på de fem första sidorna och tyckte vi dessa var intressanta läste vi även artikelns sammanfattning. Upplevde vi även sammanfattningen intressant läste vi hela artikeln. Om en artikel vi läste förde ett intressant resonemang i ämnen med andra intressanta externa källor så tittade vi även på dess källor. För att ge oss en klar definition av vad XP och dess praktiker innebär valde vi att använda oss av skaparen Kent Becks beskrivningar från andra upplagan av boken Extreme Programming Explained som också är den senaste. Kvalitativ studie Studien som genomförts har varit kvalitativ med intervjuer som insamlingsmetod. Eftersom studiens syfte var att få en förståelse om hur XPs praktiker fungerar och anpassas i verkligheten och inte bara ta reda på vilka som används hölls intervjuerna med färre personer (4 stycken) men med ett större djup och möjlighet för den svarande att grundligt beskriva och förklara sina svar (Oates, 2006). 13

14 Ramverk Ramverket har skapats utifrån teorin som beskrivits i tidigare kapitlet och kommer användas i flera steg. Ramverket kommer ligga till grund för planering av intervjun, genomförandet av intervjun samt analysen av de svar som intervjuerna ger. Även om intervjuerna genomförs semi-strukturerat vilket kommer beskrivas senare i kapitlet så användes ramverket för att säkerhetsställa att alla praktiker berördes under intervjun i form av en grundfråga kring varje rubrik i ramverket. Litteraturen och teorin ligger alltså till grund för ramverket som i sin tur ligger till grund för vilka frågor som ställs under intervjuerna. Även under analysen av intervjusvaren kommer ramverket vara en viktig del då vi matchar de svaren vi får med de punkter som är beskrivna under respektive praktik i ramverket. Detta kommer också att beskrivas ytterligare senare i kapitlet. Sit Together Sitter utvecklarna på företaget tillsammans i ett öppet kontorslandskap? Har man öppet kontorslandskap istället för bås för era arbetsstationer? Whole Team Är utvecklingsteamen dynamiska på ett sådant sätt att man är öppen för att flytta utvecklare när behov förändras i ett projekt? Har man skapat en sammanhållning i utvecklingsteamen där utvecklarna känner lagkänsla? Informative Workspace Presenteras utvecklingsprocessen på arbetsplatsen med hjälp av stories, diagram eller annan typ av grafisk illustration? Energized Work Använder man sig av 40-timmarsvecka på arbetsplatsen? Är arbetsplatsen flexibel för programmerare att själva ändra sin arbetstid? Uppmuntras man att stanna hemma vid sjukdom? Pair programming Används parprogrammering kontinuerligt under utveckling? Används parprogrammering i syfte att öka kodkvalitén? Stories Används så kallade stories på arbetsplatsen? Innehåller stories vad som i teorin beskrivs som vem/vad/varför? Weekly Cycle Sker planering veckovis? Går förra veckans planering igenom och jämförs mot de förväntningar man hade? Får kunden möjlighet att vara med och påverka vad som ska fokuseras på under veckans arbete? Börjar veckans praktiska arbete med att automatiserade test skrivs för det uppgifter som ska utföras? Quarterly Cycle Har man utöver veckoplaneringen en plan i utvecklingsteamet för hela kvartalet? Slack Inkluderar man medvetet enklare uppgifter i planeringen som kan strykas om tiden inte räcker till för att slutföra det man planerat för? 14

15 Ten-Minutes Build Jobbar man för att inte överstiga tio minuters byggtid? Continuous Integration Integreras olika delar av systemet kontinuerligt med varandra till ett och samma huvudprojekt? Arbetar man alltid utifrån den senaste versionen av systemet? Test-First Programming När man skriver kod, skrivs test allra först? Incremental Design Under tiden som systemet utvecklas, utvecklas även design och arkitektur? Intervjuplanering Intervjuerna planerades för att vara semi-strukturerade i sin karaktär. En semi-strukturerad intervju har förutbestämda teman och intervjufrågor är öppen för att ändra ordningsföljd för frågor beroende på hur konversationen fortgår (Oates, 2006). Vidare så tillåter en semi-strukturerad intervju intervjuaren att ställa nya frågor som inte är förberedda om den intervjuade lyfter ett ämne som verkar relevant men inte planerat för (ibid). Oates menar vidare att en semi-strukturerad intervju tillåter den intervjuade att tala öppet och fritt om deras åsikter och erfarenheter vilket var precis den typ av information studien sökte. Även om intervjun planerades att vara semi-strukturerad förbereddes intervjufrågor baserade på det ramverk som vi skapat utifrån teorin. Detta gjordes för att försäkra sig om att samtliga praktiker vi var intresserade av på något sätt berördes under intervjun. Vidare förbereddes vissa underfrågor som under intervjun kunde användas för att följa upp ett visst svar från den intervjuade. Frågorna som förbereddes var öppna och i ett brett perspektiv. Oates (2016) menar att öppna frågor är att föredra i intervjuer av denna karaktär då de uppmuntrar till mer omfattande svar från de intervjuande. Frågor som behandlade praktiken Sit Together nämnde aldrig praktikens faktiska namn utan löd istället Hur placerar ni medarbetare på er arbetsplats?, Har ni någon tanke bakom varför ni sitter som ni sitter?, Anser du att fin placering och omgivning bidrar till din arbetsförmåga, positivt eller negativt?. Detta i syfte att inte uppmuntra den intervjuade att rabbla inlärda fakta om vad en praktik bör innebära utan istället berätta hur de faktiskt arbetar. Urval Kontakt med företag togs via telefon där studien i korthet presenterades där det också kontrollerades om företagen anser sig använda XP i sina utvecklingsteam. Studien valdes att genomföras på två jämnstora företag där antalet anställda var ca 50 personer. Båda företagen arbetade som konsultföretag och marknadsförde sig som agila. De informerade även om att de implementerat praktiker inom XP. Vi valde sedan ut två utvecklare att intervjua från respektive företag där kompetensen varierande i antal år de hade arbetat. Ingen av utvecklarna hade arbetat mindre än tre år och men heller inte arbetat lika länge. På ena företaget var utvecklarna fyra och fem år inom branschen och det andra tre och fyra. På så sätt fick vi en variation på erfarenheter hos utvecklarna på respektive företag och det kunde ge oss ett starkare resultat. Eftersom intervjuerna planerades att vara utförliga med stort utrymme för den intervjuade att förklara och utveckla sina svar togs beslutet att lägga fokus på just fyra intervjuer. Ett annat beslut som togs var att intervjua två utvecklare från respektive företag. Detta i syfte att ytterligare kunna jämföra och förstå enskilda utvecklares åsikter och tankar till den 15

16 metodimplementation som skett. Genomförande av intervju De utvecklare som skulle intervjuas fick själva välja vart intervjun skulle genomföras då det är viktigt att de känner sig bekväma i miljön där intervjun hålls för att ge möjlighet att svara så öppet som möjligt (Oates, 2006). Samtliga fyra valde sitt eget företags kontor. Eftersom vi inte själva hade kontroll över lokalen där intervjun hölls så fick intervjun genomföras på bästa möjliga sätt efter de förutsättningar som gavs. Vi introducerade oss själva och inledde samtalet med småprat för att lätta upp stämningen och få den intervjuade mer avslappnad (ibid). Den intervjuade blev tillfrågade om det var okej att spela in intervjun vilket samtliga gav godkännande till. Försäkran gavs också att både de intervjuade samt företaget de arbetar på hålls anonymt i uppsatsen. Intervjun inleddes med de något enklare frågorna först i syfte att få respondenten att slappna av och få möjlighet att bygga förtroende till den som håller intervjuer till de lite mer svåra och möjligen känsliga frågorna (Ibid). Stor vikt lades på att ställa frågor och följdfrågor utan att blanda in egna värderingar. Detta är viktigt då den som intervjuar själv kan styra vilket typ av svar respondenten upplever att den uppmanas att ge (Ibid). Intervjun avslutades med att respondenten gavs möjlighet att ställa några frågor eller utveckla ett tidigare resonemang. Slutligen tillfrågades respondenten om hen ville ha en transkribering skickad till sig i efterhand vilket samtliga fyra tackade nej till. Analys av intervjudata När intervjuerna var genomförda och data var insamlad i form av inspelade ljudfiler valde vi att gemensamt transkribera dessa till text. Genom att sitta gemensamt öppnade det upp för att kunna stanna och föra en diskussion om intressanta stycken, för att sedan fortsätta vidare i transkriberingen. Allt eftersom skrev vi ner diskussionerna i text och filtrerade bort det som inte var relevant så som utfyllnadsords. Vi noterade även om en fråga upplevdes vara svår att besvara eller om respondenten upplevdes vara lite extra engagerad i frågan. Detta i syfte att fånga upp mer än bara orden som sades för att på så vis berika intervjun med den mänskliga faktorn (Oates, 2006). När transkriberingen var färdig användes materialet till att presentera resultatet kategoriserat under respektive praktik. Detta resultat analyserades sedan gentemot det ramverk vi presenterat. En bedömning genomfördes där vi genom matchning mot de punkter kring varje praktik vi presenterat i ramverket för att se om praktiken är uppnådd eller inte. På så sätt fick vi också möjlighet att se vad som saknas i metodutövandet för att uppfylla det som beskrivs inom XP. Metodkritik Under våra intervjuer ställde vi inte exakt samma frågor för varje respondent eftersom vi använde oss utav semi-strukturerade intervjuer. Detta kan tyckas leda till att man kan missa viss information i en intervju till skillnad från en annan. Dock var detta inget som vi upplevde, vi fick istället mycket mer bredd i varje intervju eftersom vi kunde ställa formade frågor utifrån situationen och även kunna komma med motfrågor när det var något intressant vi behövde veta mer om. Resultatet blev i sin tur svårt att analysera eftersom vi inte följde ett exakt likadant mönster för varje intervju. Vi fick då lägga mer energi på att arbeta fram resultatet och något vi skulle kunna gjort var att ha ännu mer 16

17 strukturerade frågor. Dock var vi intresserade av mindre styrda diskussioner och det var ett medvetet val som vi gjorde, på så sätt fick vi lägga mer arbete på transkribering men samtidigt fick vi också välutvecklade svar till våra frågor, vilket vi kanske inte hade fått om vi var mer strukturerade. Oates nämner intressanta aspekter att tänka på när man skall intervjua respondenter, exempelvis kan de bli obekväma av att bli inspelade (Oates, 2006). Detta var ingenting som någon av våra respondenter uttalade sig emot när vi i början på intervjun ställde frågan. Hade de varit det hade vi istället fört anteckningar. 17

18 Analys och Resultat I det här avsnittet har vi sammanställt svaren från intervjuerna där vi presenterar varje företags arbetssätt utifrån de frågor vi ställt och grupperat efter respektive praktik i vårt ramverk. Efter att varje resultat har redovisats har vi även gått in på analys av dessa. När vi nämner företagen har vi valt att använda benämningarna Företag A och Företag B, detta för att göra upplägget tydligt för läsaren. Eftersom vi har pratat med två respondenter från respektive företag har dem tilldelats benämningarna Anna och Adam från Företag A, samt Berit och Benny från Företag B. I slutet av detta avsnitt presenteras även en tabell för att tydliggöra resultatet och analysen ytterligare. Sit Together Resultat I våra intervjuer berättar samtliga respondenter att de sitter i en gemensam yta. Detta är något som man hävdar att ledningen för respektive företag har gjort medvetet, d.v.s. man har avsiktligt utformat arbetsplatsen för att göra det möjligt för utvecklare som arbetar i projekt att aktivt kunna sitta tillsammans. Anna från företag A uttrycker dock att, även fast de sitter tillsammans i större utvecklingsteam, så händer det ofta att de även arbetar i mindre projekt där man kan vara utspridda. Detta är något som upplevs som rörigt, som Adam även bekräftar när han pratar om hur de brukar jobba i mindre projekt. Om exempelvis en diskussion startar om ett annat projekt där Anna inte är delaktig upplever hon att det kan vara svårt att hålla sig fokuserad. Dock är båda övertygade om att sitta tillsammans är något som de ser stort värde i på Företag A även om de skulle kunna önska mer flexibel placering där man kan byta plats beroende på projektdelaktighet, då det främjar utvecklandet på det sättet att man lätt kan fråga om hjälp eller diskutera eventuella lösningar eller hinder. Företag B sitter i olika rum och menar att det är till stor del lokalerna som har satt förutsättningarna för hur de arbetar. I dem större rummen använder de sig av ett öppet kontorslandskap där de har direkt kontakt med de som arbetar i sitt utvecklingsteam och använder skärmar för att avgränsa sig när det behövs. I mindre rum kan det bli att de sätter sig för sig själva och oftast används dessa rum när man vill ha det tyst. Företag B nämner även att dom har använt sig utav en speciell kontorsinredare för att utforma arbetsplatsen i syfte att kunna sitta tillsammans samtidigt som att det är ingen av utvecklingsplatserna som är bestämda för en specifik person. Även på företag B är detta något som respondenterna uppskattar och anser hjälpande i utvecklingsprocessen. Analys Vår tolkning av deras svar är att alla fyra personer, från båda företagen, uppskattar praktiken och ser stort värde i vad den förespråkar. Det negativa som lyftes upp var att det på företag A kunde bli rörigt när de utvecklare som satt nära var inblandade och diskuterade ett annat projekt än sitt eget, något som man önskade förändra genom mer flexibel placering. Men trots detta, tolkar vi att båda företagen fyller dom kriterierna vi ställt i vårt ramverk för att uppfylla denna praktik. Whole Team Resultat När vi frågade respondenterna hur företagen sätter ihop sina utvecklingsteam och om strukturen förändras under utvecklingsprocessen, så skiljer det sig hur de svarade. Anna och Adam från företag A berättar att man inom företaget vill man att alla ska kunna samla på sig så mycket kunskap som möjligt. Därför, när man sätter ihop sina utvecklingsteam, strävar man efter att blanda dessa så mycket som möjligt för att få variation på kompetens samtidigt som de 18

19 tänker på att de ska bli så kompletta som möjligt, t.ex. kan speciell kunskap om databaser behövas och då väljer dem in personer utifrån det. Mer ingående berättar Anna att de under en längre period till stor del arbetar i två större utvecklingsteam, men även att det parallellt skapas mindre utvecklingsteam för kortare perioder. I dessa större utvecklingsteam förklarar hon att det inte är vanligt att man byter ut vilka som ingår i utvecklingsteamet, man stannar oftast kvar inom teamet och går inte över till det andra för att det skulle bli rörigt. I de mindre utvecklingsteamen är man dock flexibel, här kan man flyttas runt beroende på hur projekten kan se ut och vilka behov som kan uppstå. Att sprida kunskap är något som Adam uttrycker är viktigt och något han tycker de borde bli bättre på. Till skillnad från Anna uttrycker han sig lite mer kritisk, han anser att de behöver blanda de större teamen mer och något de skulle kunna bli bättre på. Hans uppfattning är att, även fast det i nuläget blandas i de mindre projekten så skulle alla tjäna på att de större utvecklingsteamen också skulle var mindre rigida. Enligt både Berit och Benny har man som mål på företag B att arbeta utifrån team som väljs ut i början av utvecklingsprocessen, men något som de upplever vara väldigt svårt. Benny berättar att de har många nyanställda utvecklare på företaget, vilket är något som ställer krav på att teamen är dynamiska. Samtidigt berättar Berit att utvecklare ibland går på föräldraledighet vilket också bidrar till att teamen kan förändras i utvecklingsprocessen. Ytterligare förklarar både Berit och Benny att de oftast är involverade i mer än tre projekt samtidigt, något som är vanligt hos alla utvecklare på företaget. Detta gör att de prioriteras olika inom varje projekt och ibland behöver lägga mer krut på vissa projekt vilket gör att de hoppar väldigt mycket runt inom sina projekt. Intervjun fördes även in på sammanhållning inom företaget och utvecklingsteamen och när vi frågar hur Anna på företag A upplever detta säger hon såhär: Man märker tydligt av sammanhållningen i det större projektet. Efter att ha arbetat tillsammans i ett halvår kommer man nära varandra och det känns verkligen som ett lag. Det framgår även att Anna anser detta vara väldigt viktig aspekt för att trivas på sin arbetsplats samtidig som hon vill förtydliga att det främst är i de större projekten. Adam tycker att sammanhållningen är över hela företaget och inte just specifikt för varje team. På företag B är både Berit och Benny övertygad om att sammanhållning är något som uppmuntras i företaget. Detta görs genom diverse aktiviteter i vardagen, de hittar på olika saker för att försöka bidra till att skapa en sammanhållning. I längre projekt är det något som de har lyckats skapa, Benny upplever dock att det är viss problematik med att ett team har mer lagkänsla än ett annat, då det kan bli konkurrens. Analys Efter att ha tolkat våra intervjuer har vi kommit fram till att det skiljer sig till hur man arbetar mellan företagen men gemensamt har man en snarlik uppfattning om praktiken. Det intressanta är att båda företagen strävar efter samma sak, man har som mål att arbeta utifrån ett utvecklingsteam med tillräckligt varierande kompetens men väl inne i utvecklingsprocessen behöver man göra förändringar och flyttar folk. 19

20 På Företag A tolkar vi det som att man är mindre dynamisk i sina större och längre utvecklingsteam men trots detta arbetar de väldigt dynamiskt i sina mindre projekt. På Företag B var varje utvecklare inblandad i fler än tre utvecklingsteam samtidigt vilket resulterar i att de behöver vara väldigt dynamiskt eftersom de flyttades runt. Därmed är det tydligt att Företag B är mer dynamisk än Företag A, men vår tolkning är att båda företagen följer det kravet vi ställt i vårt ramverk. När det kommer till sammanhållning var alla utvecklare medvetna om värdet och uttryckte själva att det var något som fanns på deras arbetsplats. Trots olika arbetssätt kan vi se att båda företagen använder praktiken utifrån vårt ramverk. Informative Workspace Resultat I intervjuerna med respektive företag framgick det att inget av företagen använder sin arbetsplats för att illustrera hur utvecklingsprocessen ser ut. Istället använder båda företagen sig av mjukvaruprogram som hjälpmedel för att visualisera hur man ligger till. På företag A berättar Anna att de har allt digitalt på datorn men att det skulle kunna vara något som uppskattats om det syntes på arbetsplatsen, eftersom det kan vara extra tydligt för andra hur projektet går. I intervjun med Adam berättar han att man på morgonmöten, med hjälp av mjukvaruprogrammet, visar upp hur man ligger till och får en slags visualisering av läget. Dock uttrycker han även som Anna, att det skulle uppskattas att man har något som sitter uppe, exempelvis på en vägg där man enkelt kan få andra som inte är med i utvecklingsteamet att bli mer delaktig i utvecklingsprocessen. Samtidigt som han säger att det inte är något som han känner saknas, utan mer som något han skulle uppskatta och tycka var roligt. På företag B har man även här mjukvaruprogram som hjälpmedel, dock har man provat att använda sig av omgivningen men något som de upplevt som mer rörigt än bidragande. Benny berättar hans uppfattning är att det främst var svårt att visa kunden hur de ligger till när de vanligtvis jobbar med kunder som inte alltid kan komma till deras arbetsplats. Då behövde de fotografera arbetsplatsen och mejla över till kunden för att få respons, det är därför som han anser att dem har gått över till att använda sig av mjukvara för detta istället. I Berits intervju intygar hon även samma sak, men tillägger att det är olika beroende på hur utvecklingsteamen ser ut. Ibland kan man exempelvis arbeta själv och då påstår hon att de gör lite hur de vill beroende på vad de ska göra. Analys Eftersom omgivningen på arbetsplatsen inte har använts, utan istället digitalt mjukvaruprogram, är våran tolkning att inget av företagen utifrån vårt ramverk använder sig av praktiken på det sätt som är beskrivet. Dock anser vi att dom har modifierat denna praktik passa in på respektive företag. Detta har man lyckats med och man har tagit de delar av praktiken som gett mest värde och implementerat det på ett nytt sätt. Energized Work Resultat Vid intervjuerna framgår att båda företagen använder sig av 40-timmarsvecka men samtidigt att stor fokus ligger på att leverera till kund i tid. På företag A berättar Adam att man även har möjlighet att flexa, det vill säga gå hem tidigare om man jobbat mer en annan dag, men att det kan vara svårt då det på morgonen finns fasta tider för möte och att det under eftermiddagen ofta finns så mycket att göra att det kan vara svårt att komma ifrån. Anna sa samma sak som Adam men la även till att utvecklarna hade möjlighet att arbeta hemifrån om det skulle behövas eller önskas. Varken Adam eller Anna har upplevt press från arbetsgivare eller kollegor att arbeta trots sjukdom. 20

21 Båda nämner dock att de på grund av arbetsbördan ofta i alla fall försöker att jobba hemifrån trots sjukdom. Respondenterna på företag B berättar också att de har möjlighet att flexa. Benny berättar att det ofta finns möjlighet att gå hem tidigare men att det är helt beroende av hur arbetsbördan ser ut för dagen. Berit berättar att även om hon ofta jobbar över sin normala tid så har det aldrig varit på grund av påtryckningar från andra utan för att det passat henne. Gällande arbete i kombination av sjukdom så nämns det även på företag B av båda utvecklarna att man hellre arbetar hemifrån än sjukskriver sig helt. Både Benny och Berit understryker dock att dom aldrig känt sig tvingade att arbeta från ledning eller kollegor. Benny tar upp att det kan bli dyrt att inte arbeta då de på företaget har många så kallade karensdagar innan man får sjukersättning. Hur många dagar det handlar om ville han inte svara på. Analys Vi tolkar resultatet som att man på båda företagen sett ett värde i praktiken och försöker arbeta därefter men att det i verkligheten inte alltid fungerar. Ingen av de fyra utvecklarna känner någon uttalad press från kollegor och ledning att arbeta vid sjukdom men istället nämns arbetsbördan och personlig ekonomi som faktorer som påverkar. Flexibel arbetstid finns i viss mån i form av flextid men precis som med arbete och sjukdom så finns vissa hinder på båda arbetsplatserna för att det ska fungera fullt ut. Ingen av respondenterna nämner något om att arbeta så länge man är produktiv utan de handlar istället om att göra de timmar som hör en arbetsvecka till. En arbetsvecka på båda företagen är 40-timmar så som XP uppmanar till. Sammanfattningsvis tolkar vi det som att man på båda företagen tydligare behöver uppmuntra sina utvecklare till att ta den tid som behövs för att sedan kunna prestera på sin högsta nivå. Pair programming Resultat Programmera i par är något som båda respondenterna på företag A berättar händer lite då och då. Oftast, berättar Adam, att detta sker i samband med att ett nytt projekt startar eller att någon ny form av ny teknik skall användas. Då förklarar Adam att det blir väldigt naturligt att man sätter sig två vid samma dator för att jobba tillsammans med de första problemen. När vi intervjuar Anna säger hon såhär: Vi gör det i vissa fall, men det kunde nog vara lite mer. Man kan ha nytta av att alltid ha det, eftersom man sprider kunskap och det blir en slags kvalitésäkring. Anna berättar samtidigt att de, trots detta, bara sätter sig och parprogrammerar när det finns ett behov för teamet och inte utifrån att någon gemensam bestämmelse eller typ av beslut från ledningen. På företag B beskriver både Benny och Berit att dom inte har något bestämt arbetssätt som understryker att dom ska sätta sig och parprogrammera två och två. Däremot, sker det spontant när någon behöver hjälp och då sätter de oftast sig med någon som har mer kunskap inom området. Benny beskriver även att ibland vet man av att det kan behövas två personer för att lösa ett problem och då brukar man bestämma i förväg att två personer tar på sig detta och faktiskt parprogrammerar. Då förklarar han, att problemet blir löst snabbare och det är något som de använder sig av för att göra snabba insatser, detta eftersom det kan ta tid att synkronisera sin kod och samtidigt vara ansträngande att hålla koll på vem som gör vad. 21