Gruppens erfarenheter

Gruppen fattade aldrig formellt beslutet att använda sig av KL, och termen förekommer in- te i projektplanen för applikationen. Trots detta så använde gruppen många processer som associeras med KL, och följde ett arbetssätt som påminner om vad som används inom KL. En agil arbetsmetodik användes, där utvecklingen av applikationen bröts upp i 5 iterationer. Vid början av varje iteration planerades ett visst antal aktiviteter som skulle slutföras under iterationens gång, som sedan tilldelades till gruppmedlemmar. Dessa aktiviteter var oftast ny funktionalitet eller felkorrigeringar som skulle implementeras. Vid slutet av varje iteration skulle koden för alla färdiga aktiviteter sammanfogas och överföras till projektets huvudgren. Gruppen siktade på att kontinuerligt överföra ny funktionalitet till projektets huvudgren, och att hålla huvudgrenens kod i ett fungerande och lättläsligt skick. Vid utvecklingens start fat- tades beslutet att alla sammanfogningar in i projektets huvudgren skulle granskas av minst en annan gruppmedlem innan de verkställdes. Detta skedde via GitLabs inbyggda funktio- nalitet för sammanfogningsförfrågningar, så att gruppmedlemmar kunde se aktiva förfråg- ningar på projektets GitLab-sida. Vilken gruppmedlem som helst kunde ta initiativet för att ganska en sådan förfrågan, och lägga kommentarer på delar av koden som bör ändras för att uppfylla projektets krav på kodkvalitet. Dessa kommentarer åtgärdas sedan av utvecklaren som lämnade sammanfogningsförfrågan, och en ny sammanfogningsförfrågan lämnas. I de flesta fallen hade granskaren inga kommentarer, och då accepterades förfrågan utan ytter- ligare kommunikation, varefter ett automatiskt mail skickas till medlemmen som lämnade förfrågan. Större ändringar skulle sammanfogas vid gruppmöten, så att alla medlemmar för-

E.6. Diskussion

stod ändringarna och fick en chans att lämna kommentarer. Ändringar som accepterades in i huvudgrenen sjösattes automatiskt på en särskild server.

Vid slutet av varje iteration skedde en leverans till kunden, vilket innebar att all ny funktiona- litet skulle vara införd i huvudgrenen innan dess. För att se till att detta skedde planerades ett sammanfogningsmöte där alla gruppmedlemmar tillsammans fick reda ut hur koden skulle sammanfogas. Dessa möten varade ofta längre än vad som var tänkt och var relativt kao- tiska, med ett antal buggar som upptäcktes och fixades på plats. Eftersom ett flertal grenar behövdes sammanfogas in i huvudgrenen bildades en kö av sammanfogningsförfrågningar, och följande arbetsflöde behövde följas:

1. Grenen som ska sammanfogas granskas, och kommentarer läggs på vad som behövs ändras.

2. Eventuella kommentarer åtgärdas. 3. Sammanfogningsförfrågan accepteras.

4. Övriga grenar i sammanfogningskön integrerar de nya ändringarna. 5. Nästa gren väljs för att sammanfogas.

Dessa steg upprepas tills samtliga ändringar har integrerats in i huvudgrenen. Detta gav inte upphov till några större problem under projektets gång, men det är lätt att se att detta inte är särskilt skalbart, och det finns tydligt rum för förbättring.

Webbapplikationen som utvecklades hade en tillhörande back-end som även den uppdatera- des på liknande vis, dock inte lika ofta. Vid vissa tillfällen accepterades en ändring i front-end utan att tillhörande back-end uppdatering också accepterades, vilket under en kort tid ledde till att de två delarna av projektet var icke-kompatibla.

