Magic Stats. - Samarbejde med brugere

Transkript

1 Magic Stats - Samarbejde med brugere

2

3 Institut for datalogi Aalborg Universitet INF 2 TITEL: Magic Stats - samarbejde med brugere. PROJEKTPERIODE: INF2, 3. februar - 30.maj, 2008 PROJEKT GRUPPE: i201ba GRUPPEMEDLEMMER: Michael Bønnerup Ole Risgaard Hansen Gunnar Konradsson Søren Hugger Møller Jonas Urth Olsen Rahuvaran Pathmanathan Thulasika Rasenthiran VEJLEDER: Andreas Munk-Madsen SYNOPSIS: Dette projekt behandler udviklingen af et s- tatistiksystem i samarbejde med brugere. Systemet er henvendt til spillere af kortspillet Magic the Gathering og har til formål at formidle og administrere statistik, kampe og decks. Der er i projektet og dokumentationen lagt hovedvægt på brugerinvolveringen og dermed den procesrelaterede del. Der er anvendt udvalgte teknikker til at inddrage brugere i udviklingen af systemet. I form af forbilledanalyse, brugsmønsterudvikling og prototypetest har brugerne haft en væsentlig indydelse på kravspeciceringen og været med til at vurdere systemet. Vi har valgt at udvikle systemet med Scrum som udviklingsmetode. Systemet er programmeret i ASP.NET/C# og er udviklet i Microsoft Visual Studio 2008 med en MSSQLdatabase og systemet DB Flow, som er udviklet af Jacob Volstrup. ANTAL KOPIER: 9 RAPPORT SIDEANTAL: 70 BILAG SIDEANTAL: 50 TOTAL SIDEANTAL: 130

4

5 Forord Denne projektrapport samt det tilhørende software er udfærdiget af INF2, gruppe i201ba på Aalborg Universitet fra d. 3. februar til d. 30. maj Semestertemaet var "Samarbejde med brugere"og projektet tog udgangspunkt i udviklingen af it-system til statistik af kortspillet Magic: The Gathering (Magic)[[3]]. Som baggrund for semestrets tema er der inddraget viden fra undervisning i følgende kurser: Software Innovation (SWI) og Software Engineering (SOE). Vi vil gerne takke vores brugere af systemet, som vi i forbindelse med projektet har haft et tæt samarbejde med i forbindelse med de adskillige sessioner vi har haft under udviklingsprocessen. Endvidere vil vi takke vores vejleder Andreas Munk Madsen for gode råd og vejledning igennem dette semester på INF2, foråret Forsidefoto af magickortspillerne, er taget af Christopher Bruno på Flickr 1. Aalborg Universitet, 30. maj IV

6 Læsevejledning Rapporten er delt op i ere kapitler, som der herunder gives et overblik over: Kapitlernes indhold Kapitel 1 beskriver den indledende proces, hvor projektets problemformulering og afgrænsning beskrives. Dernæst kommer kapitel 2 om projektets strategi, hvor det beskrives hvilken tilgang, der er taget til udviklingen af systemet. Usikkerheder og vanskeligheder i projektet bliver fremlagt, og der opstilles løsningsforslag i form af forskellige aktiviteter. I kapitel 3, som omhandler valg af systemudviklingsmetode, bliver der taget stilling til de generelle agile metoder, hvor de hyppigst brugte bliver beskrevet og dertil valget af den metode, som vi har valgt at arbejde med i dette forløb. Den valgte udviklingsmetode beskrives yderligere i kapitel 4. Kapitel 5 omhandler samarbejdet med brugerne, her bliver de forskellige aktiviteter med fokus på inddragelse af brugere beskrevet. Der reekteres på samme tid over de forskellige aktiviteter. I kapitel 6 reekteres der over processen i projektforløbet. Dette kapitel beskriver processen i forhold til den valgte udviklingsmetode og dertil beskrives procesforløbet kronologisk, hvor resultaterne af aktiviteterne med inddragelse af brugerne bliver præsenteret. Kapitel 7 beskriver de værktøjer, vi brugte i udviklingen af systemet, samt de teknikker som blev brugt til at styre og organisere opgaverne i projektforløbet. Kapitel 8 beskriver og vurderer de forskellige innovative og kreative metoder/teknikker vi har brugt i projektforløbet. I kapitlerne 11, 9 og 10 bliver der set på projektet i en helhed, og der bliver perspektiveret, reekteret og konkluderet på det endelige resultat. Generelt Rapporten er skrevet, så der forekommer både kildehenvisninger og fodnoter. Kildehenvisninger vil i teksten være noteret som [kildenummer], og gurhenvisninger vil skrives som gur "gur nr.". Fodnoterne vil indeholde uddybende eller forklarende information om emnet, og vil være tilgængelige nederst på den pågældende side og betegnes med numre. Referencehenvisninger til bilag beskrives med bogstav og nummer. I beskrivelsen af projektets forløb arbejdes der med begreber som Sprint, Sprint backlog og Product backlog, Product owner, Sprint team, Daily scrum og Scrum master. Disse er alle begreber som behandles i den systemudviklingsmodel, som vi har valgt at udvikle efter. Begreberne bliver beskrevet i kapitel 4 V

7 En stor del af projektet beskæftiger sig med mange forskellige begreber fra spillet Magic, som ofte ikke er eksplicit deneret og vi har derfor vurderet det væsentligt at fastlægge hvad der i det følgende forstås ved de centrale begreber. Magic-begreber Magic: The Gathering er et samlerspil opfundet i 1993 af Richard Gareld og udgivet af Wizards of the Coast. Spillet er det første eksempel på et sådan samlerspil og antages i dag at have seks millioner spillere fordelt over 17 lande [[16]]. Player bruges til at beskrive en spiller i den periode, der spilles Magic. I spillet repræsenterer denne en troldmand, der udkæmper kampe ved hjælp af magi. Kort repræsenterer spillerens magi. Kortene har lille indydelse i dette projekt, men er grundstenen i Magic. Deck er en samling af kort. Alle kortene i hvert deck er specielt udvalgt af spilleren til at komplimentere hinanden. Match bruges til at beskrive en kamp, hvor hver spiller spiller med et enkelt deck. Hver match har vindere og tabere, en match kan have to til seks spillere. VI

8

9 Indhold Indhold VIII 1 Indledning Problemformulering Problemafgrænsning Projektstrategi Karakterisering af betingelser Vanskeligheder Fokus og Strategi Valg af systemudviklingsmetode Agil systemudvikling Agile udviklingsmetoder Scrum Roller Begivenheder Værktøjer Fordele og ulemper Samarbejde med brugere Vores brugere Spørgeskemaet Forbilledanalyse Brugsmønstre Prototypetest Proces Pre-game Foranalyse Første sprint Andet sprint Tredje sprint Reeksion VIII

10 7 Teknik ASP.NET, C# og DB Flow Google Docs Versionsstyring - SVN Innovation Innovation i vores projekt Forbilledsanalyse Udarbejdelse af brugsmønstre Reeksion For sen opstartsfase Samarbejdet med Product owner Samarbejdet med brugerne Samspillet imellem Scrum og samarbejdet med brugerne Metodisk tilgang Konklusion Udviklings metode Perspektivering Brugerinvolvering Udviklingsmetode Benytte tredjepartskode Project Management A Analyse 73 A.1 Foranalyse A.2 Systemdenition A.3 BATOFF A.4 Prioriteringsskema A.5 Problemområde A.6 Anvendelsesområde A.7 Forbilledanalyse A.8 Spørgeskema A.9 Forberedelse til brugsmønstersessionen A.10 De 4 brugsmønstre B Opbygning af layoutet 91 C Scrum 93 C.1 Første sprint C.2 Andet sprint C.3 Tredje sprint C.4 Sprint backlogs D Vurdering af vanskeligheder 109 D.1 Formål D.2 Fremgangsmåde D.3 Problemområde D.4 Anvendelsesområde IX

11 D.5 Teknisk platform D.6 Projektorganisation D.7 Specielle forhold D.8 Reeksion E Funktionsliste 112 F Prototypetest 114 F.1 Resultater G Klassediagram 121 H KMM-model 122 Litteratur 124 X

12 XI

13 Kapitel 1 Indledning Temarammen for dette INF2-semesterprojekt er "Design og vurdering af et edbsystem i samarbejde med brugere". Hertil har vi for vores vedkommende valgt at konkretisere det yderligere til "Design, realisering og vurdering af et it-system med henblik på sammensætning af en udviklingsmetode med fokus på interaktionen med brugerne". I modsætning til INF1-semestret, hvor vi fokuserede meget på en analytisk og metodisk fremgang, lægger vi denne gang vægt på interaktionen og samarbejdet med brugerne med henblik på at udvikle et it-system. Et it-system består typisk af en række funktioner, og en brugergrænseade til at iværksætte dem. En af fordelene ved it-systemet er den interaktivitet, der kan tilbydes, det vil sige den form for dialog mellem mennesker og maskiner, hvor man som bruger kan få feedback på en række eventuelle forespørgsler. I tider som disse, hvor it-systemer stiger i kompleksitet og udvikling af brugervenlige systemer derfor vanskeliggøres, er det en god ide at involvere brugere i udviklingen af produkter, de siden selv kommer til at bruge. Det afgørende at få brugerne involveret maksimalt i udviklingsprocessen, da de har de bedste forudsætninger for at kunne se hvordan et system skal passe ind i deres brug. Vi har valgt at arbejde sammen med en gruppe af spillere, der spiller kortspillet Magic, om at udvikle et system, der bygger videre på deres oplevelse af spillet. Det er planlagt at være en statistikapplikation. Ideologien bag en statistikapplikation er administrationen af spillere og dertil deres decks samt overståede kampe. På baggrund af disse skal applikationen give et fyldestgørende statistisk overblik over vundne og tabte kampe spillerne imellem og formidle dette på sådan en måde, at brugeren nder det tilfredsstillende at interagere med systemet. Tilfredsstillende i den forstand, at applikationen bliver interessant, og belønnende i et sådan omfang, at brugeren fastholder sin interesse over tid og dermed har en tilbagevendende lyst til at benytte den. Systemet skal desuden tilbyde og forstærke lysten til at interagere med andre spillere på sådan en måde, at applikationen danner grobund for et online community, hvor brugeren har mulighed for at udforske andre brugere samt diskutere forskellige emnerelaterede problemstillinger. 1

14 Kapitel 1 Magic Produktet udvikles med netop denne gruppe af brugere, da disse brugere virker dedikerede til deres hobby. Desuden ndes der ikke i skrivende stund et alternativ produkt, som opfylder deres stillede behov. På baggrund af dette, mener vi at kunne opnå et godt samarbejde med en solid dialog i løbet af udviklingen. 1.1 Problemformulering Ud fra de indledende overvejelser søger vi følgende problemstilling besvaret: Hvordan kan man opnå et godt samarbejde med brugerne og på baggrund af dette realisere en applikation med vægt på interaktion og statistik? 1.2 Problemafgrænsning På baggrund af semestrets overordnede fokus blev det valgt at projektet skulle fokusere på processen frem for produktet. Dette indebærer at der vil fokuseres på samarbejdet med brugerne i højere grad end udviklingen af produktet. Som følge heraf, sættes visse begrænsninger for det system, der udvikles. Der stræbes ikke efter at få et færdigt produkt ved endt projektperiode. I stedet sigtes der efter at ende ud med en fungerende prototype, indeholdende en del af det færdige systems funktionalitet. Denne prioritering dannes på baggrund af en vurdering af den tilgængelige tid i projektperioden, og hvor meget af denne tid der er mulighed for at anvende til systemudvikling, i forhold til læring og dokumentation af denne. 2

15 Kapitel 2 Projektstrategi I dette kapitel beskrives de metoder, der blev anvendt til at udforme strategien for udviklingsprocessen, og set på de mulige usikkerheder, der kan forekomme. Vi udarbejdede udviklingsstrategien efter at have set på problem- og anvendelsesområdet i foranalysen, der kan læses nærmere om i kapitel 6.2. Derfor er det essentielt allerede på forhånd at kunne prioritere samt fastlægge en struktureret fremgangsmåde for de aktiviteter, som kommer til at foregå i udviklingsprocessen. Der skal udarbejdes en situationsbestemt strategi, hvor det er muligt at identicere de vanskeligste betingelser og krav, som danner grundlag for en mere konkret analyse- og designopgave. En sådan strategi giver udviklerne indsigt i indholdet, omfanget, kompleksiteten og usikkerheden af de aktiviteter, som indgår i processen. 2.1 Karakterisering af betingelser Karakteriseringen af betingelserne kan ske ved at se på de krav, der ligger til projektet. Dette vil på samme tid give en forståelse af projektets omfang, der muliggør en udarbejdelse af en strategi. For at få en grundig forståelse af opgaven, ser vi på nogle spørgsmål fra Objektorienteret Analyse & Design, s. 284 [[10]], der forsøges besvaret. Spørgsmålene tager udgangspunkt i følgende fem forhold: Problemområde Anvendelsesområde Teknisk platform Udviklingsprojekt Specielle forhold 3

16 Kapitel 2 Magic Problemområde Har vi erfaring med typen af it-system? Vi har ikke tidligere arbejdet med et it-system til at håndtere statistik, som det ses i netop dette projekt Anvendelsesområde Har vi erfaring med brugerorganisationen? Størstedelen af udviklingsgruppen har ikke haft erfaring med brugerorganisationen, dog har vi fået et godt indtryk af, hvilken slags brugere, vi har med at gøre. Det er dog et krav, at brugerorganisationen bliver studeret mere, før en systemudvikling kan begynde Teknisk platform Har vi erfaring med teknologien? Vi har ikke i et tidligere projekt udviklet et webbaseret it-system, men vi har haft erfaring med selve programmeringssproget. Det giver os den fordel, at vi ikke behøver bruge tid og ressourcer på at lære et nyt programmeringssprog Udviklingsprojekt Hvor dygtige er udviklerne og hvor gode betingelser har de? Den erfaring, som vi har haft til den tekniske platform er fra et tidligere projekt, hvilket betyder at kravene ikke stilles højt i forhold til mængden af arbejde, der kan udføres i projektet Specielle forhold Hvilke specielle forhold gælder for løsning af denne opgave? Da erfaringen med systemudvikling ikke er så høj, og vi som udviklere stadig er i en læringsproces, vil forventningerne og kravene til et færdigt system være begrænsede. I stedet forventes en virkende prototype af et it-system, som opfylder et minimumskrav. Vi har ønsket at lokalisere de potentielle vanskeligheder, der kan forekomme i projektforløbet, således at planlægningen og uddelingen af ressourcer kan tilpasses. Idéen er, at når vanskelighederne kendes, er opgavens karakteristik ligeledes kendt. Dette vil gøre det muligt at vælge de værktøjer, som bedst er tilpasset situationen. 2.2 Vanskeligheder For at skabe et overblik over situationen samt kunne analysere og vurdere de vanskeligheder, som er knyttet til den specikke situation i projektet, udførte udviklergruppen en øvelse, som gik ud på at udfylde en tjekliste til karakteristik af udviklingsopgaven. Tjeklisten er fra Objektorienteret Analyse & Design, s.285 [10]. Ved at gå igennem tjeklisten, fandt vi ud af i hvilke områder i projektet, der er potentielle vanskeligheder. De spørgsmål og emner, som ikke har været 4

17 Magic Kapitel 2 til at besvare med et Ja, har været taget op til en større diskussion, hvor det skulle være muligt at nde en måde at løse problemet på. Tabellen som ses på gur 2.1 giver et overblik over de fundne vanskeligheder ud fra tjeklisten, samt hvilke strategier og fokus der skal knyttes dertil. Hele tjeklisten er til at nde i bilag D. Anvendelsesområde 5 Har brugerne erfaring med denne type it-system? 6 Er systemets funktioner velkendte for systemudviklerne? 7 Er anvendelsesområdet og brugergruppen overskuelig og ensartet? 8 Er der etablerede procedurer eller traditioner for brug af systemet? 10 Vil systemet kunne indføres uden store forandringer? Specielle forhold 20 Er der erfaring med tilsvarende systemer? 21 Ligner projektet tidligere udviklingsforløb? Ved ikke Nej Ved ikke Nej De brugere, som er valgt som vores målgruppe til udviklingen af itsystemet, formodes at være brugere af PC'er og Internet. Systemet skal udvikles i tæt samarbejde med brugerne, og deres krav til funktioner mangler. Brugergruppen formodes at være overskuelig og ensartet. Der er usikkerhed om hvorvidt anvendelsesområdet er overskueligt og ensartet, idet det endnu ikke vides, hvorledes brugerne vil anvende systemet. Denne type system er ikke blevet udviklet før Nej Systemet bliver noget helt nyt, og brugerne skal først vænne sig til anvendelsen af systemet. Nej Tidligere har ingen af gruppemedlemmerne haft erfaring med netop udviklingen af et sådan system. Nej Denne gang skal udviklingen forgå i tæt samarbejde med brugerne, hvilket sikkert vil have indydelse på valget af udviklingsmetode. Spørgeskema Tabel 2.1: Overblik over potentielle vanskeligheder Nr. Spørgsmål: Svar: Beskrivelse: Strategi/Fokus: Problemområde 2 Er modellen af problemområdet Nej Vi har endnu ikke fået Problemområdet overskuelig og enkel? lavet en model over problemområdetelleres mod- Brainstorming med brugerne og en funktionsliste. Forbilledanalyse, spørgeskema, udvikling af brugsmønstre med brugerne Forbilledanalyse, funktionsliste, udvikling af brugsmønstre med brugerne Iterativ udviklingsmetode, prototyper, udvikling af brugsmønstre Iterativ udviklingsmetode, prototyper, Forbilledanalyse Fokus på procesforløbet, Scrum og fokus på kommunikationen mellem brugere og udvikler 2.3 Fokus og Strategi Ud fra tabel 2.1, kan der ses forskellige strategier til løsning af de forskellige spørgsmål i tjeklisten, og herunder er de produkter, der skal udarbejdes, listet. Valg af udviklingsmetode 5

18 Kapitel 2 Magic Spørgeskema Forbilledanalyse Udvikling af brugsmønstre Test af prototype Valg af udviklingsmetode For at udviklingsgruppen kan udvikle et produkt, er det nødvendigt at bruge en udviklingsmetode, som giver mulighed for en iterativ udvikling og størst mulig inddragelse af brugerne. Derfor ses Scrum-udviklingsmetoden brugbar i denne situation. Yderligere begrundelser for valget af Scrum, og hvordan det fungerer, kan læses i kapitel Spørgeskema For at kunne skabe et hurtigt overblik over, hvilken brugerorganisation vi har med at gøre, udvikles et spørgeskema til at indhente informationer om brugerne. Mere herom i kapitel Forbilledanalyse Der bør afholdes en forbilledanalyse, hvor udviklerne fremviser andre it-systemer for at kunne danne sig et overblik over, hvilket slags system brugerne ønsker at få udviklet. Hvordan forbilledanalysen forløb kan læses i kapitel Udvikling af brugsmønstre For at skabe klarhed omkring anvendelsesområdet, afholdes en session, hvor formålet er at skabe og registrere brugsmønstre. Udviklingen af brugsmønstre kan der læses mere om i kapitel Prototype-test Idet udviklingsprocessen er i gang og udviklerne når til et punkt med en fungerende prototype, vil det blive nødvendigt at kunne fremvise systemet for brugerne og lade dem prøve systemet. Dette vil give mulighed for at nde fejl og mangler i systemet, inden en udgivelse af systemet. Hvordan det forløb kan læses i kapitel

19 Magic Kapitel Procesforløb Figur 2.1 viser en oversigt over, hvordan vores udviklingsproces forløber, i forhold til hvordan vi inddrager brugerne i de forskellige stadier i forløbet. Figur 2.1: Procesforløb. 7

20 Kapitel 3 Valg af systemudviklingsmetode I dette kapitel beskrives den agile systemudvikling, valget af systemudviklingsmetode samt en beskrivelse af denne. Teorien er baseret på artiklen The New New Product Developement Game [[14]]. 3.1 Agil systemudvikling Agile metoder adskiller sig fra traditionelle udviklingsmetoder baseret på vandfaldsmodellen med komplet up-front kravspecikationer, analyse og design før en påbegyndt udvikling af et system, ved at være iterative og eksible i forhold til de forskellige fasers længde. Gruppen arbejdede i de tidligere semestre med vandfaldsmodellen som udviklingsmetode, og var derfor interesseret i at gå i en agil retning. Dette skete også på baggrund af semestrets tema, hvilket er "Samarbejde med brugere". Agil systemudvikling har blandt andet det mål at gøre udviklingsprocessen mere eksibel overfor brugernes hurtigt skiftende krav til systemet. I 2001*** oprettede et hold eksperter indenfor agil systemudvikling et manifest af principper, som var med til at gøre agil systemudvikling populært. Vi har taget de principper, vi følte var relevante for netop det projekt, vi ønsker at lave. Kundetilfredshed ved inddragelse af brugere tidligere i udviklingsprocessen. Virkende software tidligere i udviklingsprocessen. Senere ændringer i systemet er muligt (modsat vandfaldsmodellen). Tæt og daglig samarbejde mellem kunden og udviklerne. Face-2-face samarbejde er den bedste form for kommunikation. Projekterne bliver opbygget omkring motiverede individer, som giver mere tryghed. 8

21 Magic Kapitel 3 Konstant opmærksomhed på tekniske specikationer og godt design. Simpelhed. Selv-organiserende teams. Reeksivt samarbejde i teams med intention om at blive mere eektiv. 9

