Utvecklandet av webbapplikationen har givit mig användbara erfarenheter, både när det gäller det tekniska och det processrelaterade. Jag upplever att arbetet varit väldigt givande och motiverande vilket har lett till stor individuell utveckling.
18.1 Tekniska erfarenheter
Utvecklingen av single-‐page implementerades sent i utvecklingen. Teamet missförstod från början konceptet single-‐page och när detta klarnade var utvecklandet av applikationen redan igång. Utvecklandet av single-‐page bortprioriterades därför under sprint 1 då teamet ansåg det viktigare att avsluta påbörjade funktioner. Resultatet av detta blev en mycket rörigare kod samt att jag utvecklade en mindre förståelse för AJAX och JavaScript än önskat. Efter att ha sett andra teams lösningar av single-‐page blev det tydligt att vi förlorade mycket kunskap kring Jason, JavaScript och AJAX som hade kunnat göra applikationen mycket mer användarvänlig och snabb, något som jag anser är värdefull kunskap inför framtidens webbutveckling. Däremot resulterade bortprioriteringen av single-‐page att mer tid lades på utvecklandet av funktionerna vilket istället gav mig en stor förståelse för python och HTML. Detta anser jag också vara viktiga kunskaper då applikationen även måste bestå av funktioner som användaren kan se, och inte bara optimera dess smidighet, något som användaren inte lägger märke till om applikationen inte är avsevärt långsam.
En bra balans av prioriteringen mellan single-‐page och funktionalitet hade varit optimalt för att maximera språkinlärningen. Bästa sättet för oss att ha uppnått det hade därför varit att tagit tag och frågat/googlat om information kring single-‐page så att vi direkt vid utvecklingens start utvecklade applikationen som en sådan. Med den kunskap jag har idag skulle samma uppgift kunna göras om fast mycket effektivare. Jag hade idag utnyttjat mycket fler JavaScripts och JSON för att göra applikationen snabbare. Jag hade även börjat med att designa applikationen som single-‐page, istället för att utveckla funktionerna först, och på så sätt få en stabilare kodning med endast relevant kod. På grund av den här erfarenheten kommer detta tänkas på redan från början.
I början av projektet saknade teamet förkunskaper gällande versionshantering via GitLab. Detta ledde till stora problem med hanteringen av GitLab vilket gjorde att det tog längre tid än väntat för teamet att påbörja arbetet. Efter att ett möte bokades med teknisksupport löste sig problemen för vissa medlemmar. Andra hade dock fortfarande problem med puchning och pullning trots att de använde de metoder som bör användas. Detta är ett problem jag inte stött på då GitLab fungerade smidigt för mig efter mötet med teknisk support. Resultatet av detta var att jag kontinuerligt kunde ladda upp/ner kod vilket gjorde mig bekväm i mitt programmerande. Däremot innebar detta att senaste versionen inte alltid fanns tillgänglig på GitLab, då alla medlemmar inte kunde pucha och teamet förlorade delar av helhetsbilden på projektets arbete. GitLab kunde därmed inte erbjuda teamet full funktionalitet och onödigt tid lades på att sammanfoga övrig kod via mail. Jag anser dock att jag utvecklade tillräcklig kunskap kring GitLab då programvaran fungerade bra för mig och att jag smidigt skulle kunna använda GitLab igen. Däremot hade det ökat min
kunskap om teamet fick svar på varför programvaran fungerade bättre för vissa och inte alls för andra. Därför bör teamet tillsammans ha bokat ett nytt möte med teknisk support för svar. Därmed skulle även min kunskap kring GitLab öka och jag skulle veta hur jag skulle hantera programvaran om samma problem händer mig.
Mitt personliga tekniska mål var att utveckla min kompetens kring webbutveckling tillräckligt för att kunna utveckla en applikation självständigt. Detta mål anser jag att jag uppfyllt väl med de erfarenheter som projektet givit och jag har utvecklat ett stort intresse för webbutveckling.
18.2 Processrelaterade erfarenheter
Scrum var vid projektets start ett främmande och annorlunda arbetssätt som gjorde mig skeptisk gällande vissa av dess beståndsdelar. Jag ansåg dessa vara ett sidospår till framtagandet av e-‐butiken. Detta gällde främst sprint retrospektivet som teamet utförde i slutet av varje sprint. Teamets första sprint retrospektiv i slutet av sprint 0 kändes påtvingat, onödig och löjligt. Flertal av de frågor som skulle besvaras påminde om varandra och processen upplevdes repetitiv. När retrospektivtet var avslutat blev det dock tydligt att teamet ändå fått ihop många viktiga förbättringsförslag inför kommande sprint.
Efter att ha upplevt retrospektiven och personligen sett resultaten den frambringar blev dess fördelar mycket tydligare. Upplevelsen gav mig en större förståelse kring arbetssättet och jag förstår nu att arbetsprocessen är minst en lika stor del i arbetet som själva utvecklandet av produkten. Om teamet valt att inte utföra retrospektiven bara för att de från början kändes löjliga hade många förbättringsförslag och åsikter inom teamet gått skymda. T.ex. hade teamet aldrig infört demonstrationsmöten, ett förbättringsförslag som framkom i samband med retrospektivet efter sprint 1, och därmed hade möjligheten att kontinuerligt demonstrera utvecklade funktioner för teammedlemmarna inte funnits. Teamet hade då gått miste om möjligheten till att ge feedback till specifika funktioner och integrationen mellan funktionaliteten hade inte varit lika bra. Även gruppdynamiken hade påverkats negativt då dessa möten alltid belyste åtgärder för att förbättra denna.
Retrospektiven är en metod som jag gärna vill använda i framtiden. Det gäller även inom arbeten som inte använder metodiken Scrum. Detta för att jag anser att det är viktigt med stark teamdynamik oavsett arbetsmetod. Jag upplever dock att en anonym rösning gällande hur nöjd medlemmen känner sig med teamet samt en anonym förklarning om betyget 2 eller lägre ges hade gjort mötet mer effektiv då blyghet kan förekomma inom teamet. Detta för att det finns risker att dominerande personligheter kan tysta ner recessiva åsikter eller att en social omgivning påverkar individens betyg. Det kan vara väldigt känsligt att ge ett lägre betyg om övriga medlemmar ger ett högt. (27)
Under projektets gång har arbetet med individuella ansvarområden fungerat bra. En av styrkorna som teamet haft är att vi för det mesta suttit tillsammans och utvecklat. Detta har givit möjligheten till snabb input och direkt feedback från andra medlemmar i teamet, vilket har fungerat som bra stöd för mig. Däremot
programmerar jag personligen effektivast i bekväma miljöer, så som hemma, och därför har utvecklandet i grupp inneburit att jag ibland inte varit lika effektiv som jag önskat. Dock innebär hemarbete att hjälp från teammedelemmar kan ta lång tid över internet då programmering är enklast att förklara fysiskt. Detta innebär att tidsödslandet blir lika i båda fallen. Dessutom bidrar nära teamarbete till bättre teamdynamik och ett enhetligare och integrerat arbete.
Personligen hade en balanserad kombination av att sitta tillsammans och arbeta självständigt varit optimalt. Detta är dock något som är individuellt och det är därför svårt att kunna anpassa en hel grupp efter. Teamet löste detta genom att planera att sitta tillsammans varje dag men att detta inte var obligatoriskt. En lösning som jag anser vara välanpassad efter olika preferenser och som kan tas med i framtida webbutvecklingsprojekt.
Teamindelningen inför detta projekt skedde slumpvis, något som var nytt för mig. Jag har tidigare endast utfört arbeten med självvalda team vilket ofta lett till automatisk stabil och positiv gruppdynamik, då man ofta väljer att arbeta med personer man känner bra. Däremot finns den möjligheten sällan på en arbetsplats. Därför anser jag att det är viktigt att lära sig samarbeta och arbeta med personer som man möjligen inte känner, och därför inte är lika bekväm med. Detta är nödvändiga erfarenheter som förbereder inför framtida arbeten och projekt. Självvalda team utvecklas inte heller på samma sätt och bekvämligheten kan göra arbetet oseriöst. Det har därför varit lärorikt att få uppleva utvecklingen av ett slumpvist vald team.
Eftersom jag tidigare inte arbetat med Scrum hade jag inga personliga processrelaterade mål till en början. Under projektets gång utvecklades däremot en nyfiken. Jag ansåg det intressant att se om Scrum bidrar till bättre arbete och kommunikation, vilket var något som jag började studera under projektets gång. Jag blev positivt överraskad främst över Daily Scrum och dess effekt på kommunikationsvägarna. Främst för att jag under sprint 0 ansåg det, tillsammans med resten av metodiken, vara onödigt omständlig. Det blev dock tydligare under sprint 1, då utvecklingen påbörjades, att detta var nödvändigt för att övriga medlemmar ska få en klarhet och överblick i hur utvecklandet går. Utan Daily Scrum hade aldrig lika många funktioner blivit implementerade då jag är övertygad om att mycket av det som hade utvecklats inte skulle gå att integrera med övriga funktioner på grund av dåligt kontinuerlig kommunikation. Efter att ha arbetat med Scrum är det tydligt hur stor påverkan kommunikationen har på arbetet, något som jag har lärt mig under detta arbete. Detta gör mig motiverad till att i framtiden arbeta enligt Scrum igen.