Visualisering av svarstider mellan mobila klienter och datacenter

Institutionen för datavetenskap

Department of Computer and Information Science

Examensarbete

Visualisering av svarstider mellan mobila

klienter och datacenter

av

Adrian Sidenvall, Andy Truong, Erik Boman, Mikael Szreder,

Oskar Lind, Simon Eriksson, Simon Petersson

LIU-IDA/LITH-EX-G--15/026--SE

2015-06-15

Linköpings universitet Institutionen för datavetenskap

Examensarbete

Visualisering av svarstider mellan mobila

klienter och datacenter

av

Adrian Sidenvall, Andy Truong, Erik Boman, Mikael Szreder,

Oskar Lind, Simon Eriksson, Simon Petersson

LIU-IDA/LITH-EX-G--15/026--SE

2015-06-15

Handledare: Jonas Lindgren Examinator: Kristian Sandahl

Sammanfattning

Rapporten är en sammanställning av gruppens samlade erfarenheter och lärdomar av ett projekt vars syfte var att utveckla ett verktyg som ska visualisera svarstider mellan mobila klienter och datacenter. Genom att använda kontinuerlig prototypning har gruppen kunnat ar-beta på ett användarnära sätt för att uppfylla kundens verkliga behov. För att uppnå detta användes utvecklingsmetodiken Kanban. Under projektets gång anpassades metodiken för att bättre passa in i arbetet. Projektets användartester har lett till sammanfattande erfarenhe-ter om visualisering av data. Visualiseringar som projektgruppen an-sett tydliga uppfattades inte alltid på samma sätt av användarna. Att visualisera flera parametrar på en världskarta anses vara problematiskt då kartan i sig endast består av länder. För visualisering av flera pa-rametrar måste då även externa element användas, exempelvis cirklar eller andra former.

Innehåll

I

Gemensamma erfarenheter och diskussioner

1

1 Inledning 2 1.1 Syfte och mål . . . 2 1.2 Frågeställning . . . 2 1.3 Avgränsningar . . . 3 2 Bakgrund 4 2.1 Kursen . . . 4 2.2 Opera Software . . . 4 2.3 Kanban . . . 4 3 Teori 5 3.1 Kanban . . . 5 3.2 D3 . . . 6

3.3 SEMAT Alpha Kernel . . . 6

4 Metod 7 4.1 Dokumentgranskning . . . 7 4.2 Kravinhämtning . . . 7 4.3 Prototypning . . . 7 4.4 Testning . . . 8 4.5 Verktyg . . . 8 4.5.1 Utvecklingsverktyg . . . 8 4.5.2 Dokumentverktyg . . . 9 4.5.3 Planeringsverktyg . . . 9 4.6 Arbetsmetod . . . 9 4.7 Forskningsmetod . . . 10 4.7.1 Möten . . . 10

4.7.2 Biblioteket . . . 10 4.7.3 Insamling av projekterfarenheter . . . 11 5 Resultat 12 5.1 Fas 1 . . . 12 5.2 Fas 2 . . . 13 5.3 Fas 3 . . . 14 5.4 Användartester . . . 16 5.4.1 Användartester . . . 16 6 Diskussion 17 6.1 Erfarenheter för förstudie och fas 1 . . . 17

6.1.1 Kravinhämtning . . . 17

6.1.2 Aktiviteter . . . 17

6.1.3 Prototyper . . . 18

6.1.4 Mötesanteckningar . . . 18

6.2 Erfarenheter från fas 2 . . . 18

6.2.1 Arbeta mer intensivt med Kanban metodiken . . . 18

6.2.2 Mötesanteckningar . . . 19

6.3 Erfarenheter från fas 3 . . . 19

6.4 Tekniska erfarenheter . . . 20

6.4.1 Framtagning av verktyg för kartritande . . . 20

6.4.2 Framtagning av mer detaljerad kartdata . . . 20

6.5 Resultat . . . 21

6.5.1 Visualisering på kartor . . . 21

6.5.2 Visualisering av flera parametrar på en karta . . . 24

6.6 Metod . . . 25

6.6.1 Möten . . . 25

6.7 Arbeta i ett vidare sammanhang . . . 25

6.7.1 Miljöaspekter . . . 26

II

Individuella delar

29

1 Adrian Sidenvall: Projektledning i ett mjukvaruprojekt där

Kanban-metodiken används 30 1.1 Inledning . . . 30 1.2 Syfte och mål . . . 30 1.3 Frågeställning . . . 30 1.4 Avgränsningar . . . 30 1.5 Bakgrund . . . 31 1.6 Teori . . . 31 1.6.1 Stategisk projektledning . . . 31

1.6.2 Kanban och Scrum . . . 32

1.7 Metod . . . 32

1.7.1 Böcker . . . 32

1.7.2 Projekterfarenheter . . . 33

1.8 Resultat . . . 33

1.8.1 Förstudie . . . 33

1.8.2 Förberedelser till att använda Kanban . . . 34

1.8.3 Att börja använda Kanban . . . 35

1.8.4 Vår användning av Kanban . . . 36

1.9 Diskussion . . . 36

1.9.1 Resultat . . . 37

1.9.2 Metod . . . 39

1.10 Slutsatser . . . 39

1.10.1 Hur Kanban påverkar ett projekt . . . 39

1.10.2 Introduktion av Kanban i ett projekt . . . 40

1.10.3 Strategisk projektledning . . . 41

2 Andy Truong: Dokumenthantering i projekt 43 2.1 Inledning . . . 43

2.2 Syfte och mål . . . 43

2.4 Avgränsningar . . . 43 2.5 Bakgrund . . . 44 2.6 Teori . . . 44 2.6.1 Versionshantering . . . 44 2.6.2 Kollaborativ redigering . . . 45 2.6.3 Typsättning . . . 46 2.6.4 Molnbaserad lagring . . . 47 2.6.5 Verktyg . . . 47 2.7 Metod . . . 49 2.8 Resultat . . . 51 2.9 Diskussion . . . 52 2.9.1 Resultat . . . 52 2.9.2 Metod . . . 54 2.10 Slutsatser . . . 54

3 Erik Boman: Testning och säkerhet vid utvecklandet av en webbapplikation 56 3.1 Inledning . . . 56 3.2 Syfte och mål . . . 56 3.3 Frågeställning . . . 56 3.4 Avgränsningar . . . 56 3.4.1 Avgränsningar i rapporten . . . 57

3.4.2 Avgränsningar vid testning . . . 57

3.5 Bakgrund . . . 57 3.5.1 Webbapplikationer nu och då . . . 57 3.6 Teori . . . 58 3.6.1 Cross-site scripting . . . 58 3.6.2 SQL-injektioner . . . 58 3.6.3 Brute force . . . 59 3.6.4 Denial of service . . . 59 3.7 Metod . . . 60 3.8 Resultat . . . 60

3.8.1 Cross-site scripting . . . 61 3.8.2 SQL-injektioner . . . 61 3.8.3 Brute force . . . 62 3.8.4 Denial of service . . . 63 3.9 Diskussion . . . 64 3.9.1 Resultat . . . 64 3.9.2 Metod . . . 65 3.10 Slutsatser . . . 65

4 Mikael Szreder: Kanban som utvecklingsmetodik för mjuk-varuprojekt med kontinuerlig prototypning 66 4.1 Inledning . . . 66 4.2 Syfte och mål . . . 66 4.3 Frågeställning . . . 66 4.4 Avgränsningar . . . 67 4.5 Bakgrund . . . 67 4.6 Teori . . . 68 4.7 Metod . . . 68 4.8 Resultat . . . 69 4.8.1 Fas 1 . . . 69 4.8.2 Fas 2 . . . 69 4.8.3 Fas 3 . . . 69 4.9 Diskussion . . . 70 4.9.1 Resultat . . . 70 4.9.2 Metod . . . 71 4.10 Slutsatser . . . 71

5 Oskar Lind: Kontinuerlig kravinsamling 74 5.1 Inledning . . . 74

5.2 Syfte och mål . . . 74

5.3 Frågeställning . . . 74

5.5 Avgränsningar . . . 75 5.6 Bakgrund . . . 76 5.6.1 TDDD77 - Projektet . . . 76 5.7 Teori . . . 76 5.7.1 Kravhanteringsmetoder . . . 76 5.8 Metod . . . 77 5.9 Resultat . . . 78 5.9.1 Intervjuer . . . 78 5.9.2 TDDD77 – kravinsamlingsprocess . . . 78 5.10 Diskussion . . . 79 5.11 Slutsatser . . . 82

6 Simon Eriksson: Implementation av interaktiv kartvisualise-ring med D3 83 6.1 Inledning . . . 83 6.2 Syfte och mål . . . 83 6.3 Frågeställning . . . 83 6.4 Avgränsningar . . . 83 6.5 Bakgrund . . . 84 6.6 Teori . . . 84 6.7 Metod . . . 85 6.8 Resultat . . . 86