22 Kapitel 3 Magic 3.2 Agile udviklingsmetoder Der er i dag mange populære udviklingsmetoder baseret på det agile paradigme, og nogle af de mest kendte i dag, er Extreme Programming (XP), Unied Process (UP) og Scrum. I forbindelse med udvælgelsen af udviklingsmetode for projektet blev disse gennemgået, og i det følgende er der en kort gennemgang af metoderne, og argumentationen for vores valg. Dette kapitel er baseret på Larmann [[9]], [[1]]. De er alle baseret på det agile paradigme, men med forskelligt fokus i forbindelse med struktur, planlægning og brugerinddragelse. Som tidligere beskrevet fokuserer vi i dette semester på samarbejdet med brugerne, hvilket er en vigtig faktor i valget af systemudviklingsmetode. XP-metoden bliver beskrevet som værende god til brugerinddragelse, hvor udviklerne og brugerne arbejder sammen. For XP vil dette sige en "on site customer". XP kræver derfor, at brugeren under hele udviklingen skal sætte tid af til at sidde med udvikleren, og idet vores projekt er mindre og vores bruger er en frivillig gruppe af magickort-spillere, som ikke har mulighed for at afsætte tid af som ovenfor beskrevet. XP anses ikke som egnet til vores projekt. UP er en metode der blander vandfaldsmodellen og agil udvikling, hvor man har nogle fast denerede faser, der indeholder en eller ere iterative processer inden for hver fase. Igennem faserne ændres fokus på de forskellige aktiviteter. I de første iterationer er der stor fokus på kravsanalyse og design. Dette ændrer sig gradvist hen mod de sidste iterationer hvor fokus på implementering, test og udrulning bliver større. UP ligner derfor vandfaldsmodellen med hensyn til mulighed for inddragelse af brugerne. Dette sker i starten af udviklingsprocessen til udarbejdelse af kravspecikation, og til slut hvor kunden skal acceptere produktet. Derfor anser vi ikke at UP tillader brugerinddragelser gennem hele udviklingsforløbet. Scrum er en agil, iterativ metode og styringsværktøj til et udviklingsforløb. Den er designet til at støtte brugerinddragelse og revidere systemkrav i hver iteration. Den indeholder desuden nogle faste roller og værktøjer, som understøtter kontakt med brugerne gennem hele udviklingsprocessen. Dette er grundlaget for valget af Scrum som udviklingsmetode, og det efterfølgende afsnit vil beskrive Scrum dybere. 10

23 Kapitel 4 Scrum Dette kapitel er skrevet på baggrund af kurset Software Engineering [[6]] og Larman [[9]]. Scrum 1 er en agil udviklingsmetode til håndtering af små såvel som komplekse projekter, og bruges i daglig praksis til at planlægge og overvåge udviklingsforløb. Det er en iterativ proces, hvor hver iteration leverer et potentielt brugbart produkt. Iterationerne kaldes sprints og har en varighed af dage. Scrum betragtes og bruges også i dag til at afgøre koniktende interesser og behov. Scrum bliver kun brugt til at planlægge og styre forløbet i et projekt, og indeholder ikke teknikker til udviklingsaktiviteter. Derfor suppleres Scrum ofte af andre metoder, eksempelvis XP. Scrum bruges ikke kun til udvikling af nye projekter, men kan også bruges til videreudvikling af et eksisterende produkt. Metoden kan bruges til såvel kortvarige som langvarige projekter. Ved større projekter tilpasses Scrum, ved at lade mange sprints blive afviklet parallelt og overlappende. Forløbet i Scrum ses på gur 4.1. I starten bliver der oprettet Figur 4.1: Scrum udviklingsmetode. en Product backlog, hvori generelle krav til systemet blive beskrevet, men ikke i detaljer, da der i de efterfølgende sprints være frihed til at opfylde kravene på optimal vis. Dernæst oprettes en Sprint backlog for det kommende sprint. 1 Ordet Scrum er en term fra rugby og en forkortelse for scrummage som betyder skærmydsler. 11

24 Kapitel 4 Magic Sprintet bliver derefter udført med en varighed på 2-4 uger. Når et sprint er overstået, påbegyndes der eventuelt et nyt sprint, indtil der ikke er ere opgaver. Efter hver sprints inkrementeres der, det vil sige at alt udviklet samles til en opdateret version af produktet som muligvis er testbar. I Scrum bruges der i alt tre roller, tre begivenheder og tre værktøjer som herunder er listet. Rollerne er: Product owner Sprint team Scrum master Begivenhederne er: Sprint planning workshop Daily scrum Sprint review meeting Værktøjerne er: Product backlog Sprint backlog Burndown chart I de næste afsnit vil der være en kort beskrivelse af ovenstående roller, begivenheder og værktøjer. 12

25 Magic Kapitel Roller Product owner Product owner repræsenterer kunden og sørger for at Sprint teamet arbejder med de rigtige opgaver set fra et forretningsperspektiv. Product owner administrerer Product backloggen, som er en to-do-liste der indeholder kravspecikationer for det system der ønskes udviklet. Ofte repræsenteres Product owner af kunden, dog kræver det at denne er oplyst omkring de mulige tekniske speci- kationer, såsom det forretningsmæssige aspekt i systemet. Product owner skal være med til at reducere risikoen for fejlagtige investeringer i systemudviklingen. De to mest fremstående faktorer i succesfulde projekter er brugermedvirken samt en god kravstyring [[17]]. Begge dele ndes netop i Scrum. Sidstnævnte (kravstyring), står Product owner for. Aktiviteter for Product owner: Indsamler ønskede funktionalitetskrav og vurderer dem. Indsamler udestående fejl og mangler i systemet. Prioriterer funktionalitetskravene efter vigtighed. Forandrer og ændrer i prioriteringer. Medvirker til at bestemme hvilke opgaver der skal puttes i hver sprint. Afgør koniktende interesser og behov. Reagerer på synligheden der er tilstede i og ved afslutning af sprintet. Evaluering af et sprint med en reel vurdering. Deltager i Daily scrum, dog som tilskuer. Deltager i Sprint planning workshoppen, Sprint review meeting Scrum master Scrum masteren er en slags projektleder, som også indgår i Sprint teamet. Scrum masterens opgave er at være til stede til alle daglige møder (Daily scrum), og skal være kontaktperson ud af til, f.eks. kunden,product owner samt virksomhedens ledelse. Dog er hovedformålet for Scrum masteren at hjælpe teamet og holde styr på sprint-forløbene. Det er også op til Scrum masteren at afholde evalueringsmødet efter et endt sprint Sprint team Teamet påtager sig arbejde til det kommende sprint på Sprint planning workshop, som bliver beskrevet senere i kapitlet. Teamet er ansvarlig for alt det arbejde, der skal udføres og det er en fordel, hvis teamet selv kan udføre det meste. Selve Sprint backloggen tildeles teamet. Det vil sige at teamet ejer denne og den er urørlig for ledelse og deslige. Scrum teamet, kan bestå af 2-9 deltagere, dog anbefales teams af 5-7 deltagere, da det giver det bedste resultat 13

26 Kapitel 4 Magic [[9]]. Ifølge Scrum er der ingen projektroller og rollebeskrivelser i teamet, dog er der mulighed for oprettelse og uddelegering af roller. Hvad angår opgaver og opgavefordeling, skal teamet være ret uafhængigt af hvilke og hvem som får tildelt opgaverne. Der skal være mulighed for at bytte opgaver blandt deltagerne i det løbende sprint. 14

27 Magic Kapitel Begivenheder Sprint planning workshop Før det første sprint kan gå i gang, deltager Product owner, Scrum master og Sprint teamet i et møde, hvor de tilsammen udvælger de dele fra Product backloggen, de ønsker at udføre i det kommende sprint. Workshoppen skal give mulighed for at opnå en fælles forståelse af sprintet som ligger forude. Man vælger dernæst de højeste prioriteter og sætter dem som de opgaver, der løses først i sprintet og som er logiske i forhold til hinanden. Det er ikke muligt at tilføje nye opgaver, senere i sprintet. Den maksimale tid for hver opgave må højst være 16 timer Sprint Et sprint er normalvis på en periode af 31 dage, dog er det muligt at justerer på sprintets varighed alt efter hvor stort et projekt man har med at gøre. Dog skal man være opmærksom på, at ændrer man på et sprint, skal resterende sprints have samme længde [[17]]. Teamet og Scrum master, arbejder i mindre grupper og udfører opgaverne, som er beskrevet på Sprint backloggen. De kommunikerer ved hjælp af daglige små møder (Daily scrum), hvor status på sprintet bliver diskuteret, samt der bliver beregnet på hvor mange timers arbejde der resterer i forhold til sprintets afslutningsdato (Burndown chart). Såfremt der er for mange opgaver, fjernes opgaverne fra sprintet, og indsættes eventuelt i det næste sprints Sprint backlog. I et projekt er der ofte op til ere sprints før det endelige release af systemet. Dog vil der være mulighed for mini-release efter hvert sprint er færdiggjort, hvor der bliver lavet et Sprint Review, som bliver beskrevet senere i dette kapitel Daily scrum Under sprint-forløbet afholder Scrum master samt teamet daglige møder. Møderne har en varig hed på maksimalt 15 minutter, og alle de deltagende i mødet står op og på en sådan måde at alle kan se og høre alle, og udtaler sig hver især om følgende [[9]]: Hvad vedkommende har arbejdet med siden sidste møde. Hvad vedkommende vil arbejde med frem til næste møde. Hindringer i det forud liggende arbejde. Aktiviteter der skal rettes i sprint backloggen. Lærte hændelser som skal deles med resten af deltagerne. Under mødet udføres der ikke arbejde, og der er kun de fem punkter som diskuteres. Andre end Sprint teamet er velkomne til mødet, dog må de ikke forstyrre teamets fysiske placeringer eller deltage i diskussionen, men kun observere. Disse deltagere kaldes ifølge Scrum, Chickens, hvor Sprint teamet kaldes Pigs. 15

28 Kapitel 4 Magic Sprint review meeting Sprintet afsluttes med et review-møde, hvor Scrum master, teamet og Product owner deltager. Det arbejde, som er blevet udviklet præsenteres, og der evalueres ud fra Sprint planning workshoppen og den udviklede Sprint backlog. Varigheden af reviewet er maksimalt sat til tre timer, hvor der til sidst bliver evalueret fra Product owner. Såfremt der er opgaver, som ikke er løst, bliver de sat i rækken til næste sprint, og der analyseres på hvorfor de ikke blev løst i det afsluttede sprint. 16

29 Magic Kapitel Værktøjer Burndown chart Et andet værktøj i Scrum er Burndown chart, som viser sprintets resterende antal mandetimer, og derved hjælper med at give teamet såvel som andre et overblik over status i sprintet. Charten vedligeholdes udelukkende af teamet og Scrum master. Et eksempel på en Burndown chart ses på gur 4.2 Figur 4.2: Burndown chart Product backlog Som tidligere beskrevet oprettes Product backloggen af Product owner. Product owner har mulighed for at stille nye krav samt rette tidligere krav til systemet. Efter at alle kravene er blevet opstillet, prioriteres de efter hvad der er vigtigst i forhold til det forretningsmæssige aspekt samt det funktionelt virkende system. Denne prioritering laves kun af Product owner, og så snart Product backloggen er færdig, fryser Product owner statussen til og med et sprint er afsluttet. Product backloggen adskiller sig fra Sprint backloggen ved at den indeholder opgavebeskrivelser og funktionskrav frem for aktiviteter, som skal indgå i en angiven periode. Ofte bruges brugsmønstre og scenarier som beskrivelsesskabelon for indholdet i Product backloggen. Product backloggen lever så længe systemet er under udvikling, og vil derfor på ethvert tidspunkt have udestående krav og/eller ønsker. 17

30 Kapitel 4 Magic Sprint backlog Som tidligere beskrevet opretter teamet en liste over de aktiviteter, der skal udføres i det givne sprint for at kunne realisere målet. I Sprint backloggen er der aktiviteter som kodning, test og design. Den oprettes i starten af et sprint. Aktiviteterne udspeciceres til et niveau som for teamet er overkommeligt, og det foreslås at lave aktiviteter med en varighed på maksimalt en hel arbejdsdag. Sprint backloggen lever kun i det givne sprint, og opløses så snart sprintet er udløbet. 18

31 Magic Kapitel Fordele og ulemper Sprint planning workshop Hvis man skal se på Scrums fordele, er den velegnet til udvikling, som baseres på en kravspecikation der ændrer sig. Det kan dog også bruges til projekter med en komplet, korrekt og stabil kravspecikation, som i den situation betyder en høj produktivitet. Scrum handler om at fjerne risici ved hjælp af eksempelvis: Product owners direkte prioritering (Product backlog). Den daglige opfølgning (Daily scrum). Synliggørelsen af fremdrift, problemer og projektets aktiviteter (Sprint review) Ulemper Når vi ser på ulemperne i Scrum, kan de sammenlignes med de generelle ulemper, som der er i iterativ systemudvikling. Derudover produceres der ikke s- tore dokumentationer, og man ender på samme måde ikke med brugsmønstre, sekvensdiagrammer, klassediagrammer osv., som er med til at dokumentere produktet. De kan selvfølgelig produceres, men dette sker ved at oprette dem som krav og opgavebeskrivelser i en Sprint backlog. Det man skal være opmærksom på, er at de ikke normalvis oprettes i Scrum. I kapitel 3 beskrives, hvordan vi netop har tilpasset Scrum til vores projekt, og der reekteres over hvordan det er gået. 19

32 Kapitel 5 Samarbejde med brugere Når der skal ndes brugere til et universitetsprojekt er der visse ting man skal gøre sig klart. Det er vigtigt at brugeren er klar over hvilke betingelser, der er for et samarbejde med en universitetsgruppe. Det er vigtigt at gøre det klart for potentielle brugere at de ikke skal forvente at få en 100 % færdigudviklet og funktionsdygtigt system. Ligeledes er det vigtigt at brugerne er klar over at universitetsstuderende jo er i en læreproces, og derfor måske ikke er de mest professionelle til udførelsen af en opgave. At systemet ikke nødvendigvis når at blive færdigudviklet hænger sammen med at de studerende ved siden af udviklingsarbejdet skal skrive rapport, og deltage i undervisning. Det er dog også vigtigt at huske de positive sider af et samarbejde med universitetsstuderende. Et samarbejde giver mulighed for at hjælpe de studerende, og i sidste ende også gavne samfundet, når de bliver færdiguddannet. Universitetsstuderende kan også være gode samarbejdspartnere fordi de går op i det de arbejder med, det er en del af deres uddannelse. Og selvom man måske ikke ender ud med et 100 % færdigt produkt, kan man få et fundament som man selv kan arbejde videre med. Det er naturligvis også vigtigt at de studerende tænker over disse betingelser når de leder efter brugere. Under vores søgen efter brugere gik vi således meget op i at gøre de potentielle brugere opmærksomme på under hvilke vilkår et samarbejde ville komme til at foregå. Det lykkedes os at nde et par potentielle brugere, og i sidste ende endte vi ud med en ok Magic-spillere. Da der var tale om privatpersoner, var det knapt så presserende at lave ten helt færdigt system, som hvis der havde været tale om en virksomhed hvis forretning ville være afhængigt at systemet. En anden fordel ved dette projekt var at et gruppemedlem sandsynligvis havde interesse i at fortsætte arbejdet med systemet efter endt studieprojekt. 20

33 Magic Kapitel Vores brugere Udvælgelsen af de brugere som skulle bistå med udviklingen af applikationen, skete ved et brainstorming-møde, hvor en række magic-kort-spillere deltog. Her præsenterede de deres behov og ideer til et Magic-statistiksystem, det var med til at åbne op for en længere diskussion om hvad spillerne specielt havde i tankerne. Af de fremmødte spillere var der nogle som var mere interesserede end andre, og som desuden var villige til at bidrage med udviklingen af systemet. Disse interesserede talte otte til ti personer og udgjorde ca. femten procent af en større gruppe af spillere i Aalborg som jævnligt spillede sammen. Gennem udviklingen af applikationen vil det således blive disse otte-ti spillere som vil være vores brugere og de vil dermed repræsentere de andre magic-spilleres interesser. I forhold til Scrum-udviklingsmetoden, der benyttes igennem projektet, er der kun en enkel Product owner, som repræsenterer hele målgruppen. Valget af Product owner blev en fra gruppen, som også selv er medlem af studiegruppen. Begrundelsen for valget af denne person som Product owner er at han har en del års erfaring med Magic, og har arbejdet med små miniprojekter i forhold til studiet samt har en stor interesse i netop at udvikle et system til sin hobby. Derudover har han et godt forhold til resten af Magic-spillerne, og anses for at være samlingspunktet for spillerne imellem. En anden grund til at denne person påtog sig rollen som Product owner, var at Magic-spillerne ikke havde overskud i hverdagen til at kunne hjælpe til "side by side", da dette for alle Magic-spillerne er en fritidsinteresse. En detaljeret beskrivelse af Product ownerens opgave ses i kapitel 6. Et generelt problem i en systemudviklingsproces er, at udviklerne og brugerne ikke nødvendigvis opfatter kravene til systemet ens. Herved kan der opstå risiko for at det forkerte system udvikles, dvs. at systemet kun er udviklet efter udviklernes opfattelse af hvordan systemet skal fungere og ikke efter brugernes. Da det i sidste ende er brugerne, der skal bruge systemet, er det vigtigt at udviklerne får indsigt i brugernes forudsætninger og forestillinger, således at brugernes krav bliver imødekommet og risikoen for at der bliver talt forbi hinanden mindskes. En måde hvorpå udviklerne kan tilstræbe sig at imødekomme brugernes ønsker, er ved at inddrage brugerne i udviklingsprocessen. Herved kan udviklerne nde løsninger sammen med brugerne frem for at nde løsninger for brugerne. Gennem hele dette projektforløb vil vi derfor prøve at fokusere på at inddrage brugeren så meget som muligt. I dette kapitel bliver der fokuseret på de teknikker og udvalgte tilgange til brugerinddragelse, vi har valgt at bruge i systemudviklingsprocessen. 21

34 Kapitel 5 Magic 5.2 Spørgeskemaet Der kan opstå problemer i udviklingen, hvis dialogen mellem udvikleren og brugeren bygger på en forkert opfattelse af brugerens erfaring med udviklingsområdet. Derfor er det en god ide, at danne sig en bedre forståelse af brugerens motivation for udviklingen, samt en god forståelse af deres erfaringsmæssige baggrund. Som udviklere har det stor relevans, at de brugere vi er i kontakt med dvs. den udvalgte fokusgruppe som vi beskæftiger os med, har den rette baggrund for at repræsentere de kommende brugeres interesse Ide og afvikling En spørgeskemaundersøgelse er et oplagt redskab til eektivt at få svar, indsigt i den brede brugergruppes viden, baggrund og holdninger. Før man går i gang med at tilrettelægge spørgsmålene i undersøgelsen, er det vigtigt, at gøre sig helt klart hvad man præcist vil opnå. Vi har valgt at udarbejde et kort spørgeskema, for bedre at kunne danne os et hurtigt overblik over brugerens erfaring med Magic. Specielt erfaringen er relevant, da udviklingen af applikationen hviler på den feedback som erhverves gennem brugerens inddragelse. Hertil bidrager undersøgelsen også til at se om brugerne er homogene på en række punkter. Hertil er det igen muligt at relatere til andre og større undersøgelser inden for samme områder, for at se om de brugere vi arbejder med, er en fornuftig udsnit af den ønskede målgruppe. Selve afviklingen forløb ved at spørgeskemaet blev udleveret til vores brugere. Herefter var fremgangsmåden, at brugerne satte sig sammen i en større gruppe. Her blev de præsenteret for hvordan de skulle udfylde skemaet og hvad vi ville opnå med det. Dertil var der mulighed for at stille spørgsmål, og under forløbet var der desuden mulighed for at spørge om hjælp. Hele processen var afslappet og brugerne udfyldte spørgsmålene på kort tid. Resultatet af spørgeskemaundersøgelsen kan ses i bilag Udviklingsøkonomien Begrebet udviklingsøkonomi dækker over såvel tidsmæssig som nansiel økonomi, i forbindelse med udviklingen af et projekt. Det gælder om at få projektet til at kunne betale sig, at få det optimale arbejde udført på så lidt tid som muligt, og for så lidt penge som muligt. Sådan vil det i hvert fald optimalt set være i en virksomhed. I et universitetsprojekt er det imidlertid lidt anderledes. Her vil udviklingsøkonomien primært omhandle den tidsmæssige del, da der i forbindelse med et universitetsprojekt med stor sandsynlighed ikke er penge involveret. Her gælder det altså om at få udviklingen af et system til at passe ind i forhold til forelæsninger og udarbejdelse af rapport. 22

35 Magic Kapitel 5 Aktivitet: Tidsforbrug: Brugere: Udviklere: Udviklere-timer: Bruger-timer: Forberedelse Transport Møde med brugerne Reektionsmøde Dokumentation Samlet: 22 4 Tabel 5.1: Brugerinvolvering ved spørgeskema, tidsforbrug På baggrund af de opnåede resultater og den fremstillede økonomi, ser vi at udbyttet er alt for lille, set i forhold til de økonomiske omkostningerne processen har haft Reektion Spørgeskemaet var en af de første aktiviteter med brugerne. Det er et udmærket redskab i startfasen af et projektforløb til at få kvantitativ statistik over brugere. Som udgangspunkt er det vigtigt at få deneret formålet med spørgeskemaet. Hvis vi skal se på spørgeskemaet med kritiske briller, kan vi se at udbyttet af den data vi k fra brugerne, er alt for lille i forhold til de timer der blev afsat til udviklingen af forløbet. Vi k bekræftet de antagelser vi havde om brugerne før spørgeskemaundersøgelsen. Mange af spørgsmålede ikke havde et entydgt svar. Desuden opfattede vi enkelte steder, hvor brugerne havde svært ved at forstå spørgsmålene, hvilket betød at spørgsmålene kunne have været udarbejdet mere præcist. Da skemat ikke var det blevet afprøvet af en eller ere personer som ikke havde med til at uarbejde det, Blev disse fejl ikke opdaget. Et spørgeskema er egnet til brug med et større antal brugere, da det ikke kræver meget mere arbejde at afvikle aktiviten med 20 end 6 brugere. En undersøgle med et så lille antal brugere havde sikkert ikke tage længere tid hvis det var foregået i en mere interview ligende form. F.eks. ved at at spørgsmålene havde kræver mere uddybende svar og lagdt op et længere svar. De primære erfaringer ved aktiviten, var at bedre forberedelse og at en større gruppe brugere burde deltage i undersøgelsen, så var resultatet blevet bedre. 23

