Under projektets gång har jag införskaffat mig många goda erfarenheter. Från att aldrig arbetat med arbetsmetodiken Scrum och aldrig utvecklat en webbapplikation förut har jag gått till att känna mig bekväm med arbetet inom gruppen. Jag har vågat ta ansvar och gett mig på problem som känts utmanande, något som lett till ett väldigt lärorikt projekt och jag har kunnat känna mig stolt över vad jag åstadkommit, både som del av ett team och som individ.
25.1 Tekniska erfarenheter
Mitt huvudansvar under programmerandet har varit kundkorgens funktionalitet. Eftersom detta är en ganska central del av applikationen så gjorde det att jag fått möjlighet att arbeta med de flesta språk och funktioner som använts på sidan, bland annat HTML, CSS, AJAX, Python, SQL och JavaScript. Detta har gjort att jag utvecklat en ganska bred kompetens och ofta behövt sätta mig in i de andra teammedlemmarnas kod och hjälpa till vid behov. Då har jag insett vikten av införandet av teamets riktlinjer för kommentering. Det gjorde att det blev lätt att få en överblick över vad funktionen gjorde och det blev därmed också enklare att navigera i koden.
En annan sak som gjorde det enklare att navigera i koden var införandet av separata JavaScript-‐filer, eftersom detta gjorde att varje fil inte innehöll lika mycket text. Detta var något som implementerades väldigt sent under projektets gång men som jag tycker borde gjorts från början. Då hade förmodligen problem som att samma jQuery-‐script laddades in flera gånger kunnat undvikas, något som skapade problem med viss funktionalitet och var tidskrävande att lösa.
Jag har även fått erfarenheter inom användning av olika utvecklingsprogram såsom GitLab och OpenShift. GitLab fungerade väldigt bra för mig och det var sällan jag hade några stora problem, till skillnad från flera andra i teamet. Det gjorde att jag kunde hjälpa andra teammedlemmar att lägga upp ny kod när deras GitLab inte fungerade, vilket skedde genom att de uppdaterade filerna skickades på mail och jag sedan manuellt fick lägga in den nya koden.
Jag var även den i teamet som hade ansvar för OpenShift vilket gjorde att jag fick erfarenheter av att ladda upp kod på en server samt att testa den ofta. Just testningen var något jag insåg vara viktigt under slutet av sprint 1. Då upptäcktes att all funktionalitet inte fungerade exakt som den skulle på OpenShift vilket ledde till att det blev ont om tid inför sprintinlämningen. Detta var något som åtgärdades inför sprint 2 då jag såg till att kontinuerligt testa all ny kod som skrevs genom att lägga upp den på OpenShift. Problem, såsom att användandet av Flask Mail gjorde att sidan kraschade, kunde då lösas i god tid genom antingen internet-‐resurser eller teknisk support.
25.2 Processrelaterade erfarenheter
En av de viktigaste sakerna jag fått erfarenhet av är att arbeta på ett så pass stort projekt, både till projektets omfattning och till antalet personer i teamet. Det har gett
en stor inblick i hur verkliga projekt skulle kunna fungera och hur viktigt det är med en tydlig struktur på arbetet. När så pass många personer arbetar med samma sak så behövs bland annat en välarbetad projektplan för att se till att ett gemensamt mål finns. Det måste även finnas en tydlig tidplan som gör att hela teamet är insatta i kommande deadlines. Om någon av alla dessa planeringsdokument saknas så finns det en risk att det kommer märkas av under projektets gång.
Ett exempel på detta är kommunikationsplanen som teamet kompletterade med i efterhand. Detta gjordes eftersom teamet tyckte att det ibland kunde vara svårt att veta vilken kanal som information skulle flöda genom, då teamet hade en SMS-‐grupp, en Facebook-‐grupp och en gemensam Google-‐Drive. Dessutom märktes att det fanns en brist på kommunikation till teammedlemmar som var frånvarande från ett möte. Därför bestämdes att en person skulle utses till sekreterare varje möte och skriva ner de viktigaste sakerna som togs upp för att sedan dela med sig av dokumentet på Google-‐Drive. Det var dock något som jag inte tyckte vi lyckades fullfölja fullt ut och det hände ofta att det glömdes att utse en sekreterare. Det hade förmodligen fungerat bättre att införa någon typ av rullande schema för att hålla reda på vem som skulle föra anteckningar varje möte eller eventuellt utse någon i teamet som alltid hade ansvar för detta.
Det var även en ny erfarenhet att arbeta så pass länge och nära med teammedlemmar på distans. Detta var något som jag i början var skeptisk till eftersom det kändes som om det kunde vara svårt att upprätthålla en bra kommunikation och att ha ett tätt samarbeta under projektets gång. Speciellt skeptiskt var jag till att redovisa tillsammans med någon på distans men blev positivt överraskad efter att ha fått prova på detta. Anledningen till att det fungerade bra var förmodligen tack vare att teamet valde att dela upp presentationen på mitten så att det inte blev så många byten av talare. Enda nackdelen enligt mig var att det var svårare att få fullständig delaktighet över Skype vid frågestunden. Detta berodde troligtvis på att det var en fördröjning i samtalet och jag eller någon annan i teamet hann påbörja ett svar innan personen på distans kunde höra frågan. Problemet hade förmodligen kunnat undvikas genom att ta hänsyn till denna fördröjning och ibland låta ordet gå över till personen på distans. Detta är något jag definitivt kommer tänka på inför liknande presentationer i framtiden.
Fördröjningen över Skype ledde även till problem under våra interna möten. Ibland kunde det kännas som om de som satt på distans hade svårt att vara delaktiga under vissa längre möten vilket gjorde att vi fick utveckla egna strategier för att kunna få ut så mycket som möjligt av dessa möten. Teamet valde därför att prova att ha vissa möten med hela teamet över Skype. Detta var dock något som inte visade sig vara lämpligt för längre möten eftersom det var svårt att föra långa diskussioner. Teamet valde trots det att fortsätta att hålla en del Daily Scrums över Skype eftersom dessa inte krävde lika mycket diskussion utan mest bestod av presentation.
I slutet av projektet tyckte jag dock att det fungerade bättre på mötena med medlemmar på distans då hela teamet fått mer vana av detta och hela tiden försökte visa hänsyn och bli tysta när någon på distans försökte säga något. Teamet försökte även att alltid ha en dagordning inför varje längre möte så att det gick att hela tiden
följa med på vilka punkter som togs upp. Tyvärr var detta något som, precis som mötesanteckningarna, ofta inte fullföljdes.
Jag har även fått mina första erfarenheter inom Scrum. Detta var en metod som jag inte ens hade hört talas om innan detta projekt drog igång. Jag tyckte metoden fungerade väldigt bra eftersom jag kände att teamet fick ett väldigt nära samarbete, mycket tack vare våra Daily Scrums. Dessutom kändes det som att dessa gav en bra översikt över vad alla i teamet gjorde, vilket skapade bättre diskussionsunderlag för våra längre möten.
Jag tyckte även att sprintretrospektiven utgjorde en bra diskussionsplattform för att gemensamt komma överens om vad som fungerat bra och mindre bra inom teamet. Det mest positiva med sprintretrospektiven var att dessa hölls kontinuerligt under projektets gång så att förbättringsförslag hann träda i kraft och påverka hur teamet arbetar, istället för att bara ha en utvärdering i slutet av projektet.
Mindre team kan även ha nytta av att experimentera med Scrum och applicera den variant av metoden som känns bäst (35). Detta var något vårt team gjorde när vi efter halva projektet insåg att det vore en bra idé att införa demonstrationsmöten, då alla teammedlemmar inte alltid hade koll på vad de andra gjorde på en mer detaljerad nivå. Trots att teamet inte hann hålla så många av dessa möten tycker jag att de gav en positiv effekt. Detta berodde främst på att teamet med egna ögon fick se vad som åstadkommits och vilka delar på sidan som blivit färdiga. Det gjorde även att det gick att ge varandra konstruktiv kritik direkt utan att behöva vänta på att mer detaljerad testning utförs. Hade dessa möten implementerats från början hade de förmodligen kunnat ge en ännu bättre effekt. Då hade många funktioner redan i ett tidigt skede kunnat granskas av teamet och förändringar kunnat göras utan att så mycket arbete gjorts i onödan. På så sätt kunde tid sparats till annat.
Som helhet var projektet väldigt givande och de lärdomar jag fått kändes både aktuella och användbara. Jag känner att jag kommit teamet väldigt nära och vi har kunnat hjälpa varandra och alla har kunnat dela med sig av sina egna kunskaper. I slutet av projektet har jag kunnat känna mig stolt över det jag åstadkommit och känna att jag utvecklats både som programmerare och som teammedlem.
På svenska
Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under en längre tid från publiceringsdatum under förutsättning att inga extra-‐ordinä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 det lösningar av teknisk och administrativ 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 sammanhang som är kränkande för upphovsmannens litterä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/
In English
The publishers will keep this document online on the Internet -‐ or its possible replacement -‐ for a considerable time from the date of publication barring exceptional circumstances.
The online availability of the document implies a permanent permission for anyone to read, to download, to print out single copies for your own use and to use it unchanged for any non-‐commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional on the consent 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 University 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/