6.8.1 Första fasen med Datamaps . . . 86

6.8.2 Övergripande funktioner . . . 86 6.8.3 Världskartan . . . 87 6.8.4 Bubblorna . . . 87 6.8.5 Datacenter . . . 88 6.8.6 Sidebar . . . 89 6.8.7 Statistik . . . 89 6.9 Diskussion . . . 89 6.9.1 Resultat . . . 90 6.9.2 Metod . . . 90

6.10 Slutsatser . . . 91

7 Simon Petersson: Kvalitetssäkring och inspektioner 92 7.1 Inledning . . . 92 7.2 Syfte och mål . . . 92 7.3 Frågeställning . . . 92 7.4 Avgränsningar . . . 93 7.5 Bakgrund . . . 93 7.6 Teori . . . 93 7.6.1 Inspektioner . . . 94 7.6.2 Kvalitetsbegrepp . . . 94 7.7 Metod . . . 95 7.8 Resultat . . . 96 7.8.1 Granskning av dokument . . . 96 7.8.2 Inspektioner av kod . . . 96 7.8.3 Allmänt om kodinspektioner . . . 97 7.9 Diskussion . . . 98 7.9.1 Resultat . . . 100 7.9.2 Metod . . . 101 7.10 Slutsatser . . . 102 Referenser 104

Del I

Gemensamma erfarenheter och

diskussioner

1

Inledning

Detta dokument behandlar ett projekt i kursen TDDD77: Kandidatprojekt i programvaruutveckling vid Linköpings universitet. Dokumentet inleds med de frågeställningar som projektet behandlat samt en beskrivning av de ut-vecklingsmetoder och utvärderingsmetoder som använts.

Projektet gick i korthet ut på att skriva en applikation för visualisering av svarstider mellan mobila klienter och datacenter, beroende på datacenters placering. För att uppnå detta använde sig projektet av utvecklingsmetodiken Kanban.

1.1

Syfte och mål

Syftet med projektet var att utveckla ett verktyg vars uppgift var att genom visualisering underlätta och effektivisera placeringen av nya datacenter för att förbättra svarstider för mobila klienter.

Målet var att kunden, Opera Software, skulle få ett bättre hjälpmedel för diskussion kring placering av nya datacenter. Då de tidigare använt sig av kalkylblad var förhoppningen att det nya visuella hjälpmedlet skulle ge en bättre överblick över hur placeringen av datacenter påverkade deras använ-dare.

1.2

Frågeställning

Här tas frågeställningar upp som besvaras i rapporten.

1. Vilka erfarenheter kan man få av att genomföra ett programmerings-projekt?

2. Vilket stöd kan man få genom att använda och följa upp SEMAT Kernel Alphas?

3. Vad finns det för för- och nackdelar med att använda metoden Kanban i ett programmeringsprojekt?

4. Hur kan man visualisera flera olika data för enskilda länder simultant på en världskarta?

5. Finns det bra verktyg som kan användas för visualisering av data för olika länder i en webbaserad applikation?

6. Vad kan man stöta på för problem vid hantering av kartdata?

1.3

Avgränsningar

Då projektet hade begränsad tidstillgång har fokus legat på att uppfylla de primära prioritetskraven, vilket har begränsat mängden uppfyllda sekundära prioritetskrav.

Projektets huvudsyfte var att applikationen skulle visualisera svarstider för specifika länder och inte specifika positioner. Applikationen begränsas även av tillgänglig information och kommer endast använda den vid visuali-sering.

Programmet hanterar endast de datacenter som kunden tillhandahåller. Dessa datacenter behöver endast kunna aktiveras och inaktiveras. Den sekun-dära delen av projektet handlade om automatisk optimering av datacenter. På grund av tidsbegränsningar och svalt intresse från Opera lades inget ar-bete på denna del.

Då visualiseringen skulle ske i en webbapplikation fanns det direkt ett flertal begränsningar på vilka verktyg och tekniska lösningar som kunde an-vändas.

2

Bakgrund

Här beskrivs bakgrund om kursen som projektet utfördes i, kunden för pro-jektet och projektmetodiken Kanban.

2.1

Kursen

Detta projekt utfördes som en del i kursen TDDD77: Kandidatprojekt i pro-gramvaruutveckling som är kandidatprojektkursen för studenterna som stu-derar civilingenjör datateknik vid Linköpings universitet. Kursen omfattar 16 högskolepoäng där även kursdelar i entreprenörskap och kommunikation ingår.

2.2

Opera Software

Kunden för projektet var Opera Software som är ett mjukvaruföretag grundat i Norge år 1995. Deras huvudsakliga produkt är deras webbläsare, Opera, som har över 350 miljoner användare. De har kontor på 25 olika platser runt om i världen och huvudkontor i Oslo. Detta projekt utfördes i kontakt med Operas kontor i Linköping. [1]

2.3

Kanban

Kanban är från början en del av Toyotas Lean-metodik och utvecklades i Japan under 1940-talet. Syftet med metoden är att, i de områden där den tillämpas, öka produktionstakten och minska kostnaden. Ordet Kanban kom-mer från japanskan och betyder ”visuellt kort”. På Toyota är Kanban det visuella system med kort eller lappar på tavlor som används för att binda ihop deras Lean-metodik. [2]

Här beskrivs den projektmetodik som utvecklats utifrån Toyotas idéer och därifrån fått namnet Kanban. Grunden i den metodiken, eller det pro-cessverktyget som det också kan kallas [3], kommer från just de tavlor med lappar som Toyota kallar Kanban-tavlor.

3

Teori

Här nedan beskrivs relevant teori som berör projektets frågeställningar.

3.1

Kanban

I Kanban finns egentligen bara tre principer som ska följas för att man ska kunna säga att Kanban används.

Den första är just Kanban-tavlan. Tanken är att varje projektgrupp har en egen tavla där de sätter upp lappar med de olika uppgifter som måste utföras för att projektet ska bli klart. Tavlan delas upp i olika kolumner och/eller rader med sin egen titel och/eller prioritet. Lapparna med uppgifter flyter sedan över denna tavla, från att uppgiften lagts till som något som behöver göras, till att den är färdigutvecklad. Tavlans utseende, och kolumner och rader, finns inte definierat i Kanban utan anpassas efter det/de projekt som den ska användas till. Ett enkelt exempel för hur en Kanban-tavla kan se ut syns i figur 1 nedan.

Figur 1: Enkelt exempel på en Kanban-tavla med tre flödestillstånd. [4]

Utöver att visualisera arbetsflödet med tavlan så begränsar man antalet pågående arbetsuppgifter (Works In Progress – WIP) i de olika

flödestill-stånden, detta är den andra Kanban-principen. Projektgruppen bestämmer då hur många lappar som får finnas i varje kolumn utefter vilket antal som passar för just det projektet. Kanban säger inget om vilket antal WIP som får finnas och inte heller om antalet måste begränsas i alla flödestillstånd. Detta är något som gruppen får komma fram till, och ständigt utveckla, själva för just deras projekt.

Den tredje och sista principen som ska följas är att lead time ska mä-tas. Lead time är den tid det tar från att en arbetsuppgift påbörjas, eller kan påbörjas, tills att den är klar. Alltså den tid det tar från att en upp-giftslapp flyttas in på tavlan, t ex från uppgiftsbanken, backlogen, till att den har flyttats till de färdiga uppgifterna. Denna tid kan användas för att utveckla användandet av Kanban vidare. Man vill nämligen få en så kort och förutsägbar lead time som möjligt. [3]

3.2

D3

JavaScript-biblioteket D3, som står för Data-Driven-Documents, valdes som grund till visualiseringen i projektet. D3 är ett bibliotek som använder sig av de standarder som finns implementerade inom moderna webbläsare så som HTML, CSS och JavaScript. Syftet med D3 är att underlätta skapandet av datavisualiseringar i webbläsare.

3.3

SEMAT Alpha Kernel

SEMAT Alpha Kernel är ett enkelt sätt för en organisation att utvärdera ett mjukvaruprojekt nuvarande status. Den kan också underlätta planeringen av nästa steg i utvecklingen. Alphas representerar nyckelområden för ett projekt och Alpha States representerar tillståndet inom dessa områden [5].

4

Metod

Här beskrivs olika metoder och arbetssätt som använts under projektets gång. Vissa är verktyg som använts till delar av projektet medan andra beskriver sätt som vi arbetat på.

4.1

Dokumentgranskning

För att se till att projektets dokument höll en viss kvalitet granskades allt som skrevs av minst en annan person utöver författaren själv. Detta gjordes för att minimera antalet mindre fel och för att kunna peka ut brister i tex-ten. Dokument samskrevs i Google Docs och förslagsläget användes för att den som granskade skulle kunna ge förslag på förbättringar och ändringar. Dokumentansvarig hade sedan ansvar för att godkänna dessa förslag för att sedan överföra ändringarna till LA_{TEX för formatering.}

4.2

Kravinhämtning