36 Kapitel 5 Magic 5.3 Forbilledanalyse Når man skal udvikle et nyt system, er det en god ide at undersøge eksisterende systemer tidligt i analysefasen, for at lære af de erfaringer, andre systemudviklere allerede har gjort sig. Som forberedelse til udviklingen af vores applikation, fandt vi det derfor relevant at analysere allerede eksisterende applikationer, for på denne måde at få inspiration til konstruktionen af vores eget produkt. Denne inspiration skal forstås som inspiration til applikationens design, funktionalitet samt indhold, dertil skal den skabe diskussion af gamle samt nye ideer som et led i udviklingsprocessen, se s.30 i Objektorienteret Analyse & Design [[10]] Ide og afvikling Med overstående mål for øje valgte vi at analysere to internet-applikationer, der på hver deres måde ligner det system, vi ønsker at udvikle. Frem for at u- darbejde analysen internt som udviklere, valgte vi den tilgang at lade brugerne være i fokus, således at brugernes egne analyser kunne være med til at danne en god forståelse af deres behov rent funktionelt, dvs. hvilke informationer og funktioner, brugerne havde behov for og hvornår og hvordan disse skulle vises. Desuden er denne teknik med til at give os en bedre forståelse for, om brugerne har ensartede krav eller om der er uenigheder brugerne imellem. Baggrunden for forløbet af analysen var en systematisk gennemgang af de to applikationer overfor brugerne, med det formål at bibeholde strukturen i analysen konsistent over de to analyseforløb. Vi inddelte således gruppen af brugere i to mindre grupper af tre til re deltagere, som hver især skulle arbejde med de to forbilleder på skift. En udvikler gennemgik en række af de funktioner, som forbilledet indeholdte, over for brugerne. Ideen bag dette var at skabe en dialog mellem brugerne, så deres personlige meninger og ideer til bl.a. funktionaliteten kom til udtryk. Begrundelsen for at arbejde i disse mindre grupper, var at skabe bedre muligheder for at den enkelte bruger k sin mening ud, dertil ville en mindre gruppe også mindske muligheden for, at en brugers mening ville påvirke de andre deltagende. Deltagerne virkede engagerede og aktive under processen, dette udmøntede sig i en alsidig diskussion og feedback/respons fra dem. Funktionsforslagene medførte også at brugerne blev inspireret og kom med forslag og ændringer der bedre egnede sig til et magic-system. Så mange af de funktioner, der var hentet fra forbillederne blev tilpasset magic-systemet, idet funktionerne ellers ikke ville optræde i en logisk sammenhæng. Et eksempel herpå er News-feed-funktionaliteten fra Facebook.com. Denne vil i magic-systemet blive anvendt som en opslagstavle over de senest indtastede kampe. Opstillingen for analysen forgik på basisbygningen, hvor vi fandt et ledigt lokale. Der blev samlet nogle borde i hver ende af det store lokale, i den ene ende var der mulighed for at anvende projektor, hvilket vi benyttede os af, for at give brugerne et bedre overblik over forbilledet. I den anden ende kiggede brugerne en udvikler over skulderen. En udvikler stod for afviklingen af hver analyse og til sin hjælp havde han en anden udvikler, vis opgave var at udarbejde referat over brugernes løbende kommentarer og ideer. Selve afviklingen af analysen forløb 24

37 Magic Kapitel 5 Figur 5.1: Opstilling for forbilledsanalyse. således: Brugerne blev opdelt i to grupper, hvorpå hver gruppe arbejdede med hver sit forbillede i 30 minutter, derefter byttede de to grupper forbilleder og forløbet gentog sig. Dvs. vi stod med to analyser for hvert forbillede, udarbejdet af to grupper af brugere. Resultatet af forbilledanalyserne kan ses i bilag A Udviklingsøkonomien Aktivitet: Tidsforbrug: Brugere: Udviklere: Udviklere-timer: Bruger-timer: Forberedelse Transport Møde med brugerne Reektionsmøde Dokumentation Samlet: Tabel 5.2: Brugerinvolvering ved forbilledsanalyse, tidsforbrug Vi er som udviklere godt bekendt med forbilledanalyse, vi har dog ikke fortaget en i samarbejde med brugeren før, derfor bærer økonomien præg af dette, dog i mindre grad Reektion Det vi kort sagt har fået ud af at benytte os af forbilledanalyse-metoden er en kravspecikation over funktioner til magic-systemet. Hvad der har været mest vigtigt her, er at kravspecikationen ikke blev baseret på vores egne antagelser men speciceret ud fra brugernes feedback og deres forudsætninger for hvad sådan et system skal indeholde af funktioner. Formålet med forbilledanalysen var at give brugerne såvel som os selv, inspiration og gode ideer til netop dette. Vi havde fra det første møde med brugerne fået det indtryk, at de i forvejen havde nogle ideer og forestillinger til hvordan systemet skulle udformes. 25

38 Kapitel 5 Magic Af praktiske erfaringer vi har gjort os gennem afviklingen af analysen kan vi nævne, at det ikke var det store problem at den ene af grupperne arbejde fra en laptop frem for en projektor, alle i gruppen var med og der var ikke nogen der havde problemer med at se. Dette begrunder vi bl.a. med at det var små gruppe vi arbejde af 3-4 personer vi arbejde med, hvis der havde været ere brugere vil det have været hensigtsmæssig men to projektorer. Vi erfarede desuden at det ikke var et problem, at vi afviklede de to analyser samtidigt i samme rum. Rummet var tilpas stort til at vi kunne sidde uforstyrret af hinanden i hver sin ende. Igen viste det sig, at det var en fordel at vores to grupper var af mindre størrelse, da der ellers kunne have opstået støjgener. Hvis man skal se kritisk på forbilledsanalysen, var vi ikke alt for gode til at holde en pause imellem de to analyseforløb, da man på brugerne kunne mærke en vis form for træthed, som forløbet skred frem. Derfor er det essentielt at kunne afholde korte pauser, som får brugeren til at få et afbræk, og kunne få deres tanker hen et andet sted. En sådan analyse kan være med til enten at bekræfte at den oprindelige ide var udmærket, at den måske skulle modiceres lidt eller at noget andet ville være en bedre løsning. Med denne forbilledanalyse ville vi gerne danne grobund for en kravspecikation, som vi kunne følge under udviklingen af systemet. Udover at vi k et godt indtryk af hvad brugerne gerne ville have med i systemet, så har vi ud fra oplysningerne kunnet udarbejde en fornuftig kravspecikation, der var bredtfavnende mht. funktioner. Derudover k vi en god dialog med brugerne, så vi k det vi forventede, hvis ikke mere. Forbilledanalyser kan på sin vis være inspirerende, men det kan også ødelægge udviklernes kreativitet ved at der bliver fokuseret meget på de løsninger, forbillederne kommer med og der bliver overset, at det kan løses på en bedre måde, der ligger nærmere brugernes ønsker. Så længe man som udvikler ikke kopier løst uden at være kritisk over de mulige IT-løsninger, er forbilleder en god måde at få inspiration på. En af de store fordele ved netop at involvere brugerne i forbilledanalyse er, at de har meget bedre forudsætninger for at sætte et forbillede ind i deres egene ide om hvordan et system skal opbygges. Da de pr. denition er bedre inde i problemområdet end udviklerne. En forbilledanalyse handler meget lidt om tekniske løsninger, som udviklere traditionelt er gode til at udtænke og mere om funktionalitetsidéer som ikke kræver samme tekniske indsigt. Derfor kan brugere med succes inddrages i denne proces. Mange fra udviklingsgruppen har tidligere stiftet bekendtskab/arbejdet med forbilledanalyse-metoden. Den gang agerede vi både som brugere og som udviklere, og de krav der blev dannet på baggrund af dette, var derfor nogle vi selv fandt relevante i forhold til det system, der blev udviklet. Ved at sammenligne den mere gængse forbilledsanalyse, hvor udviklerne selv lavede analysen, kom vi frem til at det nytter at inddrage brugere og at der kan komme anderledes og brugbart information ud af det, end hvis vi selv havde påtaget os rollen som brugere. Ved at sammenligne denne forbilledanalyse med 26

39 Magic Kapitel 5 tidligere, kom vi frem til, at det nytter at inddrage brugere og at der kan komme anderledes og brugbart information ud af det, end hvis vi selv havde påtaget os rollen som brugere. Der skal tages kritisk stilling til hvilke applikationer der bliver analyseret på. Og at de valgte forbilleder ikke minder for meget om hinanden, såfremt der er ere end to forbilleder, da den feedback som analysen resultere i let kan blive den samme. Der kunne måske være blevet valgt en spilorienteret side som der har mere fokus på spilstatistik end facebook.com, som primært blev valgt på grund af populariteten samt kommunikationselementerne. Ved afholdelsen af en forbilledsanalyse, er det vigtigt at gøre op med hvor mange personer der er deltagende i analysen, og hvor stort et lokale der skal bruges. De rammer som bliver opstillet til analysen, skal være gode for brugerne, så de ikke føler presset, og det miljø det sidder i skal forstyrre deres motivation og engagement i analysen. Vi kan se positivt på forbilledanalysen, dog skal vi være opmærksomme på de ændringer og mangler, som kunne være forårsaget et bedre resultat. Såfremt man har en god forberedelse før forløbet, med f.eks. en række spørgsmål klar til brugerne, kunne det styrke dialogen mellem udviklere og brugere, samt give brugerne plads til at bidrage til indholdet af systemet. I stedet for at vi som udviklere gør det efter vores ideer og antagelser af hvad de ønsker at vil have. Vi k meget stor nytte af vores forbilledanalyse. Det var succesfuldt at foretage forbilledanalyserne i samarbejde med brugerne. Bruger var engagerede og gav god feedback. Vi burde måske have gjort os nogle ere overvejelser om selve udførelsen af forbilledanalysen. F.eks. endte forbilledanalyse-forløbet lidt brat da vi ikke havde sikret os at booke et lokale. Ligeledes burde vi have planlagt lidt nøjere hvordan vil regnede med at forløbet ville være, f.eks. med hensyn til pauser. 27

40 Kapitel 5 Magic 5.4 Brugsmønstre Ide og afvikling Brugsmønster kan være med til at fastlægge anvendelsesområdet, og til denne session er der blevet inddraget brugere til vurdering af brugsmønstre. Der blev afsat tre gruppemedlemmer, og to brugere deltog. Roller blev uddelegeret, så to gruppemedlemmer blev sat til at være observatører, og skrive notater vedrørende hver enkelt af de to brugere, under udarbejdelsen af de forskellige brugsmønstre, mens det sidste gruppemedlem styrede processen. Som forberedelse op til mødet blev det noteret, hvordan sessionen skulle forløbe, forventninger, fordele og ulemper samt de brugsmønstre/scenarier, brugerne skulle konstruere. Dokumentet ses i bilag Under forberedelsen af forløbet blev det drøftet, hvordan brugerne bedst muligt kunne blive motiveret. Der var den holdning, at det var bedst at give brugerne tid til at komme med ideer til systemet. Derfor skulle der ikke være fastlagt for mange betingelser på forhånd, men muligheden for at gå en alternativ vej skulle stå åben. Mødet er udført på en sådan måde, hvor brugerne skal forestille at der er aktuelt system, da der på daværende tidspunkt ikke er et produkt at vise frem. Derfor skulle brugerne forestille sig, at der var et aktuelt system. For at gøre forløbet realistisk skulle mødet afholdes hos et af gruppemedlemmerne og brugerne skulle medbringe deres Magic-kort. Den forventede fremgangsmåde var som følgende: Der blev startet ud med at forklare brugerne, hvad der ville komme til at ske. Herefter gik brugere og udviklere videre med i fællesskab at konstruere udvalgte spilsituationer (brugsmønstre) i form af rollespil og få det til at ligne et virkeligt setup. Brugerne fortalte ved at tænke højt, hvad de forventede at se i systemet, hvordan de forventede at det fungerede, hvilke funktionaliteter der burde være osv.. Herved blev der håbet på, at de kunne forholde sig kritisk og konstruktivt til den abstrakte beskrivelse af brugsmønstrene. Frem til mødet med brugerne var forventningerne, at brugerne var motiverede og med på det konstruerede forløb til at skabe brugsmønstre. Grunden til at der blev valgt at anvende et konstrueret forløb, var for at skabe en mere virkningsfuld fremgangsmåde, end hvis det var en almindelig samtale mellem brugere og udviklere. Endvidere skulle der gerne komme input fra brugerne, der kunne guide udviklingen af systemet i den rigtige retning mht. features/opbygning og få rettet op på eventuelle misforståelser. Hvis brugerne skulle komme med nye idéer, som måske ikke kunne bruges direkte i udviklingen af brugsmønstre, men som passede ind andre steder, ville dette også blive noteret. Der blev regnet med at have 3-4 realistiske beskrivelser af brugsmønstre og tilstandsdiagrammer efter mødet. Mødet foregik under hjemlige omgivelser og i et tilpas stort og lyst opholdsrum rundt om et langt spisebord, hvor de, der skulle tage notater sad i den ene ende, mens de to brugere og ordstyreren sad i den anden ende af bordet. Allerede fra starten af udviklede det sig til dialog af en slags, hvor der blev stillet spørgsmål til brugerne og de svarede og kommenterede. Det var ikke helt den tiltænkte fremgangsmåde, men resultaterne blev ikke dårlige af den grund, da brugernes input var brugbare. Den ene bruger var mere aktiv end den anden og deltog 28

41 Magic Kapitel 5 meget engagerende under mødet. Midtvejs i mødet da det var tiltræng, blev der holdt en pause på fem minutter, hvor der blev sørget for kae og cola. Herefter blev forløbet genoptaget, indtil det sluttede efter en times forløb. På dette tidspunkt gik brugerne i gang med at spille Magic, mens udviklerne yttede sig til et værelse ved siden af, hvor mødets afvikling blev drøftet og udviklerne reekterede over forløbet. Resultatet af Brugsmønster sessionen se i bilag A.10. Figur 5.2: Opstilling for brugsmønster session Udviklingsøkonomien Aktivitet: Tidsforbrug: Brugere: Udviklere: Udviklere-timer: Bruger-timer: Forberedelse Transport Møde med brugerne Reektionsmøde Dokumentation Samlet: 38 4 Tabel 5.3: Brugerinvolvering ved registrering af brugsmønstre, tidsforbrug Økonomien er præget af, at dette er første gang, vi gennemgår processen, så der er en del indlæring som tager ekstra tid. Efter at udviklerne har skabt mere rutine, kan tidsforbruget mindskes Reeksion Ved at se på den feedback brugerne kom med, k vi et bedre og større overblik over hvorledes de forskellige spilsituationer forløber. Deraf kunne brugsmønstre og tilstandsdiagrammer for nogle udvalgte situationer laves ud fra brugernes beskrivelser af hvordan de generelt spiller. Og systemet skal agere som forlængelse af denne spiloplevelse. Vi havde nogle forventninger til hvordan den forberedte session ville foregå. Disse viste sig ikke at holde stik, da det viste sig at et sådan procesforløb er afhængigt af, hvorledes kommunikationen udvikler sig i løbet af sessionen, brugernes indsat og motivation. Erfaringerne af dette forløb, viser at der er en høj risiko for dårlige resultater, ved brug af få brugere. Såfremt begge parter i sessionen havde været passive, havde det skabt en større sandsynlighed for uklare resultater, som ved slutningen af sessionen ikke var til at arbejde videre 29

42 Kapitel 5 Magic med. Derfor er det vigtigt at forberede alternative strategier for mere inddragelse af passive brugere i sessionen. En ide kunne være, at få brugerne k tildelt papirprototyper til at skabe et fælles fokuspunkt, som ville have hjulpet med at bibeholde fokus på sessionen. Inden mødet med brugerne havde vi ikke fået udviklet nogle brugsmønstre, men vi havde skitser til hvordan de kunne se ud. Her ville det have været godt, hvis vi havde færdigudviklet udvalgte brugsmønstre og præsenteret dem for brugerne. Hernæst kunne vi i samarbejde med brugerne udvikle de udvalgte brugsmønstre efter hvordan de syntes det skulle være, hvorved ville vi stå med to versioner af den samme brugsmønstre og deraf lave den endelige version af brugsmønster. Vi k i vores brugsmønstersession også input fra brugerne, som guidede os i den rigtige retning med hensyn til features og opbygningen af systemet, og endnu engang k rettet eventuelle misforståelser af vores opfattelse af spillernes tankegang og forventninger til systemet. På reektionsmødet som vi som udviklere holdte bagefter, blev vi enige om, at det ville være en god idé at sætte som mål at lave et brugbarhedstest på systemet, netop for at fange denne type af situationer. Alternativt kunne det være en idé at involvere brugerne i at få lavet scenarios, for at fange mulige nye krav som ville forekomme. 30

43 Magic Kapitel Prototypetest Som udviklingen af et nyt produkt skrider frem, er prototypen med til at kunne inddrage brugerne på sådan en måde at de, såvel som udviklerne får en bedre fornemmelse for produktet, dvs. de får mulighed for at udforske og vurdere alt lige fra funktionalitet, brugervenlighed til det graske design af applikationen Ide og afvikling Før man kan teste og analysere henholdsvis applikationen og brugernes interaktion, er det dog vigtig at forberedelsen for testen er i orden. På gur 5.3 ses de fem hovedpunkter, som er hensigtsmæssig at følge, for at opnå en struktureret opbygning for det overordnet forløb, se Planlægning af en usability-evaluering [[15]]. Figur 5.3: Processtruktur. Med udgangspunkt i denne struktur har vi udarbejdet en onsite usabilitytest på baggrund af vores prototype, den grundlæggende ide i denne testtype er at testet kan afvikles på en dag, og desuden afvikles uden brug af videoanalyse, med forbillede i Instant Data Analysis [[8]]. Den centrale ide i vores test, er at brugsmønstrene vurderes gennem planlagte eksperimenter med brugerne, hvor brugerne gennemgår brugsmønstrene vha. prototypen i så relevante og realistiske omgivelser som det er muligt, jf. Objekt Orienteret Analye & Design s.32 [[10]]. For brugerne, giver dette mulighed for at udforske og vurdere brugsmønstreforløb, udformning, relevans og dertil komme med kommentarer til udviklerne, enten fordi de har ændret deres holdning til indholdet, eller fordi de er udviklet 31

44 Kapitel 5 Magic på baggrund af miskomminikation mellem de to parter. For udviklerne giver dette mulighed for at observere brugerne og derved får bekræftet eller afkræftet det arkitektoniske såvel som det graske design. Dvs. opbygning og udformning af funktioner samt navigationen og dermed brugervenligheden i applikationens graske fremtoning. Med dette mål for øje valgte vi at udarbejde en test med brugerne i centrum, dels fordi vi ønskede bekræftelse på, at den applikation vi udvikler lever op til de brugernes funktionelle forventninger, som er fremsat på baggrund af tidligere dialog, men også fordi vi ønskede at se hvordan brugerne interagere med applikationen og hvilke komplikationer som kunne opstå og derved give os indblik over faktorer som vi ikke har afhandlet rigtig og derpå kan forbedre. Vores egen forventninger til fremvisningen af prototypen for brugerne og den efterfølgende test, er at brugerne ville stille motiveret og være med til at give en masse kreativt feedback til rettelser og videreudvikling af produktet. Selve forløbet blev afviklet hos Product owneren som stillede to stuer til rådighed, den ene indrettet således at brugerne havde mulighed for at dyrke deres spil, hertil sørgede vi for at servere vand og snacks for at stimulere stemningen. Det andet rum var indrettet således at brugeren havde tilgang til en pc med applikationen og der yderligere var gode observationsmuligheder for udviklerne. Under forløbet kom brugerne på skift ind og udførte en række opgaver inspireret af brugsmønstre på baggrund af de kampe, som lige var blevet afviklet brugerne imellem. Inden brugerne k adgang til applikationen k de en vejledning i hvorfor vi udførte denne test og hvilke opgaver vi ønskede at de skulle udføre. Derpå lod vi brugeren koncentrere sig om opgaverne og observerede resultaterne, under hele forløbet blev der taget notater og desuden blev brugerne opfordret til at tænke højt dvs. komme med de øjeblikstanker som opstop under afviklingen, som letter registreringen af fejl. Notaterne kan ndes i bilag F. Figur 5.4: Opstilling for prototype test. 32

45 Magic Kapitel Analysen De brugsmønstre der blev lagt vægt på i dette forløb var oprettelse af en prol, oprettelse af et deck og oprettelse af en kamp. På baggrund af disse var det i øvrigt muligt for brugeren at se de resulterende statistikker. I denne analyse af prototype blev der primært lagt vægt på applikationens funktionelle design, dvs. at vi som udviklere i første omgang var interesseret i feedback på de udarbejdede funktioner som brugerne testede på baggrund af de opstillede brugsmønstre. Denne feedback kan vi inddele i forskellige kategorier herunder kosmetiske, alvorlige, kritiske og katastrofale problemer. Resultatet af prototypen kan ses i bilag F Udviklingsøkonomien Aktivitet: Tidsforbrug: Brugere: Udviklere: Udviklere-timer: Bruger-timer: Forberedelse Transport Møde med brugerne Reektionsmøde Dokumentation Samlet: Tabel 5.4: Brugerinvolvering ved prototype test, tidsforbrug Fremvisningen af prototypen og den efterfølgende analyse har givet os store mængder feedback, hvilket gør at det økonomiske aspekt ser rigtig godt ud. Økonomien havde været højere ved afvikling i laboratorium, frem for onsite, det havde kostet ere bruger timer både i transport og afvikling Reeksion Testen var som nævnt ikke struktureret så fast som tidligere test som udviklergruppen har afviklet. Dette k brugerne til at slappe af og gjorde at der blev nået langt omkring i funktionerne. Da vi var tre personer under prototypetesten, havde vi intet problem med hensyn til efterbehandling af resultaterne. Såfremt vi havde haft andre til at arbejde med resultaterne havde vores ustrukturerede tilgang til testen, påvirket resultatbehandlingen og en mere uklar analyse havde været fremkommet. Derfor kan man sige, at der skal tages forbehold når man udarbejder prototypetest med en ustruktureret gennemgang, og det netop ikke i alle situationer kan give gavn, i vores tilfælde gjorde det. Miljøet som afviklingen af prototypetesten foregik i, har stor indydelse på brugeren. Vi har tidligere arbejdet med prototypetests i laboratorium. Denne gang valgte vi at foretage testen i brugernes vante omgivelser, for at skabe et mere afslappet testmiljø. Dette medførte at stemningen blandt brugerne var mere behagelig og afslappet, end hvis vi havde foretaget en laboratorietest. Hvis vi havde valgt at foretage en laboratorietest havde der været ere faktorer at tage højde for. Et laboratorie vil sætte brugerne i uvante og muligvis utrygge omgivelser. Derfor skal der gøres mere ud af at få brugerne til at føle sig trygge 33

46 Kapitel 5 Magic i forbindelse med testen. Derfor vil en laboratorietest kræve mere forberedelse og potentielt være mere stressende for brugerne. 34

47 Kapitel 6 Proces I dette kapitel beskrives Pre-game-planlægning og udførelsen af de tre sprints, som blev gennemført i udviklingen af produktet. 6.1 Pre-game Planlægning Scrum-metoden anbefaler en planlægningsworkshop, og derfor blev der afholdt en planlægningsarbejde-session, hvor et medlem af gruppen repræsenterede den såkaldte Scrum master, og et andet medlem fra gruppen repræsenterede Product owner. Efter vi havde lavet en såkaldt Product backlog, kontaktede vi en ansvarlig fra Magic-gruppen, som kommenterede og kom med forslag til rettelser samt prioriteringen af emner i Product backloggen via MSN Messengerkorrespondance. Figur 6.1 viser Product backloggen. Figur 6.1: Product backlog 35

