Linköpings universitet SE–581 83 Linköping
Linköpings
universitet | Institutionen för datavetenskap
Examensarbete
på grundnivå, 15hp | Datateknik/Mjukvaruteknik
Vårterminen
2017 | LIU-IDA/LITH-EX-G--2017/044--SE
Agil utveckling av
webbapplikation för
konkurrentanalys
–
Agile development of web application
for competitor analysis
Adam Combler
Philip Friberg
Jani Jokinen
Elin Larsson
Erik Mansén
Tobias Martinsson
Albin Pettersson
Handledare : Victor Tranell Examinator : Kristian Sandahl
Upphovsrätt
Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under 25 år från publiceringsdatum under förutsättning att inga extraordinära omständigheter uppstår. Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och admin-istrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sam-manhang som är kränkande för upphovsmannenslitterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/.
Copyright
The publishers will keep this document online on the Internet – or its possible replacement – for a period of 25 years starting from the date of publication barring exceptional circum-stances. The online availability of the document implies permanent permission for anyone to read, to download, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the con-sent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Linköping Uni-versity Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/.
c Adam Combler Philip Friberg Jani Jokinen Elin Larsson Erik Mansén Tobias Martinsson Albin Pettersson
Sammanfattning
Syftet med den här rapporten är att beskriva utvecklingen av en webbapplikation för konkurrentanalys. Rapporten baseras på fem frågeställningar som berör produktens värde för kunden, gemensamma erfarenheter från projektet, användning av en syste-manatomi, integration av separat utvecklade moduler samt anpassning av den agila projektstyrningsmetodiken Scrum. Projektet utfördes av sju studenter under 19 veckors tid med Scrum som projektstyrningsmetodik. Systemet har utvecklats utifrån en modulär modell och består av fem moduler; två API-moduler, en affärslogikmodul, en visualiser-ingsmodul samt en server. Detta tillvägagångssätt valdes för att underlätta utvecklingen om till exempel delar av mjukvaran behövde bytas ut.
Värde för kunden skapades dels genom att utveckla systemet utifrån en modulär modell, men även genom noggrann dokumentation av kod och framställning av en användar-manual till kundens förfogande. De viktigaste gemensamma erfarenheter som togs med från projektet var vikten av öppen kommunikation inom gruppen samt att vara tydlig vid dialog med kund. Användandet av en systemanatomi gav enkelt en översikt över systemet, men eftersom det inte är en lika vedertagen modell som en designskiss i form av UML-diagram kan det försvåra vid verifikation med kund. För att underlätta integra-tion av separat utvecklade moduler följdes en greningsmodell inom versionshantering och utvecklingen utfördes i par för att sprida kunskap. Slutligen applicerades en modi-fikation av projektstyrningsmetodiken Scrum, med influenser av parprogrammering och Kanban-tavla, på projektet.
Tillkännagivanden
Vi vill börja med att tacka vår handledare Victor Tranell för all hjälp och allt stöd under projektets gång. Vi vill även tacka vår kund Tim Hansen och Jonas Lindgren som gjorde detta projekt möjligt.
Innehållsförteckning
Sammanfattning ii Tillkännagivanden iii Innehållsförteckning iv Figurförteckning xi Tabellförteckning xiiiDel I - Gemensamma erfarenheter och diskussion 1
1 Inledning 2 1.1 Motivering . . . 2 1.2 Syfte . . . 2 1.3 Frågeställningar . . . 3 1.4 Avgränsningar . . . 3 2 Bakgrund 4 2.1 Tidigare erfarenheter . . . 4 3 Teori 5 3.1 Engelska termer . . . 5 3.2 Definition av termer . . . 5 3.3 Scrum . . . 7 3.3.1 Scrumteam . . . 7 3.3.2 Sprint . . . 8 3.4 Bisnode . . . 9 3.5 Boardeaser . . . 9 3.6 Systemanatomi . . . 9 3.7 Kanban-tavla . . . 9 4 Metod 10 4.1 Förstudie . . . 10 4.2 Utvecklingsfas . . . 10 4.2.1 Möten . . . 11 4.2.2 Planering . . . 11
4.2.3 Arbetssätt och verktyg . . . 11
4.2.4 Testning . . . 12
4.2.5 Versionshantering . . . 13
4.2.6 Kundkontakt . . . 13
4.2.7 Metod för att fånga erfarenheter . . . 13
5.1 Värde för kund . . . 15 5.2 Gemensamma erfarenheter . . . 15 5.3 Systembeskrivning . . . 15 5.3.1 Produktbeskrivning . . . 16 5.3.2 Helhetsbeskrivning . . . 18 5.3.3 Implementationsdetaljer . . . 18 5.3.4 Moduler . . . 18
5.4 Anpassning av Scrum till ett agilt småskaligt mjukvaruprojekt . . . 19
5.4.1 Modifieringar av Scrum . . . 20
5.5 Översikt över individuella bidrag . . . 20
6 Diskussion 22 6.1 Värde för kunden . . . 22
6.2 Gemensamma erfarenheter . . . 23
6.3 Arbete kring en systemanatomi . . . 23
6.4 Integration av moduler . . . 24
6.4.1 Parprogrammering och integration . . . 24
6.4.2 Kunskapsspridning och kommunikation . . . 24
6.4.3 Versionshantering och greningsmodell . . . 24
6.5 Anpassning av Scrum . . . 25
6.6 Arbetet i ett vidare sammanhang . . . 25
7 Slutsatser 27 7.1 Värde för kund . . . 27 7.2 Gemensamma erfarenheter . . . 27 7.3 Systemanatomi . . . 28 7.4 Integration av moduler . . . 28 7.5 Anpassning av Scrum . . . 29
Del II - Individuella bidrag 30 A En studie av tidsuppskattningsmetodik i ett agilt, småskaligt mjukvaruprojekt av Adam Combler 31 A.1 Inledning . . . 31 A.1.1 Syfte . . . 31 A.1.2 Frågeställning . . . 31 A.2 Bakgrund . . . 32 A.3 Begränsningar . . . 32 A.4 Teori . . . 32 A.4.1 Tidsuppskattningsmetodiker . . . 32 A.4.2 Verktyg . . . 33 A.5 Metod . . . 33
A.5.1 Insamling av data . . . 34
A.5.2 Sprint 2 . . . 35
A.5.3 Sprint 3 . . . 36
A.5.4 Sprint 4 . . . 36
A.5.5 Sprint 5 . . . 37
A.6 Resultat . . . 37
A.6.1 Andel avklarade uppgifter . . . 37
A.6.2 Andel feluppskattade uppgifter . . . 38
A.6.3 Medelavvikelse . . . 38
A.6.4 Andel tillagda och antal duplicerade uppgifter . . . 38
A.7 Diskussion . . . 39
A.7.1 Andel avklarade uppgifter . . . 39
A.7.2 Andel feluppskattade uppgifter . . . 39
A.7.3 Medelavvikelse . . . 40
A.7.4 Andel tillagda och antal duplicerade uppgifter . . . 40
A.7.5 Metod . . . 40
A.8 Slutsatser . . . 41
A.8.1 Hur väl stämmer uppskattningen av tidsåtgång i projektet i relation till arbetet som utfördes? . . . 41
A.8.2 Hur kan tidsuppskattning av uppgifter inom en sprint förbättras till nästa? . . . 41
A.8.3 Hur väl stämmer de framtagna uppgifterna inom en sprint överens med det utförda arbetet och finns någon metod för att förbättra detta? . 41 B Kundens inverkan på ett agilt mjukvaruprojekt av Philip Friberg 42 B.1 Inledning . . . 42 B.1.1 Syfte . . . 42 B.1.2 Frågeställning . . . 42 B.2 Bakgrund . . . 42 B.3 Teori . . . 43
B.3.1 Kundens roll i mjukvaruprojekt . . . 43
B.3.2 Anledningar till brist på kundens engagemang . . . 43
B.3.3 Produktägare i Scrum . . . 43 B.3.4 Produktbacklogg . . . 43 B.4 Metod . . . 43 B.4.1 Litteraturstudie . . . 43 B.4.2 Projekt . . . 44 B.5 Resultat . . . 44 B.6 Diskussion . . . 45 B.6.1 Litteraturstudie . . . 45 B.6.2 Projekt . . . 45
B.6.3 Alternativ för god kundkommunikation i Scrum . . . 45
B.6.4 Vilket alternativ ger bäst effekt avseende kundkommunikation i Scrum 46 B.7 Slutsatser . . . 46
B.7.1 Alternativ för god kundkommunikation i Scrum . . . 46
B.7.2 Vilket alternativ ger bäst effekt avseende kundkommunikation i Scrum 47 C Fysiska eller nätbaserade möten i vår digitala värld? av Jani Jokinen 48 C.1 Inledning . . . 48 C.1.1 Syfte . . . 48 C.1.2 Frågeställning . . . 48 C.2 Bakgrund . . . 48 C.3 Teori . . . 49 C.3.1 Google hangouts . . . 49 C.3.2 Skype . . . 49 C.3.3 Slack . . . 49 C.3.4 Andra kommunikationsverktyg . . . 49 C.3.5 Vad är kommunikation? . . . 50 C.4 Metod . . . 51 C.4.1 Projektet . . . 51 C.4.2 Enkäten . . . 51
C.5 Resultat . . . 52
C.5.1 Hur fungerade internetbaserad kommunikation inom gruppen? . . . 52
C.5.2 Vilka internetbaserade kommunikationsverktyg använder studenter? . 52 C.6 Diskussion . . . 54
C.7 Slutsatser . . . 56
C.7.1 Vilka för och nackdelar finns med internetbaserad kommunikation? . . 56
C.7.2 Vilka internetbaserade kommunikationsverktyg används av studenter? 56 D Dokumenthantering i ett småskaligt mjukvaruprojekt med agil utvecklingsme-todik av Elin Larsson 57 D.1 Inledning . . . 57 D.1.1 Syfte . . . 57 D.1.2 Frågeställning . . . 57 D.2 Bakgrund . . . 57 D.3 Teori . . . 58 D.3.1 ShareLaTeX . . . 58 D.3.2 Google Drive . . . 58
D.3.3 Dokumentation och agila arbetssätt . . . 58
D.4 Metod . . . 59 D.4.1 Litteraturstudie . . . 59 D.4.2 Projekt . . . 59 D.5 Resultat . . . 59 D.5.1 Förstudie . . . 59 D.5.2 Utvecklingsfas . . . 60
D.5.3 Enkät om de framtagna dokumentens värde . . . 61
D.6 Diskussion . . . 63
D.6.1 Metod . . . 63
D.6.2 Resultat . . . 63
D.7 Slutsatser . . . 65
E REST och SOAP, en jämförelse av webbtjänsters uppbyggnad av Erik Mansén 66 E.1 Inledning . . . 66 E.1.1 Syfte . . . 66 E.1.2 Frågeställning . . . 66 E.2 Bakgrund . . . 67 E.3 Teori . . . 67 E.3.1 HTTP . . . 67 E.3.2 XML . . . 67 E.3.3 Cache . . . 67 E.3.4 Kodkomplexitet . . . 67 E.3.5 SOAP . . . 68 E.3.6 WSDL . . . 68 E.3.7 REST . . . 68
E.3.8 Att välja rätt metod för utveckling av API . . . 69
E.3.9 JSON-baserade API:ers popularitet . . . 69
E.3.10 REST:s växande popularitet . . . 69
E.4 Metod . . . 70
E.4.1 Litteraturstudie . . . 70
E.4.2 Enkätundersökning . . . 70
E.4.3 Undersökning av kodkomplexitet . . . 70
E.5.1 Resultat från enkätundersökning . . . 70
E.5.2 Undersökning av kodkomplexitet . . . 70
E.6 Diskussion . . . 72
E.6.1 Egna erfarenheter . . . 72
E.6.2 Brist på WDSL-konsumerande klient . . . 72
E.6.3 Kodkomplexitetsresultat . . . 72
E.6.4 Projektets storlek och omfattning . . . 73
E.7 Slutsatser . . . 73
E.7.1 Hur bör man välja mellan REST eller SOAP för att utveckla ett system? 73 E.7.2 Hur matchar resultaten vad som syns i industrin? . . . 73
F Undersökning av metod för testning och enhetstesters betydelse vid parprogram-mering av Tobias Martinsson 75 F.1 Inledning . . . 75 F.1.1 Syfte . . . 75 F.1.2 Frågeställning . . . 75 F.2 Bakgrund . . . 76 F.3 Teori . . . 76 F.3.1 Testdriven utveckling . . . 76 F.3.2 Parprogrammering . . . 76 F.3.3 Enhetstester . . . 76 F.3.4 Systemtester . . . 76 F.4 Metod . . . 77
F.4.1 Undersökning och testprocess . . . 77
F.4.2 Sammanställning av data och erfarenheter . . . 78
F.5 Resultat . . . 78
F.5.1 Resultat från enkät . . . 79
F.6 Diskussion . . . 80
F.6.1 Testa sin egen eller testa någon annans kod . . . 80
F.6.2 Antal buggar och alternativ metod . . . 80
F.6.3 Parprogrammering och enhetstester . . . 81
F.7 Slutsatser . . . 81
F.7.1 För - och nackdelar med att testa sin egen och testa någon annans kod . 81 F.7.2 Effekter av parprogrammering på enhetstester . . . 82
G Effekten av versionshantering på projekt och val av versionhanteringsverktyg av Albin Pettersson 83 G.1 Inledning . . . 83 G.1.1 Syfte . . . 83 G.1.2 Frågeställning . . . 83 G.2 Bakgrund . . . 83 G.3 Teori . . . 84
G.3.1 Mest populära versionshanteringsverktyget . . . 84
G.3.2 Git . . . 84
G.3.3 SVN . . . 84
G.3.4 Skillnader mellan Git och SVN . . . 84
G.4 Metod . . . 84 G.4.1 Källor . . . 85 G.4.2 Projekt . . . 85 G.4.3 Enkätundersökning . . . 85 G.5 Resultat . . . 86 G.5.1 Projekt . . . 86
G.5.2 Enkätundersökning . . . 86 G.6 Diskussion . . . 90 G.6.1 Metod . . . 90 G.6.2 Resultat . . . 90 G.7 Slutsatser . . . 91 Referenser 92 H Bilaga 1 - Utvärdering 97 H.1 Samarbete . . . 97 H.1.1 Bra . . . 97 H.1.2 Dåligt . . . 97 H.2 Stämning . . . 97 H.2.1 Bra . . . 97 H.2.2 Dåligt . . . 97 H.3 Kommunikation . . . 98 H.3.1 Bra . . . 98 H.4 Roller . . . 98 H.4.1 Bra . . . 98 H.4.2 Dåligt . . . 98 H.4.3 Förbättringsförslag . . . 98 H.5 Möten . . . 98 H.5.1 Bra . . . 98 H.5.2 Dåligt . . . 98 H.5.3 Förbättringsförslag . . . 98 H.6 Verktygen . . . 99 H.6.1 Bra . . . 99 H.6.2 Dåligt . . . 99 H.6.3 Förbättringsförslag . . . 99 H.7 Parprogrammering . . . 99 H.7.1 Bra . . . 99 H.7.2 Dåligt . . . 99 H.7.3 Förbättringsförslag . . . 99 H.8 Iteration 1 . . . 100 H.9 Iteration 2 . . . 100 H.10 Övriga tankar . . . 101
I Bilaga 2 - Enkät om testning 102 I.1 Har du testat och/eller varit iblandad i testning under projektets gång? . . . . 102
I.2 Hur har du upplevt testningen du utfört under projektet? . . . 103
I.2.1 Vad var bra med testningen? . . . 103
I.2.2 Vad hade kunnat göras bättre? . . . 103
I.3 Upplevelse av enhetstester vid parprogrammering . . . 104
I.3.1 Nödvändig/onödig . . . 104
I.3.2 Tidseffektiv/slöseri med tid . . . 104
I.4 Upplevelse av integrationstester vid parprogrammering . . . 105
I.4.1 Nödvändig/onödig . . . 105
I.4.2 Tidseffektiv/slöseri med tid . . . 105
I.5 Upplevelse av systemtester vid parprogrammering . . . 106
I.5.1 Nödvändig/onödig . . . 106
I.5.2 Tidseffektiv/slöseri med tid . . . 106
I.6 Tror du att arbeta i par medför granskning av koden på ett sätt som gör enhet-stester redundanta? . . . 107
I.6.1 Om ja/nej varför? . . . 107
J Bilaga 3 - Testmall 108
K Bilaga 4 - Enkät om versionshantering 109
L Bilaga 5 - Enkät om dokuments värde i ett småskaligt, agilt mjukvaruprojekt 112
M Bilaga 6 - Enkät om uppfattningar angående REST och SOAP 114
Figurförteckning
4.1 GitHub Flow . . . 13
5.1 Systemanatomi . . . 17
5.2 Representation av systemet i sin helhet. . . 18
C.1 En illustration av kommunikation, enligt artikeln ”Art of communication in project management”. . . 50
C.2 Vilken kommunikations kanal är favorit? . . . 53
C.3 Är internetbaserad kommunikation är ett bra komplement till fysiska träffar? I grafen finns Datainriktade utbildningar (D), Maskinteknik (M) och Industriell ekonomi (I). . . 54
D.1 Viktigaste dokumentet under projektets gång . . . 61
D.2 Använda dokument under projektets gång . . . 61
D.3 Ej använda dokument under projektets gång . . . 62
D.4 Upplevelse av aktuella dokument under projektets gång . . . 62
D.5 Viktiga dokument för ett projekt i allmänhet . . . 62
E.1 Cyklomatisk komplexitet per funktionsblock i de undersökta SOAP-modulerna. Y-axeln motsvarar komplexitetsnivå och x-axeln frekensen av denna nivå. . . 71
E.2 Cyklomatisk komplexitet per funktionsblock i den undersökta REST-modulen. Y-axeln motsvarar komplexitetsnivå och x-Y-axeln frekensen av denna nivå. . . 71
F.1 Enhetstestflöde . . . 77
F.2 Sammanställning av alla testessioner . . . 78
F.3 Hur nödvändiga är enhetstester vid parprogrammering? . . . 79
F.4 Hur tidseffektiva är enhetstester vid parprogrammering? . . . 79
F.5 Gör parprogrammering enhetstester redundanta? . . . 80
G.1 Användning av versionshantering. . . 86
G.2 Vilka delar som versionshanteras. . . 87
G.3 Önskan att ha tillgång till en tidigare version. . . 87
G.4 Tidsbesparing på grund av versionshantering. . . 88
G.5 Olika versionshanteringsverktyg. . . 88
G.6 Påverkan som versionshantering har på projekt. . . 89
G.7 Viktiga egenskaper hos ett versionshanteringsverktyg. . . 90
I.1 Har du testat och/eller varit iblandat i testning under projektets gång? . . . 102
I.2 Generell upplevelse av utförd testning . . . 103
I.3 Hur nödvändig är enhetstester vid parprogrammering? . . . 104
I.4 Hur tidseffektiv är enhetstester vid parprogrammering? . . . 104
I.5 Hur nödvändig är integrationstester vid parprogrammering? . . . 105
I.7 Hur nödvändig är systemtester vid parprogrammering? . . . 106 I.8 Hur tidseffektiv är systemtester vid parprogrammering? . . . 106 I.9 Tror du att arbeta i par medför granskning av koden på ett sätt som gör
enhet-stester redundanta? . . . 107 M.1 Andelen projektmedlemmar som arbetat med REST under projektets gång. . . 114 M.2 Fördelning av projektmedlemmars åsikter angående hur enkelt det är att arbeta
med REST. Y-axeln visar svarsfrekvens, x-axeln åsikt i skalan 1-5. . . 115 M.3 Fördelning av projektmedlemmars åsikter angående REST:s roll som verktyg för
API-implementation. Y-axeln visar svarsfrekvens, x-axeln åsikt i skalan 1-5. . . 115 M.4 Andelen projektmedlemmar som arbetat med SOAP under projektets gång. . . 116 M.5 Fördelning av projektmedlemmars åsikter angående hur enkelt det är att arbeta
med SOAP. Y-axeln visar svarsfrekvens, x-axeln åsikt i skalan 1-5. . . 116 M.6 Fördelning av projektmedlemmars åsikter angående SOAP:s roll som verktyg för
API-implementation. Y-axeln visar svarsfrekvens, x-axeln åsikt i skalan 1-5. . . 117 M.7 Fördelning av projektmedlemmars åsikter angående SOAP:s roll som verktyg för
API-implementation. . . 117 M.8 Fördelning av vilken av de två metoderna som skulle användas av olika
Tabellförteckning
3.1 Kort uppslagsverk över översatta termer . . . 5
4.1 Insticksprogram till Atom . . . 12
A.1 Minneslista över potentiella uppgifter . . . 37
A.2 Andel avklarade uppgifter inom utsatt tid . . . 37
A.3 Andel feluppskattade uppgifter . . . 38
A.4 Medelavvikelse . . . 38
A.5 Andel tillagda och antal duplicerade uppgifter . . . 38
A.6 Tidsperioder för varje sprint . . . 38
D.1 Lista över framtagna dokument . . . 60
D.2 Lista över officiella deadline . . . 60
E.1 Tabell över diverse kodkomplexitetsvärden för dyra undersökta moduler för kom-munikation med API:er. . . 72
Del I
1
Inledning
En styrelsemedlem ska deltaga på ett styrelsemöte för det företag denne är involverad i. Det är dags att utvärdera sitt egna företag, och jämföra det med konkurrenterna för att kunna hitta sin vinkel till marknaden. För att kunna göra det har företagets VD anlitat en extern revisor som gått igenom all intressant information om alla konkurrenter. Det kostar företaget flera tusentals kronor, men är ett nödvändigt ont för att kunna genomföra en konkurrentanalys. Detta är en vanlig situation på företag världen över. Finns det något sätt denna situation kan lösas på ett billigare och snabbare sätt, och dessutom göra företagsdatan mycket mer lättöverskådlig?
1.1
Motivering
Projektet gick ut på att utveckla tjänsten Complyzer, en automatisk konkurrentanalys, för att underlätta arbetet för bolagsstyrelser. Med denna tjänst kan en styrelse enkelt få en bild över hur det egna företaget ligger till jämfört med sina konkurrenter. Tjänsten använder sig av insamlad ekonomisk data och den kommer vara en del i webbapplikationen Boardeaser [1]. Med tjänsten ska användaren på bara en minut kunna få en initial bild av läget, medan man på fem minuter kan införskaffa sig mer djupgående information. Tjänsten producerar all data på ett enkelt, grafiskt och pedagogiskt sätt som är lätt för användaren att ta in.
1.2
Syfte
Syftet med rapporten är att beskriva den tjänst som har producerats samt vilka utveck-lingsmetoder som har använts under projektets gång. Gruppens erfarenheter och lärdomar av att arbeta i en projektgrupp om sju personer och tillsammans utveckla en tjänst för en kund kommer även att dokumenteras och diskuteras. Rapporten utgår ifrån fem frågeställningar, som presenteras i kapitel 1.3.
1.3. Frågeställningar
1.3
Frågeställningar
Följande frågeställningar bygger resten av rapporten på:
1. Hur kan produkten Complyzer implementeras så att det skapar värde för kunden? 2. Vilka erfarenheter kan dokumenteras från programvaruprojektet Complyzer som kan
vara intressanta för framtida projekt?
3. Vilket stöd kan man få genom att skapa och följa upp en systemanatomi? 4. Hur kan man säkerställa att moduler utvecklade separat kan integreras? 5. Hur kan Scrum anpassas för ett småskaligt utvecklingsprojekt?
1.4
Avgränsningar
Projektet utfördes i samband med kursen TDDD96 Kandidatprojekt i programvaruutveckling vid Linköpings universitet, en kurs på 15 högskolepoäng. Denna kurs medförde att an-talet timmar som varje projektmedlem hade till förfogande var begränsade. Varje medlem hade 400 arbetstimmar att tillgå under kursens gång. Eftersom antalet timmar var be-gränsade och vissa projektmedlemmar saknade erfarenhet av webbutveckling avbe-gränsades hur mycket funktionalitet som implementerades. Målgruppen för det utvecklade systemet är styrelsemedlemmar. Rapportens målgrupp är i huvudsak handledare och examinator i kursen TDDD96 Kandidatprojekt i programvaruutveckling, men även andra studenter med grundläggande kunskap inom mjukvaruutveckling.
2
Bakgrund
Många bolag lägger väldigt mycket resurser på att förstå sin ställning i förhållande till konkurrenter. Antingen får bolagets VD sammanställa rapporter från en ekonom, eller får någon anlitas specifikt för att skapa dessa analyser. Rapporterna ska innehålla information om hur det går för bolaget, samt en analys om hur bolaget ligger till i förhållande till konkur-renter. Detta arbete är tidskrävande och kostsamt.
Kunden för projektet har som mål att göra det smidigare och billigare för en styrelse och ledning att få konkurrentanalyser. Med hjälp av systemet som utvecklats bör det gå att få en snabb överblick över sitt bolags situation, och en mer djupgående bild om det önskas. Slutprodukten kommer när den är färdigutvecklad utgöra en del i webbtjänsten Board-easer. Boardeaser erbjuder en tjänst vars syfte är att via en webbapplikation underlätta styrelsearbete, bland annat genom att sammanställa ekonomisk data på ett smidigt sätt. För mer om Boardeaser se kapitel 3.5.
2.1
Tidigare erfarenheter
Alla gruppens medlemmar har läst minst fem terminer på civilingenjörsprogrammet inom datateknik eller mjukvaruteknik vid Linköpings universitet. En majoritet av gruppens medlemmar har även tidigare arbetat i större projekt i bland annat kursen TSEA29 Konstruk-tion med mikrodatorer vid Linköpings universitet och har därmed en del erfarenheter. Vissa i gruppen har också erfarenhet inom webbprogrammering och Python Flask. De viktigaste er-farenheterna och lärdomarna som gruppmedlemmarna tagit med sig från tidigare projekt var hur viktig kommunikation mellan gruppmedlemmarna var och att det var svårt att tidsupp-skatta uppgifter. För att undvika dessa problem bestämde gruppen tidigt att alla medlemmar skulle vara tillgängliga via kommunikationsverktyget Slack [2]. Dessutom beslutades det att olika agila tidsuppskattningsmetodiker skulle användas för att förbättra tidsuppskattningen.
3
Teori
I detta kapitel presenteras teori kring verktyg, arbetsmetoder, termer och andra områden som är relevanta för resten av rapporten.
3.1
Engelska termer
I tabell 3.1 presenteras termer som har en mer bekant engelsk notation men som i detta doku-ment översätts till en svensk term.
Tabell 3.1: Kort uppslagsverk över översatta termer
Engelska Svenska
Branch Förgrening
Daily Scrum meeting Dagligt Scrummöte
Master Huvudförgrening
Merge Sammanfoga
Planning poker Planeringspoker Product backlog Produktbacklogg
Scrum-team Scrumteam
Sprint backlog Sprintbacklogg Sprint planning meeting Sprintplanering Sprint retrospect Sprintåterblick Sprint review meeting Sprintgranskning
Extreme programming Extrem programmering eller XP
User story Användarberättelse
3.2
Definition av termer
Nedan ges en kort förklaring till termer som används i rapporten men som ej beskrivs någon annanstans:
• Förgrening är ett begrepp inom versionshantering. För att låta flera utvecklare jobba på samma projekt utan att deras kodändringar krockar med andras ändringar kan för-greningar skapas för de olika utvecklingsuppgifterna. Dessa förför-greningar är i princip
3.2. Definition av termer
kopior av en ursprungsförgrening där förändringar i en förgrening inte påverkar andra förgreningar, eller originalet. [3]
• Huvudförgrening är den ursprungliga förgreningen ur vilket ett projekt som använder Git startar. Tanken är oftast att huvudförgreningen ska innehålla endast kod som fak-tiskt fungerar och är testad. Det vill säga, den senaste stabila versionen av produkten. [3]
• Sammanfoga är ett begrepp inom versionshantering. När en gren nått sitt ändamål, det vill säga den funktionalitet som grenen skapats för har implementerats och testats till belåtenhet, brukar nästa steg vara att sammanfoga den med sin ursprungsgren. Efter sammanfogningen kommer den ursprungliga grenen innehålla både den gamla och nya funktionaliteten. [4]
• Användarberättelse är en berättelse på en mening som beskriver en funktionalitet an-vändaren kan nyttja i ett system som ska konstrueras och varför det är önskvärt. En mall för ett användarfall anges i nedanstående citat [5]:
“Som en roll vill jag mål/önskan så att nytta.”
• API - Application programming interface (sv: applikationsprogrammeringsgränss-nitt) specificerar hur det går att kommunicera med mjukvara från en applikation. API:et är ett gränssnitt som applikationen kan kommunicera med mjukvarans funktioner genom. [6]
• JSON (JavaScriptObjectNotation) är ett standardiserat format för att skicka textbaserad information över internet baserat på programmeringsspråket JavaScript [7].
• HTML (HyperTextMarkupLanguage) är språket vilket webbsidor skrivs i som standard [8].
• JavaScript är ett dynamiskt, svagt typat språk som oftast används i samband med HTML genom att bädda in skript i HTML-koden. Dessa skript kan till exempel an-vändas till animationer eller för att skapa en interaktiv webbsida. [9]
• TypeScript är ett språk utvecklat av Microsoft som kompilerar till ren JavaScript. Tanken med språket är att underlätta skrivandet av stora JavaScript-projekt eller ap-plikationer genom att införa till exempel klasser, moduler och statisk typning. [10] • HTTP (HyperTextTransferProtocol) är det kommunikationsprotokoll som används på
internet för att överföra webbsidor [11].
• REST är en metod för att designa webbaserade API:er. Det går i princip ut på att använda redan existerande protokolls (nästan alltid HTTP) kommunikationsfunktion-alitet för att definiera ett sätt att skicka data mellan olika enheter. Detta görs ofta i form av så kallade nyckel-värde-par formatterade enligt någon väldefinierad modell som till exempel JSON. Ändamålet är att skapa ett "språk" med vilket olika enheter kan kom-municera med varandra trots att de i sig är väldigt olika, till exempel kan en enhet vara en stor, robust serverdator och en annan vara en mobiltelefon. [12]
• SOAP är till skillnad från REST ett fullständigt API i sig självt, utvecklat av Microsoft, och inte bara riktlinjer för att designa sådana. SOAP är likt REST oftast byggt ovanpå HTTP även om andra protokoll också kan användas för dataöverföringen. Det som skiljer de två API:erna åt är att SOAP har en mycket strikt beskrivning över hur ett meddelande ska se ut. Denna strikthet leder ofta till att SOAP kräver betydligt mycket mer text per meddelande vilket gör det mer krävande att utveckla och läsa. En fördel med SOAP är dess användning av WSDL, Web Service Description Language (sv: Språk
3.3. Scrum
för beskrivning av webbtjänster) vilket är ett språk som används för att beskriva de olika funktionerna en webbtjänst tillhandahåller. WSDL är väl anpassat till att läsas av maskiner vilket leder till att så kallade SOAP-klientprogram kan autogenerera den kod som krävs för att tala med ett API, en process kallad att "äta API:et". Detta kan i vissa fall förenkla arbetet med ett API avsevärt. [13]
• Flask är ett Pythonbaserat ramverk för att utveckla webbsidor och webbtjänster, speciellt lämpat att implementera egna REST-API:er med. Ramverket hanterar kom-munikation med internet bakom kulisserna vilket låter utvecklare fokusera på webbsi-dornas funktionalitet och innehåll. [14]
• Requests är ett Python-bibliotek för HTTP-funktionalitet [15]. Requests används i pro-jektet för att göra anrop till olika API:er.
• WizCFO är kundens startup-företag som är en underleverantör till Boardeaser, se kapi-tel 3.5.
• Swagger är ett verktyg för att designa, dokumentera, och testa REST API:er [16].
3.3
Scrum
Scrum är ett ramverk som används för produktutveckling och grundar sig på empirisk pro-cesstyrningsteori, även kallat empirism. Empirism förklarar hur kunskap kommer ifrån er-farenheter och ifrån beslutsfattande som har baserats på det som redan är känt. Implemen-tationer som baseras på empirisk processtyrning innehåller tre grundpelare; transparens, granskning och anpassning. [17] Dessa tre grundpelare förklaras som följer:
• Transparens innebär att alla delar inom projektet ska vara synliga för alla involverade. Detta kräver att dessa delar är definierade i en standard så att alla som är ansvariga för resultatet får en gemensam förståelse. Exempel på detta är att alla involverade har ett gemensamt språk vid tal om processen, men även att alla är överens om vad ordet "klart" innebär i relation till resultat. [17]
• Granskning är en del av utvecklingsarbetet och måste utföras för att upptäcka avvikelser. Dessa moment får dock inte komma i vägen för själva arbetet. Granskningarna bör utföras av skickliga granskare i nära anslutning till arbetet. [17] • Anpassning måste utföras då en granskare upptäcker att en process leder till en
pro-dukt som inte kan accepteras. Antingen förändrar man själva processen eller det mate-rial som man har arbetat med. Denna anpassning behöver göras så snart som möjligt för att undvika ytterligare avvikelser. Inom en sprint, som är en tidsbegränsad pe-riod där utvecklingsarbete sker, finns det fyra olika tillfällen för granskning och an-passning; sprintplanering, dagligt Scrummöte, sprintgranskning samt sprintåterblick. Dessa beskrivs mer utförligt i kapitel 3.3.2. [17]
Vidare definieras Scrum som lättviktigt, lätt att förstå och svårt att bemästra. Ramverket består av ett Scrumteam, aktiviteter, artefakter och regler. [17]
3.3.1
Scrumteam
Ett Scrumteam består av en produktägare, ett utvecklingsteam och en Scrum master. Dessa Scrumteam är självorganiserande, vilket innebär att teamets medlemmar själva bestämmer hur de ska lägga upp arbetet och styrs inte av någon utomstående. Dessutom beskrivs de som tvärfunktionella. Att vara ett tvärfunktionellt team betyder att alla medlemmar, tillsammans, besitter all den kunskap och kompetens som krävs för projektet. [17] Nedan beskrivs olika roller inom ett Scrumteam:
3.3. Scrum
• Produktägare är den person som har ansvar för att maximera värdet av produkten samt utvecklingsteamets arbete. Denna person har även huvudansvar för produkt-backloggen, se kapitel 3.3.2. Alla förslag till förändring av en post i produktbackloggen måste gå via produktägaren och hans eller hennes beslut måste respekteras. [17] • Utvecklingsteamet består av en konstellation yrkesmänniskor som tillsammans
ansvarar för utvecklingen av en produkt och levererar ett användbart inkrement, se kapitel 3.3.2. Enbart personer ur teamet får delta i utvecklingen av dessa produktver-sioner. Följande kännetecknar utvecklingsteamet; de är självorganiserade och tvärfunk-tionella, ingen i teamet får ha en individuell titel utan alla benämns som utvecklare samt att alla i teamet har gemensamt ansvar. [17]
• Scrum master är den personen som ansvarar för att Scrum efterlevs genom att följa Scrumteorin med dess tillämpningar och regler. Denna roll har även ansvar för kommunikationen med personer utanför Scrumteamet och ser till att interaktionerna därimellan maximerar teamets arbete. Scrum master bistår inte bara med hjälp till Scrumteamet, utan även till produktägaren och organisationen. [17]
3.3.2
Sprint
Sprinten är hjärtat i Scrum och är en tidsbegränsad period på upp till en månad. Under denna period sker allt arbete med produkten och i slutet av sprinten ska ett användbart inkrement kunna levereras. En sprint består av ett antal processer; sprintplanering, dagliga Scrum-möten, utvecklingsarbete, sprintgranskning och sprintåterblick. Om en sprint inte längre känns meningsfull på grund av omständigheterna, eller om sprintmålet inte känns aktuellt, bör den avbrytas. Den enda som har tillåtelse att avbryta en sprint är produktägaren. [17] Följande är några centrala begrepp och aktiviteter inom Scrum:
• Inkrement är en version av en produkt som har arbetats fram i en sprint [17].
• Produktbacklogg är en prioriterad lista som innehåller beskrivningar av allt som pro-dukten kan bestå av. Dessa beskrivningar formuleras vanligtvis som användarberät-telser. Produktbacklogg är en Scrumartefakt. [17]
• Sprintplanering är en aktivitet som hela Scrumteamet deltar i där det arbete som ska genomföras under en sprint planeras. För att planera arbetet används produktback-loggen som grund och antalet poster som väljs ut är enbart upp till utvecklingsteamet. Därefter formulerar hela Scrumteamet ett sprintmål som är tänkt att vägleda teamet och skapa ett sammanhängande arbete. [17]
• Dagligt Scrummöte är ett möte tidsbegränsat till 15 minuter som syftar till att planera dagens arbete samt att reflektera över gårdagens. Alla i utvecklingsteamet svarar på följande frågor;
– Vad gjorde jag igår? – Vad ska jag göra idag? – Ser jag några hinder?
Det dagliga Scrummötet används för att avgöra om utvecklingen går framåt samt hu-ruvida utvecklingen sker tillräckligt snabbt för att uppnå sprintmålet inom den tidsbe-gränsade sprinten. [17]
• Sprintgranskning hålls i slutet av varje sprint där både utvecklingsteamet och in-tressenterna för produkten deltar. Detta möte är till för att granska det framtagna inkre-mentet och få återkoppling. [17]
3.4. Bisnode
• Sprintåterblick sker efter varje sprintgranskning och innan varje sprintplanering. Syftet med den aktiviteten är att utvecklingsteamet ska utvärdera hur den senaste sprinten har fungerat och identifiera förbättringsmöjligheter som ska appliceras på nästkommande sprint. [17]
• Sprintbacklogg är en plan över hur utvecklingen ska gå till under den kommande sprinten. Denna Scrumartefakt baseras på de poster som valts ut ifrån produktback-loggen. [17]
3.4
Bisnode
Bisnode är ett företag som sammanställer ekonomisk data om olika företag. Den sam-manställda datan tillhandahålls Bisnodes kunder via ett API. API:et gör det möjligt att på ett enkelt sätt hämta offentlig ekonomisk data och ekonomiska dokument. [18]
3.5
Boardeaser
Boardeaser är det befintliga system som produkten ska integreras till. Boardeaser sam-manställer företagsdata till ledningar så att de snabbt kan se hur det går för det egna företaget samt snabbt och effektivt ta fram mötesprotokoll och rapporter till ledningsmöten. [1]
3.6
Systemanatomi
En systemanatomi är en beskrivning av vilka funktionaliteter ett system kräver och ska lev-erera samt relationerna mellan dessa. Systemanatomin kan realiseras med inringade korta beskrivningar av olika funktionaliteter med pilar dragna mellan ringarna för att representera en relation. Pilen pekar på den funktionalitet som krävs innan funktionaliteten pilen utgår från kan implementeras. Systemanatomin ska inte bli för stor, en tumregel är att den ska kunna rymmas på ett vanligt papper. Basfunktionalitet finns längst ned i anatomin och mer komplex eller användarnära funktionalitet finns i toppen. [19]
3.7
Kanban-tavla
Med kanban-tavla menas en tavla, elektronisk eller fysisk, där uppgifter som ska utföras sammanställs. Dessa uppgifter motsvaras av varsin post-it-lapp på kanban-tavlan. På tavlan finns dessutom flera olika kategorier dessa lappar kan flyttas mellan. Det finns oftast en kategori för ej påbörjade uppgifter, en för de som arbetas med just nu, och slutligen en för avklarade. Ytterligare kategorier kan läggas till för olika typer av projekt. Flödet för en uppgift blir ofta att den först väljs ut, och sedan flyttas mellan dessa minst tre kategorier i ordning under arbetets gång. Kanban-tavlan ger därmed möjlighet till att få en överblick över sprintens nuvarande tillstånd. [20]
4
Metod
I detta kapitel beskrivs hur arbetet har lagts upp under de två huvudfaserna som projektet har delats upp i, förstudie och utvecklingsfas. Vidare beskrivs inverkan av Scrum på utveck-lingsfasen och hur olika verktyg använts.
4.1
Förstudie
I förstudien ägnades mycket tid åt att ta fram en bas för projektet att stå på. En kravspeci-fikation arbetades fram utifrån de önskemål om funktionalitet kunden angett. Kunden hade mycket tydliga önskemål om vad som skulle utvecklas i form av funktionalitet, men im-plementationen lämnades delvis fri. Produkten skulle dock fungera med redan existerande system i form av företaget Bisnodes API och kundens eget API. Ett första utkast av en kravsammanställning arbetades fram för att verifiera med kunden att gruppen förstått vad som önskats. Efter kundens godkännande producerades en första version av kravspecifika-tionen.
Nästa steg var att producera en systemanatomi. En systemanatomi beskriver vilka funktion-aliteter systemet kräver och ska leverera, och relationerna mellan dessa. Funktionfunktion-aliteterna togs fram utifrån kravsammanställningen samt att gruppen under ett möte fick skriva ned de uppfattade funktionaliteterna på olika lappar. Dessa jämfördes med varandra för att ta bort dubbletter och diskutera vilka som berörde varandra. När funktionaliteterna var framtagna kunde dessa sedan relateras till varandra vilket resulterade i den slutgiltiga sys-temanatomin. Utifrån systemanatomin kunde sedan en designskiss utarbetas, till stor del genom att låta närliggande funktionaliteter hamna i samma modul. Även systemanatomin och designskissen verifierades med kunden.
4.2
Utvecklingsfas
I nästa fas, utvecklingsfasen, valde gruppen att använda projektstyrningsmetodiken Scrum, men anpassad till att fungera för projektet i fråga. Det är dessa anpassningar som presenteras här.
4.2. Utvecklingsfas
4.2.1
Möten
En sprint innehöll alltid tre speciella möten kallade sprintplanering, sprintgranskning och sprintåterblick, se kapitel 4.2.2, 4.2.6 samt 4.2.7. Ytterligare möten hölls i form av korta Scrum-möten, se kapitel 3.3.2. Dessa möten var utformade för att få en gemensam överblick över systemets nuvarande status och fånga problem snabbt. De korta Scrummötena hölls inled-ningsvis ett par gånger i veckan, för att sedan gå över till att bli dagliga i den tredje sprinten. I den fjärde sprinten hölls de varannan dag. Resterande delen av projektet hölls de vid behov, i genomsnitt varannan dag. Mötena har ägt rum med alla fysiskt närvarande, men också med delar av eller hela gruppen närvarande via internetbaserade kommunikationskanaler i form av Slack [2] och Google Hangouts [21]. För mer om detta se avsnitt C.
4.2.2
Planering
I slutet av förstudien och i första sprinten togs även en produktbacklogg fram utifrån kravspecifikationen. Det är en så kallad Scrumartefakt och bestod av ett antal användar-berättelser, vilka rangordnades efter kundens önskningar i kombination med gruppens uppskattade svårighet att implementera funktionaliteten. Produktbackloggen och kravspeci-fikationen var utgångspunkten i de sprintplaneringsmöten som ägde rum i början av varje sprint. Under sprintplaneringsmötena bröts användarberättelsen ned till mindre uppgifter som behövde avklaras för att lyckas implementera funktionaliteten användarberättelsen beskrev. Under mötet togs även mötestid och dokumentskrivning upp som uppgifter. För varje sådan mindre uppgift uppskattades tiden, eller den relativa storleken jämfört med andra uppgifter, gemensamt av gruppen. I slutet räknades storleken eller timmarna ihop för att jämföra med den budgeterade storleken eller tidsåtgången för respektive sprint. Även ett sprintmål togs fram för varje sprint.
Det som ändrades mellan sprintarna gällande sprintplaneringen var hur uppskattningen av uppgifternas storlek eller tidsåtgång gick till. Detta gjordes för att kunna se om gruppen kunde förbättra sin prestation under planeringen. För mer om detta se avsnitt A.
4.2.3
Arbetssätt och verktyg
När planeringen var avklarad följde arbetet mot det utsatta målet, genom att utföra de uppgifter som tagits fram. Denna utvecklingsprocess styrdes av ett antal arbetssätt som förk-laras här.
Parprogrammering
Ett arbetssätt som användes under hela utvecklingsfasen och som hämtades från den agila programutvecklingsmetodiken extrem programmering var parprogrammering. Det gick ut på att två gruppmedlemmar tillsammans programmerade vid en dator. Anledningen till att detta arbetsätt valdes var för att det ofta gynnar kvaliteten på koden och mindre problem kan undanröjas i en snabbare takt då medlemmarna i paren ofta besitter olika kompetens. [22][23]
Kodprinciper
All kod som skrevs av gruppen dokumenterades genom att en beskrivande kommentar lades in i toppen av varje funktion. Dessutom fick funktionerna namn i form av verb som beskriver handlingen de utför. Variablerna hade i den mån det gick namn i form av substantiv som beskrev vad de representerade.
4.2. Utvecklingsfas
Arbetsfördelning
För att fördela arbetet mellan gruppens par använde sig gruppen av en kanban-tavla. På tavlan sammanställdes de uppgifter som planerats under sprintplaneringsmötena i början av varje sprint, och deras tillhörande tidsåtgång eller storlek. Kategorierna Backlogg, Pågående, Redo för testning samt Arkiv fanns representerade. Flödet för de programmatiska uppgifterna var att de började i kategorin Backlogg för att sedan fritt väljas ut av ett av paren varefter de flyttades till kategorin Pågående. När arbetsuppgifterna var färdigställda flyttades de till Redo för testning för att antingen kunna väljas av en annan grupp att testa eller för att testas av samma grupp som skrivit koden. Processen för testning skiftade under projektets gång. När testningen slutförts fördes uppgiften till sist till Arkiv. De icke programmatiska uppgifter följde samma flöde med undantag för kategorin Redo för testning som inte användes.
Skillnaden mellan sprintarna var att i den första sprinten användes en kanban-tavla utveck-lad av en gruppmedlem, men från den andra sprinten och framåt användes Trello [24]. Dessutom varierade antalet kategorier, men de ovan beskrivna fanns alltid med.
Atom
Som utvecklingsmiljö valdes texteditorn Atom [25] efter jämförelse med den integrerade utvecklingsmiljön WebStorm [26]. Till Atom har en mängd insticksprogram installerats för att kunna rätta de språk som behandlats i projektet. De insticksprogram som rekommenderats av utvecklingsledaren för utveckling med TypeScript och HTML kan ses i tabell 4.1.
Tabell 4.1: Insticksprogram till Atom
Insticksprogram Version Syfte
angularjs 0.4.0 Rätta AngularJS-grammatik atom-typescript 10.1.13 Känna igen/bygga TypeScript
emmet 2.4.3 Kortkommandostöd för HTML
linter 1.11.21 Krävs av de grammatiska insticksprogrammen linter-jshint 3.0.2 Rätta JavaScript-grammatik
4.2.4
Testning
Under en stor del av projektet har tester skrivits på olika nivåer. Tester har utförts för att säkertställa att koden har den kvalitet som gruppen önskade när produkten väl skulle över-lämnas till kunden. Testerna som utfördes delades in i tre nivåer:
• Enhetstester som syftar till att testa individuella funktioner eller moduler i koden. En-hetstester ska säkerställa att mindre bitar av ett system fungerar. [27]
• Integrationstester är till för att testa hur olika funktioner eller moduler fungerar till-sammans. Denna typ av tester ser till att diverse gränssnitt och sammankopplingar i systemet fungerar. [27]
• Systemstester är de tester som testar hela systemet. Syftet med dessa tester är att bedöma status på hela systemet. [27]
Efter det att ett test utförts på någon av de tre nivåerna har resultaten dokumenterats. Detta för att kunna se vilka, om några, fel eller buggar som hittades. Testning tas upp vidare i avsnitt F.
4.2. Utvecklingsfas
4.2.5
Versionshantering
I detta projekt användes versionshanteringsverktyget Git [28] och den greningsmodell som följdes kallas ”GitHub Flow” [29]. Denna modell är uppdelad i följande steg, se även figur 4.1:
1. Skapa en gren 2. Utveckla grenen 3. Få feedback 4. Diskutera och testa 5. Integrera till huvudgrenen
Tanken var att allt som låg på huvudgrenen skulle vara testat och fungerande, samt vara levererbart till kund.
Figur 4.1: GitHub Flow
4.2.6
Kundkontakt
Under hela projektet hölls kontinuerlig kontakt med kunden, främst via e-post. Detta för att tillgodose dennes intresse av att se i vilken riktning produkten strävade under utvecklingen. Kontakten underlättade också verifikationen av systemet, att få kundens och projektgrup-pens bild av systemet att konvergera samt att besvara frågor om det redan existerade systemet. Med denna praxis kunde missförstånd lätt fångas upp och var av särskild vikt i början av utvecklingsfasen.
Utöver detta hölls ett sprintgranskningsmöte i slutet på varje sprint för att stämma av hur långt projektet hade kommit. Dessa möten användes även för att demonstrera inkrementet och ta upp problem eller frågor som inte hade förmedlats via e-post.
4.2.7
Metod för att fånga erfarenheter
Varje sprint avslutades med att hålla ett möte för att gemensamt samla erfarenheter från sprinten och se vad som bör göras annorlunda till nästa sprint. Detta möte, som kallas sprintåterblick, var en utvärdering där alla gruppmedlemmar gavs chansen att lyfta fram vad de tyckte var bra och mindre bra under den senaste sprinten. Dessa möten såg likadana ut genom hela utvecklingsfasen.
Sprintåterblicken följde alltid samma protokoll. Vad som varit framgångsrikt och vad som skapat problem i sprinten identifierades med avseende på personer, relationer, processer och verktyg [17]. Därefter skapades en plan för att hantera det som gått dåligt, och bevara det som fungerat bra. Planen kunde sedan appliceras på efterföljande sprintar. Vid varje sprintåterblick så dokumenterades det som togs upp i ett mötesprotokoll
Mot slutet av projektet genomfördes en större utvärdering för att fånga upp alla medlem-marnas tankar och åsikter. Ett möte ägde rum där alla deltog och fick besvara frågor som
4.2. Utvecklingsfas
berörde hela projekttiden. För att allas röster skulle bli hörda valdes ett tillvägagångsätt som innebar att talan gick från person till person, hela varvet runt, tills alla hade fått säga sitt i den specifika frågan. Varje punkt diskuterades utifrån frågorna; vad har varit bra? Vad har varit mindre bra? Vad kan förbättras?
5
Resultat
I detta kapitel beskrivs resultaten från projektet. Hur implementationen av produkten kunde ge värde för kunden förklaras, gruppens gemensamma erfarenheter behandlas och systemet beskrivs på olika nivåer. Därtill beskrivs hur Scrum har anpassats för detta projekt samt ges en kort introduktion till varje gruppmedlems individuella bidrag.
5.1
Värde för kund
Eftersom kunden ville ha en produkt som var tänkt att utöka ett redan befintligt system, samt ha möjlighet till vidareutveckling, skapades ett modulärt system. Det underlättar vid integration med det befintliga systemet och vidareutveckling av den framtagna produkten. För att denna produkt skulle ge möjligheter för vidareutveckling var kvalitet något som var viktigt under skapandet. Kodkvalitet har säkerställts genom både parprogrammering, kontinuerlig testning samt kommentering av all kod. Vidare upprättades en kontinuerlig kundkontakt under hela projektets gång. Detta för att återkommande kunna rapportera om projektets status samt se att utvecklingen gick åt det håll kunden önskade.
En användarmanual togs fram och överlämnades till kunden i samband med projektets avslut. I användarmanualen ingick en kom-igång med Flask samt dokumentation om vilken mjukvara som installerats på servern.
5.2
Gemensamma erfarenheter
Resultatet från utvärderingen över stora delar av projektet kan ses i bilaga H. Där finns en sammanställning av samtliga medlemmars tankar och åsikter som lyftes fram. Dokumentet är strukturerat efter de punkter som togs upp under utvärderingen.
5.3
Systembeskrivning
Följande kapitel beskriver det system som utvecklades av gruppen. En noggrann beskrivning av arkitekturen och hur den är uppdelad i moduler presenteras.
5.3. Systembeskrivning
5.3.1
Produktbeskrivning
Detta projekt beställdes av företaget WizCFO med målet att utveckla ny funktionalitet till tjänstplattformen Boardeaser, som WizCFO är underleverantör till. Denna plattform är en webbapplikation riktad åt bolagsledningar som automatiskt sammanställer data om ett bo-lags diverse företag. Detta för att ledningen ska kunna få en överskådlig blick över deras företag, som då ska underlätta när beslut ska fattas.
Syftet med detta projekt var i första hand att utöka denna funktionalitet med möjligheten att jämföra ens företag med konkurrenters företag. Något som försvåras av att man inte lika enkelt kan komma åt data som hör till företag utanför ens egen koncern. För att lösa detta är produkten Complyzer tänkt att integrera med Bisnode, en tjänst som sammanställer all tillgänglig offentlig företagsdata och gör den sökbar för sina kunder.
Bisnode gör sina tjänster tillgängliga via ett API och implementationen av anropen till detta API var ett av projektets huvudsakliga mål. För att förenkla hanteringen av data skulle data som hämtats från Bisnode mellanlagras på kundens egna servrar. Detta för att få mer kontroll över den data som hämtats och inte behöva anropa en tredje part varje gång. Detta system kallas i det här dokument helt enkelt för WizCFO och tar formen av ytterligare ett API. Förutom dessa definitioner om var data skulle hämtas ifrån och lagras var en annan viktig detalj från kundens sida att göra den grafiska delen av systemet, där data presenteras pedagogiskt och överskådligt för användare.
Beskrivningen av alla systemets funktionaliteter sammanfattades i en systemanatomi, se figur 5.1.
5.3. Systembeskrivning
5.3. Systembeskrivning
5.3.2
Helhetsbeskrivning
Systemet tar formen av en webbserver som är tänkt att agera dels som en brygga mellan Bisnodes och WizCFOs API:er, och eventuella andra API:er som behöver läggas till i framti-den, samt tillhandahålla de tjänster gruppen utvecklat. Servern är alltså tänkt att automatiskt uppdatera WizCFOs servrar med relevant information från Bisnode i takt med att denna blir tillgänglig. Men också låta utomstående användare ta del av denna information genom att skapa ett användargränssnitt i form av en serie hemsidor som visas för serverns besökare. I figur 5.2 visas en översiktsbild över systemet, där pilarnas riktning visar det huvudsakliga informationsflödet från API:erna.
Figur 5.2: Representation av systemet i sin helhet.
5.3.3
Implementationsdetaljer
Servern är i huvudsak implementerad med hjälp av det Python-baserade ramverket Flask vilket tillsammans med bibliotektet Requests hanterar alla lågnivådetaljer som berör nätverk-sanrop. Detta innebär i praktiken att projektet kunnat fokusera på att implementera anropen till de olika API:erna, översättningen av data mellan de olika formaten de förväntat sig, samt att designa och implementera de delar av de hemsidor som kommer visas för systemets an-vändare.
5.3.4
Moduler
För att förenkla utvecklingen av systemet valdes det tidigt att använda en modulär mod-ell där programmet kunde delas upp i ett antal mindre delar. Detta ledde till en naturlig uppdelning av arbetsuppgifter och risken för att uppgifter skulle krocka med varandra min-imerades. Vidare innebar det att man enkelt kunde byta ut delar av mjukvaran om till exem-pel projektets förutsättningar förändrades. I figur 5.2 visas de olika modulerna som bygger
5.4. Anpassning av Scrum till ett agilt småskaligt mjukvaruprojekt
upp webbservern samt hur de kommunicerar med varandra. Nedan följer en mer utförlig beskrivning av vad de olika modulerna har för uppgift:
• API-modul för Bisnode samlar alla implementationer av anrop till Bisnodes API samt hanterar översättning av denna data till en form som enklare kan hanteras av resten av systemet.
• API-modul för WizCFO implementerar de anrop som krävs för att kommunicera med WizCFO-servrarna. Den huvudsakliga modulen för hämtning och lagring av data, till och från systemets användare.
• Affärslogikmodulen är ett mellanlager mellan WizCFO-modulen och visualiser-ingsmodulen. Den ansvarar för att rätt data skickas på rätt sätt mellan de två delarna av systemet.
• Visualiseringsmodulen hanterar skapandet av grafer, menyer och andra grafiska ele-ment som visas för systemets användare i deras webbläsare. Via dessa användargränss-nitt är det dessutom tänkt att ta emot användardata som skickas tillbaka till WizCFO-modulen för att sparas undan.
• Servern kontrollerar alla de andra modulerna och gör att systemet kan anropas via internet. Denna modul implementerar i sig ett tredje API som används för att göra serverns funktioner tillgängliga för användare på ett kontrollerat sätt.
5.4
Anpassning av Scrum till ett agilt småskaligt mjukvaruprojekt
Scrum har ett antal riktlinjer och processer som ska följas för att nyttja projektstyrningsme-todiken som det är tänkt. Följande är de artefakter och processer som använts och modifier-ats:
• En produktbacklogg producerades i början av projektet, utgående från kravspecifika-tionen som tidigare verifierats av kunden.
• En sprintbacklogg togs fram för varje sprint. Denna utgick från kravspecifikationen mer än produktbackloggen. I princip inga användarberättelser användes, utan istäl-let undersöktes de krav som hade högst prioritet för att skapa uppgifter i sprintback-loggen.
• Sprintplaneringen finns beskriven i kapitel 3.3.2 och hölls i början av varje ny sprint. Det som är viktigt att poängtera här är återigen att kravspecifikationen oftare stod i cen-trum än produktbackloggen vid val av uppgifter inför kommande sprint, vilket gjorde att utgångspunkten var krav och inte användarberättelser.
• Dagliga scrummöten hölls inte dagligen. De hölls i genomsnitt varannan dag, mer i behov än som en rutin. Att ha dagliga möten var dock inplanerat i varje sprint och fanns med på gruppens kanban-tavla.
• Sprintgranskningen hölls alltid i slutet av andra veckan i varje tvåveckorssprint, se kapitel 3.3.2. Ibland kunde inte en demo med ny funktionalitet färdigställas för kunden att inspektera, men då levererades istället status över vilken funktionalitet som imple-menterats och vad nästa målsättning var.
5.5. Översikt över individuella bidrag
Utöver detta har alla individer i utvecklingsteamet haft roller utöver de angivna i Scrum. Dessa inkluderar till exempel projektledare, testledare och dokumentansvarig. Det gjorde att visst ansvar tillföll de olika rollerna, istället för att alla i gruppen hade lika stort ansvar för allting.
Även en av Scrums grundpelare, transparens, efterlevdes genom de processer som beskrevs tidigare. Detta genom att låta alla i gruppen ha tillgång till all kod och alla aktiva grenar genom att dela en gemensam datakatalog, där alla gruppmedlemmar fritt kunde se över projektet under utveckling. Mötesprotokoll fanns sparade i webbapplikationen RunY-ourMeeting [30] där alla kunde logga in och läsa igenom vad som beslutats på alla möten som uträttats i gruppen. Alla dokument som skrevs fanns också tillgängliga för alla i grup-pen via webbapplikationen ShareLaTeX [31]. E-post med viktig information från handledare, kursansvarig och kund vidarebefordrades också ut till alla medlemmar i projektet.
5.4.1
Modifieringar av Scrum
De större modifieringar som gjordes av Scrum, inkludering av parprogrammering och Kanban-tavla, upplevdes enligt undersökningen i appendix H som något positivt av arbets-gruppen. Parprogrammering upplevdes som något som eliminerade småfel och gjorde det lättare att arbeta då det var lättare att hålla fokus när man inte arbetade ensam. Parprogram-mering gjorde även så att kunskap spreds inom gruppen och det därmed nästan alltid fanns någon på plats som var insatt i en specifikt del av systemet. Kanban-tavlan skapade struk-tur i arbetsgruppen eftersom det var lätt att se vad som det fanns att arbeta med, vem som arbetade med vad, och hur lång tid olika uppgifter hade tagit.
5.5
Översikt över individuella bidrag
Nedan följer en kort sammanfattning av respektive gruppmedlems individuella bidrag. A Adam Combler: En studie av tidsuppskattningsmetodik i ett agilt, småskaligt
mjuk-varuprojekt
I ett agilt mjukvaruprojekt kommer varje iteration att behöva planeras. Hur denna planer-ing står sig mot den verkliga tidsåtgången och hur planerplaner-ingen kan förbättras studeras i detta avsnitt. Från studien framgår det främst att det är möjligt att få en hög andel avklarade uppgifter av de planerade vid sprintens slut. Detta med hjälp av de i studien använda metodikerna och verktygen, som planeringspoker, ansvar för Kanban-tavla och användandet av en hjälplista.
B Philip Friberg: Kundens inverkan på ett agilt mjukvaruprojekt
I detta avsnitt behandlas hur man går till väga med kundkommunikation i ett agilt varuprojekt samt vilken roll kunden har i förhållande till utvecklarna i ett agilt mjuk-varuprojekt. Med hjälp av jämförelser mellan teori och erfarenheter från projektet framgår det att utvecklarna och kunden bör befinna sig på samma plats för fysiska möten, det krävs även en hel del tid från kundens sida för att arbeta med agila utvecklare. Det viktigaste är att båda parterna kan vara flexibla annars kan inte arbetet fungera agilt.
C Jani Jokinen: Fysiska eller nätbaserade möten i vår digitala värld?
Kommunikation är ett kraftfullt redskap som används dagligen. Detta avsnitt kommer att ge en inblick i vilka kommunikationskanaler används av studenter, samt vilka för och nackdelar det finns med de.
D Elin Larsson: Dokumenthantering i ett småskaligt mjukvaruprojekt med agil utveck-lingsmetodik
5.5. Översikt över individuella bidrag
inom en projektgrupp kan hantera och producera dokument agilt samt vilket värde de framtagna dokumenten får. Resultatet visar följande nyckelpunkter för dokumenthanter-ing; fördela arbetat mellan alla gruppmedlemmar, inför en granskningsprocess, genomför regelbundet dokumentmöten samt sätt upp interna deadline. Vidare framkommer det att kravspecifikationen och arkitekturdokumentet får ett högt värde för gruppen och kunden. E Erik Mansén: REST och SOAP, en jämförelse av webbtjänsters uppbyggnad
Detta avsnitt behandlar fenomenen REST och SOAP, de två huvudsakliga metoderna för API-implementation. Det finns mycket att vinna på att förstå skillnaderna mellan dessa, så att man kan göra rätt beslut i valet mellan dem. Studien finner att enklare system i längden vinner över mer avancerade sådana, då avancerade system ofta innebär en större ansträngning för att hantera egenskaper man i slutändan inte har behov av.
F Tobias Martinsson: Undersökning av metod för testning och enhetstesters betydelse vid parprogrammering
I detta avnsnitt behandlas det hur parprogrammering påverkar enhetstester samt för- och nackdelar med att testa sin egen och testa andras kod. I undersökningen visas det att parprogrammering fungerar bra för småskaliga projekt och minskar antalet mindre fel i koden. Det visas även att testa kod skriven av någon annan kan vara väldigt gynnsamt för mindre projekt.
G Albin Pettersson: Effekten av versionshantering på projekt och val av versionshanter-ingsverktyg
Inget projekt kan få perfekt kod på första försöket och därför är versionshantering ett väldigt effektivt hjälpmedel för att underlätta utvecklingen av projekt. Men hur stor ef-fekt har det egentligen på ett projekt och vilket versionshanteringsverktyg ska man an-vända? Detta avsnitt undersöker just dessa punkter och visar vilka för- och nackdelar versionshantering har samt vilka olika egenskaper som är viktigast för ett versionshanter-ingsverktyg.
6
Diskussion
I detta kapitel behandlas lärdomar och vad som hade kunnat göras annorlunda i projek-tet. Diskussion kring hur den framtagna produkten kunde skapa värde för kund, gruppens gemensamma erfarenheter samt hur det är att arbeta med en systemanatomi tas upp. Resone-mang kring hur man kan säkerställa integration av separat utvecklade moduler och hur Scrum har anpassats till detta projekt behandlas. Även hur produkten spelar in på hållbar utveckling och hur detta hade kunnat påverka skapandet av kravspecifikation presenteras.
6.1
Värde för kunden
Något som hade kunnat förändras i projektet, och möjligtvis skapat samma värde för kun-den, är hur koden granskades. Exempelvis hade en metod som over-the-shoulder review (sv: över-axel-granskning ) kunnat användas istället för parprogrammering. Metoden går ut på att en utvecklare visar sin kod för en annan utvecklare och förklarar tanken bakom den efter att en arbetsuppgift är avklarad [32]. Det hade kunnat skapa värde för kunden på ett annat sätt än vad parprogrammering gjorde.
Över-axel-granskning istället för parprogrammering ger möjligheten att arbeta på flera arbetsuppgifter samtidigt. Det medför att kunden kan få mer värde från produkten med avseende på hur mycket som utvecklats. Fördelen med parprogrammering är att kunskap delas inom gruppen, koden granskas direkt samt, i bästa fall, får hög kvalitet samtidigt som den skrivs [22]. Enligt en studie av Cockburn och Williams kan antalet buggar minska med upp till 15 procent då parprogrammering används [23].
Även om detta alternativa sätt hade gjort att fler saker hade utvecklats samtidigt är det inte säkert att det hade bidragit till en bättre produkt och arbetsklimat. Enligt utvärderingen, som hittas i appendix H, upplevde flertalet i projektgruppen att arbeta i par som något pos-itivt. Därför var parprogrammering att föredra för denna arbetsgrupp istället för att jobba själva.
6.2. Gemensamma erfarenheter
6.2
Gemensamma erfarenheter
Ett alternativ till det möte som ägde rum där den stora utvärderingen genomfördes hade varit att dela upp det i två möten. Mötet blev långt, uppemot tre timmar, och tiden hade istället kunnat fördelats på två olika tillfällen. Detta hade kunnat medföra att alla deltagare hade känt fullt fokus under hela utvärderingen och inte känt någon stress för att hinna igenom de avslutande punkterna.
Tillvägagångssättet som tillämpades för att få fram allas åsikter kan ha lett till att alla inte vågat säga vad de tyckte. Ingen var anonym eftersom allas åsikter kom fram muntligt inför hela gruppen. En annan metod som hade kunnat applicerats hade varit att varje per-son skrivit ner sina tankar och åsikter på en lapp, helt anonymt. Dessa lappar kunde sen ha lästs upp inför gruppen för att skapa möjlighet till en diskussion, eller enbart förts in i sammanställningen över utvärderingen.
Dagen innan mötet skulle äga rum skickades en agenda ut, till alla projektmedlemmar, där de punkter som skulle tas upp fanns med. Dessa punkter kunde istället ha tagits fram genom samarbete i hela gruppen. Till exempel om alla, var för sig, funderat vilka punkter de tyckt varit viktiga att ha med och sen förmedlat det till en person i gruppen som gjort en sammanställning. På så vis kanske fler punkter hade tagits upp under utvärderingen samt att alla fått mer tid på sig att fundera igenom vilka tankar och åsikter de vill lyfta upp under mötet.
6.3
Arbete kring en systemanatomi
Att ta fram systemanatomin, som visas i figur 5.1, gemensamt av gruppen i projektets start var ett steg i processen till att få gruppens och kundens bild av systemet att konvergera. Detta eftersom systemanatomin beskriver systemets olika funktionaliteter och dess relationer till varandra. För att konstruera systemanatomin hölls därför ett möte, beskrivet i kapitel 4.1. Eftersom kunden befann sig på annan ort, och hade begränsat med tid, valdes detta möte att hållas internt i gruppen. Hade kunden närvarat hade oklarheter kring systemet kunnat redas ut fortare, då frågor mellan gruppen och kunden direkt hade kunnat besvaras. I detta projekt hade kunden dock sammanställt sina mycket tydliga önskemål om vad som skulle utföras, både i textform och under tidigare möte, vilket underlättade konstruktionen av anatomin. Dessutom hade initiala krav sammanställts och verifierats av kunden vilket ökade förståelsen av systemet ytterligare.
När systemanatomin var klar verifierades den av kunden. Systemanatomin visade sig inte vara en tillräckligt vedertagen beskrivning av ett system för att direkt kunna appliceras på den verkliga industrin. Kunden fick skicka vidare den till tekniskt ansvariga som försökte tolka representationen av systemet. Eftersom kontakt mellan kund och projektgrupp endast upprätthölls via e-post i detta skede blev det mest förvirring om vad det var som skulle utläsas. Kunden önskade istället en designskiss över systemet. För att använda sig av denna typ av beskrivning i framtiden är det viktigt att vara säker på att båda parter förstår innebör-den av anatomin, och att en orinnebör-dentlig beskrivning ges.
Det som är fördelaktigt med systemanatomin är att den inte beskriver så mycket om hur sys-temet ska realiseras, utan mer dess funktionaliteter och relationerna mellan dem. Det gjorde att anatomin kunde tas fram tidigt, i jämförelse med till exempel en designskiss. Dessutom stod sig systemanatomin genom hela projektet, och behövde inte modifieras speciellt mycket, även om implementationen av systemet ändrades.