För kravinhämtning har projektgruppen använt sig av möten med kund samt av ett formulär med frågor som skickades till kunden för evaluering. Formu-läret skapades genom att alla gruppmedlemmar skrev frågor och funderingar som fanns angående projektet. Dessa skrevs sedan rent och formulerades om till tydliga frågor som kunden sedan besvarade. Till vissa frågor användes en sifferskala, detta för att ge en bättre bild av hur relevant en viss funktionalitet var.

4.3

Prototypning

För att få en bättre bild av kundens verkliga behov och vilka krav som sat-tes så användes kontinuerlig prototypning. Tidigt i projektet användes helt visuella prototyper utan funktionalitet, dessa gav en enkel bild av hur appli-kationen skulle kunna se ut. Senare användes dessa prototyper som grund till

framtida prototyper. Dessa prototyper utvecklades vidare med utökad funk-tionalitet genom projektets gång. Varje ny prototyp som fungerade kunde då fortsätta utvecklas mot den slutliga produkten. Vi presenterade även några av dessa prototyper för kunden vid möten och antecknade reaktioner och kommentarer.

4.4

Testning

Under projektet har webbapplikationen testats för att se till att den uppfyller de krav som gruppen och Opera haft på den. Dessa tester har delvis skett informellt under tiden som produkten har utvecklats men även mer formella tester har utförts och finns dokumenterade i testrapporterna. Fokus under dessa tester låg framförallt på att hitta buggar samt avvikelser i applikationen mellan olika webbläsare.

I slutet av projektet gjordes även ett antal användartester för att se hur intuitiv applikationen var. För utförandet av testerna användes en använd-arberättelse för att sätta in testanvändaren i ett sammanhang inför testning-en. De observationer som noterades under användartesterna dokumenterades med hjälp av ett standardiserat protokoll. Dessa tester gav mycket värdefull feedback om potentiella framtida förbättringar och funktionaliteter.

4.5

Verktyg

Under projektets gång har gruppen använt sig av ett antal olika verktyg. Dessa finns beskrivna nedan.

4.5.1 Utvecklingsverktyg

För att underlätta utvecklingsprocessen användes Redmine. Redmine är ett webbaserat projektverktyg där aktiviteter har hanterats enligt Kanban me-todiken. Gruppmedlemmarna har även rapporterat spenderad tid på varje aktivitet.

För att hantera all källkod har versionshanteringssystemet Git använts. För att få en bättre översikt över utvecklingsprocessen integrerades Git med Redmine.

4.5.2 Dokumentverktyg

För en stor andel av dokumenten som producerades under projektets gång användes Google Docs. Detta för att enkelt kunna samskriva gemensamma dokument. Google Docs har bra funktionalitet för kommentarer och ändrings-förslag vilket har använts produktivt i arbetet med kontinuerlig uppdatering och förbättring av dokumenten. Sedan har LA_{TEX använts för att renskriva}

al-la dokument så att de blivit utseendemässigt korrekta och följt en gemensam mall.

Google Docs har även använts för att dela med sig av erfarenheter och information samt för att samla material till presentationer och oppositioner.

4.5.3 Planeringsverktyg

Gruppen har använt sig av tjänsten Doodle för underlätta planeringen av möten inom projektgruppen. Där har teamledaren planerat möten utifrån tillgängliga tider och sedan skickat ett formulär till gruppmedlemmarna. Där har alla gruppmedlemmar kunnat välja individuellt passande tider för mötet.

4.6

Arbetsmetod

I utförandet av projektet så har utvecklingsmetodiken Kanban använts. Från och med att Kanban infördes fanns en Kanban-tavla tillgänglig på gruppens Redmine-sida. Där har gruppens utvecklingsledare ansvarat för att lägga till och flytta runt aktiviteter.

Vi valde att använda arbetsstegen Backlog, To Do, Development, Integra-tion & Testing och Resolved. Dessa blev kolumner på gruppens Kanban-tavla. Begränsningarna av antalet aktiviteter som fick finnas i de olika kolumnerna

sattes initialt till tre, men anpassades under projektets gång med avseende på arbetsflödet.

Under möten bestämde gruppen vilka aktiviteter som skulle påbörjas, dessa flyttades då från Backlog till To Do.

Då Kanban saknar specificerade ansvarsposter för exempelvis teamledare eller testledare så har dessa lagts till utifrån de ansvarsposter som föreslagits i kursen.

4.7

Forskningsmetod

Nedan följer en beskrivning av metoder som projektgruppen använt sig av för att samla erfarenheter under projektet gång. Primärt har erfarenheter erhållits från möten, där protokoll och tankar samlats.

4.7.1 Möten

Under projektets gång har minst ett möte i veckan, ofta fler, hållits med hela gruppen. Vid vissa av dessa möten har även gruppens handledare närvarat för att ge gruppen stöd och svara på eventuella frågor. Mötena har använts både för att samordna och planera arbetet såväl som för att dela med sig av erfarenheter och diskutera problem och framsteg. Tanken var att alla gruppmedlemmar skulle komma till tals under möte och därför inledes varje möte med en statusuppdatering från varje gruppmedlem.

Initialt var tanken att en sekreterare skulle föra mötesprotokoll, vilket följdes till stor del. Dessa mötesanteckningar kunde sedan användas för att få en återblick på beslut som tagits under möten samt för att snabbt få en överblick av vad som sades. Mötesprotokollen samlades på Google Drive för enkel tillgång.

4.7.2 Biblioteket

Biblioteket på Campus Valla har använts för att få tillgång till böcker och artiklar på ett smidigt sätt. Där finns en stor samling böcker om både

pro-grammering, projektmetodiker och projektledning vilket har varit en värde-full resurs, både för projektet i sig och för skrivandet av denna uppsats.

4.7.3 Insamling av projekterfarenheter

Mallar och riktlinjer för dokumentation av erfarenheter från projektet har saknats. Dessa erfarenheter har istället främst samlats från kommunikation, såsom mötesanteckningar och mail. Varje vecka har teamledaren skickat in en tidrapportering till examinatorn och handledaren där framsteg under gången vecka, planer för den kommande veckan samt de risker som funnits för till-fället sammanfattades. Dessa rapporteringar har senare kunnat användas för att se tillbaka på vad som gjorts och, i vissa fall, på de funderingar som tagits upp. En del individuella anteckningar av erfarenheter har även förekommit.

Insamling av erfarenheter har även gjorts vid de tillfällen då faser av projektet har utvärderats. I samband med att faser har avslutats har även erfarenheter från dessa skrivits in i andra dokument, framförallt i denna uppsats.

5

Resultat

Här presenteras resultaten från projektets olika faser. Resultatet är i stort uppdelat efter de tre faser som projektet genomgått. Men då projektgruppen använts sig av Kanban har faserna inte varit lika strikta.

Under första fasen lades mycket arbete på prototyper, detta för att kunna få återkoppling av kunden om vad som önskades samt för att testa flera sätt att visualisera den givna data. I slutet av första fasen togs den första inter-aktiva prototypen fram. Under fas 2 fortsatte arbetet med prototypen och den utvecklades vidare med utökad funktionalitet. Efter fas 2 var bilden över var kunden önskade tydlig och prototypen övergick till den verkliga produk-ten. Under fas 3 fortsatte arbetet med utökad funktionalitet och kartdatan uppdaterades ett flertal gånger. I fas 3 introducerades även en back-end för hantering av data.

5.1

Fas 1

I fas 1 tog gruppen fram ett flertal enkla prototyper som diskuterades med kund för att få återkoppling. Denna återkoppling användes sedan för att få en klarare bild över vad kunden önskade. Detta gav gruppen en bättre bild över vad som skulle utvecklas, och hur utvecklingen skulle gå till.

Gruppen producerade även en interaktiv prototyp där länder visualisera-des med färger utifrån deras svarstid och där landets namn kom upp då man hade muspekaren över landet. Se figur 2.

Denna prototyp användes sedan för vidare utveckling med utökad funktio-nalitet som zoomning och möjligheten att aktivera och inaktivera datacenter. Prototypen gjordes på ett sådant sätt att den med fördel kunde användas för vidare utveckling under senare faser.

Figur 2: Skärmdump av produkten efter fas 1.

5.2

Fas 2

Då gruppen gick ifrån iterationer efter fas 1 för att istället jobba mer emot Kanban-metodiken behandlar det här avsnittet istället tidsperioden vecka 13-16. Under denna period ändrades arbetssättet och användningen av Redmine mot att mer efterlikna Kanban med en webbaserad Kanban-tavla. Detta efter att teamledaren, och även arkitekten, läst boken Kanban and Scrum – Making the most of [3] av Henrik Kniberg och Mattias Skarin. En Kanban-tavla skapades och aktiviteter formades mer som Kanban-uppgifter.

Under fas 2 påbörjades en ny prototyp med bubblor efter att kund ut-tryckt sig positivt om den idén. Sidfältet förbättrades också markant med en sortering av datacentren efter svarstid. Ny och mer detaljerad kartdata började också användas. Efter fas 2 såg produkten ut som i figur 3.