48 Kapitel 6 Magic Rollefordeling Uddelegering af roller i forhold til Scrum-udviklingsmetoden blev foretaget efter et lille møde under planlægningssessionen. Der blev diskuteret interessefelter i forhold til projektet, og på baggrund af disse uddelt roller. En af gruppemedlemmerne blev udnævnt til Scrum master, en anden til Product owner. De resterende medlemmer blev Sprint team, som i Scrum bliver kaldt for Pigs. Valget af Product owner blev en, som også selv var medlem af studiegruppen. Baggrunden for det er, at han har en del års erfaring med Magic. Han har derudover et godt forhold til resten af Magic-spillerne og anses for at være samlingspunktet for spillerne. Dertil skal det siges, at det ifølge Scrum er nødvendigt med en Product owner onsite, derfor var det nødvendigt at udpege en af udviklerne. Begrundelsen for dette valg udmunder også i, at Magic er en fritidsinteresse, og på baggrund af dette var Magic-spillerne alle optaget af andet i hverdagen. Figur 6.2: Product owner. Figur 6.3: Scrum master 36

49 Magic Kapitel Tidsplan Før påbegyndelsen af sprint-processen blev det besluttet at lave tre sprints i processen. Selvom Scrum-metoden fortæller, at et sprint optimalt varer omkring 31 dage, valgte vi at forkorte og ikke at benytte os af samme varighed på de forskellige sprints. Vi havde i starten af projektet brugt en del tid på at sætte os ind i den nye udviklingsmetode. Derfor blev der valgt at sætte første sprint til en varighed af to uger, dernæst andet sprint på en varighed af 2,5 uge, og sidste sprint på en varighed af 2,5 uge. Ifølge Scrum er det bedst at benytte så mange sprints som overhovedet muligt, idet man derved kan lave est iterationer af produktet. For at vi kan reektere på vores projekt, har vi måtte begrænse antallet af sprints til tre. Figur 6.4: Tidsplan På gur 6.4 ses en illustration af den planlagte tidsplan, hvor starttidspunkterne for de tre sprint ses (første sprint: 12. marts - andet print: 27. marts - tredje sprint: 14. april). Dernæst blev systemet udgivet og efterfølgende testet. De forskellige sprints beskrives i en mere detaljeret form, hvor der vil blive set på planlægningen af sprintet. Her vil der blive beskrevet hvert møde med Product owneren og hvad der kom ud af møderne. Dernæst vil der være et overblik over produktet, som eksempliceres via illustrationer og lignende. Til sidst vil der blive set på reeksionen over sprintet samt på fordele og eventuelle forbedringer. 37

50 Kapitel 6 Magic 6.2 Foranalyse I dette kapitel bliver det kort forklaret, hvilke metoder der er blevet anvendt i foranalysen. Som udgangspunkt var det nødvendigt først at nde ud af, h- vad systemets formål var. Formålet blev bestemt efter vores første kontakt med brugerne og kan læses i bilag A.1. For at få et bedre grundlag for den videre analyse blev der lavet en systemdenition. En systemdenition beskriver bl.a. systemets indhold, hvad det skal kunne, hvad det skal bruges til og hvilke betingelser, der gælder for udviklingen af det. Herved hjælper systemdenitionen med at fastlægge de fundamentale egenskaber for udviklingen og brugen af systemet [[10]]. For at få et overblik over vigtigheden af de forskellige krav til systemet, benyttes et prioriteringsskema, dette ses i bilag A.4. Ud fra systemdenitionen tog vi udgangspunkt i BATOFF-kriteriet, der består af seks elementer, for at sikre at systemdenitionen indeholdte alle aspekter af systemet, og for at evaluere om den var god. Vi valgte herefter at se på problemog anvendelsesområdet, der viser to forskellige men tæt relaterede syn på systemets omgivelser. I problemområdet ses der på den af omgivelserne, der skal administreres og styres af systemet. Her beskrives virkeligheden, som brugerne skal se den. For at se hvilke informationer systemet skulle behandle, lavede vi en illustration af problemområdet. I anvendelsesområdet ses der på den brugerorganisation, der skal anvende problemområdet. Formålet er at denere krav til systemets funktioner og grænse- ade. Dette område blev ligeledes illustreret og kan sammen med illustrationen for problemområdet ses i bilag A.5. De nævnte metoder blev primært valgt, fordi vi med disse kunne gå i gang med foranalysen uden nødvendigvis at have haft uddybende møder med brugerorganisationen først. Ud fra resultatet af de ovenstående aktiviteter, k vi lavet et klassediagram, der giver et samlet overblik over systemets problemområde. Klassediagrammet kan ses i bilag G. Formålet og systemdenitionen bevirkede, at både gruppen og brugerne overordnet k en fælles forståelse for, hvordan systemet skulle være til at starte med. Med problem- og anvendelsesområdet k vi modelleret omgivelserne og med disse resultater kan krav til systemet og andre detaljer blive nærmere bestemt i samarbejde med brugerne i de efterfølgende aktiviteter. 38

51 Magic Kapitel Første sprint Formål og forventninger Det forventes, at ved afslutningen af sprint 1, som bliver den 27. marts, er der gennemført brugerinvolvering ved hjælp af forbilledanalyse, og at der ud fra resultaterne af denne analyse er en forståelse for, hvad der bør prioriteres på produktet. Det forventes, at disse prioriteringer bliver bragt til nytte ved at udforme en hjemmeside bygget på disse prioriteringer. Ved slutning af sprint 1 er det formålet, at teamet skal have bedre indsigt i: Hvordan brugere kan involveres i en forbilledanalyse. Hvorvidt det er til nogen nytte at bruge spørgeskemaer til andet end en kvantitativ undersøgelse. Udnyttelse af Microsoft Visual Studio som udviklingsmiljø. Hvordan det færdige produkt skal udformes. Hvordan produktets database implementeres Det faktiske forløb Det første sprint var i forhold til projektets andre to sprints det længste, det var planlagt på denne facon for at lade teamet få en forståelse for Scrum. Opgaverne, der blev løst i første sprint, og som kan ses i bilag C.1, bestod af en lille men essentiel samling af opgaver. På gur 6.5 ses et udsnit af vores Sprint backlog, en gur i fuld størrelse er præsenteret i bilag C.4 på side 106. Opgaverne var valgt ud fra den tese, at når de er løst vil teamet være væsentligt bedre rustet til at løse de resterende opgaver i Product backloggen. Set ud fra klassediagrammet og prioriteringen af opgaverne i Product backloggen var player-klassen det umiddelbare fornuftige sted at starte. Player-klassen ville være nødvendig for de andre klasser, og kravene for at implementere player-klassen ville tilfredsstille mange af kravene til implementeringen af de andre klasser med hensyn til GUI, funktioner og persistens. Da der blev stræbet efter at involvere brugerne meget i produktets udvikling, blev det besluttet at lave en forbilledanalyse (se afsnit 5.3) i samarbejde med brugerne frem for af udviklerne alene. Dertil blev der inkluderet spørgeskemaer i Sprint backloggen for at opnå viden om brugernes baggrund og erfaring med Magic mm. frem for at opstille personas. Som et sidste punkt i Sprint backloggen skulle der udarbejdes et matchsheet. Dette er en printervenlig side, der skal være adgang til fra applikationen, så denne kan printes ud og bruges til at indskrive kampe på. Matchsheetet er med på dette tidlige tidspunkt, for at få maximalt respons på dets udlæg fra brugerne. I bilag C.1 ses produktet som kom ud af første sprint. 39

52 Kapitel 6 Magic Figur 6.5: Uddrag af første sprint Burndown chart Efter afviklingen af første sprint, vil vi her se på det første sprints forløb i forhold til timeantallet, som blev sat af til sprintet. Som tidligere nævnt, blev de vigtigste opgaver i sprintet udført først og de mindre vigtige senere i forløbet. På diagrammet, som ses på gur 6.6, ses to linjer, som viser det forventede forløb i forhold til timeantallet (mørke linje) og det reelle forløb (lyse linje). Man kan se, at de to linjer ligger meget op ad hinanden, og dermed at opgaverne blev udført efter den forventning, vi havde til hvordan de ville blive udført. På begge linjer kan man se to steder, hvor linjen forbliver den samme over en given periode, hvilket skyldes ferie samt forelæsningsfulde dage, hvor der ikke har været tid til at arbejde med projektet. Der var i alt 261 timer til rådighed i sprintet, som blev fordelt ud på de syv personer, som Sprint teamet bestod af Reeksion En af aktiviteterne i Scrum efter sprint nummer et, er at teamet stiller sig selv nogle spørgsmål for at kunne reektere over den afsluttede proces. Den indgangsvinkel vi tog for at svare på disse spørgsmål, var en brainstorm-agtig proces for at få alle udviklernes kandidater til svar, og det ville få tankerne i gang hos andre. Spørgsmålene og svar på disse var følgende: Hvad bør vi gøre i større grad? Holde Sprint backloggen opdateret. Holde møde hver dag vi udvikler (Scrum-møde). Arbejde uden om problemerne. 40

53 Magic Kapitel 6 Prioritere opgaverne. Hvad bør vi gøre i mindre grad? Blive afhængige af andre. Figur 6.6: Første Burnown chart Hvad bør vi fortsætte med at gøre? Programmere i par. En del af svarene gav anledning til diskussion og ændring i forhold til næste sprint. Sprint backlog Det viste sig her, at Sprint backloggen ikke var blevet brugt, som det var tiltænkt i Scrum. Et af problemerne var, at den ikke blev opdateret løbende, ydermere blev datoen for afslutningen af sprintet rykket under afviklingen, og dette blev ikke rettet i backloggen. Et andet problem med den var, at den ikke var detaljeret nok, nogle af opgaverne blev delt mellem ere udviklere og blev derfor splittet op. Beskrivelsen af disse opgaver kom på vores tavle i grupperummet i stedet for i loggen. Dette gjorde backloggen endnu mere irrelevant, og derfor blev der generelt ikke rettet i den. Ansvaret for den dårlige opdatering af Sprint backloggen ligger hos Scrum master, som i dette tilfælde ikke har været opmærksom nok på hans rolle i teamet. For at gøre Sprint backloggen mere relevant, da den er et godt værktøj til at give overblik over opgaverne, rettede vi den til for at underbygge vores måde at arbejde på. Dertil blev det påpeget for Scrum masteren, at der skulle være mere fokus på denne opgave. Dertil vil større opgaver i Sprint backloggen blive yderlige splittet op i to eller ere dele, hvis der opstår behov for dette under afvikling. Vi holdt dog fast i, at der ikke kunne tilføjes yderlige opgaver til et 41

54 Kapitel 6 Magic sprint. Backloggen indeholdt desuden oplysninger, der ikke blev brugt, et eksempel er starttidspunktet som var det samme for alle opgaverne. Dette regnede vi dog med at ville ændre sig, da der skulle ligge ere opgaver i næste sprint, grundet at vi nu som udviklere er mere fortrolige med programmeringssproget og udviklingsmiljøet, og derfor kan nå mere i et sprint. En anden ting var, at der var to opgaver i sprintet, som ikke blev udført af den grund, at de begge ikke burde være der netop i det første sprint. Dette blev heller ikke opdateret, og ses også i bilaget som en opgave som ikke blev udført. Daily scrum-møder Afviklingen af disse møder var ikke regelmæssig, som det skulle være ifølge Scrum. Dette var der to grunde til. For det første var de este dage planlagt med forelæsninger, således at der kun var begrænset tid til projektet, og derfor var der ingen regelmæssighed i, hvornår vi arbejdede med det. På baggrund af dette blev møderne ikke indarbejdet som Scrum ellers lægger op til. For det andet betød de mange halvdage med projektarbejde, at der ikke blev nået så meget, så det kom til at virke lidt overdrevet med et møde hver dag. Alle var dog enige om, at vi skulle blive bedre til at holde møderne. Opgaverne bliver så at sige mere ocielle, når man hver dag skal føre en dialog på baggrund af, hvad man har lavet og skal lave. Dette betød, at man følte sig mere ansvarlig for, at de blev færdige. Møderne gav desuden hele gruppen et bedre overblik over sprintets udvikling. Prioritering af opgaver De udvalgte opgaver blev ikke prioriteret i forhold til hinanden, dvs. vi dannede os ikke et overblik over, hvordan en opgave kunne afhænge eller påvirke andre opgaver. Desuden kiggede vi ikke på, hvordan vi kunne arbejde videre, hvis en opgave ikke kunne løses hurtigt nok. Dette gav eksempelvis problemer, da databaselaget i applikationen blev implementeret, her var vi afhængige af et værktøj kaldet DB ow (ses 7.1). Dette værktøj var under udvikling, og kunne ikke direkte understøtte det databasesystem, vi udviklede til MySQL. Udvikleren af DB ow arbejdede på at understøtte MySQL, men ikke så hurtigt som vi havde regnet med. Havde vi dannet os et overblik over opgavernes interne afhængigheder, havde vi opdaget, at dette lag kunne give problemer, hvis det ikke var færdigt. Problemets omfang kunne minimeres, hvis vi havde gjort os tanker om hvorvidt og hvorledes det ville være muligt arbejde uden om problemet, eksempelvis ved at implementere et minimum af DB laget selv, så lagene ovenpå kunne testes. En anden løsning var at have en backup-plan, således at vi var klar til at klare hele opgaven, selv hvis det viste sig, at DB ow ikke kom til at dække vores behov. Par-programmering Gennem hele projektarbejdet i første sprint, har vi stort set arbejdet på de samme tidspunkter og det samme sted. Dette har givet gode muligheder for at støtte hinanden, og opnå en god fornemmelse af hvor vi var i processen. Desuden har vi i ere tilfælde udøvet par-programmering med stor succes. Opdelingen 42

55 Magic Kapitel 6 betød at en opgave med mange ukendte variabler kunne løses nemmere og med efterfølgende vidensopbygning hos to personer. Dette tog vi videre til de efterfølgende sprints, hvor det formaliseredes mere. 43

56 Kapitel 6 Magic 6.4 Andet sprint Formål og forventninger Vores andet sprint startede d. 9. april, og var et forholdsvis kort sprint på kun en uge, som blev afsluttet d. 17. april. Vi følte, at de næste par opgaver var små, og besluttede derfor at oprette en mindre sprint-periode for at kunne nå endnu et sprint inden udgivelse af systemet. Ved afslutningen af sprint nummer to, var det forventet at gennemføre en brugerinvolveringssession, hvor brugsmønstre og tilstandsdiagrammer ville blive udviklet i samarbejde med brugerne. Derudover var et krav i sprint to at få persistenslaget til at fungere, så vi kunne få forbindelse til databasen samt at kunne oprette decks og matches. Ved slutning af sprint to er det formålet, at teamet skal have bedre indsigt i: Hvordan de forskellige brugsmønstre ud fra brugernes brug af systemet ser ud. Hvordan relationen imellem et deck og en player udvikles. Hvordan en match oprettes i systemet og relationen til henholdsvis en player og et deck udvikles. Hvordan produktets database implementeres, både på nettet som lokalt Det faktiske forløb Det andet sprint er i forhold til de andre sprints det korteste, og det er planlagt på en sådan måde at Sprint temaet afslutter en masse små opgaver på en uge. På gur 6.7 ses et udsnit af vores sprint nummer to, en gur i fuld størrelse er præsenteret i bilag C.4 på side 107. Eftersom vi i forrige sprint k udviklet player-controlleren, og vi nu kan oprette players i systemet, var de væsentligste opgaver i sprint to at kunne oprette decks og matches, samt at få databasen til at fungere både lokalt såvel som online. En anden opgave som blev prioritet højt var brugerinvolveringen, hvor der blev udviklet brugsmønstre, scenarier og tilstandsdiagrammer for brugerne i systemet. En sidste opgave var håndtering af statistikken, hvor GUI'en til visning af statistikken skulle designes. I bilag C.2 ses produktet, som kom ud af andet sprint Burndown chart I forrige sprint havde vi i alt 261 mande-timer til rådighed. Dette tal er væsentligt mindre i dette korte sprint, i alt 182 mande-timer. Vi vil her prøve at beskrive, hvorledes vort andet sprints forløb er delt op og forløbet. I sprintet blev de højtprioriterede opgaver udført først og dem med mindre prioritet udført senere i forløbet. På diagrammet, som ses på gur 6.8, ses vores Burndown chart for sprint nummer to, hvor den lyse linje viser timeantallet, som er til rådighed og den mørke linje viser det reelle forløb. På Burndown charten til sprint to, ses det tydeligt at de to linjer afviger langt mere fra hinanden end i forrige sprint, hvor de lå meget tæt på hinanden. Dette 44

57 Magic Kapitel 6 Figur 6.7: Uddrag af andet sprint sprint er kortere, og det ses at der er mere tid til rådighed (mørke linje), end der var estimeret (lyse linje). Dette skyldes, at opgaverne skulle løses inden sprintets afslutning, samt der var en forelæsning, vi i sprint-teamet ikke følte relevant i projektet, som derfor gav os 28 ekstra mande-timer til at udvikle videre på projektet i. Der var estimeret i alt 182 timer, og den reelle tid, som var brugt i sprintet var 210 mande-timer. De 210 timer blev delt ud på Sprint teamets medlemmer, som hver gennemsnitlig k 30 arbejdstimer at udvikle på. Figur 6.8: Anden Burndown chart Reeksion Som i første sprint var en af aktiviteterne reeksion over det færdiggjorte sprint, hvor vi som Sprint team stillede os selv nogle spørgsmål for at reektere over den afsluttede proces. Indgangsvinklen vi valgte, var den samme som forrige 45

58 Kapitel 6 Magic sprint med at svare på forskellige spørgsmål, som her igen bliver listet. Hvad bør vi gøre i større grad? Flere Daily Scrum-møder. Mere fokus og brug af par-programmering. Prioritere opgaverne efter deres afhængigheder. Hvad bør vi gøre i mindre grad? Hvad bør vi fortsætte med at gøre? Holde Sprint-backloggen opdateret. En del af svarene gav anledning til diskussion og ændring i forhold til næste sprint. Sprint backlog I dette sprint blev Sprint backloggen brugt meget mere end i forrige sprint, her til viste Scrum master større ansvarlighed og spurgte jævnligt de forskellige medlemmer i Sprint teamet, om hvordan det gik med opgaverne og blev på den måde opdateret. Fejlen heri, var at Scrum masteren ikke delte denne information med resten af teamet, og derfor blev der ikke afholdt Daily scrum-møder, netop derfor vil der blive taget ekstra hånd om Sprint backloggen i næste sprint. Det at Sprint backloggen er tilgængelig for alle, har indtil videre givet Scrum masteren en følelse af sikkerhed for fremskridt, her er det derfor ikke svært at forestille sig Sprint backloggens styrke, hvis både teamet og projektet var af større dimensioner. Herved vil hver udvikler gøre mere brug af Sprint backloggen, idet der vil være ere opgaver, samt ethvert medlem vil få mulighed for at opdatere opgavens status på baggrund af dens progression. Sprint backloggen demonstrerer derved essensen af den agile udvikling, og kan derved udspecicere og simplicere opgaverne så meget, at man kun skal koncentrere sig om mindre opgaver, som er nemme at huske og overskue. Vi konkluderer derfor, at Sprint backloggen skal bruges og opdateres af alle i Sprint teamet og derved bliver et stærkt værktøj til at give overblik over både opgavernes længde og fordeling af dem samt relationerne mellem dem. Daily scrum-møder Møderne blev afholdt en del gange i sprintets forløb, dog blev det konstateret, at det ikke blev gjort så ofte som forventet, og derfor kom Sprint teamet frem til, at der hver dag, som det også er skrevet i Scrum, skulle afholdes et møde. Dette ville give teamet erfaring med at holde overblik over projektets gang, dvs. hvad der mangler at blive lavet og hvad man har lavet. Derudover er det også med til at koge møderne ned til, at man kun diskuterer det, som er mest relevant under afholdelsen. I teamet blev der aftalt to mødetidspunkter, hvor Daily scrum kunne afholdes kl på de dage, hvor teamet starter med projektarbejde fra morgenstunden, og på de dage, hvor der er forelæsninger om morgenen. De dage, hvor der er forelæsning hele dagen, bliver der ikke afholdt Daily scrum. 46

59 Magic Kapitel 6 Par-programmering I forrige sprint blev det konstateret, at teamet skulle blive ved med at programmere i par. I dette Sprint review blev vi igen enige om at blive ved med at programmere i par, idet sidste sprint ikke var over en længere periode, og vi ikke har brugt det så meget som vi har ønsket for at kunne analysere på, om ideen med par-programmering er god nok. 47

60 Kapitel 6 Magic 6.5 Tredje sprint Formål og forventninger Tredje og sidste sprint blev afviklet i perioden 22. april til og med 30. april, og var som det forrige et forholdsvis kort sprint. Opgaverne, som blev udført i dette sidste sprint, var de opgaver som i Produkt backloggen var vigtigst at gennemføre, før et endeligt udgivelse af systemet. Ved afslutningen af det tredje sprint, var det forventet, at systemet kunne udgives og testes af rigtige brugere. De største og vigtigste ting, som dette sprint skulle afvikle, var en brugerinvolveringssession, hvor der onsite blev testet på systemet og fundet fejl og mangler inden det endelige udgivelse. Derudover skulle statistikvisningen samt søgefunktionen i systemet være færdigudviklet ved afslutning af sprintet. Ved slutning af sprint nummer tre er det formålet, at teamet skal have bedre indsigt i: Hvilke fejl og mangler der er i systemet før en given udgivelse. Hvorledes statistikken for spillere, decks og kampe bliver udviklet og vist. Hvorledes søgefunktionerne skal virke og resultaterne skal fremvises Det faktiske forløb I dette sidste sprint var statistikvisning, søgefunktion samt involvering af brugere (on-site location) de vigtigste emner. I Sprint backloggen blev statistikvisning spået til at være den opgave med størst kompleksitet, hvilket gjorde, at der blev afsat est timer til udførsel af denne opgave. Dernæst blev søgefunktionen udviklet og brugerinvolveringssessionen blev afholdt to dage før afslutning af sprintet for at kunne teste før en afslutning, der dermed kunne give anledning til rettelse af fejl og mangler, som var spottet under sessionen. Herunder på gur 6.9, ses et udsnit af Sprint backlog nummer tre, en gur af den i fuld størrelse er præsenteret i bilag C.4 på side 108. Vi kan nu oprette spillere i systemet med decks og tilføje kampe med kampgodkendelse fra modparten. Vi kan nu søge i spillere og decks og få vist de kampe som er spillet. Vi kan nu se statistik på spillere, og se rates i forhold til andre spillere i systemet. I bilag C.3 ses produktet, som kom ud af tredje Sprint Burndown chart Dette sprint var planlagt til at have i alt 144 mande-timer til rådighed, og vi vil herunder beskrive, hvorledes sprintets timer er blevet brugt. Der blev sat est Sprint team-udviklere på opgaver med størst kompleksitet og disse blev udført først, hvor mindre opgaver blev udført senere i forløbet. På diagrammet på gur 6.10 ses vores Burndown chart for sprint tre, hvor den 48

