gångarna fick gruppen hålla ett antal korta presentationer av vad varje delgrupp hade jobbat med under sprinten. Kunden påpekade att de hade förväntat sig en enda större presentation där gruppen skulle presentera ett enda system med delar som fungerade ihop. Kunden höll även med om att det var nästintill omöjligt att hinna klart med systemet innan slutdatumet. Kunden undrade då om projektgruppen hade funderat på mål de ville uppnå under den res- terande tiden. Projektgruppen besvarade kundens fundering med att målet som sattes inför den kommande sprinten var att integrera systemets delar med varandra.
5.6
Översikt över individuella bidrag
Varje gruppmedlem har, utöver att bidra till den gemensamma delen av denna rapport, gjort en individuell undersökning inom ett valt ämne. Dessa undersökningar utgör andra delen av detta dokument och presenteras nedan.
Scrum-utvecklingsmetodik för utveckling hos små team av Dawid Abucewicz
Detta kapitel undersöker skillnader som kan uppstå mellan den klassiska Scrum- utvecklingsmetodiken och den som används under kandidatprojekt. Fokus av undersök- ningen ligger på Scrums beståndsdelar som används av kandidatgrupper, samt hur olika Scrum-roller kan påverka utvecklingen. Huvudkällor för undersökningen är både litteratur- studie, enkät som distribuerades bland övriga kandidatgrupper och egna observationer av utvecklingen av detta projekt.
Kommunikationsverktyg i en mindre grupp av Frida Blomstedt
I detta kapitel undersöks hur kommunikationsverktyg kan användas i en grupp av samma storlek som den i detta projekt. Undersökningen utgår till stor del från hur de kommunika- tionsverktyg som har använts under detta projekt har upplevts av gruppen och vilka kom- munikationsverktyg som har använts mest. För att koppla erfarenheterna från detta projekt till en mer allmän slutsats har även en litteraturstudie gjorts.
Grön mjukvaruteknik av Nazir Elpustaty
I detta kapitel handlar undersökningen om hur energiförbrukningen mäts hos olika sorters mjukvaruprodukter. Dessutom, undersöks en studie som jämförde ett antal programmerings- språk med varandra för att reda på det mest miljövänliga av dem. I detta kapitel utfördes en litteraturstudie för att ta reda på data.
Automatisk testning och testning på distans av Edwin Forsberg
Här presenteras en fallstudie som utfördes på projektet som avser att svara på frågeställning- ar rörande automatisk testning och testning på distans.
Att leda utvecklingsteam på distans av Carl Harris
Detta kapitel undersöker möjliga skillnader i ledningsstekniker för team på distans och på plats. Genom litteraturstudie och en enkätundersökning jämförs skillnader mellan att arbeta på distans och plats för att diskutera hur detta påverkar ledarens roll inom utvecklingsteam.
Continuous Integration i mindre grupper av Max Helmrich
I detta kapitel undersöks kontinuerlig integration och om det är lämpligt att använda i mind- re grupper. Det undersöks även om det är värt att lägga ner den tid det tar för att komma igång med kontinuerlig integration och vilka fördelar det kan ge. Några relevanta koncept
5.6. Översikt över individuella bidrag
som kontinuerlig leverans, kontinuerlig spridning och automatisering av arbetsflöden tas även upp i relation till mindre grupper.
Är tekniktävlingar för alla? av Evelina Holmgren
I detta kapitel undersöks huruvida tekniktävlingar såsom Teknikåttan är ett bra sätt att in- tressera barn och särskilt tjejer för teknik. Genom en litteraturstudie besvaras dessa fråge- ställningar och slutsatsen är att det finns både för och nackdelar med en tävlingsmiljö som Teknikåttan, men det finns även många saker man kan göras för att förbättra omständighe- terna så att den inkluderar och motiverar tjejer i större utsträckning.
React eller Angular, vad passar bäst? av Carl Lidman
En jämförelse av React och Angular, två populära verktyg för att utveckla webbapplikationer för att svara på vilket alternativ som passar bäst för vilka typer av projekt, samt om båda dessa har en plats på marknaden. En granskning av dessa verktygs officiella dokumentation används för att ta fram fördelar och nackdelar med de två olika alternativen. Efter diskussio- nen blir slutsatsen att dessa verktyg har sin plats på marknaden då denna marknad är stor, och det kommer alltid att finnas utvecklade med personliga preferenser som personligen fö- redrar de olika verktygen.
6
Diskussion
I detta kapitel diskuteras de metoder som har använts och de resultat som erhållits under denna rapport. Dessutom diskuteras projektets roll i ett vidare sammanhang, ur samhälls-, miljö- samt etiska aspekter.
6.1
Resultat
I detta avsnitt diskuteras de resultat som erhållits gällade erfarenhetsfångst, test av använd- barhet, processarbete, kundkontakt samt användning av en systemanatomi.
6.1.1
Erfarenhetsfångst
Resultatet visade att det fanns många olika erfarenheter att fånga in. De erfarenheter som lyckades fångas in var erfarenheter om gruppmöten, arbetsmetodik, gruppkontrakt, uppdel- ning av arbete, versionshantering och sammanhållning.
Som resultatet visade har det funnits både bra och dåliga erfarenheter från tidigare pro- jekt angående strukturen på arbetet. Det har både varit jämnt fördelat, bra utbyte av kunskap och stort engagemang samtidigt som det har funnits grupper som har haft motsatta upple- velsen. Erfarenheterna från mitten av projektet enligt gruppen var generellt sett bra. Gruppen ansåg att arbetet har delats upp relativt jämnt. Detta var även hur gruppen kände i slutet av projektet.
Från tidigare erfarenheter som samlades in i början av projektet hade få i gruppen använt Scrum eller någon annan tydlig arbetsmetodik. Alla gruppmedlemmar ansåg att de i tidiga- re projekt haft ett väldigt ostrukturerat arbetsätt som ledde till att allt arbete skedde i slutet av projektet samt att ”jobbiga” uppgifter undveks att göras i tid. Från avstämningen i mit- ten av projektet ansåg gruppen att arbetet i detta projekt har skett mycket mer strukturerat när det kommer till uppdelning och utveckling. Dock upplevdes planeringen av issues något otydliga och svåra att veta när de var klara. I slutet av projektet upplevdes arbetsmetodiken fungera något bättre då issues blev tydligare formulerade. Dock kunde fortfarande det över- gripande målet för varje sprint förtydligas vilket är något man kan ta med sig i nästa projekt. Anledningen till varför de övergripande målen inte var så bra som de bör varit kan bero på brist av erfarenhet av att sätta bra mål.
6.1. Resultat
Sammanhållningen har varit av blandad kvalitet i tidigare projektarbeten enligt gruppen. Det har bland annat förekommit att konflikter uppstått i slutet av projektet när det är mycket kvar att göra men lite tid. Detta har troligtvis berott på en bristande sammanhållning. Det som gruppen ansåg kunde varit ett sätt att förbättra detta i detta projekt var genom teamaktivite- ter. Senare i mitten av projektet när erfarenheter samlades in igen hade gruppen genomfört två teamaktiviter. Gruppen ansåg att efter första aktiviteten blev det ingen större skillnad i sammanhållning, dock menade gruppen att det var för att det redan var en bra sammanhåll- ning. Efter andra teamaktiviteten som skedde några veckor senare ökade sammanhållning. Detta stärkte tesen från i början av projektet att teamaktiviteter förbättrar sammanhållning- en. I slutet av projektet hade sammanhållningen minskat något som en effekt av distansläget. För att förbättra sammanhållningen blev det extra viktigt att ha fler teambuildingaktiviteter på distans då man inte interagerar utanför projektet på samma sätt som man annars gör på plats. Detta är dock svårt då det innebär att folk sitter framför sina dator vilket många vill försöka minimera efter arbetstid.
Gruppen hade tidigare erfarenheter kring olika ambitionsnivåer i sina projektgrupper. För att undvika detta skrevs ett gruppkontrakt för att försäkra gruppen om att alla har samma inställning om hur arbetet ska gå till och vad som förväntas av varandra. Vid mitten av pro- jektet ansåg gruppen att kontraktet i sig inte var till nytta men diskussionen som hölls för att skapa kontraktet hjälpte gruppen att hamna på samma nivå. Efter projektet var känslorna angående gruppkontraktet relativt samma som vid mitten av projektet. Dock skulle en upp- datering av kontraktet hjälpt, speciellt när arbetet övergick till distans vilket innebar ett helt annat arbetssätt.
En erfarenhet som inte samlades in från tidigare projekt men som fångades upp under detta projekt var angående gruppmöten. I mitten av projektet ansåg gruppen att det fanns bättringspotentiall vid gruppmötena. Gruppen ansåg att bra diskussioner hölls men att det ibland inte diskuterades det som behövdes diskuteras. Denna avstämning skedde precis i början av att arbetet övergick till distans och gruppen ansåg att mötena hade mer struktur när möten hålls på distans än på plats. Även vid slutet av projektet tyckte gruppen att distansläget bidrog till effektivare möten. Flera i gruppen ansåg dock att det hölls fler möten än tidigare. Dock var detta en nödvändighet när fler timmar i veckan spenderades på utveckling vilket medför fler oklarheter som behövdes redas ut. En anledning till varför mötena gick bättre på distans kan vara att det inte går att prata samtidigt som någon annan när det sker digitalt. Allt ljud kommer från en källa vilket gör att det är svårare att skilja om fler pratar samtidigt. Vilket leder till att en person pratar åt gången medan de andra lyssnar.
I både tidigare projekt och i detta projekt användes Git som versionshanteringsverktyg. Gruppen ansåg att versionshanteringen hade varit bristfällig i tidigare projekt då ingen riktigt behärskade Git. Gruppen ansåg vid mitten av projektet att det var bättre än tidigare projekt men att det fortfarande kunde förbättras. Många ansåg att det tog mycket tid i början av projektet som istället kunde läggas på utveckling. Denna känsla av att versionshanteringen var något av en tidsbov kvarstod i slutet av projektet. Detta beror troligtvis på att problem inom detta löstes temporärt och ingen grundlig genomgång kring hur Git egentligen fungerar hölls, vilket hade behövts i gruppen.
6.1.2
Test av användarvänlighet
Resultatet av testerna som utfördes för att mäta användarvänligheten och därmed en aspekt av värdet som skapats för kunden var positivt. I testet för att skapa frågor och i testet för att redigera frågor tog det nya systemet ungefär en tredjedel så lång tid och krävde en tredjedel så många interaktioner jämfört med det tidigare systemet.
När typiska uppgifter tar kortare tid och och färre interaktioner tyder det på att systemet är lättare att använda. Eftersom detta är typiska uppgifter är det sannolikt att de skulle kom- ma att utföras många gånger. Detta mångdubblar effekten av den sparade tiden, eftersom det vid varje tillfälle kan förväntas spara ungeför en tredjedel.
6.1. Resultat
I testet som gick ut på att köra en tävling var skillnaderna inte lika stora. Antalet inter- aktioner var bara några färre i det nya systemet och det tog drygt hälften så lång tid. Detta beror troligtvis på att uppgiften i sig inte är så komplex och att det därför inte finns så många olika sätt att utföra det på. Detta leder till att de två system är mer snarlika i den här delen än i andra.
Resultatet av testerna indikerar starkt att det nya systemet är lättare att använda och att det går snabbare att göra tävlingar i det. Utöver skillnaden i tid och interaktioner var även kommentarerna mycket mer positiva, men indikerade att det upplevdes som en beta version. Eftersom programmet inte var helt färdigt när det testades är detta inte speciellt konstigt. Ett system som är lättare att använda och som går att göra mera i på mindre tid är av stort värde för kunden, då många timmar spenderas på att använda systemet i dagsläget.
6.1.3
Process
Att arbeta med processer gav inte så mycket till detta projekt som det kan göra om man arbetar mer aktivt med det valda processområdet. Att ha processmål gav dock gruppen något att fokusera sitt arbete på vilket hjälpte då det var ett av de större problemen gruppen hade under utvecklingen. Det hjälpte även att reflektera över hur arbetet med processen hade gått efter varje sprint, det gjorde att man lättare kunde se om framsteg gjordes eller inte.
Då förbättringen av processen endast gav upphov till en ny risk är det svårt att säga om förbättringen gjorde så stor skillnad i projektet. Risken som uppstod var dock en risk som gruppen aktivt började arbeta med så fort den definierades. Vissa av riskerna som gruppen identifierade i början av projektet arbetades aktivt med samt påverkade aldrig vårt arbete särskilt mycket då gruppen aldrig hann så pass långt i utvecklingen. Dessa risker var risk R4 och R5. Detta berodde även på att dessa risker hade en riskmagnitud som bedömdes vara för låg för att någonsin vara aktuell. Detta i kontrast till den nya risken som identifierades efter sprint 2 som arbetades aktivt varje vecka efter den blev identifierad.
När risker identifieras i början av ett projekt är de oftast hypotetiska medan risker som identifieras under projektets gång oftast är större risker. Dessa risker är oftast en produkt av den faktiska utvecklingen och adresserar faktiska problem som gruppen står inför. Därför är det rimligt att de tillagda riskerna arbetas med i större utsträckning än risker som identifie- rades i början av projektet.
6.1.4
Kundkontakt
Resultatet visade att det i början var svårt att komma överens med kunden om hur kraven skulle prioriteras. Detta beror på både kunden och gruppen. Gruppen var inte tydlig med kunden från början om vikten av dokumenten för kursen, vilket resulterade i att kunden trodde att mycket mer tid skulle läggas på utveckling. När gruppen på ett möte strax innan projektets avslut till slut var tydliga med kunden förstod dessa till slut hur det låg till. En annan sak som gruppen borde ha gjort tydligare i början av projektet var bristen på erfarenhet av webbutveckling, då tiden som krävdes för inlärning tog mycket tid från utvecklingen.
Som tidigare nämnt kom de två kundrepresentanterna som gruppen främst hade kontakt med från olika bakgrunder, och hade olika erfarenhet av utveckling. Att detta resulterade i att de hade olika prioriteringar över vilka krav som skulle uppfyllas är därför ingen över- raskning, då olika erfarenheter ger olika synsätt. Det är därför även förväntat att det blev diskussion mellan representanterna angående prioritering då frågor de ej hade kunnat förbe- reda sig för kom. När gruppen senare i projektet skickade ett mejl med agenda och diskus- sionspunkter innan ett möte resulterade detta i att konversationen flöt på bättre. Detta beror troligtvis på att kunden då kunde förbereda sig mer på vad som skulle tas upp på mötet och sammanställa vad de hade för gemensam åsikt.
En sak som gruppen hade kunnat göra i början av projektet hade varit att sätta färre krav som högsta prioritet. Dels kan det psykologiskt sett vara lättare att höja prioriteringen av
6.2. Metod
krav än att sänka dem, eftersom en sänkning av prioritet kan tolkas som ett misslyckande. Dessutom blir det svårare att arbeta efter en kravlista med många högprioriterade krav. I det- ta fall var väldigt många krav en anledning till varför gruppen arbetade på många olika delar av systemet samtidigt, istället för att arbeta på ett gemensamt system. I början av projektet borde därför gruppen och kunden haft en diskussion om prioriteringen mellan kvantitet och kvalitet. De hade då kunnat göra bedömningen om flera delar av systemet skulle finnas med men fungera buggigt eller inte finnas med alls, eller om få delar av systemet skulle finnas med men fungera bra.
6.1.5
Systemanatomi
Eftersom systemanatomin togs fram så tidigt i utvecklingsfasen blev den inte helt fullständig. Den utvecklades direkt efter första kundmötet och det var då inte helt fastställt vad systemet skulle innehålla. Till exempel saknar systemanatomin anatomer för inloggning och konto- hantering just av denna anledning. Gruppen har inte använts sig av systemanatomin särskilt mycket under de senare stegen i utvecklingen, utan främst under den tidiga planeringen, men även under den tidiga delen av projektet användes inte systemanatomin i stor utsträck- ning. Gruppen ansåg att den inte var till mycket hjälp dels för att den var svår att förstå då det var ett nytt koncept för alla i gruppen, och den skiljer sig från mer traditionella sätt att visa strukturen på projekt som till exempel flödesscheman eller UML-diagram.
En systemanatomi kan lämpa sig bättre för stora projekt där väldigt många anatomer kan identifieras och man få får en bättre överblick av ett komplicerat system. I det här projektet fanns inte så många anatomer, och systemet i sig hade ganska skilda delar som inte berodde på varandra, så en systemanatomi hjälpte inte till massvis med strukturering. Mycket av det som systemanatomin ska hjälpa med blev uppenbart i projektet då det är på relativt liten skala. Att anatomen bläddra fråga är beroende av anatomen visa upp fråga är ganska uppenbart och i utvecklingen blev det naturligt att utveckla i den ordningen, även utan systemanatomin som referens.
6.2
Metod
Här kommer metoderna som producerat resultatet att diskuteras. De konsekvenser som de valda metoderna gett och eventuella alternativ och begränsningar som de har. På samma sätt kommer de källor som används i rapporten att analyseras och diskuteras för att ge resultatet kontext och säkerställa trovärdigheten.
6.2.1
Källkritik
Mycket av den teori som behandlades i denna rapport är relaterad till programvara. Detta kan resultera i att källor som behandlar dessa ämnen snabbt blir utdaterade, då programvaran uppdateras och ny funktionalitet läggs till. Detta innebär att de böcker som användes som källor riskerar att ha gett mer utdaterad information än de internetkällor som användes, då information inte kan uppdateras efter tryckning.
6.2.2
Metod för analys av skapat värde för kund
Metoden rörande frågeställningen ”Hur skapas värde för kunden” är en jämförelse, men in- formationen införskaffades med olika metoder vilket kan medföra att jämförelsen reflekterar verkligheten sämre. Eftersom inte alla delar av projektet blev slutförda kan inte systemen som helhet testas, därför jämfördes de delar som kan utföras i båda versioner för att få den mest meningsfulla jämförelsen möjlig. De delar som testades var valda utifrån vad som finns i projektet och bygger på projektets styrkor. Trots detta betyder det inte att det ursprungli- ga projektet nödvändigtvis är bättre på det som inte testades, utan endast att det saknas för