Figur 3: Skärmdump av produkten efter fas 2.

5.3

Fas 3

Under fas 3 fortsatte arbetet enligt Kanban-metodiken. Kanban-tavlan bör-jade användas mer frekvent och antalet WIP justerades ytterligare för att passa slutfasen av projektet. Även aktiviteter för buggar började skapas för att rapportera buggar eller felaktig funktionalitet. Dessa aktiviteter innehöll kommentarer om när buggen uppstod och hur man skulle gå tillväga för att buggen skulle uppstå, för att förenkla för den person som skulle åtgärda felet. I vissa fall fanns även en tilldelning till en person som skulle utföra aktivite-ten. Detta ledde till att buggar åtgärdades väldigt snabbt och effektivt.

Under fas 3 vidareutvecklades produkten som tagits fram under fas 2. En sökfunktion lades till i sidfältet och datacentren ritades ut på kartan. Utöver kartförbättringar skapades även en ny vy för statistikvisualisering med syftet att ge en bättre överblick över den tillgängliga datan. Utöver detta gjordes även många visuella förändringar och finjusteringar. Även flaggor för länderna introducerades under fas 3.

utvecklats men som inte använts. Detta för att konverteringen av data skulle bli enklare för kunden då back-end hanterar detta. Kartdatan ändrades även för att större länder som USA skulle gå att dela upp i mindre regioner.

Under fas 3 gick gruppen över till att helt använda D3 istället för ett det tidigare biblioteket som innehöll vissa begränsningar. Detta då utökad funktionalitet krävdes utöver det tidigare bibliotekets funktioner. I figur 4 visas resultatet efter fas 3.

5.4

Användartester

Här beskrivs de användartester som utfördes med resultaten redovisade.

5.4.1 Användartester

För att testa hur den visualiserade datan tolkades av användare utfördes tester mot personer med liknande teknisk kompetens som slutanvändaren.

Testet

Testet inleddes med att varje användare fick ett scenario uppläst för sig. Detta scenario handlade om att användaren hade en viss roll hos kunden och skulle använda sig av den utvecklade produkten för att göra vissa bedömningar.

Det första steget var att användaren skulle bekanta sig med produkten och dess olika egenskaper. Steg två handlade om att tolka den visualiserade datan. Steg tre handlade om att utföra en specifik uppgift med de kunskaper som testpersonen erhållit från de två första stegen.

Resultatet

Många av de funktioner som för utvecklingsteamet var självklara tog tid för testpersonerna att förstå. Bland annat var det svårt att förstå skillnaden mellan färg och storlek på bubblorna. Användarna var osäkra om färgen eller storleken representerade antalet användare. Det var inte heller helt intuitivt att använda sidfältet eller att nyttja några av de mer avancerade funktionerna som fanns tillgängliga. De streck som målats ut för att visa kopplingarna mellan de olika länderna och de tre bästa datacentrena var också svåra för användarna att förstå, speciellt när de var långa och delvis ritades utanför kartan.

6

Diskussion

Här tas diskussioner om resultat och erfarenheter från projektets olika faser upp. Diskussionen är uppdelad i tre delar efter projektets faser och består av olika delar i projektet, som kravinhämtning, prototyper och möten.

6.1

Erfarenheter för förstudie och fas 1

Fas 1 bestod till stor del av att ta fram prototyper för att få en tydligare bild av kundens behov. Då kunden från början inte hade en klar bild av den slutgiltiga produkten ledde detta till mycket prototyparbete. Denna process gav gruppen många erfarenheter inom prototypning och kravinhämtning.

6.1.1 Kravinhämtning

Projektet var från början otydligt definierat och kunden gav projektgruppen fria händer över produktens utformning. Det fanns endast ett fåtal funktio-nella krav som kunden önskade, vilket ledde till ett intensivt arbete inom gruppen för att ta fram krav och diskutera fram en kravspecifikation tillsam-mans med kund. Då det tog tid innan kraven specificerades ledde detta till att gruppen till en början kände att det var svårt att påbörja utvecklings-arbetet. Gruppen ville nämligen inte påbörja arbetet på något som sedan skulle visa sig inte behövas. I slutändan var det ändå bra att få erfarenhet av hur en kravinhämtning där kunden inte vet vad den behöver.

6.1.2 Aktiviteter

Då det till en början fanns många oklarheter i projektet var det svårt att planera aktiviteter. Detta ledde i sin tur till att det i förstudien och delar av första fasen var svårt att arbeta effektivt i gruppen. Detta löstes genom mycket enskilt arbete i gruppen vilket fungerade bra men kunde lösts bättre med ett annat upplägg än det som var definierat i kursen. Något som var svårt i det enskilda arbetet var att jämnt fördela arbetet över gruppmedlemmarna.

6.1.3 Prototyper

Tidigt i kursen valde gruppen att fokusera på ett par prototyper utifrån de idéer och tankar som uppkommit under förstudien. Prototyperna demonstre-rades sedan till kund för återkoppling och eventuella förbättringar. Dessa prototyper fungerade bra och gav bra respons från kunden. Det gruppen tar med sig till framtida projekt är att det är betydligt lättare att visa konkreta idéer för kund och observera kundens reaktioner än att bara diskutera tankar med kunden. Då gruppen sedan övergick till första fasen kunde prototyperna direkt användas som en bas för vidareutveckling.

6.1.4 Mötesanteckningar

Gruppen valde tidigt en sekreterare som ansvarade för att skriva mötespro-tokoll på handledarmöten och gruppmöten. Dessa mötespromötespro-tokoll har varit uppskattade och har möjliggjort att snabbt och enkelt gå tillbaka och se vad som bestämdes på ett visst möte, exempelvis vid eventuella konflikter. Dessutom fungerade dessa utmärkt för att frånvarande personer skulle få en överblick av vad som tagits upp på mötet.

6.2

Erfarenheter från fas 2

Fas 2 sträckte sig från och med vecka 13 till och med vecka 16.

6.2.1 Arbeta mer intensivt med Kanban metodiken

Under fas 2 satte teamledaren in sig bättre i utvecklingsmetodiken Kanban och planerade upp arbetet efter metodiken för att uppnå ett bättre arbets-sätt. Från början hade gruppen lite svårt att komma på aktiviteter och även minimera pågående arbete. Men i det stora hela gick gruppen mer in i Kan-bans sätt att tänka och kunde på detta sätt använda metodiken på ett effek-tivare sätt under fortsättningen av projektet.

Det märktes att det krävdes en del tid att komma in i Kanban-tänket, spe-ciellt då majoriteten av gruppen inte använt metoden tidigare. Att gruppen

inte hade ett eget kontor gjorde inte saken lättare då Kanban centraliseras kring visuella hjälpmedel, med Kanban-tavlan i spetsen. Det skulle även ha varit lättare att ha fler korta spontana möten om gruppen haft en gemensam samlingsplats som ett eget kontor. Gruppen minskade detta problem genom att ofta sitta flera stycken tillsammans på CreActive som är en mötesplats för samverkan mellan studenter och näringslivet, men gruppen saknade möj-ligheten att ha tillfällen med obligatorisk närvaro då gruppmedlemmar haft andra viktiga saker att göra.

6.2.2 Mötesanteckningar

Under denna fas ändrades de handledarmöten som gruppen haft till grupp-möten där handledaren fanns närvarande för att kunna lägga in synpunkter samt kunna rådfrågas. Då både gruppmöten och handledarmöten nu skedde på samma sätt, med enda skillnaden om en handledare var närvarande eller inte, var det svårt att separera de två mötestyperna. Då gruppen från början valde att producera två typer av protokoll för de två mötestyperna var de anpassade för det specifika möten, vilket bidrog till att gruppen inte var lika noggrann med att skriva mötesprotokoll.

Gruppen ansåg dock att det fortfarande gick bra att planera och hålla koll på alla delar i projektet, men protokollen skulle ändå ha varit bra att ha. Därför återupptogs mötesanteckningarna mot slutet av fasen, med mallen för gruppmöten.

6.3

Erfarenheter från fas 3

Fas 3 sträckte sig från och med vecka 17 till och med vecka 20.

Under fas 3 arbetade gruppen vidare med och utvecklade användandet av Kanban. Detta gav djupare kunskap om hur Kanban fungerar. En annan erfarenhet som gruppen tar med sig är från de användartester som gjordes under denna fas. Gruppen blev förvånad över att de användare som produk-ten testades på hade svårt att förstå vad vissa visualiseringar betydde. Denna kunskap kommer vara till stor nytta av i framtida projekt.

6.4

Tekniska erfarenheter

Detta stycke behandlar de tekniska utmaningar som gruppen mött under sitt arbete samt vilka erfarenheter som utvecklats för att möta dessa.

6.4.1 Framtagning av verktyg för kartritande