61 Magic Kapitel 6 Figur 6.9: Uddrag af tredje sprint lyse linje viser timeantallet, som er til rådighed og den mørke linje viser det reelle forløb. Trods de 144 mande-timer, som var afsat til forløbet, valgte Sprint Figur 6.10: Tredje Burndown chart temaet at fravælge en del forelæsninger i perioden, hvilket gav ekstra tid til at udføre opgaverne, og dermed fuldføre sprintet med de opgaver, som skulle løses. I alt k vi ved aysning af diverse forelæsninger forøget timeantallet til 216 mande-timer. De 216 timer blev delt ud på Sprint teamets medlemmer, som hver gennemsnitlig k 30 arbejdstimer at udvikle på Reeksion Som i de tidligere sprints har en aktivitet i sprintet været reeksion over et endt sprint, hvor vi som Sprint team stiller os nogle spørgsmål for at kunne forbedre 49

62 Kapitel 6 Magic et fremtidigt sprint. Da dette var det sidste sprint i vores udviklingsforløb, har vi ikke haft den samme tilgang til reeksionen over sprintet som tidligere sprints, og har derimod reekteret over de forskellige emner, som kom op til diskussion i løbet af vores Sprint review-session i Sprint teamet. Sprint backlog I dette sprint har teamet brugt Sprint backloggen jævnlig, hertil har Scrum masteren opdateret og orienteret teamet, når det har været nødvendigt for at skabe yderlige overblik og samle fokus. Daily scrum-møder I sidste sprint blev det konkluderet, at vi skulle have ere Daily scrum-møder. Dette forsøgte vi at overholde, og vi formåede at afholde møder hver dag i sprintperioden. Mødernes varighed var på omtrent 15 minutter, som gav en god mulighed for alle i Sprint teamet at få et indblik i, hvad de forskellige i teamet arbejdede med, samt et større overblik over de opgaver som skulle udføres. Sprintperiodens varighed har været væsentlig kortere end den "originale"scrumudviklingsmodel, og dette har også fået os til at indse, at Daily scrum-møderne kunne være mere brugbare over længere sprint-perioder, samt Sprint backlogs med ere opgaver. Par-programmering I dette sprint har vi ikke programmeret i par så meget, da vi følte, vi havde mange små opgaver, vi skulle nå inden et udgivelse af systemet. Vi kan dog konkludere, at aktiviteten at programmere i par har været rigtig god og giver en god mulighed for sparring på hinandens viden og at skabe ny form for læring. Vi fandt på samme tid ud af, at der er et behov for at kunne sætte tid af til netop programmering i par, da det ofte kan tage længere tid, idet der er mulighed for, at der kan opstå diskussioner i forbindelse med udviklingen. Burndown chart I dette sprint brugte vi Burndown charten i starten af sprintet til at få et overblik over de timer, som var til rådighed, og hvor mange timer der yderligere var brug for. Vi har dog ikke kunnet bruge Burndown charten som en virksomhed eksempelvis ville bruge den, idet mande-timer er tid/penge, og derfor er der et økonomisk aspekt som spiller ind, hvad angår den tid, der bliver sat af til udvikling. Hvis vi skulle sammenligne en virksomhed overfor os som gruppe, kan vi se økonomien i forbindelse med de forelæsninger (viden), som vi er gået glip af. Derudover er en projektaevering en deadline for aevering af system, som hvis en kunde ville have et resultat klar til en bestemt given dato. 50

63 Magic Kapitel Reeksion I dette afsnit, vil vi reektere over forskellige områder i forhold til vores proces. Vi vil her se på, hvorledes Scrum metoden har været brugbar i forhold til inddragelse af brugere under processen. Vi vil først se på vores brugerinddragelse i udviklingen med Scrum overfor hvorledes det skulle fungere i forhold til Scrum. Dernæst vil vi se på, hvorledes vi brugte Scrum for samarbejde med Product owner, samt hvorledes det forløb. Alle dele af Scrum passede ikke ind i et semesterprojekt, så modellen blev ikke fulgt til punkt og prikke, men tilpasset projektet Tidsplan Indledningsvis udviklede vi en tidsplan, som ses på gur 6.4, hvor vi fastlagde en række datoer for de tre sprints. Her skulle det vise sig, at som projektforløbet skred frem, kunne vi ikke overholde disse datoer helt, specielt sprint to og tre blev rykket lidt på bekostning af deres længde, da det ikke var muligt at ytte afslutningsdatoen for sidste sprint. En erfaring, vi har gjort os her, er at der skal være mere plads i tidsplanen efter et sprint, således at der er bedre mulighed for at reektere over det overståede forløb og dertil forberede det næste. Hertil har vi desuden ikke været gode nok til at tage højde for helligdage og forelæsninger Møder Scrum-metoden beskriver sprint-planlægningsprocessen som to møder for hvert nyt sprint. Det første møde med Product owneren og det næste med de forskellige interessenter. Møder forløb ikke efter denne skabelon grundet to faktorer. Igennem udviklingsprocessen havde udviklingsteamet en generel god kontakt til brugerne, da brugerne indgik i mange af analyse- og designopgaverne. Product owneren var en del af udviklings-teamet, og derved havde udviklings-teamet en bruger, som man var i daglig kontakt med. Dette gav os en uformelle ekstra kontakt til brugerne mellem sprints, som betød at vi kunne få svar på mindre spørgsmål løbende som de kom op. Imellem hvert sprint blev der udarbejdet en Sprint backlog på baggrund af inddragelse af Product owner og en repræsentant fra Sprint teamet. Det betød derfor her, at Product owner k et større ansvar til at tage kontakt til interessenterne og få information om deres holdninger, hvilket han blev oplyst om ved planlægning af første sprint. Det at medlemmer fra Sprint teamet var med til udvælgelsen af opgaver, som skulle i Sprint backloggen, gjorde det muligt at opsætte deadlines for forskellige dele i systemet, som skulle være udført. Denne måde for struktureret udvælgelse af opgaver for et specikt sprint, gjorde det nemmere at give individuelle opgaver før det næste sprint review-møde, og derpå give det som interessenterne ville have. Ved afslutning af hvert sprint, holdte vi et Sprint review-møde med Product owner, som er Scrum-metodens måde at formalisere samarbejdet med brugeren på. Derpå var det muligt for Product owneren at se på det udførte arbejde, og opstille en ny Sprint backlog for det næste sprint. 51

64 Kapitel 6 Magic I starten var vi ikke så gode til at afholde de såkaldte Daily scrums, men med tiden blev vi bedre til det, og det var med til at holde overblik og give indblik i hvad de forskellige medlemmer i Sprint temaet arbejdede på. Denne måde at koordinere opgaver og vedligeholde et overblik viste sig at fungere godt. Uddelingen af opgaver på Sprint backloggen blev gjort efter interesse, og man k i de este tilfælde selv lov til at vælge sine opgaver, hvilket resulterede i at vi nåede de opgaver, som var opstillet i de forskellige sprints. En ulempe ved denne model var, at Product owneren kunne få for meget magt, da han var inddraget i alle aspekter af udviklingsprocessen. En anden var, at de møder der var med brugerne ikke havde samme fokus hver gang. Så de kom ikke til at fungere som et fast holdepunkt før hvert nyt sprint som optakt til en ny Sprint backlog. Der er simpelthen fare for, at brugerne ikke k nok indydelse på Sprint backloggen Agil udvikling Først og fremmest var det anderledes at bruge agil systemudvikling på dette semester sammenlignet med de øvrige semestre, hvor det var traditionel systemudvikling baseret på vandfaldsmodellen. En anden ting i dette semester var, at det ikke var påkrævet at undersøge problem- og anvendelsesområdet så meget som i sidste projekt. Det gjorde, at vi havde mere tid til den iterative proces, og et produkt blev synligt allerede efter første sprint. Man kan tænke, at det må være svært at begynde udvikling af et system uden konkret at have analyseret problemstillingen, dog har det her været Product ownerens ansvar at prioritere de forskellige dele, som skulle laves i systemet og ansvaret har derfor været yttet fra udviklerne til repræsentanten af interessenterne. Derfor blev det aldrig et emne at diskutere, hvilke under-opgaver der skulle løses før andre i forhold til udviklingen af systemet, idet Product owneren havde det sidste ord. For at konkludere kan vi sige, at Product owner klart satte linjen for, hvilke opgaver som skulle udføres, baseret på guidelines fra Scrum metoden. De prioriterede opgaver blev indtastet i Google Docs 1, som gjorde det muligt for Sprint temaet at følge de forskellige opgavers statusser, manglende opgaver osv. For at konkludere på brugen af Scrum-metoden i forhold til samarbejde med brugerne, kan vi sige at brugen af Scrum har været positiv, og de resultater vi k ud af metoden har været brugbare netop på det område, som omhandler inddragelse af brugere i udviklingsprocessen. Selvom ikke alle områder og aktiviteter var brugbare i forhold til vores projekt, har vi formået at skræddersy vores "egen"scrum-metode. Måden at arbejde med Sprint review-møder imellem hvert sprint, Product owner-prioriterisering og Daily Scrum-møder har lagt et grundlag for et godt samarbejde med brugerne. Scrum-metoden har netop givet os en brugerinddragelse, idet den tilpasser sig til en kobling imellem udviklere og brugerne. 1 Google Docs er et online oce-program, hvor regnearksdelen blev benyttet til Product backlog og Sprint backlog 52

65 Magic Kapitel Traditionel overfor agil systemudvikling Imens krigen om traditionel og agil systemudvikling raser, vil vi gå et skridt tilbage og reektere på forskellene imellem dem og se på, hvilken udviklingsmetode der passer bedre til vores situation. Vi vil derudover kigge nærmere på de forskellige metoder til tilegnelse af viden og vores personlige erfaringer som startpunkt. Et vigtigt område, hvorpå Scrum adskiller sig fra det traditionelle udviklingsparadigme er på fokusområdet. Vi har tidligere arbejdet med en mere traditionel udviklingsparadigme igennem et semester, hvor der var stor vægt på struktureret beskrivelse af arkitekturen og dokumentation før påbegyndelse af systemudviklingen (programmering). Scrum har derimod ikke samme fokus på arkitektur, struktur og dokumentation, dens fokus er på styring og kontrol af selve udviklingsprocessen, samt kommunikation med brugeren under udviklingsprocessen ansigt til ansigt, som giver mulighed for løbende ændringer af systemet under udviklingen Levede Scrum op til forventninger? Valget af Scrum blev træet som sagt fordi vi forventede variationer i brugernes ideer til systemet under udviklingsforløbet, så dens agile approach med fokus på brugerkommunikation så ud til at være den bedst tilpassende tilgangsmetode. Vi fandt ud af, at Scrum er en Lean 2 metode til at styre forløbet, men skaer ikke nogen konkrete teknikker til aktiviteter tilhørende udviklingen. Vi var meget fokuseret på at udføre selve Scrum aktiviteterne efter forskriften, men vi kunne have suppleret Scrum med en anden konkret metode, f.eks. XP. Vi savnede nogle af disse kommunikative værktøjer i vores proces, fordi når opgaven er så fragmenteret, så bliver det svært at danne et overblik over helheden, og få den delt tværs over gruppen. Til gengæld anvendte vi nogle værktøjer fra OOAD bogen. Vi kan godt forstille os nu, at grunden for at Scrum ikke fastlægger nogen konkrete udviklingsaktiviteter, er til at kunne overholde Lean princippet, som den er baseret på, ved at lade ansvaret ligge hos udviklerne. På den måde kan et i forvejen velsynkroniseret udvikler-team med en god fordel adaptere Scrum metoden, og dermed øge eektiviteten ved at fjerne overhead, som kunne være en del af dokumentationen, da den ikke er nødvendig for intern kommunikation i udviklergruppen, da de muligvis er sammenstillet i forvejen og deres tænkemåde er forholdsvist ens Refactoring Hvor der i det traditionelle udviklingsparadigme ikke arbejdes med refactoring, har det hovedfokus i agile udviklingsparadigmer. I agil systemudvikling er man nødsaget til at arbejde iterativt med koden, når man optimerer koden, ved f.eks. reducering af kodelinjer, og forbedre læsningen og brugbarheden af koden. Når vi kigger tilbage på vores projekt, og ser på måden vi har arbejdet iterativt på, kan vi sige vi brugte det på de steder, vi følte det nødvendigt. Vi fandt ud 2 Lean Production er en forretningsloso der er opstået på Toyota-fabrikkerne i 1960'erne 53

66 Kapitel 6 Magic af, at det var nemmere at programmere uden at tænke på "refactoring", men hvis man brugte lidt tid på at tænke tingene igennem, viste det sig ofte, at det tog mindre tid at implementere, så frem man havde tænkt det hele igennem. I det traditionelle vandfaldsparadigme ville dette dog ikke være muligt, idet alle klasser og metoder er struktureret, før man skriver den første linje kode Forstå brugerens kontekst En anden vigtig pointe er udviklernes forståelse af brugernes kontekst i forhold til hvorledes systemet skal bruges. I traditionelle paradigmer bruger udviklerne en masse tid på at lære brugernes kontekst, og sætte sig ind i brugernes situation for at kunne udvikle et system til dem. Dette sker for at kunne sikre brugeren, at hver en lille del bliver udviklet for at opfylde brugernes krav. I det agile udviklingsparadigme er det nødvendigt for udviklerne først at kende til brugerens ideer, interesser og behov, før der bliver skrevet noget kode. I vores projekt var det ikke helt så svært at forstå brugerens kontekst, idet vi alle som udviklere havde en ide om, hvorledes brugerens interesser og behov var. Dog vil vi kunne se et større problem i et større agilt udviklingsprojekt med ere udviklere. Idet der foregår en iterativ proces får brugeren altid mulighed for at se resultatet af processen, og har mulighed for at komme med ændringer under udviklingen, frem for i de traditionelle udviklingsparadigmer hvor der først kan ændres efter systemet ligger færdigt Var Scrum det rigtige valg? Vi vil nu reektere over de forskelle, vi har erfaret ved at bruge traditionelle og agile udviklingsparadigmer. Som tidligere fortalt brugte vi traditionel udvikling forrige projekt og agil udvikling i dette projekt, og vi vil nu se på de konsekvenser, der er ved at bruge agil udvikling. Vi har erfaret, at agil systemudvikling gør det muligt hurtigere at udvælge nye ideer under Sprint-møderne, hvor udviklerne har mulighed for at foreslå ændringer til systemet. Dette har været en opmuntring for os, siden vi prøvede at være kreative og komme med gode løsninger til forskellige problemstillinger, imens vi udvikler. Møderne gav os tit feedback på de ting, vi havde gjort rigtigt og gav os muligheder for at komme med løsningsforslag på mulige problemer. Det har derudover været motiverende for os at følge Burndown charten og Sprint backloggen, idet den har givet os et overblik over, hvordan vi udnytter vores ressourcer, og hvor langt vi er nået i selve processen på hvert givent tidspunkt. Vi følte dette som en stor fordel ved brug af iterationer/sprints med en specik længde med mulighed for fjerne opgaver, som Sprint teamet ikke havde mulighed for at udføre til tiden, og give Sprint teamet opnåelige deadlines. Vi føler, at processen med agil systemudvikling har været tilfredsstillende, idet vi har udviklet et system som næsten er færdigudarbejdet, og man kan se at systemet er blevet forbedret fra første sprint til tredje sprint. Det agile udviklingsparadigme, som vi har arbejdet med har været baseret på Scrum. Der har været mere fokus på processen og samarbejdet med brugeren, hvilket netop er i fokus med agil systemudvikling, og får udviklerne til at tænke kreativt. Vores valg af systemudviklingsmetode vil klart være agil systemudvikling, ved udviklingen af brugercentreret applikationer, hvor brugerne er i kontakt med applikationen 54

67 Magic Kapitel 6 under hele afviklingstiden. Agil systemudvikling giver mulighed for onsite udvikling med brugeren i centrum. 55

68 Kapitel 7 Teknik 7.1 ASP.NET, C# og DB Flow Vi valgte at anvende ASP.NET til udviklingen af vores system. Dette blev valgt, fordi vi fra et tidligere semester havde erfaring med programmering i C#, og C# er netop et af de sprog, som kan anvendes til programmering i ASP.NET. Inden det endelige valg blev truet, havde vi forskellige muligheder, som f.eks. PHP og Java, oppe at vende, men i sidste ende valgte vi alligevel ASP.NET, da det som nævnt var det, vi havde mest erfaring med. Vores erfaring med C# stammede fra udvikling af Windows-applikationer. Derfor var det stadigvæk en udfordring at skulle arbejde med en web-applikation, da der er visse forskelle i hvordan udviklingen foregår. Forskellene ligger især i udviklingen af GUI'en. Udvikling til web kræver også en vis indsigt i HTML og C- SS. WebForms, som anvendes i ASP.NET opfører sig desuden ikke helt på samme måde som WinForms, som anvendes i udviklingen af Windows-applikationer. På trods af at der var visse forskelle kunne vi alligevel bruge meget af vores C#- erfaring i udviklingen af systemet. Et screenshot af værktøjet, vi brugte for udvikling i ASP.NET, ses på gur 7.1. I de tidligere semestre har vores fokus ikke været på brug af database, men i dette semester vurderede vi, at vi blev nødt til at bruge en database. Men frem for at lave hele arbejdet med databasen selv, valgte vi at samarbejde med en specialestuderende, som arbejdede med et projekt kaldet DB Flow. DB Flow står for forbindelsen fra C#-koden til databasen og gør det simplere at gemme og hente data. At vi valgte at arbejde med DB Flow betød som nævnt, at vi sparede en del tid på arbejdet med databasen, i forhold til hvis vi selv skulle have ordnet det hele. Arbejdet med DB Flow havde også visse ulemper. Det betød at vi var afhængige af en ekstern udvikler, noget som ikke kunne undgå at have indvirkning på vores arbejde. Ligeledes var der det faktum, at vi arbejdede med noget, vi ikke selv havde udviklet, hvilket betød, at vi ikke selv ville have mulighed for at rette i det. 56

69 Magic Kapitel 7 Figur 7.1: Visual Studio Vi havde planlagt at vi ville anvende en MySQL-database, da denne er de factostandarden inden for webudvikling. Der var nogle problemer med at få DB Flow til at understøtte en MySQL-database, da DB Flow-udviklerens primære fokus ikke var webudvikling. Det betød at vi blev nødt til at bruge en MSSQLdatabase i stedet, men da det kom i stand, var det heller ikke et større problem. Overordnet set gik samarbejdet godt, og det gav os en stor hjælp i projektet, da vi slap for selv at skulle tænke for meget over database-delen. Man kan sige at vi var i den situation, at vi selv var brugere i forbindelse med DB Flow. Noget som også har været gavnligt at prøve, da det hjælper med til at forstå, hvordan brugere generelt tænker. 7.2 Google Docs Vi valgte i gruppen at anvende Google Docs til at håndtere fælles dokumenter, som ikke skulle være en del af rapporten. Grunden til at vi fravalgte rapportskrivning i Google Docs var, at vi valgte at bruge SVN og LaTeX til at håndtere rapporten. Et screenshot af Google Docs, ses på gur 7.2 Google Docs er browserbaseret tekstbehandling, regneark og præsentationsværktøj. Vi brugte tekstbehandlings- og regnearksdelen i vores gruppearbejde. Da det er browserbaseret, ligger alle dokumenterne online, og på den måde ikke behøver at deles med gruppemedlemmer via fx . Google Docs tillader også at ere brugere kan redigere det samme dokument på samme tid. Det kræver en smule forsigtighed, men kan også være meget praktisk. Vi brugte bl.a. Google Docs til vores Product backlog og vores Sprint backlogs, 57

70 Kapitel 7 Magic Figur 7.2: GoogleDocs og som nævnt til forskellige fælles dokumenter. 7.3 Versionsstyring - SVN Som nævnt brugte vi Google Docs til håndtering af fælles dokumenter, som ikke skulle være en del af rapporten. Selve rapporten blev sat op i LaTeX, som giver en række fordele når der arbejdes med større dokumenter. For at sikre os mod tab af data og for at lette samarbejdet, valgte vi at anvende versionsstyring på vores rapport-ler. Vi brugte versionsstyringssystemet Subversion (SVN) [[?]]. Vi valgte ligeledes at bruge SVN til at holde styr på programmeringsdelen af vores projekt, kildekoden til vores system. På samme måde som med rapporten, gjorde det det meget nemmere for os at arbejde på programmeringsarbejdet. 58

71 Kapitel 8 Innovation Innovation ses i dag ofte deneret som opndelser og ideer, som er omsat til produkter eller tjenester der bliver bragt til marked. Der er tale om processen fra ide til udrulning, som indebærer tre elementer [[2]]: En ny ide. Ny ide omsættes til et nyt eller forbedret produkt. Et nyt produkt markedsføres. Innovation deneres også i dag på følgende måde: "Innovation er stærkt sammenbundet med kreativitet. Hvis en løsning på et problem skal kunne deneres som kreativ, kræves at den er nyskabende og har høj brugbarhedsværdi, samt at den ikke skal være triviel. Der er så først tale om innovation, hvis løsningen har opfyldt det første kriterium, og der lykkes derefter at implementere denne på en succesfuld måde":[4] Figur 8.1 viser hvordan kreativitet kan opnås ved kombination af ere af de følgende færdigheder[5]: Ekspertise, som er erhvervet viden. Kreative tænkefærdigheder, er med til at generere ideer via proces. Motivation som kommer indefra, med tvang udefra har mindre eekt. 59