När utvecklingen på applikationen påbörjades sattes ett automatiskt build-test upp, eftersom detta var relativt snabbt och enkelt att implementera och aldrig behövdes skrivas om under projektets gång. Dock skrevs inga tillhörande automatiska enhetstester, eftersom att grupp- medlemmarna hade begränsad kunskap om automatisk testning och ville undvara så lite tid som möjligt från själva systemutvecklingen. En annan faktor till att avstå från automatiska enhetstester var att många komponenters funktionalitet förändrades mycket under utveck- lingens gång, vilket hade gjort det nödvändigt att spendera mycket tid på att skriva om en- hetstester varje gång en komponent förändrades. Majoriteten av all testning skedde istället i form av oregelbundna manuella tester, där gruppmedlemmar försökte använda applikatio- nen för att se om den fungerade som önskat. Inga tillfällen för användartestning förekom, dock fick kunden tillfälle att komma med kommentarer när applikationen visades upp under leveranserna.

E.6

Diskussion

Problemen som gruppen stötte på under utvecklingens gång visar tydligt på att det finns rum för förbättring gällande gruppens arbetssätt. Integrationsproblemen orsakades av att för många och för stora ändringar tilläts hamna i kö. KL lägger stor vikt vid att nya ändringar ska integreras in i kodbasen så fort som möjligt, vilket hade minskat eller eliminerat projektets in- tegrationsproblem. Genom att lägga fokus på att hålla grenarna med ny funktionalitet så små som möjligt så skulle fler grenar lättare kunna integreras in i huvudgrenen under iterationens

E.7. Slutsatser

Automatiserade enhetstester som täcker en betydelsefull del av komponenternas funktiona- litet hade tagit lång tid att implementera, vilket möjligtvis hade lett till att mindre funktio- nalitet blev klar under projektets gång. Buggar skulle ha upptäckts tidigare med hjälp av automatiserade tester, och detta skulle i sin tur leda till färre integrationsproblem. Det är även möjligt att det fortfarande existerar oupptäckta buggar i slutprodukten som levereras till kunden, och att automatiserade enhetstester hade hjälpt gruppen att hitta och åtgärda dessa buggar i tid.

E.7

Slutsatser

I detta kapitel besvaras rapportens frågeställning. Hur kan KL implementeras?

KL kan implementeras genom att skicka varje kodändring genom en sekvens av steg som kallas en pipeline. En kodgranskning ger en första försäkran om att koden följer projektets standarder för kodkvalitet. Därefter körs en serie automatiska tester för att se till att systemet kan sammanställas korrekt och att dess komponenter fungerar som väntat. Slutligen testas systemet manuellt av utvecklare och användare för att kontrollera att systemet är lättanvänt och uppfyller de krav som ställs på det.

Ett utvecklingslag kan på detta vis snabbt och effektivt bekräfta att en ny version av ett system är redo att levereras.

Vilka delar av teorin om KL saknar utvecklingsprocessen bakom SecTrack?

Utvecklingsprocessen bakom SecTrack har mycket gemensamt med en typisk implementa- tion av KL, men de skiljer sig när det gäller testning. När KL används så ska varje ny integ- ration in i projektets huvudgren typiskt passera automatiska byggnadstester och enhetstes- ter, följt av manuella acceptanstester och eventuellt även användartester. Vid utvecklingen av SecTrack användes utav dessa endast byggnadstester och acceptanstester, och acceptan- stesterna skedde inte i samband med varje integration in i huvudgrenen utan var istället oregelbundna. När KL används läggs vikt vid att integrationsfrekvensen ska vara hög nog för att minimera eller undvika integrationsproblem, vilket inte var fallet vid utvecklingen av SecTrack.

F

Arbetsmiljöers påverkan på

grupparbeten av Niklas Nilsson

F.1

Inledning

Den här rapporten kommer att ge en insikt i hur arbetsmiljöer kan påverka grupparbeten, både hur gruppen samt gruppmedlemmar påverkas. Vilka faktorer är det egentligen som påverkar välmåendet på en arbetsplats? Finns det bättre eller sämre arbetsmiljöer för just grupparbeten?

Information kommer att komma från erfarenheter under projektets gång, tidigare erfarenhe- ter samt artiklar och andra typer av källor som till exempel arbetsmiljöverket.