När vi började undersöka hur produkten skulle utvecklas tänkte vi först an-vända kartdata från OpenStreetMap. OpenStreetMap är ett projekt som har framtagit öppen geografisk data för kartor till öppna så som kommersiella syften.

Problemet med att använda kartdata från OpenStreetMap är att det inte fanns något enkelt sätt att få ut konturerna på alla länder. Detta fick oss att leta efter andra alternativ. Efter ett tag hittades ett färdigt bibliotek kallat Datamaps. Datamaps baseras på D3 och använder SVG-element för att rita upp en interaktiv karta i en webbläsare. Efter att ha vägt för- och nackdelar med OpenStreetMap kontra Datamaps bestämde vi oss för att använda Datamaps eftersom att det uppfyllde kriteriet med att få ut konturer på länder.

6.4.2 Framtagning av mer detaljerad kartdata

Gruppen upptäckte under fas 2 att kartdatan som användes till systemet för att visualisera alla länder inte var tillräckligt noggrann för kundens data. Bland annat så saknades det en stor mängd mindre länder och öar. För att lösa detta problem så påbörjades ett arbete för att skaffa mer noggrann kartdata.

Då ingen i gruppen arbetat med kartdata förut så blev det en lärandepro-cess och gruppen fick göra flera försök innan tillräckligt noggrann kartdata erhölls.

Ett av de största problemen gruppen kämpade med var att hitta kartdata där alla länder ingick. En enkel kontroll som användes för att bedöma om kartdata var tillräckligt noggrann var att kontrollera att Franska Guyana var

ett separat land från Frankrike och att Monaco fanns som ett eget land. Detta krav var svårare att uppfylla än förväntat, då problem uppstod med att till exempelvis länder som Storbritannien blev uppdelade i dess riksdelar. Pro-blemet med detta var att kunden hade data för att visualisera Storbritannien och inte dess riksdelar.

Detta ledde till att gruppen bestämde sig för att manuellt konstruera kartdata till en världskarta som var anpassad efter kundens data. För att lösa detta var gruppen tvungen att skriva skript som använde sig av hårdkodade listor av regioner som skulle grupperas ihop med deras administrativa länder. För att få fram den slutgiltiga versionen av kartdatan så behövde gruppen för hand gå igenom varje datapunkt som skulle visualiseras och se till att länder stämde överens och att de var rätt placerade. Anledningen till varför länder ibland inte blev rätt placerade berodde på på att vissa öar som tillhörde länderna tog över som huvudland. Den enda lösningen till detta problem var att för hand hitta dessa felaktiga länder och lägga in dem till den hårdkodade listan av länder som skulle grupperas.

6.5

Resultat

Nedan följer en diskussion av resultaten. Här förs diskussion kring visualise-ring kopplat till frågeställningen om att simultant visualisera flera datapara-metrar på en världskarta.

6.5.1 Visualisering på kartor

Då projekts huvudsyfte var att producera ett verktyg för att kunna visuali-sera svarstider och användare fanns två parametrar att hantera vid visualise-ringen. Kunden ville att svarstiden skulle representeras med en färgskala och att mängden användare även skulle kunna gå att observera på världskartan. Den första tanken som kom upp var att färga länder efter en färgskala bero-ende på svarstiden men problemet var då att visualisera antalet användare.

Figur 5: Prototyp för visualisering av svarstider med färgskala för länder.

Detta medförde att flera principer för visualisering av användarantal dis-kuterades. Ett förslag som kom upp tidigt var att ge varje land en bubbla, där storleken berodde på antalet användare och färgen berodde på landets svarstid, se figur 6. Efter att ha visat kunden en prototyp med bubblor var kunden positiv inställd till idén och gruppen valde att fortsätta arbeta på den prototypen.

Figur 6: Prototyp för visualisering av svarstider med färgskala för länder.

Andra visualiseringsmetoder

Det diskuterades och utfördes även några tester på om konturlinjer skulle kunna användas för att, på samma sätt som en orienteringskarta visar höjd-skillnader, kunna visualisera mängden användare. Problemet med lösningen var att det inte var uppenbart vad konturerna visualiserade, samt att fördel-ningen av mängden användare för varje land var okänd vilket försämrade hur visualiseringen skulle ha sett ut.

Det fanns även flera andra lösningar som diskuterades, såsom att skapa tredimensionella staplar för visualisering av användarantal. Hela landet skulle då alltså ses som en stapel och bli högre om landet hade många användare. Denna idé testades aldrig utan slopades tidigt då gruppen inte trodde att resultatet skulle bli bättre än det med bubblor. Det skulle även ha varit svårt att utveckla, vilket gjorde att gruppen inte ville lägga tid på en prototyp. En svårighet med idén skulle även vara prestandaproblem. På samma sätt slopades flera andra idéer tidigt i processen för att ge mer tid åt idéer med mer potential.

Figur 7: Tidig prototyp på visualisering av användare med konturlinjer.

6.5.2 Visualisering av flera parametrar på en karta

Att simultant visualisera flera dataparametrar på enbart en världskarta är svårt. Kartan i sig består bara av länder, vilka är svåra att modifiera för att visualisera mer än en parameter. Att visualisera en parameter, t ex genom att ändra färger på länder beroende på data, är enkelt, men att visualisera två eller fler parametrar samtidigt är svårare. Man skulle kunna ändra storleken eller formen på ett land, men detta är ingen bra lösning då det lätt kan förvirra användaren.

För att lösa visualiseringen av två eller flera data simultant måste externa element användas. Det kan vara enkla symboler, som kvadrater, bubblor, linjer eller mer avancerade symboler som ikoner för specifika ändamål. Dessa element bidrar till att kunna visualisera flera parametrar simultant. Precis som tidigare nämnts använder slutprodukten sig av en bubbla för varje land, för att med storleken visa mängden användare och med färgen visa svarstiden. Man kan även tänka sig att använda kanten på bubblan för att visualisera ytterligare saker, exempelvis en förändring av svarstider.

6.6

Metod

Nedan utvärderas metoder som användes under projektet. Här ger gruppen sina synpunkter på hur metoderna har fungerat och vad som skulle kunnat gjorts bättre.

6.6.1 Möten

Hur möten har strukturerats har varierat lite under projektet, vilket beskrivs mer under resultat. Under förstudie och fas 1 var handledarmötena centrala, då handledarens stöd behövdes mycket. Detta eftersom gruppen inte visste mycket om projektet ur varken kund- eller kurssynpunkt. Från och med fas 2 var behovet av handledarmöten inte lika stort längre och handledarmötena blev till gruppmöten med handledaren närvarande.

Gruppen skrev tidigt i projektet mötesprotokoll. Mötena hölls ganska öppna och var anpassningsbara vid ändringar beroende på vad som var vik-tigt vid just det mötet. Detta har varit på både gott och ont då det har varit tillåtet att snabbt kunna ta upp vad som var viktigt vid just det mötet. Or-dentliga protokoll hade dock kunnat bidra till mer seriösa samt strukturerade möten där uppmärksamheten till mötet kunde varit bättre.

I Kanban finns det inget specificerat angående möten, men gruppens lös-ning med statsuppdateringar under mötet har fungerat mycket bra och ledde ofta till bra diskussioner.

6.7

Arbeta i ett vidare sammanhang

Att gå vidare med samma projektgrupp skulle kunna innebära att gruppen arbetar vidare med samma produkt och utvecklar den med utökad funktio-nalitet. I gruppens fall skulle detta kunna ske genom att kunden anställer gruppmedlemmarna för att integrera produkten på deras server tillsammans med deras databas. Detta skulle kunna förbättra och ge aktuell data till verk-tyget. I övriga aspekter är det beställda verktyget färdigutvecklat. Det går alltid att förbättra saker och lägga till mer funktionalitet, men i det stora

hela anser gruppen att produkten är klar.

Ett annat sätt att arbeta vidare skulle kunna vara att gruppen går vida-re och arbetar med ett annat projekt. Detta skulle innebära ett intvida-ressant perspektiv då gruppen har börjat lära känna varandra bättre och vet hur gruppmedlemmarna brukar arbeta, vilket borde förenkla arbetet i ett fram-tida projekt.

Inom detta projekt har gruppen haft en kund som givit gruppen mycket frihet med vad som ska produceras och gruppen har själva ansvarat för myc-ket av arbetet med vad som ska tas fram och vilka krav som ska sättas. I ett framtida projekt med en annan kund skulle det kunna vara så att denne är mer strikt och har tydligare krav på vad som ska göras och hur det ska göras, vilket gruppen inte blivit vana med under det här projektet. I stort har grup-pen fått många erfarenheter i detta projekt som kommer vara applicerbara även i framtida projekt.

Ytterligare erfarenheter som kan nämnas är att projektgruppen har arbe-tat inom en specifik metodik som utvidgats för att passa just detta projekt. Detta har givit bra erfarenheter som skulle kunna vara applicerbara även till andra projekt.