72 Kapitel 8 Magic Viden; - teknisk, -proceduremæssig, -intellektuel Ekspertise Kreativitet Kreative-tænke færdigheder Hvor fleksibelt og imaginativt folk tilgår et problem Motivation Intrinsic er mere effektiv end Extrinsic Figur 8.1: creativity 8.1 Innovation i vores projekt For netop at bringe innovation på banen, har vi på INF2-semestret haft kursus i Software Innovation, hvor hovedvægten har ligget i at hjælpe kursisterne til at forstå innovationsbegrebet, ved at introducere eksempler på innovative produkter og metoder. Derudover har vi fået opgaver, hvor vi har evalueret produkter med henblik på nyskabelse overfor nytteværdi (novelty vs. utility) [[7]]. Vi har været delt op i mindre arbejdsgrupper, og lavet innovationsøvelser. Resultaterne blev meget forskellige, da sammensætningen af forskellige studieretninger gav mulighed for sparring på viden og dermed på løsninger af hver deres karakter. Kurset har derudover introduceret os til nogle discipliner til innovation, som vi har forsøgt at bruge os igennem projektet. I de kommende afsnit, vil der beskrives hvor vi har forsøgt at være innovative i forhold til de teknikker og metoder vi har brugt til inddragelse af brugere. Dernæst vil vi til sidst reektere over den innovative proces. Forbilledanalyen og udarbejdelsen af brugsmønstrene var innovative processer for os, hvor vi ikke har fulgt nogen speciel guideline, for hvorledes man udfører metoden. 8.2 Forbilledanalyse Innovation starter med kreativitet. Vores første forsøg på kreativitet var at kombinere forbilledanalyse med brugersamarbejdet. Normalvis udarbejdes en forbilledanalyse således at selve udviklerne udfører en analyse af et eksisterende produkt som de synes at kunne være en kandidat for et forbillede. Vi valgte tværtimod at udføre forbilledanalysen på en måde hvor der i samarbejde med brugerne gennemgås de valgte forbillede-kandidater i fællesskab brugerne, hvor de enkelte funktioner anvendes som inspiration til diskussion. Resultaterne af disse diskussioner noteres og kan så benyttes til videre udvikling. 60

73 Magic Kapitel Reeksion Fordelene ved en forbilledanalyse foretaget i samarbejde med brugere, var at features og funktioner som udviklerne syntes var nyttige, kunne blive henstået af brugerne, hvilket resulterede i at der kunne spares ressourcer ved at få dem eliminere disse funktioner med det samme. Eksempler på features og funktioner som udviklerne allerede forinden undersøgelsen havde i tankerne, blev også revurderet af brugerne, og mulige variationer og forbedringer sandsynliggjorde en mere nyttig implementation i systemet. Der bør tages forbehold for at en sådan forbilledanalyses frie samtale, som der bliver lagt op til, har mulighed for at bevæge sig for langt væk fra en brugbar diskussion. Samtidigt kan størrelsen af den gruppe af brugere der er involveret, have en omfattende betydning. Der kan være fare for at alle ideer og synspunkter ikke når at komme frem, hvis enkelte brugere virker dominerende i diskussioner, så andre ikke får deres meninger indført. 8.3 Udarbejdelse af brugsmønstre Det andet forsøg på at være kreative, var på at få udarbejdet vores brugsmønstre igennem et slags rollespil, hvor vi k brugerne til at bruge fantasien ved at gennemgå en spilproces og med en ktiv udgave af vores system som udbyggelse af oplevelsen. Det vil sige at processen f.eks. lagde ud med hyggesnak efterfulgt af spil og afsluttet med registrering af resultaterne i systemet. Det hele blev gjort med tænke-højt-teknik, så udviklerne kunne skae sig en vis indsigt i brugernes tankegang. Ideen bag denne tilgang kommer fra en blanding den traditionelle udarbejdelse af brugsmønstre og gængse usability-tests. Normalvis udarbejdes brugsmønstre ved at udviklerne foretager observationer af brugerne baseret på brugernes udtalelser, og ud fra disse udarbejdes de forventede brugsmønstrene Reeksion Fordelene ved denne type udarbejdelse af brugsmønster, er at der skabes en mulighed for at ere versioner af brugsmønstre bliver udarbejdet i dialog med brugerne. Ved aktiv deltagelse får brugergruppen mulighed for at give kommentarer og ændre på de brugsmønstre som bliver udviklet on site under sessionen. Ved en sådan session skal der tages forbehold for, at brugerne muligvis ikke kan sætte sig ind i rollespillet, og derved falder engagementet i opgaven, og de kreative ideer til brugsmønstre vil måske blive dårligere. 61

74 Kapitel 9 Reeksion I dette kapitel reekteres henholdsvis over processen og over produktet, hvor der gennem semestret har været størst fokus på processen med samarbejdet med brugerne. 9.1 For sen opstartsfase Vores projektperiode kom lidt uheldigt fra start, i og med at vi brugte den første måned på at nde brugere. Det vil sige at vi faktisk ikke k lavet meget projektrelevant arbejde i den første måned. Problemet lå i at vi havde svært ved at nde brugere, som kunne være interesserede i at deltage i et universitetsprojekt og sætte tid af til dette. Den tid vi havde brugt på at nde brugere i starten af projektperioden, kunne være afsat til at få en mere teoretisk forståelse af samarbejde med brugere, og evt. nde metodetilgange for inddragelse af brugere i forskellige situationer. Vi kunne ligeledes have haft længere sprintperioder i forbindelse med Scrumudviklingsmetoden. 9.2 Samarbejdet med Product owner At vores Product owner var en del af udviklingsteamet, kan både have haft positiv og negativ betydning for udviklingsarbejdet. Fordelen ved at have Product owner som en del af udviklingsteamet er at vedkommende altid er tilgængelig til at give input i forbindelse med udviklingsarbejdet. Denne tætte kontakt kan være med til at undgå potentielle problemer og fejl i forhold til brugernes ønsker til systemet. På den anden side kunne det også være en ulempe, at Product owneren havde så tæt kontakt til udviklingsteamet, da det kunne være befriende at arbejde lidt friere. En ide som måske umiddelbart ikke lyder som noget der vil passe brugerne, kan vise sig at være god alligevel, eller kan eventuelt videreudvikles til noget bedre. Overdreven kontakt med Product owneren kan ligeledes være problematisk, da det kan reducere behovet for kontakt til resten af brugergruppen, Product owneren kan få for stor indydelse på systemudviklingen. 62

75 Magic Kapitel 9 En anden ting vi erfarede med hensyn til Product owner var, at det var positivt at have vedkommende involveret i de forskellige brugerinvolveringsaktiviteter. Det gav et forstærket samarbejde mellem Product owner og udviklingsteam, ved at begge parter vidste hvad der var foregået i de forskellige aktiviteter, samt h- vad brugerne meldte tilbage. Vi forventer ikke at Product owneren kan være en del af udviklingsteamet, da der vil være tale om en repræsentant fra en kunde, som ikke kan deltage i udviklingsprocessen. Man vil sjældent være ude for at en kunde også vil have udviklingskompetencer. 9.3 Samarbejdet med brugerne Vi har generelt været meget tilfredse med vores brugere, da de har været meget samarbejdsvillige og har haft en stor interesse i produktudviklingen. Dertil har de været gode til at komme til brugerinvolveringsaktiviteter til trods for kort varsel. Hvis vi ser på vores egen læringsproces kunne det have været en fordel hvis der havde været en større udfordring i kommunikationen med brugerne. Hvis brugerne havde været sværere at trække informationer ud af, ville det have krævet at vi skulle have overvejet ere værktøjer til brugerkommunikation. På grund af en velfungerende kommunikation imellem brugere og udviklere, havde vi fra starten en god idé om hvad det var som skulle laves i sidste ende. Det betød, at vi tillod os mere frihed i de aktiviteter som vi lavede sammen med brugerne, ved eksempelvis vores innovative forsøg, til trods for at den øgede frihed gav ekstra rum til tilfældigheder, som kunne øge risikoen for at aktiviteten mislykkedes. 9.4 Samspillet imellem Scrum og samarbejdet med brugerne Her ser vi nærmere på samspillet mellem udviklingsmetoden og involveringen af brugerne i forløbet, en faktor der spiller ind her, er de værktøjer som er med til at fremme associationen mellem disse, og dermed er nødvendige for at opnå progression i udviklingsprocessen. På gur 9.1 har vi illustreret en model over de pointer man bør se på ved udarbejdelsen af et projekt hvor fokus ligger i samarbejdet med brugere i en Scrum udviklingsproces. Figur 9.1 viser, at brugersamarbejdet er et krav til dette semesters projekt, som vi skal opfylde. Dette krav, samt de valgte brugere og deres krav til systemet, udgør så situationen, hvor vi har valgt Scrum som den bedste metode til at koble situationen og brugersamarbejdet sammen. Værktøjerne bruges så til at bygge bro imellem Scrum og brugersamarbejde. Ligeledes har vi brugt Product owner som vores kobling imellem brugersamarbejde og Scrum. 63

76 Kapitel 9 Magic Situation Scrum Brugersamarbejde Værktøjer 9.5 Metodisk tilgang Figur 9.1: Reektionsmodel Kensing og Munk-Madsen (KMM) [[13]] har foreslået en model, som kan bruges til at organisere værktøjer til brugerinddragelse før en påbegyndt proces. De starter med at se på de to faktorer som spiller ind for en designproces til udviklingen af et nyt produkt. Se gur 9.2. Første faktor er den viden som brugerne U sers present w ork T echnological options D esign process N ew system Figur 9.2: Tre domæner for diskurs i designprocessen. har i forbindelse med arbejdsgangen og den anden faktor er de teknologiske muligheder som der ligger hos udviklerne, som samles i en fælles designproces. For at skabe denne fælles designproces er det nødvendigt at bestemme hvilke værktøjer der skal anvendes til vidensdeling imellem begge parter og hvilke ansvar de hver i sær har i forhold til hinanden. Via gur 9.3 har Kensing og Munk-Madsen vist de seks nøgleområder for viden i kommunikationen imellem brugere og udviklere. 64

77 Magic Kapitel 9 Users present work New system Technological options Abstract knowledge Relevant Structures on Users present work (2) (5) (4) Visions Overview of And design proposals Technological options Concrete experience Concrete (1) Concrete (6) Concrete (3) Experience with users Experience with the new Experience with Present work system Technological options Figur 9.3: Seks nøgleområder for viden i kommunikation imellem brugere og udviklere. Dernæst har de opstillet en liste med værktøjer og teknikker for vidensudvikling i samarbejde mere brugere som ses et udsnit af på gur 9.4. En større illustration af tabellen ses i bilag H. Listen er opdelt efter hvilke af de seks vidensområder som er relevante i forhold til de forskellige teknikker. Tools and techniques Areas of knowledge Observations 1 Interviewing users 1 2 Self-registration 1 Developers doing users work 1 Videorecording 1 Mock-ups 1 6 Figur 9.4: Værktøjer og teknikker for vidensudvikling Vores metodiske tilgang For at reektere over den proces vi har været igennem samt de værktøjer vi har benyttet dertil, vil vi nu stille den op imod KMM-modellen. På gur 9.5 ses de værktøjer vi har brugt i projektforløbet i forhold til KMM-modellen. Vi vil nu prøve at se på de svagheder der ligger i vores metodiske tilgang, hvilket vi gør ved sammenligning med KMM-modellen. Hvis vi ser på gur 9.5, kan vi se huller i listen som ses til venstre. De seks huller, er de værktøjer vi netop har benyttet i vores projekt ud af de 26 mulige. Man kan dernæst diskutere om de seks brugte værktøjer er nok i forhold til den vidensdeling som har været nødvendig, da brug af få værktøjer kan medføre at vi ikke kan være sikre på, om vi har fået den viden som brugerne ligger inde med og omvendt. På baggrund af det mener vi, at vi burde bruge mindst to værktøjer indenfor hvert af de seks vidensområder, for at kunne vericere om vidensdelingen imellem os som udviklere og brugere var fyldestgørende. Et eksempel kunne være i vidensområde nummer (5) og (4), hvor der kun er blevet benyttet et værktøj. De værktøjer vi har benyttet i vores proces, har ikke alle været så struktureret og formelle, hvilket kunne have betydet at resultaterne deraf kunne være forringet. Et eksempel kan ses på teknikkerne Observation og Interview af brugere, som ikke har været konkrete og veldokumenterede sessioner. 65

78 Kapitel 9 Magic Tools and techniques Areas of knowledge Self-registration 1 Developers doing users work 1 Videorecording 1 Mock-ups Conceptual modelling 2 Culture analysis 1 2 Object -oriented analysis 2 5 Object -oriented design 5 Event lists 2 5 Entity -relationship diagrams 2 5 Wall graphs 2 5 M apping 2 5 Future workshop 2 5 Metaphorical design D ataflow diagram s 2 5 Language analysis 2 5 Card games 1 6 Visits to other installations 3 4 Literature study Forum theater 6 A b stract kn o wled g e C o n crete exp erien ce Users present work New system Technological options R elevant (2) Structures on Users present work Interviewing users Drawing rich pictures Users present work C oncrete (1) Experience with users Present work (5) Visions And design proposals Prototyping New system C oncrete (3) Experience with Technological options (4) Overview of Technological options Study standard software Technological options C oncrete (6) Experience with the new system A b stract kn o wled g e C o n crete exp erien ce R elevant (2) Technological options Structures on Users present work Visions And design proposals (4) Overview of (1) Technological options C oncrete Experience with users C oncrete Present work (6) Experience with the new system C oncrete (3) Experience with Technological options Interviewing users Observations Think-aloud experiments Prototyping Study standard software Think-aloud experiments Prototyping Drawing rich pictures Figur 9.5: Vores metodiske tilgang Opsummerende kan vi se en stor fordel i brugen af en metodisk tilgang, som inddrages i planlægningsfasen og KMM-modellen ville være oplagt til netop dette. 66

79 Kapitel 10 Konklusion Det gennemgående tema har i denne udviklingsproces været brugerinvolvering. Vi har derfor løbende set på forskellige teknikker for brugerinddragelse, med det formål at skabe en bedre dialog mellem aktører og os som udviklergruppe. På baggrund af denne dialog opnås en gensidig forståelse for udviklingen af det ønskede produkt, for her til slut at kunne svare på den indledende problemstilling som lød: Hvordan kan man opnå et godt samarbejde med brugerne og på baggrund af dette realisere en applikation med vægt på interaktion og statistik? Vi har erfaret at nogle af disse teknikker har været mere resultatgivende end andre. Generelt har vi erfaret at brugerinvolvering er en tidskrævende proces, men ved valg af de rigtige teknikker og korrekt forberedelse og udførelse af disse, resulterer det bl.a. i mindre tidsspilde på udvikling af uønskede funktioner og layout. Dertil opnår man desuden også større kundetilfredshed, da kunden føler sig involveret i udviklingen og dermed får bedre relation til produktet. Ved afslutningen af udviklingsprocessen står vi således med et produkt der ikke er klar til brug. Til gengæld står vi (jævnfør bilag F) med en gruppe brugere der føler, at de har medvirket til udviklingen af et system, som de har haft stor indydelse på. De har set en prototype af et system baseret på deres egne ideer, ydermere har de fået muligheden for at teste de funktioner, som de selv har vist behov og udtrykt ønsker for Udviklingsmetode På baggrund af det overståede projektforløb er vi af den opfattelse, at Scrum kan være en eektiv metode at udvikle systemer efter. Vi har dog erfaret at metoden har sine begrænsninger til brug i mindre studiegrupper som vores. Det begrunder vi med at nogle af de værktøjer Scrum tilbyder, ikke direkte kan bruges som de er tiltænkt, da et studieprojekt ikke udvikler sig i samme hast som et rent systemudviklingsforløb og dertil ikke afbrydes af studierelaterede årsager. Man bør derfor være bevidst om disse og lignende faktorer. Scrums teknikker bruges ud fra den antagelse at udviklerne er velfungerende 67

80 Kapitel 10 Magic som gruppe og at gruppens medlemmer er i stand til at bruge de værktøjer der kræves, for at løse de opgaver de hver især bliver tildelt, for at få et eektivt workow som der er ønsket med Scrum. Et godt eksempel er Sprint backloggen. Denne kommer først rigtigt til sin ret, når den indeholder en større mængde opgaver, som kan løses af gruppemedlemmer uafhængige af hinandens eller andres undervisning eller hjælp. Dette var ikke muligt af to grunde. Gruppen var samtidig i en læringsproces, og Sprint'ene var ikke er lange nok, grundet ønske om at have tre sprints i projektforløbet. Scrum-udviklingsmetoden blev valgt med henblik på at skabe mulighed for at involvere brugerne i udviklingen. Ganske vist skaber Scrum denne mulighed idet det er en iterativ udviklingsform, og dermed giver udviklerne muligheden for at ændre i deres kommende opgaver afhængigt af forudgående arbejde, som eksempelvis kunne være inddragelse af brugerne. Desuden har Scrum en Product owner som fungerer som bindeled imellem kunde/bruger og udvikler. Udover det har Scrum ikke nogen specikke værktøjer til inddragelse af brugere. Så udvikling hvori der ønskes at inddrage brugerne, kræver at sådanne teknikker hentes andet steds fra. Generelt har vi opnået en god forståelse for, hvordan man innovativt benytter forskellige metoder til at inddrage brugere i et agilt udviklingsforløb. Herunder opnås en god forståelsesmæssig dialog som medvirker til skabelse af et produkt, som både aktører såvel som udviklere kan være tilfredse med. Afslutningsvis stiller vi dog os selv det spørgsmål, om hvorvidt vores dialog har været for god, da vi ikke har oplevet de store konikter i udviklingsprocessen mellem de involverede parter. En af de mulige grunde kan være den tætte relation mellem Product owner og Sprint team og ligeledes mellem Product owner og aktørerne. Denne tætte kontakt har således medvirket til, at eventuelle konikter blev neutraliseret i opløbet. En anden grund er at udviklingen tager udgangspunkt i en fritidsaktivitet, dermed har aktørerne haft en meget afslappet tilgang til processen. Som svar på den indledende problemstilling er vi således kommet frem til, at et godt samarbejde kan opnås gennem en periodisk inddragelse af aktørerne på baggrund af udvalgte metoder i procesforløbet. Heri motiveres de løbende gennem fornemmelse for progressionen i udviklingen af produktet på baggrund af deres inddragelse og feedback. Ydermere giver denne inddragelse og feedback fra aktørerne som før omtalt mulighed for, at eektivt realisere et specikt produkt, ikke nødvendigvis hurtigt da denne inddragelse er tidskrævende, men med færre fejl opstået på baggrund af antagelser og miskommunikation. 68

81 Kapitel 11 Perspektivering 11.1 Brugerinvolvering Projektets hovedformål var at involvere brugere så meget som muligt i udviklingen af statistiksystemet. Denne involvering kan selvfølgelig tages endnu længere. En mulighed var at lade brugerne stå for en del af udviklingen. Dette giver dem direkte indydelse på produktet. Dette stiller selvfølgelig store krav til dem, og store krav til os som udviklere. Man skal gøre sig klart, hvilke opgaver man kunne lægge over på brugerne, og ville afhænge af brugernes kompetencer. Mange opgaver kunne sagtens varetages af dem, selv om de ikke har nogen umiddelbare softwareudviklingskompetencer. Områder som grask opbygning af hjemmesiden, menu-opbygning og tekster kunne lægge ud til brugerne. Brugerinvolvering på disse områder kan have forskellige grader. Samtaler, spørgeskemaer og dybdegående interviews som vi har benyttet os af, brugerne kommer med et færdig svar som udviklerne implementerer, eller brugerne laver arbejdet selv. I projektet har vi udviklet en traditionel web-applikation, der er ikke taget højde for brugerinvolvering i selve applikationen. Dette kunne man have gjort eksempelvis ved at gøre det lettere for brugeren at ændre i applikationen, man kunne have opbygget den, så det blev muligt at ændre tekster, menuer og generel placering af elementer på siderne. Statistikdelen kunne også gøres mere åben, f.eks. ved at give brugerne mulighed for at lave deres egen statistikker. Et system, hvor man havde adgang til alle data opsamlet om kampene, og kunne vælge dem, man var interesseret i at se statistik for, og selv sammensætte data i forskellig kombinationer. Man kunne som bruger give andre mulighed for se de brugergenererede statistikker. Med disse tiltag ville applikationen mere være et framework til et statistik system, hvor brugerne kunne ende med at stå helt for opbygningen ud fra en slags byggeklodser lavet af udviklerne. Disse tiltag giver dog ikke brugerne fuld kontrol over applikationen, hvilket der kan være mange gode grunde til, blandt andet at de måske ikke har kompetencerne til selv at udvikle. Hvis man ville åbne fuldt op for at brugerne kunne udvikle selv, var muligheden at frigive applikationen som opensource, og opbygge et åbent udviklingsmiljø omkring den. Dette kræver naturligvis brugere som i nogen grad selv er udviklere. Der ndes et hav af opensource applikationer med et åbent udvikling- 69

82 Kapitel 11 Magic miljø omkring sig, så det er absolut noget, der kan lade sig gøre til mange forskellige applikationer. Brugerne ville da ikke kunne skelnes fra udviklerne Udviklingsmetode Scrum blev benyttet som udviklingsmetode primært for applikationen. En mulighed var ligeledes at benytte den på rapportskrivningen. Det ville være oplagt at benytte Product backlog og Sprint backlog til skriveopgaver. Release af rapporten ville dog ikke give samme mening for en applikationen, men kunne omhandle "frigivelse"af teksterne internt i gruppen og til vejleder. Teksterne frigives, når de er færdige og skal "testes"af vejleder og de andre gruppemedlemmer. Men fordelen i at man kun planlægger et sprint af gangen, ville gøre rapportskrivningen mere overskuelig. Andre udviklingselementer kunne også lægges direkte over på rapportskrivningen. Skrivning i par, hvor der ligesom i par-programmering er en fordel i at være to om formulering, overblikket og fejlnding. Refactoring konceptet passede ligeledes nt på en rapport med hensyn til sammensætning, opsplitning og ytning af tekster Benytte tredjepartskode Vi valgte at udvikle stort set hele applikationen fra bunden af, dette har selvfølgelig haft betydning for hvordan slutproduktet er blevet. I videreudvikling ville det være oplagt at benytte eksisterende kode, hvor det er muligt. Et eksempel kunne være et forum til applikationen, som nogle brugere har vist interesse for. Dette ndes der mange versioner af, der er lige til at hente og integrere i applikationen. En anden mulighed var at omprogrammere applikationen til et modul til et eksisterende CMS system til opbygning af communities 1, af den vej ville vi som udviklere kunne fokusere på statistikdelen og mindre på brugerhåndtering mv. Hvis man ville gøre meget brug af 3. parts kode, burde man kigge på valget af programmeringssprog. C# og ASP.NET er ikke de mest oplagte valg grundet at antallet af frit tilgængelige CMS systemer, moduler og kodestumper er størst i programmeringssproget PHP Project Management I projektet brugte vi Google Docs 2, som projektstyringsværktøj. Det blev for det meste brugt i forbindelse med de forskellige sprints i vores udviklingsmetode og til uddelegering af opgaver blandt gruppens medlemmer. Det fungerede ikke helt som projektstyringsværktøj, og man kunne have valgt et mere oplagt værktøj. En løsning kunne være ProjectPier, som er et opensource værktøj til projektstyring i web-baserede projektgrupper. 1 Content Management System. Et eksempel er det PHP-baserede Community Builder ( som installeres oven på CMS systemet Joomla 2 Se kapitel 7.2 for en forklarende beskrivelse. 70

