I denna sammanfattning så kommer jag att ta upp mina tankar och åsikter om det projektarbete som jag har varit delaktig i.
Scrum
Inledningsvis var jag orolig för hur arbetsmetoden skulle fungera, vilket är naturligt när man stöter på något som man inte känner igen tidigare. Det krävdes relativt mycket arbete att sätta sig in i och förstår hur man skall arbeta med Scrum.
Jag insåg dock relativt tidigt att arbetssättet var uppbyggt på ett sätt som jag gillade. Konceptet med att tydligt rada upp vilka arbetsuppgifter som bör genomföras efter en rankade ordning var något som föll mig i smaken. Ju tydligare arbetsuppgifterna är utformade, desto lättare brukar de bli att genomföra. De dagliga möten kändes också som något nyttigt i denna typ utav utveckling, då jag kände att en uppdaterad, övergripande förståelse för applikationen var väsentlig för att kunna utveckla funktionalitet.
Arbetsmodellen innehåll vissa delar som jag upplevde som svårare att ha kontroll och uppfattning om. Att uppskatta tidsåtgången för användarberättelser, som var nyckeln för att kunna strukturera hur kommande sprint skulle komma att se ut, var väldigt svårt. Vid projektets start så hade många i gruppen ingen tidigare erfarenhet av webbutveckling, och därmed kändes det orimligt svårt att uppskatta hur lång tid det skulle ta att utveckla en viss funktionalitet. Problemet blev inte heller nödvändigtvis lättare i takt med att projektet mognade, utan det var alltid stora svårigheter att bedöma vad som kunde genomföras under en sprint.
Grupprocess
Tidigt i projektarbetet så kändes det som att gruppen att kommit in i ett bra stadie vad gällde gruppdynamiken. Gruppmedlemmarna kändes samarbetsvilliga och alla hade ett driv till att vilja genomföra arbetet. Förutsättningarna var goda för ett väl genomfört arbete.
Redan under sprint 1 så började det bli tydligt att någonting inte var rätt i gruppen.
Arbetsfördelningen hade blivit orimligt ojämn, vilket tydligt framgick av tidsrapporteringen. Projektet drevs mer eller mindre framåt av tre gruppmedlemmar, däribland vara jag en av dessa. Vi försökte lyfta problemet inom gruppen under lång tid, men det var ofta fruktlöst. För mig personligen kändes hela den situation både irriterande och jobbig, och jag vet att de andra två som lade ner tid på arbetet kände samma sak. I takt med att projektet fortskred och ingen större skillnad märktes så övergick känslorna från ångest till rent accepterande, och vi valde att bara köra vidare med vårt egna race. Det kändes väldigt dumt och konstigt att bara välja att jobba vidare som om inget hade hänt, men vi det stadiet så hade vi gett upp med att försöka tvinga folk till att göra saker. Vi som drev vidare projektet hade tappat tillit till resterande delen av gruppen, och troligen så hade de gruppmedlemmarna tappat förtroende för oss också då vi bara körde på.
Jag tror att denna situation mer eller mindre bara har påverkat alla gruppmedlemmar negativt. Vi som grupp gled isär ifrån varann. Det byggdes upp irritationer mot människor, något som inte är nyttigt för en grupp som borde arbeta tillsammans för att nå ett resultat. Och just resultatet tror jag till stor del också kan ha blivit lidande, då man skulle kunnat utveckla mer funktionalitet och genomför bättre testning om man varit fler som aktivt arbetade.
Såhär i efterhand så tror jag det finns ett antal olika punkter där det brast för gruppen. Till och börja med tror jag att de förväntningarna som gruppen hade på projektet och på slutresultatet var helt olika. Vissa förväntade sig att vi som grupp skulle satsa hårt på utveckling, och att försöka skapa en väl fungerande produkt tidigt. Andra kände nog att de hellre att prioriterade annat under arbetes början och var därmed inte benägna att lägga ner samma tid på projektet. Jag tror också att vi som drivande individer i projektet gjorde fel i att jobba mer självständigt från resterande gruppmedlemmar. Att isolera sig på det sättet tror jag inte bringar något positivt till någon del av grupperna, utan förstärker bara känslorna som man kände för
varandra. Det resulterade också i ett massivt kunskapsgap gällande webbutveckling mellan de två uppdelningarna. Då ena gruppen kontinuerligt jobbade och utvecklade applikationen så blev arbetet mer och mer komplicerat och oförståeligt för den andra ”grupperingen”. När gruppen tillslut kom samman och började att utveckla mer tillsammans så var det mycket kunskap som behövdes tas igen, och det gjorde att vi som grupp inte han utveckla allt det som vi ville får gjort.
Generellt så kan man fastslå att detta typ utav problem inte direkt är unikt för denna
projektgrupp. Olika uppfattningar om hur ett arbete skall se ut är ett vanligt problem, och ett som kan skapa stora problem för gruppen. Men det går inte att påpeka nog vikten av att alla är införstådda med vad som förväntas av gruppen. Konsekvensen av att inte noggrant definiera detta kan leda till osämja inom gruppen, likt den vi fick erfara, vilket i värsta fall kan leda till ett misslyckat projekt.
Lösningen till detta problem blev att vi tillslut fick kontakt examinatorn för detta projekt, som fick sätta sig med hela gruppen och noggrant reda ut vad det är som inte fungerar och hur folk vill åtgärda detta. Och just lösningen är nog det jag framförallt tar med mig från detta
problem, att man måste gå till botten med vad problematiken är och hur alla parter vill se en lösning. Också det faktum att man måste noggrant definiera vad som förväntas och se till att hela gruppen är med på det, för att undvika oklarheter inom gruppen.
Roller
Under projektets livstid så hade vi egentligen bara två roller inom gruppen, en Scrum Master och en merge/Openshift ansvarig. Scrum Master var ett krav som ställdes från examinatorn, samt att arbetsmetoden Scrum kräver att man har en Scrum master (Sutherland & Schwaber, 2013). Merge/Openshift ansvarig kom till då gruppen kände att en person skulle ha
huvudansvar för att kontrollera vad som skulle upp till Openshift, som en version hanterare helt enkelt. Mot slutet av projektet, när framförallt rapportskrivande var huvudfokus, så tilldelades olika grupperingar inom gruppen huvudområden som dessa skulle ha ansvar för. Det var något som fungerade väl, och just roller hade varit något som hade varit nyttigt att ha under utvecklingstiden.
Detta projektarbete har verkligen fått mig att utveckla min tekniska sida. Inledningsvis så var utvecklingen jobbig och plågsam, allting var nytt och det kändes omöjligt att få något gjort. Men i takt med att man skaffade lärdom om hur systemen fungerade så gick allt smidigare, och intresset väcktes. Det blev lättare att transformera något från ide till verklighet. Det fanns också en trygghet i att fler i gruppen följde ungefär samma utvecklingstakt, och därmed kunde man kommunicera problem mellan varandra och gemensamt finna lösningar. Jag har också fått upp ögonen för ett gäng tekniska verktyg som har varit nyttiga för utvecklingen. Trello har varit ovärderligt för att kunna strukturera upp vad som skall
kontinuerligt tar på sig nya arbetsuppgifter. Till en början var vi som grupp ganska dåliga med att använda verktyget, men när vi började komma igång så var det väldigt bra.
Också kommunikationsplattformen Slack har visat sig väldigt användbar. Att kunna dela upp kommunikationen baserat på kategori har varit fantastiskt, då man inte behöver leta igenom en massa onödig text när man letar efter något specifikt.
Det har också funnits en massa jobbiga tekniska områden som jag har fått arbeta igenom. När vi inom gruppen valde att refaktorera hela designen mot slutet av sprint 2 så hamnade jag i en roll som huvudansvarig, vilket betydde att jag fick spendera väldigt mycket tid med CSS och responsivitet. Just dessa två områden har varit riktigt frustrerande att jobba med, då det inte alltid har varit klart hur de olika komponenterna fungerar samt att det är mycket småfix på varje del. Men det har varit väldigt belönande att se det slutgiltiga resultatet av sitt arbete.
Inför projektstarten så satte jag ett antal personliga mål för mig själv som jag vill uppnå under projektets livstid. Framförallt så ville jag utveckla mina tekniska kunskaper så mycket som möjligt, och det tycker jag att jag har lyckats bra med. På grund av hur skev
arbetsfördelningen var under utvecklingen så har jag fått lägga mycket tid på att utveckla mina kunskaper, vilket har hjälpt mig mot mitt mål. Jag ville också lära mig om arbetssättet Scrum, vilket jag också anser att jag har lyckats med. Jag anser mig själv ha en god
uppfattning om hur man skall arbeta med Scrum, och tror att jag skulle kunna implementera detta i ett kommande projekt om det skulle vara passande.
Sutherland, J., & Schwaber, K. (Juli 2013). Scrum guides. Hämtat från