De roller som gruppen har använt under projektet är något som skulle kunna användas i ett vidare sammanhang. Gruppens medlemmar har med tiden lärt sig sin roll dess ansvarsområden, vilket kan vara bra i andra projekt om man får samma roll.

6.7.1 Miljöaspekter

Produktens syfte är att effektivisera utplaceringen av datacenter för att op-timera svarstiden för användare. Detta kommer att implicit bidra till att mängden datacenter och deras placering optimeras vilket ger positiva miljö-aspekter då överflödiga datacenter elimineras.

7

Slutsatser

För att dra en sammanfattande slutsats av projektet och dess frågeställ-ningar kan visualiseringen nämnas som den stora erfarenheten som gruppen kommer att ta med sig tillsammans med arbetssättet Kanban och hur det kan användas för att planera och utföra arbetet.

Efter genomförandet av projektet har projektets medlemmar erhållit stora erfarenheter inom webbutveckling med dess programspråk och vilka problem som ofta uppstår hos denna utvecklingsplattform. Många av gruppens med-lemmar hade inga tidigare erfarenheter av de programspråk som användes, detta ledde till att det blev olika inlärningskurvor för medlemmarna.

Den stora delen i projektet har varit att arbeta enligt utvecklingsmetodi-ken Kanban. Här har gruppen själva utvecklat metoden för att passa detta projekt och med tiden utvecklat gränser för antalet aktiviteter för olika kate-gorier i aktivitetsstegen, vilket har varit en bra erfarenhet. De projektroller som använts inom projektet har i vissa fall fungerat olika bra. För att göra arbetsgången bättre hade till exempel en kombination av Kanban och någon annan agil utvecklingsmetodik fungerat bättre.

Då produkten som utvecklas var en webbapplikation för visualisering har gruppen erhållit stora erfarenheter inom visualisering och metoder som kan användas för att visualisera data och hur användaren uppfattar det som visu-aliseras. Gruppen märkte exempelvis att lösningar som internt inom gruppen tycktes var tydliga inte uppfattades på samma sätt av de testpersoner som testade produkten. Det tydligaste exemplet på detta var att de linjer som användes för att visualisera kopplingen mellan de tre bästa datacentren och ett land vid markering där testpersonerna hade svårt att uppfatta vad som menades. Se figur 8.

Då länder har olika beteckningar beroende på vilken standard som an-vänts har vissa problem uppstått när gruppen bytt mellan standarder allt eftersom i projektet. Detta skapade vissa problem och kunde ha diskuterats mer noggrant tidigt för att undvika problem i slutet.

Figur 8: Visualisering av ett lands tre bästa datacenter med linjer.

SEMAT Alpha-korten har varit något som gruppen inte använt sig av tidigare. Detta har medfört att korten kommit i skymundan och inte använts till dess fulla potential. Gruppen har kommit fram till slutsatsen att korten inte är något att föredra i ett mindre projekt av denna typ.

Del II

1

Adrian Sidenvall: Projektledning i ett

mjuk-varuprojekt där Kanban-metodiken används

1.1

Inledning

I den här delen kommer projektledning undersökas djupare. Då vårt projekt använder metodiken Kanban kommer projektledning i just sådana projekt vara i fokus. Både erfarenheter från vårt projekt och mer generell teori om projektledning kommer att tas upp.

1.2

Syfte och mål

Syftet med denna undersökning är att få en djupare kunskap om projektled-ning samt att samla de erfarenheter om detta som insamlats under projektet. Tanken är att detta ska kunna hjälpa mig att vara en bättre teamledare i detta projekt såväl som eventuella framtida projekt.

1.3

Frågeställning

1. Hur påverkar användning av Kanban ett projekt?

2. Vad är det viktigt att tänka på då Kanban introduceras i ett projekt, som teamledare?

3. Vad innebär strategisk projektledning?

1.4

Avgränsningar

Då detta projekt har utförts på ganska kort tid, med begränsade resurser och med ganska lite förkunskaper, har användningen och utvecklingen av Kanban varit begränsad. Detta begränsar då även utvärderingen av Kanban i sin helhet då vi inte kunnat använda det fullt ut.

1.5

Bakgrund

En bakgrund om Kanban återfinns i huvuddelen av denna uppsats i av-snitt 2.3.

1.6

Teori

Här sammanfattats teori från källor som använts till denna del av uppsatsen.

1.6.1 Stategisk projektledning

I boken Strategic Project Management Made Simple [6] beskriver Terry Sch-midt strategisk projektledning. Där ser man projekt i ett bredare perspektiv än i den mer traditionella taktiska projektledningen. Istället för att fokusera på uppgifter som behöver utföras i projektet ser man mer på helheten och de behov som finns. Centralt i boken finns fyra frågor som varje projektgrupp bör försöka svara på.

• Vad försöker vi uppnå och varför?

• Hur kommer vi mäta projektets framgång?

• Vilka externa förutsättningar måste existera för projektet? • Hur ska vi nå målet?

Dessa frågor måste, enligt Schmidt, ställas i just den ordningen, och svaren kan utvecklas under projektets gång.

För att hjälpa läsaren att kunna använda dessa frågor finns ett kapitel för varje fråga. Där går författaren in mer på djupet om vad man ska tänka på vid diskussion kring varje fråga, vad som är viktigt m.m. Detta bildar en av tre delar av boken. De andra två delarna beskriver strategisk projektled-ning mer generellt och vilka verktyg man kan använda respektive hur man applicerar strategisk projektledning och vad som är viktigt att tänka på som projektledare. Även mer detaljerade saker, såsom en lista över bra verb att använda vid kommunikation med gruppen kring projektmål, finns.

1.6.2 Kanban och Scrum

Boken Kanban and Scrum - Making the most of both [3] av Henrik Kniberg och Mattias Skarin handlar som titeln antyder om Kanban och Scrum. Båda dessa är agila projektmetodiker och de har många likheter. Boken tar i sin första del, skriven av Kniberg, upp grunderna för båda metodiker och hur de bör användas. Även viss jämförelse mellan de båda metodikerna tas upp. I bokens andra del, som Skarin skrivit, finns en case-studie som behandlar introduceringen av Kanban i en projektgrupp på ett större företag. Dessa två delar ger tillsammans en väldigt bra bild av hur både Kanban och Scrum fungerar, och hur man kan gå tillväga för att introducera någon av metodi-kerna i en projektgrupp. Något som boken trycker mycket på är att ingen av dessa metodiker är ett komplett regelverk, det är endast grunder eller verktyg för hur man kan jobba i ett projekt. Man kan alltså inte bara läsa hur metodikerna fungerar och följa en punktlista, man måste själv utveckla metodiken för just sitt projekt. Detta ställer en del krav på projektgruppen. Tanken är dock inte att man ska behöva vara expert på metodiken för att kunna använda den, det finns många hjälpmedel för att på ett enkelt, och ofta ganska självklart, sätt utveckla sin process.

1.7

Metod

Insamling av kunskap för den här delen av uppsatsen har skett på två huvud-sakliga sätt. Dels genom att läsa böcker i ämnet och dels genom insamling av erfarenheter från projektet som utförts. Ingen tydligt specificerad metod har använts vid insamlingen av denna kunskap utan metoden har anpassats efter situation. Här kommer dock beskrivas mer övergripande hur insamlandet har gått till.

1.7.1 Böcker

För att hitta givande böcker att läsa har Google-sökningar använts flitigt. Genom att undersöka vilka författare som är framstående inom de intressanta

områdena och sedan undersökning av vilka av deras böcker som var mest intressanta för just detta projekt har bra val av böcker kunnat göras. Val har även till viss del begränsats av tillgängligheten av böckerna och till denna del har alla böcker kunnat lånas från Vallabiblioteket.

För att sedan få ut så mycket som möjligt från böckerna har de kunskaper som de har givit använts i projektet så snart som möjligt. De huvudområden som böckerna har behandlat är projektmetoden Kanban och projektledning. För mig har båda dessa områden varit direkt applicerbara i projektet och många av de saker som böckerna beskrivit har varit mycket användbara. För att komma ihåg att använda de metoder som böckerna beskrivit har ofta min-nesanteckningar använts. Dessa har ibland även varit korta handledningar, hämtade från böckerna, om hur metoderna bör användas.

1.7.2 Projekterfarenheter

En viktig grund för det som skrivs i denna del är erfarenheter från projektet i stort och även erfarenheter för mig som teamledare speciellt. Hur dessa erfarenheter har samlats in och utvärderats har dock varierat kraftigt. I vissa fall har reaktioner från gruppen av hur något fungerar antecknats. Ibland har erfarenheter direkt kunnat skrivas in i denna uppsats. Som nämnts i metodavsnittet i huvuddelen av uppsatsen har erfarenheter även samlats och utvärderats i tidrapportering och utvärderingar av faser i projektet.

1.8

Resultat

I det här avsnittet läggs vårt arbete under projektet genom dess olika faser fram, sett från min synvinkel som teamledare.