83 Magic Kapitel 11 Systemet er skrevet i PHP 3 og JavaScript. Værktøjer tilbyder oprettelse af opgavelister, indsættelse af milepæle og deadlines. Derudover giver den projektgruppen mulighed for at styre og organisere medlemmernes opgaver, og har revisionskontrol i forhold til upload af ler. Et screenshot af fronten af systemet ses på gur 11.1 Figur 11.1: ProjectPier 3 PHP: Hypertext Preprocessor 71

84

85 Bilag A Analyse A.1 Foranalyse Formålet med systemet er muligheden for at fremføre statistik for spillere på en måde, så det giver et uddybende billede af, hvorledes udfaldet af de afviklede kampe, spillerne imellem, har været. Dertil tilbyder applikationen den enkelte spiller en mulighed for at beskrive deres decks, dvs. historien bag en sammensætning og de væsentligste kort i decket. Dette lægger op til en dannelse af community, i første omgang i det fællesskab der allerede eksisterer, men senere også på tværs af disse. Da applikationen er et underholdningsprodukt som anvendes i fritiden i forlængelse af kortspillet, er interaktionen mellem applikation og bruger ligeledes i højsædet, da det er lyst og ikke nødvendighed, der driver anvendelsen. A.2 Systemdenition En web-applikation udviklet til, at administrere og vise statistikker af kampafviklinger, mellem spillere af kortspillet "Magic The Gathering". Formålet med systemet er, at anskueliggøre resultaterne af kampene og rangering af brugere og decks imellem, samt intern kommunikation. Desuden skal applikationen være nem at bruge samt have en lettilgængelig brugergrænseade. Applikationen skal bruges i fritiden af ren interessemæssige årsager og kræve et minimalt kendskab til IT. Applikationen skal afvikles fra en central Web-server. 73

86 A.3 BATOFF Betingelser Systemet skal være nemt at lære og bruge og have en overskuelig brugergrænse- ade. Det skal kunne holde styr på magickort-spilleres kamphandlinger og indeholde en form for et social community, hvor spillerne har mulighed for at kommunikere internt med hinanden og give brugerne mulighed for at mødes udenfor den virtuelle verden. Derudover skal systemet som nævnt give mulighed for at kunne holde styr på deres kamphandlinger, og der tildeles point efter hvordan de udfører deres kampe. Dette pointsystem er deneret ud fra et standard-deneret regelsæt, som systemet er opbygget af. Anvendelsesområde Systemet egner sig hovedsageligt til magickort-spillere, som har interesse i at holde styr på deres kamphandlinger. Derudover er det også for magickort-spillere, som har interesse i at møde andre magickort-spillere på nettet. Teknik Teknikken, som skal bruges til systemet skal være bygget på Web-teknologien, med databaseintegration mm. Objekter Spillere, decks, kampe, turnering og grupper. Funktioner Systemets funktioner er håndtering af kampe og statistikgenerering over kampe, brugere og decks. Derudover skal det fungere som en agent, som hjælper spillere med at nde andre spillere i området, og skabe en mulighed for kontakt imellem dem. Filoso Hjælper spillere med at få overblik over deres kamphandlinger, og bygge videre på spiloplevelsen. Systemet hjælper spillere til at blive en bedre taktisk spiller. Ideologien bag en statistikapplikation er administrationen af spillere og dertil deres decks samt overståede kampe. På baggrund af disse skal applikationen give et fyldestgørende statistisk overblik over vundne og tabte kampe spillerne imellem og formidle dette på sådan en måde, at brugeren nder det fornøjelig at interagere med systemet. Fornøjende i den forstand, at applikationen bliver interessant og belønnende i sådan et omfang, at brugeren fastholder sin interesse for det over tid og dermed har en tilbagevendende lyst til at benytte denne.

87 A.4 Prioriteringsskema Som beskrevet i systemdenitionen i kapitel A.2, vil brugerne af systemet hovedsageligt anvende systemet i deres fritid. At brugen foregår i brugernes fritid vil med stor sandsynlighed medføre, at brugerne har et mere afslappet forhold til brugen. Det vil f.eks. sige at brugeren sandsynligvis ikke har så store krav til, hvor meget tid der skal bruges med systemet, som hvis det var et system, der skulle bruges i en virksomhed. Derfor er kravene til memorability og learnability ikke så strenge. Det er selvfølgelig stadig vigtigt, at systemet er forholdsvis nemt for brugeren at gå til (learnability), men da systemet skal bruges ofte, er det vigtigere at brugeren kan huske, hvordan systemet fungerer (memorability), fremfor at det er nemt at lære. Da systemet ofte skal bruges i brugernes fritid, er kravene til experience vigtigere, end hvis det var et system, som skulle bruges i et arbejdsmiljø. Det er meget vigtigt, at systemet opfylder brugernes forventninger (satisfying), da brugernes brug er motiveret af deres interesse i systemet. At brugerne er motiveret af deres interesse medfører, at systemet gerne skal være behageligt (enjoyable) og til en vis grad underholdende (entertaining) at bruge. Brugerne har direkte udtrykt ønske om, at systemet skal være rart at se på (aesthetically pleasing). Meget vigtigt Vigtigt Mindre vigtigt Irrelevent Usability Eectiveness Eciency Safety * Utility Learnability Memorability Experience Satisfying Enjoyable Fun Entertaining Helpful Motivating Aesthetically pleasing Supportive of creativity Rewarding Emotionally fullling Tabel A.1: Prioriteringsskema *Hvis safety deneres som sikkerhed mod at brugeren udfører en forkert handling er det mindre vigtig, hvis det deneres som datasikkerhed mht. til personlige oplysninger er det vigtig.

88 A.5 Problemområde For at se på hvilke informationer systemet skal behandle i problemområdet, kan vi se på gur A.1, som illustrerer problemområdet. Group Player Match Card Deck Kommentar til game Eeg syntes, at din deck var fantastic, Bare man kunne nu selv have sådan sdfas fdasdf asdfasdfsadfsadfa sdfasdf asdf asdf sdf asdfsadfadsfasdfassdfa sdf as df asdf a Comment Tournament Statistic Figur A.1: Problemområdet Illustrationen viser de forskellige objekter, som er relevante netop til udviklingen af systemet. Her ses en gruppe af spillere, som spiller en større kamp. Derudover ser man hvorledes man kan spille for sig selv og i grupper. Spillerne spiller med kort, som kan samles i såkaldte decks. Der kan på samme måde afholdes større kampe, i form af turneringer. Forskellige spillere har forskellige decks, og nogle er bedre end andre, og man kan som spiller nogle gange være interesseret i andres mening, om deres kort og decks via kommentarer og lignende. Under alle disse afviklinger af kampe imellem de forskellige spillere, mangler der en rangering og statistik over de afholdte kampe, hvilket kan give et problem, idet man forsøger at blive bedre til spillet samt ønsker at se hvor man selv er rangeret i forhold til andre spillere. A.6 Anvendelsesområde I anvendelsesområdet er den brugerorganisation som anvender systemet, magickortspillere, med interesse for at få et større overblik over deres kort, decks, kampe og turneringer. Den applikation vi vælger at udvikle, skal kunne oprette spillere og decks, samt kommunikere med andre spillere i systemet. Det skal

89 give mulighed for at kunne holde styr på afholdte kampe. Systemet skal køres som et web-system, og der skal være adgangsmuligheder fra alle systemer med internetadgang. En illustration af anvendelsesområdet ses på gur A.2. User Webserver User User Figur A.2: Anvendelsesområdet Her ses forskellige brugergrupper, som kan være grupper af spillere, som enkelte spillere, som anvender systemet via en PC med internetadgang. PC'en kommunikerer op på en server som håndterer hele systemet. Spillere kan spille magic-kort-spillet og registrere deres kampe løbende ved siden af.

90 A.7 Forbilledanalyse A.7.1 Analyse for Blood Bowl and Beer Internetapplikationen "Blood Bowl and Beer"(herefter BBB) er udarbejdet i fritiden på en ikke kommerciel basis. Applikationen henvender sig til bekendte i udviklerens vennekreds, og er derfor ikke specielt kendt. Applikationens eksistens hviler således på, at brugeren spiller spillet, da den ellers ikke har nogen nytteværdi, dvs. den udelukkende er udarbejdet som supplement til spillet og den funktionalitet som tilbydes, appellerer til brugeren, fordi applikationen er med til at forbedre brugerens overblik over andre spillere og afviklede kampe. For os er siden relevant i den henseende at den funktionalitet som den tilbyder, ligner de funktioner vi ønsker at udarbejde, derudover er eksistensgrundlaget for applikationerne de samme. Applikationen er meget simpelt opbygget med menuer og en række informationsbokse, den tilbyder bl.a. mulighed for oprettelse af en personlig prol som for det første indeholder personoplysninger, men hvor der også er mulighed for at oprette de hold man spiller med samt data herom. Dertil er det muligt at oprette de afviklede kampe spillernes hold imellem. Sluttelig er det muligt, at føre nogle simple statistikker i form af hvilken plads man ligger på med sine forskellige hold i forhold til andre mm. Som tidligere nævnt er Blood Bowl and Beer en simpel applikation, hvor en del af elementerne med sandsynlighed kan anvendes til Magic-systemet. I det følgende ser vi på hvilke egenskaber, der kan overdrages til vores system og y- dermere hvilke der er opstået på baggrund af analysen og diskussionen. Ligesom på Blood Bowl and Beer er det en god ide, med en række informationer på forsiden såsom en oversigt over de seneste ti afviklede kampe. Desuden ville det være smart at have en online-now-funktion, hvor man kan se hvem der er online realtime. Dertil blev der givet udtryk for en form for top ti topic, der bliver diskuteret i det eventuelle forum og sidst men ikke mindst en event-liste, hvor brugeren kan se kommende arrangementer mm. Ved oprettelse af en prol, blev der på baggrund af BBB givet udtrykt for ønske om følgende muligheder. At se hvilke decks man har, kontakt muligheder, beskrivelse, favorit farve, hvor meget man spiller, hvilke farve man spiller mest mm. Desuden blev der givet udtryk for en form for titelgenereret ud fra hvordan man som spiller klarer sig. Dertil skulle det være muligt for alle at oprette en prol, som også skal være nødvendigt, for at have adgang til alle de funktioner som applikationen understøtter. Ved oprettelse af decks, som på sin vis minder om et hold fra BBB, kan vi drage følgende ønsker: generelle oplysninger om decket: farve, favorit kort, ide med decket, historien bag decket, antal kort. Hertil mulighed for både en kort og lang af decket. Der blev desuden givet udtryk for at det var

91 vigtigt, at beslutte hvilken type af decks vi ville understøtte såsom Type 1 og Type 2 eller vintage, som er en strukturering af brugerens decks på baggrund af hvornår de kort decket er sammensat af er udgivet. Ydermere ville det være en ide med mulighed for typebestemmelse af decks, såsom om det er Control eller Creature deck. Og til sidst og ikke mindst om antal tabte og vundet kampe på decks. Ved oprettelse af nye afviklede kampe, skal det modsat BBB ikke være muligt at kunne oprette kampe for alle spillere, denne funktion hviler således på brugerens egne decks, hvor man kan vælge et af sine decks og derpå vælge sin modstanders. Derpå påhviler det så den valgte modstander at godkende kampen, der så er afsluttet. Der blev dog givet udtryk for en moderator login, hvor denne havde mulighed for at afslutte kampe for alle brugere. En anden ide var at brugeren havde mulighed for at tilføje kommentaren til de afviklede kampe, både som private og oentlige meddelelser. Som i BBB er grundideen med applikationen, muligheden for at danne overblik over de afviklede kampe, derfor skal prototypen som BBB også understøtte muligheden for, at se de mest vindene spillere, bedste decks, mest spillede farve, mest spillede type mm. Dertil blev der ydret ønske om mere avanceret statistik, såsom hvordan farverne klarede sig mod hinanden og hvilke der klarede sig værst. En mulighed for at gøre pointssystemet i en rangliste for deck og spillere mere fair, kan man benytte dierentieret points, således at jo større forskel der er på to decks, jo mere har man at tabe eller vinde ved afviklede kampe. På denne måde betyder det ikke så meget, at man taber med et nyt deck til et gennemprøvet. Hertil er det også vigtig at der er mulighed for større gevinst af points ved afvikling af mængder af kampe, eksempelvis bedst ud af tre. A.7.2 På denne måde opretholdes også lysten til at oprette og spille med nye decks. En anden mulighed er at lave ranglisten ud fra en rating på spillerens decks og kampe, dvs. at brugerens rating bliver genereret på baggrund af hvor mange kampe han har spillet totalt med sine decks og deraf hvor mange sejre han har. Dertil bliver et decks rating beregnet på samme måde, men dog her både ud fra en ociel og en uociel liste af tabte og vundet kampe. Analyse for Facebook Facebook.com er et populært community website, der de seneste år har haft en massiv fremgang af tilmeldte brugere. Det anslås at Facebook på verdensplan har over 50 millioner medlemmer, heraf er ca danskere. På Facebook.com er det muligt at blive ven med en fra det virkelige liv og sitet bruges primært af folk der vil komme i kontakt og/eller vedligeholde forbindelsen med familiemedlemmer, venner, skolekammerater, arbejdskollegaer etc. Herunder vises en illustration A.3 af en bruger på Facebook. Siden er blevet brugt til forbilledanalysen, da den er relevant i den henseende,

92 Figur A.3: Facebook at den kan have nogle community-funktioner, som med fordel kan overføres til magic-systemet. I det følgende vil der være en overordnet opsummering af de funktioner på siden, som brugerne testede og kommenterede på, hvorefter der ses på hvilke egenskaber, der kan overføres til magic-systemet. En bruger på siden har sin egen prolside, hvor brugeren kan tilføje forskellige former for oplysninger om sig selv. Det kan være fra de basale omlysninger om hvornår man har fødselsdag, hvilken by man bor i til ens fritidsinteresser, yndlingslm, favorit citat osv. For at folk kan se ens prol skal man som udgangspunkt have dem på vennelisten. En person kan tilføjes ved at sende en friend request til denne. En sådan forespørgsel kan enten accepteres eller afvises. Udover at indeholder personoplysninger, er det muligt at bygge prolsiden op. Her kan brugeren tilføje applikationer, der tilbyder forskellige services. En af dem er den populære wall-applikation, der minder om en gæstebog. Udover at tilføje applikationer, kan brugeren tilkendegive hvad han/hun interesserer sig for eller støtter ved at tilmelde sig en af de mange grupper, der ndes på siden. Det er også muligt at tilmelde sig til en event, såsom Roskilde Festivalen, hvor man også kan se alle de andre der har tilmeldt sig. Det er muligt at få besked via , hvis f.eks. brugeren er blevet tilføjet af en ven eller at der er blevet skrevet på personens wall. En anden måde at blive holdt up-to-date på hvad folk på vennelisten laver på Facebook er via funktionen News Feed. Her får brugeren et udpluk af de aktiviteter ens venner har foretaget på Facebook. Som tidligere nævnt kan Facebook have visse funktioner, som sandsynligvis kan anvendes til magic-systemet. I det følgende angives, hvordan de egenskaber, der kan overføres, kan fungere i forhold til magic-systemet. Punkterne er et resultat af forbilledanalysen af Facebook med brugerne samt efterfølgende analyse. Ligesom i Facebook skal den enkelte spiller have en prolside. Der blev på

93 baggrund af Facebook-forbilledet givet udtryk for ønske om at de oplysninger, der skal opgives, skal være af en anden art end i Facebook. Udover navn og lokation, vil det være mere relevant at oplyse hvilken spillertype man er, hvilke kampe man foretrækker, hvad ens foretrukne/stærkeste deck er mm. Facebooks fremgangsmåde at tilføje en ven på, kan i magic-systemet anvendes i forbindelse med godkendelse af et kampresultat. Dvs. en spiller sender en request af sted, hvori han har angivet resultatet for den specikke kamp. De andre spillere får en forespørgsel, hvor de enten kan acceptere at resultatet er det rigtige eller også afvise den, fordi der er fejl. Det kan også bruges til at invitere spillere til en kamp. Her vil spillerne blot få en forespørgsel om de vil deltage i kampen. Notikation via bruges til at oplyse brugerne om at de er blevet inviteret til en kamp eller turnering, men dertil blev der givet udtryk for at man ikke ville spammes med kamp-tilbud, og at der skulle være mulighed for at afmelde denne funktion. I Magic-spillet kan man spille gruppe mod gruppe. Der vil derfor kunne dannes grupper, hvor en ok spillere er medlemmer, og de vil udover deres egen prolside, have en fælles side for gruppen. Ved at gå ind på gruppens side, skal man kunne se hvem der er medlemmer af gruppen. Gruppen vil også have en wall, hvor spillerne har mulighed for at skrive til hinanden. I modsætning til Facebook, vil der i magic-systemet være fri adgang til spillernes prolsider for ikke-registrerede brugere med den undtagelse at de personlige oplysninger, såsom adresse og telefonnummer, ikke vil være frit tilgængelige. Event-funktionen bruges til, at en spiller annoncerer fx en turnering, hvor det afholdes og antal pladser. Spillerne kan dernæst tilmelde sig turneringen indenfor en bestemt tidsfrist. Ligesom i Facebook vil det være muligt at se hvem der har tilmeldt sig. News Feed bliver overført til systemet, således at brugerne kan se opsummeringer over ugens kampe og resultater. A.7.3 Opsummering På baggrund af de udarbejdede analyser kan man udlede en række krav til informationer og funktioner, desuden skal man være bevist om de indbyrdes uoverensstemmelser mellem brugerne, her er det nødvendigt at udarbejde et kompromis med henblik på at teste disse i en senere prototype, hvor problemet således kan tages op igen og en evt. rettelse kan tilgå på baggrund af evaluering af det senere design. I dette tilfælde var der ikke enighed om synligheden af informationer for omverdenen. Det vil sige, hvorvidt omverdenen skal kunne se informationer om spillere og decks uden at have en prol i applikationen. Her giver det ikke mening at oplysningerne skal være skjulte, da brugerne ikke havde noget krav for at oprette en prol, på baggrund at dette vil prototypen

94 således blive udarbejdet sådan, at kun de emner som indeholder personlige oplysninger holdes skjulte. Et andet tilfælde er hvordan spilleren og decks skal rangeres, her var der også ere tiltag. Her er det nødvendigt at diskutere mulighederne igennem og udarbejde prototypen på denne baggrund. I dette tilfælde betyder det at forslaget om en rating på spiller og decks forfølges, det vil ske ud fra brugerens total antal kampe og derudaf antal vundet kampe, desuden vil også forslagene om at lave to ranglister blive forsøgt implementeret. Det begrundes med ønsket om, at så mange brugere registrerer deres kampe som muligt, og ved at have to forskellige former for ranglister, kan det mindske risikoen for, at brugere undlader at oprette afviklede kampe, da de ikke vil rates dårligere. Ved at lade brugeren operere på både en ociel og en uociel rangliste, har brugeren mulighed for at arrangere vennekampe mm., som således ikke tillægges den samme betydning som ocielle kampe. A.7.4 Kravspecikation På baggrund af de afviklede analyser kan der opstilles følgende krav til funktionaliteten og indholdet af applikationen. Nogle af kravene går igen i begge forbilleder, her er der valgt den løsning, der på nuværende tidspunkt synes at falde mest i brugerens interesse. Generelle krav Der skal være hurtig adgang til de forskellige sektioner på programmet. Brugerne skal have let ved at tilgå de funktioner som er relaterede til deres prol, og disse skal være tydeligt adskilte fra resten af programmets funktioner. Der skal ikke placeres for mange informationer på lidt plads, da dette kan gøre siden uoverskuelig. Forsiden skal indeholde News Feed - liste over de seneste kampe. Top 10 topic i forummet. En Eventliste. Personlig prol skal indeholde Person- og kontaktinformationer. Rating på spilleren. Titel på spilleren ud fra antal kampe og rating. Spillerens decks. Notikation via mail, når der oprettes data der vedrører en. Valgfri notikation via mail, når der kommer en invitation til en kamp.

95 Gruppedannelse. Wall. Decks skal indeholde Oplysninger om decket. Baggrund for decket. Rating på decket. Oprettelse af afviklet kamp Oprettelse af egne kampe med egne decks. Godkendelse af sejre og nederlag (notikation via mail). Moderator med mulighed for at afslutte alle kampe under ansvar. Matchsheet. Statistik Rating over de bedste spillere mm. Rating over de bedste decks mm.

96 A.8 Spørgeskema Vi har valg at tage udgangspunkt i "Lord of the Rings - bog, lm, roller, computerspil"[[12]], her viser undersøgelser at det hovedsageligt er drenge i alderen 15 til 18 der spillede RPG, da kortspillet Magic har en del relationer til rollespils-verdenen, forventer vi at det ligeledes er drenge eller unge mænd der spiller dette spil. Vi forventer også at alderen kan være en anelse højre, det begrunder vi med at spillet vandt frem i midten af 90erne. Dvs. at der i dag kan være væsentlig ældre spillere da de har bibeholdt interessen. På baggrund af de udfyldte spørgeskemaer A.8 kan vi nu danne os et overblik over brugerne, her k vi bekræftet af en stor del af spillerne havde spillet i mange år og at deres gennemsnitsalder var 23, desuden havde de alle grundlæggende kendskab og adgang til pc samt internet. Halvdelen af den var bekendt med eller var brugere af forummer og communities. Dertil k vi en ide om hvor tit spillerne spillede kampe og dermed en ide om hvor tit en applikation ville blive tilgået med nyt data.

97 Spørgeskema Spørgsmål til brugerne 1. Navn: 2. Alder: 3. Hvordan vil du beskrive dig selv som bruger af IT og Internet? (sæt et eller flere kryds) [ ] Jeg har min privat PC/MAC [ ] Internet [ ] Online forums [ ] Bruger communities, f. eks. facebook eller lignende 4. Hvornår startede du med at spille Magic? 5. Var Magic det første samlerspil du startede på, hvis ikke hvilke spil har du så spillet? Svar: 6. Hvor tit spiller du kampe? Sæt et eller flere kryds) [ ] Flere end én gange om ugen [ ] Én gang om ugen [ ] Flere end én gange om måneden [ ] Én gang om måneden [ ] Sjælden [ ] Jeg er ny til spillet, så det er uklart endnu:) 7. Hvor lang tid tager en spil session du er med i i gennemsnit? Figur A.4: Spørgeskema