F.1.1

Syfte

Syftet med denna studie är att få en insikt i hur både mental och fysisk hälsa samt produkti- vitet kan påverkas av den arbetsmiljö som en större del av arbetsdagen spenderas i. Då det är individuellt vilken typ av miljö som föredras så betyder det inte att det är den bästa för ens hälsa och produktivitet. Den här studien ämnar sig åt att ge en insikt i hur olika typer av arbetsmiljöer kan påverka en och förhoppningsvis leda till en förbättring av sin egen.

F.1.2

Frågeställning

1. Hur påverkas en projektgrupp av arbetsmiljön? 2. Hur påverkas en person av arbetsmiljön?

F.1.3

Avgränsningar

Rapporten baserar sig på egna erfarenheter från olika projekt vilket resulterar i att rapporten kommer att vara begränsad till ett mindre antal arbetsmiljöer.

F.2

Bakgrund

Följande rapport om hur en arbetsmiljö kan påverka sitt arbete både i grupp och individuellt görs i samband med att kursen TDDD96 - Kandidatprojekt i programvaruutveckling läses. I denna kurs arbetar vi i grupp mot en extern kund där varje grupp får sina egna och olika förutsättningar beroende på uppgift. Då vissa kunder erbjuder tillgång till antingen platser på deras arbetsytor eller tillgång till separata lokaler hos antingen kund eller på skola kan detta ses som en väldigt stor fördel, till skillnad från de grupper som inte har tillgång till någon fast arbetsmiljö. De grupper som inte får någon tilldelad arbetsyta behöver lösa detta

F.3. Teori

F.3

Teori

Denna del kommer att handla om de faktorer som har en påverkan på ens arbetsmiljö och vad som kan göras för att undvika problem och skador. Följande information är hämtad från Arbetsmiljöverkets informationssida och en rapport framtagen av Arbetslivsinstitutet [77, 78].

F.3.1

Arbetsplatsens utformning

Det finns nog inte en arbetsplats som är den andra lik, men det går att dela upp kontor i ett par kategorier vilket denna del kommer att handla om [79, 80].

F.3.1.1 Öppna kontor

Ett öppet kontor är ett kontor där det istället för flertalet små rum är en större lokal där grupper bestående av de personer som arbetar med varandra är utplacerade tillsammans. Till skillnad från ett cellkontor så leder denna typ av kontor till att det är lättare att arbeta inom gruppen och upprätthålla kommunikationen mellan varje gruppmedlem. Denna typ av kontor kan lida av störande ljud då det inte finns mycket som kan absorbera ljudet mellan arbetsplatserna.

F.3.1.2 Cellkontor

Cellkontor är ett kontor där allt är uppdelat i enskilda kontorsrum med syftet att ha en stor avskildhet vilket kan leda till ökad koncentrationsförmåga och minskade störmoment från ljud. Denna uppdelning av ett kontor leder till minskad sammanhållning och kommunika- tion inom grupper samt att informationsflödet hämmas. Flexibiliteten som finns när kontoret består av en öppen lokal försvinner och det blir svårare att ändra på arbetsgrupper. Det blir lättare för personer att fokusera på sitt eget men gruppen får lida.

F.3.1.3 Kombikontor

Denna typ av kontor är en kombination av fördelarna hos de två ovannämnda kontorstyper- na, det finns många små enskilda arbetsrum utspridda runt ett större gemensamt rum. På detta sätt kan en grupp bibehålla sammanhållningen och kommunikation men gruppmed- lemmar kan även sitta enkelt för sig själva om det behövs för att hålla koncentrationen uppe. F.3.1.4 Flex- och aktivitetsbaserade kontor

I ett flexkontor har varje enskild person ingen förbestämd arbetsplats, istället kan en person sätta sig lite var den vill och arbeta. I det aktivitetsbaserade kontoret finns även möjligheten att välja miljö beroende på det arbete som ska utföras.