1.8.1 Förstudie

Under projektets förstudie så hade vi ännu inte börjat arbeta efter någon projektmetodik, att undersöka vilken metodik vi skulle välja var en del av arbetet under den fasen. På grund av detta hade vi inte så mycket struktur

i vårt arbete till en början. För att vårt arbete, och samarbete, ändå skulle fungera och flyta på bra krävdes en mer flexibel typ av projektledning än vanligt. Gruppen och arbetet behövde få någon form av struktur, trots att avsaknaden av metodik och oklarheten i projektet gav en brist på just det.

I förstudien skrevs mycket dokument. Avtal med kunden skrevs på och projektmetodik samt mjukvara till denna valdes. Som teamledare låg mitt ansvar främst på att se till att alla i gruppen hade något att göra och att samarbetet i gruppen fungerade bra, men även mycket på kontakten med kunden.

Vi bestämde roller i gruppen tidigt och detta gav en bra grund i vem som hade ansvar för vilket dokument. Det fanns dock många oklarheter i vad som skulle skrivas i vilket dokument och det behövdes en hel del samordning för att vi skulle få en bra samling dokument utan så många upprepningar eller felaktigt placerad information. Som teamledare fick jag även ansvar för projektplanen, som jag skrev i samarbete med resten av gruppen.

Det blev en hel del kontakt med kunden under förstudien då det var en del krångel med avtalet och även för att projektet var otydligt definierat. Denna kontakt sköttes av mig och analysansvarige, Oskar Lind. Som teamledare var det jag som hade ansvar för avtalet och det var även jag som planerade möten med kunden och skötte den mesta kontakten med dem, med undantag för ren kravanalys vilket sköttes av Oskar.

1.8.2 Förberedelser till att använda Kanban

Processen med att börja anpassa vårt arbete efter Kanban var ganska utdra-gen. Vi bestämde tidigt, ca 3 veckor in i projektet, att vi skulle använda oss av Kanban men det tog många veckor innan vi verkligen började göra det. Till en början, efter att vi bestämt att Kanban skulle användas, så gjorde vi väldigt lite för att anpassa oss till Kanban, mest för att vi inte visste så mycket om det.

Vi började dock läsa på lite smått om Kanban och diskuterade det en del på möten. Vi kom då fram till att vi behövde något datorbaserat verktyg

där vår Kanban-tavla kunde finnas. Man bör förstås ha en riktig tavla som gruppen kan samlas kring för diskussioner och möten men då vi saknade ett eget rum kunde vi inte ha någon sådan. Efter en del undersökning av alternativ började vi använda Redmine där man kan ha ett tillägg för agila projekt med en tavla som kan användas som Kanban-tavla.

Vi försökte även planera aktiviteter på ett sådant sätt att de skulle kunna göras till aktivitetslappar då vår Kanban-tavla tagit form. Detta försvårades precis som mycket annat av att vi inte riktigt visste vad vi skulle utveckla, på grund av otydligheterna från kunden. Dock gjorde inte det så mycket eftersom att Kanban är en agil metod och inte kräver en komplett aktivitetslista från början, fler aktiviteter kunde läggas till efterhand.

1.8.3 Att börja använda Kanban

Innan vi verkligen började använda Kanban läste jag boken Kanban and Scrum - Making the most of both [3] av Henrik Kniberg och Mattias Skarin. Det behövdes för att jag skulle ha den kunskap om Kanban som krävdes för att jag skulle kunna bidra till att få gruppen att använda det på rätt sätt.

Efter att ha läst i den boken omformade jag den Kanban-tavla som vi ska-pat på Redmine så att den verkligen blev en Kanban-tavla, anpassad efter vårt projekt. De flödestillstånd jag skapade då var: Backlog, To Do, Develop-ment, Integration & Testing och Resolved. Vi började då med begränsningar på 3 Works In Progress (WIP) på To Do, Development och I&T, egentligen bara för att ha någon begränsning att börja med. Backlog höll vi utan be-gränsning då det bara var en kolumn där vi lade uppgifter som vi trodde skulle behöva utföras någon gång under projektet, den var inte heller med i flödet då uppgifterna där inte arbetades på.

Tanken var att Backlog skulle vara sorterad, med uppgifter av högre prio-ritet längst upp. På möten skulle vi då kunna flytta in uppgifter från toppen av Backlog till To Do så att de skulle finnas tillgängliga för gruppmedlemmar att börja jobba på. Uppgifter i Backlog var annars låsta där så att de endast kunde flyttas av administratörer, tanken var att de endast skulle flyttas in

till To Do på möten. När uppgifter flyttats till To Do skulle de även där vara sorterade efter prioritet.

Denna information om hur jag tänkt att vi skulle använda vår Kanban-tavla kommunicerade jag först till gruppen via mail då vi just då inte kunde ha möte på över en vecka. Det var dock en period då gruppen hade mycket annat att göra utanför projektet och Kanban-tavlan började inte användas ordentligt förrän efter ett möte då vi kunde diskutera den mer. Då började vårt arbete till slut likna Kanban.

1.8.4 Vår användning av Kanban

När Kanban väl hade börjat användas ordentligt betydde det inte att allt arbete kring projektmetodik var klart, istället flyttades fokus till att förbättra snarare än implementera metodiken. Kanban är uppbyggt på ett sådant sätt att processen hela tiden ska utvecklas och anpassas bättre för projektet.

Från att Kanban introducerats ordentligt i gruppen användes det kon-tinuerligt genom resten av projektet. De saker som gjorde att det märktes tydligast att vi använde Kanban var Kanban-tavlan på Redmine och hur vi jobbade med denna på möten. Vid mötena kunde vi ha Kanban-tavlan fram-me på en datorskärm eller projektor och utifrån den diskutera läget. Det kunde handla om ifall någon aktivitet på tavlan skulle flyttas fram då den var klar i den kolumn den låg i eller att någon ny aktivitet skulle flyttas in eller läggas till.

Hur många WIP som var tillåtna i varje kolumn ökades efterhand då det märktes att den ursprungliga gränsen på 3 var väldigt låg. Tanken med den låga gränsen var att få medlemmar att samarbeta mer och att alla bara skulle fokusera på en aktivitet i taget. Då detta inte fungerade bra ökades gränserna för att inte skapa flaskhalsar i arbetsflödet.

1.9

Diskussion

1.9.1 Resultat

Det finns mycket som kan diskuteras om hur vi använde oss av Kanban och hur jag jobbade som teamledare. Här tas en del av detta upp. Jag har delat upp detta i två delar för att först diskutera tiden innan vi började använda Kanban och sedan hur vi använde Kanban.

Förstudie

Till en början visste vi väldigt lite om projektet, vilket gjorde planering svårt. Så istället för att lägga en bra plan för resten av projektet bestod vår förstudie till stor del av att skapa en tydlig bild av vad vårt projekt egentligen bestod av. Kontakten med kunden fungerade ändå bra och mot förstudiens slut började det kännas som att vi hade bra koll på projektet så att vi åtminstone kunde börja göra prototyper.

För mig, som teamledare, så innebar den bristande informationen vi hade om projektet stora svårigheter i att planera vårt projekt. Det tog lång tid innan vi kunde göra en aktivitetslista för utvecklingen av programmet, så gruppen blev snart rastlös och trött på att bara jobba med dokument. Något som man hade kunnat tänka sig var att fler gruppmedlemmar skulle vara med i kontakten med kunden för att kunna jobba fram specifikationer för projektet snabbare. Detta var dock något som vi snabbt insåg att inte skulle hjälpa, utan vi höll oss till att bara jag och Oskar höll den kontakten. Detta eftersom att vi nästan enbart jobbade mot en enskild kontaktperson på Opera och det bara skulle bli överväldigande och förvirrande för honom om han skulle behöva ha kontakt med många olika gruppmedlemmar. Det skulle antagligen bara ha bidragit till en sämre relation med kunden.

Något som jag kan se i efterhand att jag hade kunnat göra bättre är att jag borde ha lagt mer fokus på att undersöka projektmetodik under förstudien. Det hade varit bra om vi hade kommit igång med att följa en metodik tidigare så att vi hade fått mer tid till att lära oss den och använda den mer effektivt. Valet av Kanban var ändå bra och arbetet fungerade bra under merparten av den tid som Kanban användes. Jag tror dock att jag kunde ha bidragit

mer till användandet av metodiken, och varit en bättre teamledare, om jag hade läst på mer tidigare.

Kanban

Då jag själv aldrig hade jobbat med Kanban tidigare och inte heller visste speciellt mycket om metoden var det mycket viktigt att jag läste boken om Kanban [3] som nämnts tidigare. Som teamledare var det nödvändigt att jag hade den kunskap som boken gav, då det var jag som styrde arbetet med Kanban. Vi hade inte tid till att alla gruppmedlemmar skulle läsa på mycket om Kanban utan istället fick jag förmedla det jag lärt mig, tillsammans med hur jag tänkt att det skulle appliceras i vårt projekt.