98 A.9 Forberedelse til brugsmønstersessionen Formål: At lave brugsmønstre og tilstandsdiagrammer. I samarbejde med brugerne skal der foregå en vurdering af brugsmønstre. Vi vil forsøge at konstruere et spilforløb og anvendelsen af magic-systemet, baseret på input fra brugerne. Hvordan: Vi mener, at det for brugerne vil være bedst hvis de ikke bliver fastlåst med for mange krav, da det mulighvis kan forhindre dem i at komme med ideer. Derfor vil vi undgå at fastlægge for mange ting før vi mødes med dem, men lade så mange muligheder stå åbne som muligt. Vi henter vores inspiration fra usabilitytest, hvor brugerne tænker højt og fra rollespil. Fremgangsmåde: Brugerne medbringer kort, og vi prøver at skabe lidt magi i luften. Der forklares overfor brugerne hvordan vi har tænkt os at processen skal forgå. De bliver bedt om at forestille sig, at der er et aktuelt system, da vi ikke har et færdigt produkt at vise dem. I fællesskab prøver vi at konstruere en spilsituation i form af rollespil og få den til at ligne et virkeligt setup. Systemet gennemgås trin for trin, mens brugerne tænker højt og interagerer med hinanden og udviklerne igennem hele processen. Ved at tænke højt fortæller de hvad de forventer at se, hvordan de forventer at det fungerer, hvilken funktionalitet de forventer, der kommer næst osv. Forventninger: Forventninger frem til mødet er: At brugerne er med på det rekonstruerede forløb og er motiverede. At fremgangsmåden for vurderingen af brugsmønstre med brugerne er mere virkningsfuld end hvis det bare havde været en samtale mellem brugere og udviklere. At vi får lavet realistiske brugsmønstre og tilstandsdiagrammer ud fra de beskrevne brugsmønstre/scenarier. At vi får input fra brugerne der kan guide os i den rigtige retning mht. features/opbygning af systemet. At få rettet eventuelle misforståelser af vores opfattelse af spillernes tænkemåde. At nye idéer dukker op, også idéer der ikke kan bruges direkte i udviklingen af brugsmønstre, men som passer ind andre steder. Fordele/Ulemper: En fordel ved at inddrage rollespil-metode kan være, at det kan virkelig tænde for fantasien hos brugeren, og på den måde kan der skabes et godt ow, og derfor skabe et godt grundlag for at dokumentere realistiske brugsmønstre og tilstandsdiagrammer. En ulempe kan eventuelt være at brugerne ikke bryder sig om rollespil-forløbet og derfor ikke deltager aktivt, som de måske vil have gjort, hvis forløbet var gået efter en "standardprocedure", hvor vi stiller spørgsmål og de svarer og derved får en dialog i gang. Det ow,

99 som vi gerne vil opnå, vil herved udeblive. Rollefordeling: 2 observatører, der noterer ned hvad brugerne siger og hvordan processen forløber, og én ordstyrer, der styrer processen. A.9.1 Match-scenarie Vi har tænkt os to forskellige scenarios; online, hvor brugerne taster resultater ind direkte under eller lige efter kampen (match). oine, hvor de bare noterer ned, og taster resultaterne ind, når de er kommet hjem. Hensigten er at tillade brugeren frit at komme med ideer til hvordan brugsmønstret vil danne sig. Vi vil dog selv notere vores egne forestillinger til dem ned, således det evt. kan anvendes senere til at sammenligne med de brugsmønstre som bliver dannet sammen med brugerne. Herunder er vores forslag til hvordan processen kunne være: Brugsmønster når man ikke har computeren med til kampen: Udskrive matchsheet: Medtage matchsheet til kampen, udfylde et matchsheet, login i systemet, opret kamp, skriv oplysningerne fra matchsheet ind, nd bruger2, send til bruger2. Bruger2 logger ind og accepterer eller afviser resultaterne. Brugsmønster hvor man har computeren med under matchen: Login: opret kamp, indtast resultater, nd bruger2, logout; bruger2 logger ind og accepterer. Scenario beskrivelse for oprettelse af et deck: Brugeren logger ind i systemet (indtaster brugernavn og password). Under navigationsmenuen nder han link til sin personlige prol. Han aktiverer denne link, og et nyt skærmbillede åbnes. Derinde nder han og aktiverer en link til oprettelse af et nyt deck. Her vil vi gerne få brugeren til at forstille sig, hvilke informationer han gerne vil taste ind, hvilke valgmuligheder han gerne vil se, og hvilke funktioner, hvis nogle, skulle være tilgængelige. A.9.2 Statistik-scenarie To statistik-scenarios: den hvor man sidder hjemme og kigger på statistik, og den hvor man tager computeren med til kamp, og kigger på statistikken der i det sociale samvær. Brugsmønstre når man sidder hjemme: Man er som spiller interesseret i at se statistik for en selv, ens deck og andre spillere. Hvordan ville det forgå, hvilke informationer kunne have interesse for spilleren. Hvordan skal det organiseres, hvordan forestiller spilleren sig det. Eks.: Spilleren logger ind, på hans prol kan han se en oversigt over de tabte og vundne kampe, og hvilke decks han har.

100 Han kan sammenligne to decks eller ere med hinanden. Han vælger en andens spillers deck og sammenligner med hans eget deck. Han vælger en anden spiller og sammenligner med sig selv over tabte og vundne kampe. Han vælger en anden spiller og sammenligner med en tredje spiller. Brugsmønster når man sidder sammen og kigger på statistik To spillere vil se statistik sammen, er der andre informationer der har interesse? Er der information som de vil give hinanden lov til at tilgå, som ikke skal ses af andre. Er der en bestemt type statistik, de har interesse i? A.9.3 Spørgsmål til brugerne Mulige spørgsmål til brugerne om forløbet efter sessionen: Hvad synes I om forløbet? Inspirerende med en anderledes fremgangsmåde frem for alm. dialog? Skulle vi have grebet det an på en anden måde? Var det et forstyrrende element at der var rollespil inkluderet eller ligefrem en fordel for idegenereringen? Har I selv fået noget ud af det her? Andet I gerne vil sige? Er vores brugsmønstre og scenarier realistiske eller er fremgangsmåden en anden? Noget vi mangler at tilføje til brugsmønstrene A.10 De 4 brugsmønstre I denne afsnit beskrives de resulterende brugsmønstre lavet efter sessionen med brugerne. A.10.1 Brugsmønster I Beskrivelse: Brugsmønsterbeskrivelse af registrering af en match med matchsheet. En spiller går ind på systemet og udskriver et eksemplar af matchsheet. Han tager af sted for at spille med en anden magic-spiller. Efter hvert match udfylder han felterne ud på matchsheet. Så snart han er hjemme igen vil han uploade informationerne, derfor logger han ind sig ind på magic-systemet med sit brugernavn og password. Under menunavigationen nde han punktet Tilføj Match, hvor han indtaster oplysningerne fra matchsheet (evt. først søge efter modspilleren i systemet i stedet for at skrive det manuelt?). Til slut trykker han på Tilføj Match-knappen og sender derved en acceptmeddelelse til spiller nummer 2. Hvis han har ere kampe at tilføje trykker han i stedet på Tilføj ere-knappen. En illustration af brugsmønstret ses i tilstandsdiagrammet på

101 gur A.5 Objekter: De objekter som bruges i brugsmønstret er 2 spillere, 2 decks og en Match. Funktioner: Udprintning af et matchsheet. Tilføj flere match Ny match oprettet Find modspiller Modspiller fundet Opret ny match Match tilfjøjet Indtast beskrivelse Beskrivelse indtastet Tilføj match Bruger logged ind Modspiller findes ikke Find en anden Fjern match modspiller Fortryd Fortryd Fortryd Godkend Login accepteret Login A.10.2 Figur A.5: Registrering af en match med matchsheet. Brugsmønster II Beskrivelse: Brugsmønsterbeskrivelse for registrering af en match uden matchsheet. En gruppe spillere bender sig hjemme hos en af dem hvor de har adgang til internettet. En af dem logger sig ind på magic-systemet, trykker på Tilføj Match under navigationsmenuen og udfylder felterne, så han, når kampen er over, kun skal udfylde hvor lang tid kampen har varet og hvem der har vundet. Når vinderen er fundet, indtaster spilleren de resterende felter i systemet og trykker på Tilføj Match. (Der dukker en popup-boks op, hvor modstandsspilleren kan logge ind og med det samme acceptere resultatet). En illustration af brugsmønstret, ses i tilstandsdiagrammet på gur A.5 Objekter: De objekter som bruges i brugsmønstret er 2 spillere, 2 decks og en Match. Funktioner: Ingen funktioner. A.10.3 Brugsmønster III Beskrivelse: Brugsmønster beskriver en spiller som vil statistik for et deck. Spilleren logger ind i systemet, og skal identicere sig ved hjælp af brugernavn og password. Spilleren vælger et af sine decks (deck1) for at se statistik for dette, med det mål at se hvordan decket har udviklet sig over tid, og ændre decket. System generer en graf eller tabel over vundet og tabte kampe over tid med det

102 deck, og viser desuden et kommentarfelt for dette deck. Spilleren læser de kommentarer, han har lavet til decket, og vælger at udskifte to kort i decket. Han skriver en ny kommentar i kommentar feltet. En illustration af brugsmønstret, ses i tilstandsdiagrammet på gur A.6. Objekter: De objekter som bruges i brugsmønstret er en spiller, et deck, 2 eller ere matches. Funktioner: Funktionerne i dette brugsmønster er statistik og søg. Skift statistik Deck valgt vælg statistik Statistik på deck valgt See på valgt statistik Statistik vises Vælg deck Vælg et andet deck Vælg en anden statistik Bruger logged ind Gå tilbage Login A.10.4 Brugsmønster IV Figur A.6: Se på statistik. Beskrivelse: Brugsmønster der beskriver en spiller sammenligner statistik mellem hans eget deck og en anden spillers deck. Spiller 1 er brugeren, spiller 2 er en spillerprol på systemet. Spilleren logger ind i systemet, og skal identicere sig ved hjælp af brugernavn og password. Spillere1 vælger et af sine decks (deck1) for at se statistik for dette med det mål at se, hvordan decket har udviklet sig over tid, og ændre decket. Systemet giver ham mulighed for at sammenligne med en anden spillers deck. Han søger efter en anden spiller (spiller2), og kan vælge at se hans prol. Systemet giver ham en liste over spiller2's decks, og han vælger et af de decks (deck2), der ligner hans eget. System generer en graf eller tabel over antal vundet og tabte kampe over tid med data fra deck1 og deck2. En illustration af brugsmønstret ses i tilstandsdiagrammet på gur A.6. Objekter: De objekter, som bruges i brugsmønstret er en spiller 1, spiller 2, deck 1, deck 2 og to eller ere matches. Funktioner: Funktionerne i dette brugsmønster er statistik og søg.

103 Bilag B Opbygning af layoutet De forskellige prototyper af systemet blev udarbejdet på baggrund af de informationer, der blev tilegnet gennem samarbejde med brugerne, men også gennem teori vi som studerende har været igennem på tidligere semestre. På det funktionelle plan blev der specielt taget udgangspunkt i brugernes ønsker. Til det graske plan havde brugerne ikke nogle specikke krav, men for os var det vigtigt, at det graske layout blev udformet således, at det fremstod appellerende til brugerne. Appellerende i den forstand, at layoutet af brugergrænseaden havde de rigtige signaler i forhold til hvad systemet skulle bruges til. De to t- ing skulle gå op i en højere enhed for, at skabe et godt produkt der sikrede at brugerne k et fornuftigt udbytte af systemet, men også blev motiveret til at bruge den og vende tilbage til den. Ved design af brugergrænseaden bør vi som udviklere have ere ting i baghovedet. Først og fremmest den generelle opbygning med vinduer, menuer og funktioner, men dertil også et korrekt sammensat tema i form af gurer, billeder, fonte og farver. Alt sammen for at fuldende applikationens konsistens og opnå at brugerne blev motiveret til at bruge systemet. Herunder på gur B.1 ses en skitse af layoutet af den endelige prototype. Skitsen viser i dette tilfælde startsiden, men er også den generelle skabelon til alle sider tilhørende applikationen. Øverst er siden domineret af en header, som indeholder et logo samt applikationens navn. Logoet er placeret i venstre side af headeren og i forlængelse af logoet står applikationens navn. Placeringen af logoet venstre er valgt, fordi det øverste venstre hjørne, ifølge usabilityeksperten Jakob Nielsen [[11]], er det sted på en webside som est brugere ser først. Logoet er i dette tilfælde mere et varemærke for siden, ideen med det er, at det skal fungere som en stemningsskaber for brugeren, det er derfor vigtig at brugeren på baggrund af dette billedets centrale placering, opnår de rigtige associationer til magic ved det første øjekast. Det er derfor et godt sted at præsentere webstedets navn og logo. Placeringen af navnet tæt på logoet er desuden fuldt ud i tråd med gestaltlovene, der bl.a. siger at ting som hører sammen skal placeres tæt på hinanden - navnet og logoet er tæt relaterede til hinanden. En anden ting, som Jakob Nielsen tillægger stor vigtighed, er at logoet og navnet fungerer som link tilbage til forsiden. 91

104 Figur B.1: layout Vi mener, at det er yderst relevant, at brugeren føler at applikationen lever op til de forventninger, der allerede er blevet skabt på baggrund af de signaler som bl.a. logoet er med til at sende, inden den endelige ibrugtagning af applikationen. Det ses derfor også at applikationens layout er inspireret af magic-kortene. Langs sidens kant følger et mønster, der minder om det der er på magic-kortene. Dette er gjort igen for at forøge personliggørelsen af applikationen på sådan en måde, at brugeren opnår en større glæde gennem afviklingen. Under headeren er indholdsdelen, her vil alt indholdet på den aktuelle side være at nde. Til venstre for indholdet er navigationsmenuen placeret. Den indeholder de punkter, som er tilgængelige fra alle sider for brugeren og brugeren behøver ikke nødvendigvis at være logget ind for at kunne se disse sider. Navigationsmenuen er placeret på det sted for at hjælpe med at give de besøgende et overblik over webstedets indhold. Denne form for menu er med til at give brugeren en fornemmelse af webstedets bredde. I højre side er login-boksen og under den søgefunktionen placeret. Adskillelsen af loginboksen og navigationsmenuen er valgt på baggrund af gestaltlovene. I de tidlige prototyper stod alle linksene i venstre side som menupunkter, men i forhold til gestaltlovene er de prolrelaterede links siden blevet yttet fra placeringen i venstre side til højre. Efter at brugeren har logget ind, vil der ved login-delens sted være de brugerrelaterede links i stedet for login-boksen. De links, som er relaterede til hinanden er altså opstillet på en måde, som får dem til at høre sammen. Dette er en fordel, da det er på denne del, hvor brugeren kan se om han har nogle ventende kampe, der skal godkendes, det er også i denne del hvor kampe og decks oprettes og brugerens egen prol kan ses og ændres på. På den måde adskilles disse funktioner fra navigationsstrukturen, og dette er forhåbentlig med til at undgå forvirring. Hvis brugeren ikke er logget ind, vil kun loginboksen være synlig.

105 Bilag C Scrum C.1 Første sprint Følgende afsnit indeholder en gennemgang af systemet, som det så ud efter første sprint var overstået. I første sprint valgte vi primært at fokusere på, at få kodet de forskellige funktioner i de forskellige lag, således at vi kunne få implementeret de mest basale funktioner, såsom oprettelse af brugere i systemet og muligheden for at logge ind i systemet. Derudover forsøgt vi at få et foreløbigt designforslag på plads. Dette blev gjort fordi vi mente at det ville være nemmere at teste de forskellige ting, hvis vi havde en nogenlunde ide om hvordan systemet skulle se ud. Dette afsnit vil indeholde en række screenshots af systemet, som skal være med til, at beskrive hvordan systemet fungerede efter første sprint. I første sprint k vi bl.a. udarbejdet et foreløbigt udkast til designet, som kan ses på gur C.1. Designforslaget er udviklet på baggrund af forskellige teorier for brugergrænse- ade design, som beskrevet i bilag B.1, samt ud fra hvilket system det er vi skal udvikle. Vi valgte at have en trold og en skov i toppen af designet, og vi valgte farver som alle var ret dystre. Dette skulle være med til forhåbentlig at skabe en stemning, som ville være relevant og passende for brugerne af websitets magic-spillere. Efter første sprint var det i systemet muligt at oprette players, i første omgang dog uden brug af en database, hvilket ville sige at en player blev slettet umiddelbart efter browseren blev lukket. Men den grundlæggende funktionalitet var på plads, og det ville umiddelbart kunne overføres til brug med en database. Oprettelses-siden så ud som på gur C.2. Felterne repræsenterer de attributter som en player havde i klassediagrammet, og som var blevet programmeret i Player Controlleren. Valideringsklassen som tjekker om et input-felt er korrekt udfyldt var ydermere implementeret efter første sprint. Udover at kunne oprette en bruger i systemet, var det også muligt at logge ind i systemet, med en eksisterende (eller nyoprette) bruger. Som det kunne ses på gur C.1 indeholdt sidebaren et område med en login-form. Når en bruger loggede ind via denne form, blev siden opdateret og login-formen blev erstattet med information om hvem der var logget ind. En bruger kunne efter at være logget ind navigere rundt i systemet, og hele tiden forblive logget ind. Det blev implementeret vha. sessions, hvilket vil sige at en bruger blev logget ud når browseren blev lukket. 93

106 Figur C.1: Designudkast, første Sprint Figur C.2: Brugeroprettelse

107 Funktionen til at redigere en player blev ikke fuldt ud implementeret, da det blev vurderet at det var bedst, at vente med det til efter vi havde mulighed for at arbejde med en database. Funktionen blev dog implementeret så langt at en bruger som var logget ind kunne åbne redigeringssiden, hvorpå felterne var udfyldt med de informationer som var gemt om den aktuelle bruger. Denne side ses på gur C.3 Funktionen til at vise players var ligeledes implementeret. Det Figur C.3: Redigeringssiden betød at en bruger som var logget ind, kunne se sine egne oplysninger ved at gå til Vis Player-siden. Ligeledes kunne andre brugeres proler ses ved at tilføje et ID til URL-en På gur C.4 ses et eksempel på Vis Player-siden. Som det Figur C.4: Vis Player-siden tydeligt ses på gur C.4, er det kun den mest basale del af denne funktion der er implementeret, selve designet af siden var ikke på plads efter første sprint.

108 C.2 Andet sprint Det følgende afsnit indeholder en gennemgang af hvorledes systemet ser ud, efter det andet sprint var overstået. I sprint nummer to blev der fokuseret på at få implementeret ere funktioner i systemet. Databasen var nu tilgængelig og det lettede arbejdet en del. Det betød dog også at der skulle foretages et par småjusteringer i systemet, for at få det til at fungerer med databasen. Der blev arbejdet videre på systemet ud fra hvordan det så ud efter sprint nummer to. Det overordnede design og opbygning blev bibeholdt, og der blev primært arbejdet på at tilføje funktionalitet. Dette afsnit vil indeholde en række screenshots af systemet, som skal være med til, at beskrive hvordan systemet fungerede efter andet sprint. Decks blev implementeret i systemet. Det var således efter andet sprint, muligt at oprette og redigere decks. Opret deck-siden så ud som på gur C.5. Figur C.5: Opret Deck En bruger som var logget ind i systemet havde mulighed for at oprette et deck, med en række attributter. Hvis en bruger ikke var logget ind, blev der i stedet vist en fejlmeddelelse, som fortalte at det var nødvendigt at logge ind for at anvende den ønskede funktion. Som i sprint nummer et var der også

109 implementeret tjek på om de enkelte ere var udfyldt eller om der var markeret en eller ere muligheder. På tilsvarende vis var det muligt for en bruger som var logget ind i systemet at redigere et af vedkommendes eksisterende decks. Det blev gjort ved hjælp af den samme side, hvorpå de eksisterende oplysninger var for-indlæst, og kunne redigeres, som det ses på gur C.6. Figur C.6: Rediger Deck Systemet tjekkede hvorvidt den bruger der forsøgte at redigere et deck rent faktisk ejede det aktuelle deck, og hvis det ikke var tilfældet blev der vist en meddelelse der bekendtgjorde dette. I forbindelse med decks blev der også implementeret en side til at vise informationer om et enkelt deck. Et eksempel på en sådan kan ses på gur C.7.

110 Figur C.7: Vis Deck Vis deck-siden viste alle tilgængelige informationer om et deck, dog var det kunne de informationer, som blev gemt i databasen der var implementeret efter andet sprint. Informationerne om statistik og seneste kampe blev ikke implementeret, da de krævede at kamp- og statistiksystemerne var blev implementeret. Vis Player-siden som blev implementeret i sprint et blev forbedret i sprint to. Der blev arbejdet med designet af siden, således at der nu var en smule mere styr på hvor de enkelte oplysninger skulle placeres. Det endelige design var dog ikke på plads endnu. Vis player-siden så efter andet sprint ud som på gur C.8.

111 Figur C.8: Vis Player Ud over de forskellige oplysninger om brugeren blev der også vist en liste over de decks som var knyttet til den aktuelle bruger. Det var fra denne liste muligt at klikke sig videre til selve deckets side, hvor yderligere oplysninger ville være tilgængelige. Der blev, som på Vis deck, implementeret er Rediger prol-knap, som kun blev vist hvis den prol som blev vist tilhørte den bruger som var logget ind i systemet. Rediger player-funktionen, som ikke var fuldt ud implementeret efter første sprint, blev færdigudviklet og der var efter andet sprint muligt at redigere sin brugerprol på tilsvarende måde som redigering af deck. Ydermere blev kampe delvist implementeret i systemet. Det var efter andet sprint muligt at oprette en match. Det foregik ved hjælp af en side som vist på gur C.9.

112 Figur C.9: Opret Match Opret match-siden giver en bruger mulighed for at indtaste alle de oplysninger der er relevante for en match. Den spiller som er logget ind i systemet vises som spiller 1, og vedkommendes decks vises, så det der blev brugt kan vælges. Navnet på modspilleren indtastes, og vedkommendes decks vises, så det korrekte deck ligeledes kan vælges her. Designet af Opret match-siden var ikke endeligt på plads efter andet sprint. Funktionen til at redigere en match blev ikke fuldt ud implementeret i andet sprint.