A.4 Metod
B.3.2 Designprocessen hos ett interaktivt system
Enligt Arvola [5] består designarbetet av en produkt från idé till färdigt system av tre faser. Dessa faser är konceptfasen, bearbetningsfasen och detaljeringsfasen. De processer som sker i varje fas beskrivs nedan.
Konceptfasen innefattar identifiering av systemets tänkta användning och generering av koncept. Genom att identifiera hur produkten eller tjänsten är tänkt att användas – i vilket sammanhang, av vem, varför den behövs – kan man sätta upp mål och krav för produkten och projektet. När de övergripande avsikterna har fått klarhet kan olika koncept börja arbetas fram. För att konkretisera sina idéer finns ett antal frågor man bör ställa sig: vad konceptet är för något, varför användaren vill ha och använda det och hur det ska vara.
Bearbetningsfasen utformar gränssnittet och alternativa lösningar på problem tas fram och värderas. Från det koncept som valts struktureras de funktioner upp som produk- ten eller tjänsten ska ha samtidigt som frågan hur interaktion med användaren ska gå till
B.4. Metod
besvaras. Gränssnittsskisser ritas upp som innehåller information om funktioner samt sys- temets innehåll och struktur. När gränssnittsskissningen är klar blir nästa steg att göra en interaktiv prototyp. Prototypen är det verktyg med vilket systemets användbarhet kan testas mot tänkta användare. Utifrån de brister och styrkor prototypen har kan sedan omstruk- tureringar och förbättringar göras innan man går vidare till den tredje fasen i designarbetet.
Detaljeringsfasenfokuserar på att förfina det tidigare arbetet och gränssnittet bestäms nu på detaljnivå. Det blir viktigt att tänka på vilken grafisk profil systemet är tänkt att ha, det vill säga vilken känsla som ska förmedlas och de associationer användaren ska få av systemet. När alla designbeslut är klara är det dags att lämna över sitt arbete för implementering, där det oftast bara uppstår mindre ändringar av den grafiska designen innan den blir en färdig produkt.
B.4
Metod
Kapitlet beskriver de metoder med vilka författaren har gått till väga för att besvara frågeställ- ningarna i avsnitt B.1.2.
B.4.1
Litteraturstudie
Under första läsperioden av vårterminen 2016 samlästes denna projektkurs med en kurs inom interaktiva system. Innehållet i den senare kursen har bidragit till mycket av kun- skapen i detta arbete. Kurslitteraturen skrevs av examinatorn, Mattias Arvola, vilken användes flitigt i arbetet med denna rapport.
Utöver detta gjordes Google-sökningar på “Prototype” och “Prototyping”. Sökprocessen ledde till en artikel skriven av C. Floyd vilken definierar uttryck och processer som förekom- mer i prototyputveckling och hur de är tänkta att användas.
B.4.2
Undersökning
För att kunna besvara frågan om hur värdefull en prototyp är för utvecklingen av mjukvara utfördes en undersökning med medlemmarna i denna projektgrupp samt andra projektgrup- per som också använt sig av prototyper i sitt kandidatarbete. Undersökningen gick ut på att svara på ett antal frågor kring hur prototypen använts, dels av varje enskild gruppmedlem och dels av gruppen som helhet. Syftet med undersökningen var att avgöra huruvida pro- totyputvecklingen för de olika projektgrupperna underlättade för den fortsatta utvecklingen samt om gruppmedlemmarna ansåg att den tid som investerats i prototyputvecklingen varit lönsam för projektet som helhet.
Frågorna skickades ut i form av en online-enkät till de olika projektgrupperna. De frågor som ställdes presenteras i bilaga 4.
B.5
Resultat
Enkäten skickades ut via mail till alla projektgruppers teamleader, som sedan vidarebefor- drade denna till sina projektmedlemmar i de fall en prototyp hade använts. Totalt svarade 24 personer från 5 olika grupper. I bilaga 4 presenteras en sammanställning av svaren från de tre grupper som hade flest deltagare i undersökningen. Figur B.1 visar fördelnin- gen över det antal timmar respektive grupp uppskattat att de investerat i prototyputveckling.
B.5. Resultat
(a) Tidsåtgång grupp A (b) Tidsåtgång grupp B (c) Tidsåtgång grupp C Figur B.1: Deltagarnas uppskattning över den totala mängd tid, i timmar, som lagts ner på prototypningsarbete
inom tillhörande projektgrupp.
Nedan presenteras några av de erfarenheter dessa grupper haft med respektive prototyp. Fler erfarenheter återfinns i bilaga 4.
Fördelar med prototypen
• Kunde blicka tillbaka på vid implementering.
• Prototypen fungerade som guide för resterande i gruppen.
• Kunnat visa kund och få feedback, vilket gör att utvecklingsarbetet känns mer legitimt och kundförankrat.
• Hela gruppen fick en tydlig bild och mål – blir lättare att arbeta. • Tid slösades inte på onödig funktionalitet.
• Snabbt och enkelt att ändra efter kundens behag och resultaten från användartester. • Uppmuntrade till utveckling.
• Kunde återanvända idéer därifrån.
Nackdelar med prototypen
• Prototypens funktionalitet var inte så bra.
• Handlingsinviter behandlades inte i prototyperna.
• Prototyparbetet kan ha försenat upprättandet av ett kodskelett.
• Mycket av designen bestämdes utifrån vad som ansågs möjligt att koda. • Tvister i implementation och utformning.
• Tar mycket tid att göra en separat prototyp, särskilt i ett tidsbegränsat projekt. • Ogenomtänkt struktur.
Grupperna gjorde sin prototyp på dator där grupp B och C arbetat med evolutionär proto- typning. Grupp A var något oense där 25 % ansåg att prototypen var av evolutionär typ och 75 % istället tyckte att den var temporär. Genom att titta på de avsikter som dessa grupper haft med prototypen kan kopplingar göras till de klasser som nämns i stycke B.3.1. Både utforskande och experiementell prototypning har använts efter gruppernas behov. Nedan presenteras några avsikter från sammanställningen.
B.6. Diskussion
Avsikt med prototypen
• Skapa en gemensam bild av produkten och ge gruppen ett mål. • Utforska flera alternativ.
• Ta reda på hur/vilka funktioner som skulle med. • Ta fram ett tilltalande GUI.
• Samla kunskap. • Lära sig verktygen.
• Ta reda på vad kunden vill ha och få snabb feedback.
Samtliga projektgrupper hade tillsatt en mindre grupp att ansvara för prototyputvecklingen. Inom de tre projektgrupper som ingick i sammanställningen tyckte minst 50 % från varje grupp att prototypen underlättade tillräckligt för att vara värt den tidsinvestering prototy- parbetet innebar. Endast 12,5 % från en av grupperna ansåg att arbetet inte direkt har varit lönsamt. Fördelningen hos de olika grupperna presenteras i figur B.2.
Figur B.2: Projektgruppernas inställning till den tid som investerats i prototyputvecklingen.
B.6
Diskussion
Detta kapitel för en diskussion kring resultatet av undersökningen, eventuella brister hos den enkät som låg till grund samt den teori som presenterats i rapporten.
B.6.1
Resultat
För att få en representativ bild av olika gruppers erfarenhet av att arbeta med prototyper krävdes deltagande från flera personer inom samma projektgrupp. Detta för att få klarhet i vad för prototyp som gjorts, hur den har använts och på vilket sätt den påverkat olika projektmedlemmar. Alla projektgrupper bestod av 8–10 medlemmar totalt men deltagandet var ofta mindre än hälften. Därför togs beslutet att endast de tre projektgrupper som haft flest deltagare skulle inkluderas i resultatet och sammanställningen.
Ur svaren på enkäten framgår att projektgrupperna tillsatte en mindre grupp som ansvariga för prototyputvecklingen. De projektmedlemmar som inte själva ingick i denna grupp hade troligtvis en annan uppfattning, i jämförelse med de som varit involverade, om vad arbetet
B.7. Slutsatser
innebar och hur lång tid det tog. Vid en blick på fråga 2: Hur många timmar har lagts ner på prototypningsarbete? har svaren inom samtliga grupper varit väldigt spridda (se figur B.1). Grupp A var jämnt fördelade i intervallet 10–150 timmar. Inom grupp B verkar hälften av deltagarna vara överens om att tidsåtgången var 200 timmar, medan andra hälften trodde 5–10 timmar. Spridningen inom grupp C var dock mindre och de uppskattade 20–60 timmar. Som framgår av figur B.2 ansåg en överväldigande majoritet av gruppmedlemmarna att tidsinvesteringen varit givande för utvecklingen. Eftersom deltagarantalet från vissa av grupperna var lågt kan man även fundera över hur de som inte deltagit i undersökning hade svarat. Det som enligt figuren ser väldigt positivt ut kan snabbt få ett mer negativt utslag med endast ett par deltagare extra. Med hänsyn till det resultat som presenterats kan dock slutsatsen dras att prototypens fördelar vägde upp för de nackdelar som uppmärksammats.
B.6.2
Metod
Frågorna i enkäten skrevs med en temporär prototyp i åtanke, eftersom det var den sorts prototyp som användes i detta projekt. Det har medfört att vissa frågor inte direkt är ap- plicerbara för de grupper som arbetat med evolutionära prototyper. En stor del av de svar som samlats in är från grupper som arbetat med just evolutionär utveckling, där alltså “pro- totypen” de evaluerat i själva verket var en tidig version av slutprodukten. Detta innebär att vissa av svaren inte kan ses som representativa då de beror på deltagarens egen tolkning av frågan.
B.6.3
Teori
Mycket av den kunskap som hämtats in kommer från samma källa. Det gör att teorin lätt kan bli ensidig och vinklad efter källförfattarens egna rekommendationer. Den artikel som också användes i rapporten är från 1984 och därför bör det ifrågasättas hur mycket av innehållet som gäller än idag. Man kan tänka sig att mycket har hänt inom prototypning i och med den tekniska utveckling som skett sedan 1980-talet och framtagandet av nya hjälpverktyg inom prototyputveckling.
Den process för framtagningen av gränssnittsdesign som presenteras i avsnitt B.3.2 är främst anpassad efter temporära prototyper. Det är alltså inte säkert att denna metod lämpar sig särskilt bra för projekt som arbetar med evolutionär utveckling.
B.7
Slutsatser
Från denna studie kan ett antal slutsatser dras gällande prototyputveckling inom projekt- grupper i kursen TDDD96 Kandidatprojekt i programvaruutveckling. Detta avsnitt har för avsikt att i korthet besvara den frågeställning som presenterades i rapportens inledning. Fördelarna med att ta fram en prototyp kan tänkas vara många. Från undersökningen syns tydligt att prototyper har använts för att undersöka olika alternativ och ge projektgruppen ett gemensamt mål att arbeta mot. De har dessutom varit till hjälp med att konkretisera kundens önskemål och tidigt kunna få återkoppling på de förslag som tagits fram. En överväldigande majoritet av deltagarna ansåg att den tid som investerades i prototyputvecklingen var gi- vande för utvecklingen av projektet.
De nackdelar som kommit fram i och med undersökningen har främst varit relaterade till den tidsinvestering som en bra prototyp ofta kräver. Deltagarna nämnde bristande funktion- alitet, dåligt skriven kod och att det tar mycket tid att göra en separat prototyp. Utöver detta påpekade en grupp att de alternativ som utforskades var ganska snarlika och att nya idéer
B.7. Slutsatser
kan ha gått förlorade eftersom alla inte var inblandade i prototyputvecklingen. Ytterligare upplevde man att gränssnittsdesignen begränsades utifrån det som ansågs vara möjligt att implementera.
Utifrån enkätsvaren framgår att samtliga projektgrupper tillsatte en mindre grupp som ansvariga för prototyputvecklingen. I två av tre fall har en prototyp av evolutionär typ använts, där alltså produkten har utformats i flera steg och “prototypen” som utvärderats avser en tidig version av slutprodukten. Vidare var avsikten att utforska flera alternativ och förtyliga kundens önskemål vilket pekar på utforskande prototypning. Den process som kan användas i utformningen av ett användargränssnitt tas upp i avsnitt B.3.2. Av de tre faser som där nämns – konceptfas, bearbetningsfas och detaljeringsfas – är det de två första som innefattar prototyputveckling. Det är värt att nämna att det inte framgår från undersöknin- gen vilka steg i processen som faktiskt har genomförts hos de projektgrupper som deltog. De olika stegen och faserna kan således anpassas efter gruppens behov.
C
Rebecka Geijer Michaeli: Daily
Scrum virtuellt via textbaserat
verktyg
C.1
Inledning
Under projektet har gruppen tillämpat en modifierad variant av arbetsmetoden Scrum [1]. En modifikation som gjorts är sättet på vilket daily Scrum-mötena har gått till, se 4.3.1. Denna undersökning handlar om dessa daily Scrum-möten, hur de har gått till och vilka erfarenheter som kan tas med till framtida projekt. Undersökningen behandlar även vad det finns för litteratur att ta del av om virtuella, textbaserade daily Scrum-möten.
C.1.1
Syfte
Syftet med den här undersökningen är att sammanställa teori som finns att hitta om virtuella, textbaserade daily Scrum-möten, samt sammanställa erfarenheter från en projektgrupp som tillämpat Scrum med virtuella, textbaserade daily Scrum-möten.
C.1.2
Frågeställning
Följande frågeställningar har legat till grund för denna undersökning:
1. Vad finns det för teori att inhämta som kan vara till hjälp vid utvärderandet av daily Scrum-möten genomförda virtuellt via ett textbaserat verktyg?
2. Vilka erfarenheter kan inhämtas från ett projekt om nio personer som tillämpat Scrum där daily Scrum-möten hållits virtuellt tre gånger i veckan via ett textbaserat verktyg?
C.2
Bakgrund
Som det beskrivs i 4.3.1 har gruppen haft daily Scrum-möten tre gånger i veckan istället för varje dag. Trots det kommer mötena refereras till som daily Scrum-möten genomgående i undersökningen. Dessa möten har hållits via kommunikationsverktyget Slack [18], de var alltså virtuella. Slack ger ingen möjlighet till video- eller telefonkonferenser, utan är helt textbaserat. Detta har lett till att gruppens daily Scrum-möten skett helt textbaserat.
För att få en enhetlig form på gruppmedlemmarnas daily Scrum-svar har Slack-tillägget geek- bot [39] använts. Varje mötesdag skickade geekbot de olika daily Scrum-frågorna till var och en av gruppmedlemmarna via privatchatt. Gruppmedlemmarna fick sedan svara till geek- bot, och avslutningsvis postade geekbot en sammanställning per gruppmedlem i en specifik Slack-kanal som var dedikerad för ändamålet.
C.3. Teori
C.3
Teori
I det här stycket presenteras först teori om daily Scrum-möten i två stycken, följt av ett stycke om möten som hålls vitruellt, och till sist ett stycke om Media Richness Theory.
C.3.1
Daily Scrum
I 3.5.1 beskrivs hur daily Scrum-möten går till. Tanken med att teammedlemmarna står upp under mötet är att förhindra att de drar ut på tiden, då det för de flesta är obekvämt att stå upp längre stunder. En effekt av utformningen av daily Scrum-frågorna, där teammedlemmarna i början av varje dag får berätta för sina kollegor vad de kommer jobba med under dagen, är att det ger en ansvarskänsla inför resten av teamet att göra framsteg på det man sagt att man ska jobba med [40].