Det var viktigt att skapa en positiv bild av Kanban inom gruppen för att alla skulle vilja jobba efter metodiken. Visst motstånd fanns mot Kanban från början då det kunde upplevas som att det krävdes en del onödigt jobb bara för att följa metodiken. Efterhand tror jag dock att alla i gruppen insåg att det inte var alls mycket jobb och att det lilla som behövde göras bidrog till att gruppen kunde jobba mer effektivt.

Jag skulle själv inte säga att vi använde Kanban fullt ut i projektet. Exempelvis så mätte vi aldrig lead time ordentligt som man ska göra i Kan-ban [3]. Detta berodde på flera saker. Främst skulle jag säga att det berodde på att Kanban användes ganska kort tid och det då inte fanns tid att lära sig det ordentligt. Det kändes inte heller som att det skulle ge så mycket för vårt projekt att lära oss om och utveckla Kanban fullt ut. Att vi inte visste så mycket om Kanban från början var förstås även det en bidragande faktor. Efter detta projekt skulle jag dock säga att jag lärt mig väldigt mycket om Kanban och hur det kan användas. Det kan definitivt användas i framtida projekt, och jag hoppas att jag får chansen att göra det. Jag har själv upplevt Kanban som en väldigt bra grundmetodik och jag har tyckt att det har varit kul att jobba med det. Det är dock viktigt att tänka på att Kanban bara är en bas att utgå från och inte en komplett metodik. Detta är dock något som jag upplever som något positivt med metodiken då inte alla projekt är likadana

och det då är dumt att behandla dem så. Varje projekt som man jobbar med Kanban ger också mycket erfarenhet och jag tror att om man jobbar med det i flera projekt så kommer man bli mycket bättre på att introducera det och använda det i ett nytt projekt.

1.9.2 Metod

Metoden som jag använt och beskrivit tidigare i denna del har varit ganska bristfällig. Det hade varit bra att göra mycket mer utförliga anteckningar av både erfarenheter från projektet och lärdomar från böckerna jag läst. Att föra anteckningar mer kontinuerligt, kanske varje dag, hade även det varit väldigt positivt. Detta hade kunnat bidra till en bättre uppsats men kanske framförallt så hade det kunnat bidra till att jag kunnat utvecklas mer som teamledare under projektets gång.

Anledningen att detta inte gjordes var främst lathet. Efter en dag i ett projekt känns det ofta inte som att man gjort något speciellt som är givande att reflektera över och anteckna, med det kan vara väldigt bra att göra det ändå. De reflektioner som behöver göras i samband med att anteckningarna skrivs kan bidra till mycket medvetenhet om vad man gör och hur det påver-kar projektet. Detta är något som jag tar med mig till framtida projekt och som jag då kan förbättra.

1.10

Slutsatser

För att sammanfatta svaren på de frågeställningar som denna del behandlar kommer de här att tas upp och besvaras var för sig. Detta är dock inga direkta svar på frågorna utan endast de erfarenheter som kunnat dras under detta projekt och från de böcker som jag har läst.

1.10.1 Hur Kanban påverkar ett projekt

Det mest centrala i metodiken Kanban är Kanban-tavlan. Denna är en bra samlingspunkt och centrum för diskussion vid möten. Även fast vi inte kunnat

ha en fysisk tavla utan enbart haft en virtuell tavla som funnits tillgänglig via internet har detta fungerat bra. Tavlan visar på ett bra sätt vilka aktiviteter som arbetas på och var i arbetsflödet de finns. Vid möten är det väldigt bra för att starta diskussioner kring hur arbetet går.

Den direkta påverkan på projektet som Kanban-tavlan i sig haft för oss är att den har ändrat sättet som vi har diskuterat aktiviteter på. Eftersom det funnits väldigt konkreta virtuella lappar med aktiviteter som varit pla-cerade på specifika platser i arbetsflödet har det gjort att diskussioner kring aktiviteterna kunnat få mycket tydligare struktur. Att lägga till och flytta runt lapparna har även gett mötena ett tydligare syfte. Istället för att bara nämna hur arbetet går på en aktivitet har vi kunnat diskutera mer om hur den ligger till, när den kan tänkas flyttas vidare till nästa kolumn, hur högt prioriterad den är och så vidare.

Utöver Kanban-tavlan i sig har vi även använt oss av gränser på antal WIP i varje flöde eller kolumn, vilket Kanban förespråkar. Detta är ett sätt att hålla fokus på rätt saker och inte jobba med för många olika saker samtidigt. Det bidrar också till att gruppen får mycket fokus på att även testa och integrera nya funktioner så att de snabbt kommer med i den sammansatta produkten. Det har fungerat väldigt bra med vår användning av kontinuerliga prototyper.

Att hela tiden försöka utveckla användningen av Kanban, exempelvis ge-nom att ändra gränserna för antal WIP, har bidragit till bättre medvetenhet kring hur vi jobbar. Då gruppen har behövt ändra sådana gränser har det tvingat oss att tänka på hur antalet pågående aktiviteter påverkar effektivi-teten i vårt arbete. Jag tror själv att medvetenhet om sådana saker i hela gruppen är något mycket positivt då det bidrar till bättre samarbete, moti-vation och i slutändan även effektivitet.

1.10.2 Introduktion av Kanban i ett projekt

Det finns många sätt att introducera Kanban i ett projekt, bra och mindre bra och mer och mindre krävande. Då min kunskap om Kanban vid

intro-duktionen var ganska bristfällig och även tiden för introintro-duktionen var mycket begränsad blev introduktionen av Kanban i vårt projekt definitivt inte opti-mal. Jag har dock fått många erfarenheter av vad som fungerar bra och inte, och jag har fått många tips från de böcker som jag läst.

Det som kanske är viktigast vid introduktionen av Kanban i ett projekt är att få gruppen att förstå vad nyttan med metodiken är. Om inte alla i gruppen förstår varför metodiken används och hur den bidrar till gruppens effektivitet så kommer metodiken motarbetas och inte kunna uppnå sin fulla potential. I case-studien i Kniberg och Skarins bok[3] används en workshop för att sprida metodens budskap. Jag kände inte att jag hade de förutsättningar som krävdes för att göra en workshop med gruppen. Istället fick jag använda vårt eget pågående projekt för att testa saker på. En workshop hade definitivt kunnat vara bättre då man i en sådan kan visa tydliga fördelar och vinster i att använda metodiken, och samtidigt lära ut hur den ska användas.

Något annat som är viktigt att tänka på vid introduktionen av Kanban är att lyssna på gruppens tankar och åsikter. Kanban ska hela tiden utvecklas i ett projekt och det kommer det inte göra om inte alla får en möjlighet att uttrycka brister. Detta är något som jag har försökt göra hela tiden så mycket som möjligt.

1.10.3 Strategisk projektledning

Denna frågeställning besvaras främst utifrån boken om strategisk projektled-ning[6] som jag har läst i och mina tankar kring detta.

Att se projektet i det helhetsperspektiv som boken beskriver tror jag är väldigt bra som projektledare. Som boken säger så är projektledarens uppgift att få gruppen att producera resultat som bidrar till projektets syfte. Detta uppnås inte på bästa sätt om projektledaren sätter sig in mycket i varje enskild del av projektet. Det är då bättre om projektledaren ser och förmedlar helheten av projektet och projektets syfte.

De frågor som nämns under teori i denna del tror jag bidrar till en väldigt bra grund för projektgruppen. Om dessa besvaras ordentligt efter mycket

reflektion så är det sannolikt att hela gruppen har en bra bild av projektet och dess syften och mål.

2

Andy Truong: Dokumenthantering i projekt

2.1

Inledning

Genom ett systematiskt arbetssätt kan dokumenthantering i större projekt bli enklare och effektivare med högre kvalitet på dokumenten. Denna indi-viduella del utreder projektgruppens tillvägagångssätt för att effektivisera hanteringen av projektets elektroniska dokument.

Metoder såsom versionshantering, kollaborativ redigering och typsättning behandlas i denna utredning. De erfarenheter som förvärvats under projektets gång analyseras och redogörs.

2.2

Syfte och mål

Syftet med denna delrapport är att redogöra samt reflektera över projekt-gruppens arbetssätt med avseende på dokumenthantering.

2.3

Frågeställning

• Hur kan flera personer simultant arbeta i ett dokument men samtidigt bibehålla dess kvalitet?

• Vilka metoder finns för att effektivisera dokumenthanteringen och där-med spara tid och resurser?

2.4

Avgränsningar

Utredningen behandlar inte hela arbetsflödet av dokumenthantering. Delar såsom informationsinhämtning samt dokumentdistribuering till tredje part utelämnas. Utredningen avgränsas till teknisk och vetenskaplig dokumen-tation som lagras elektronisk. Resultatet av versionshantering begränsas till dokument även om det dessutom tillämpats på källkod. Resultatet begränsas till detta projekts erfarenheter.