Administrationssystem med Android applikation Driving Academy

Transkript

1 Dette er procesrapporten til Bacheloropgaven på University College Nordjylland, omhandlende udviklingen af et Administrationssystem til Driving Academy. Opgaven indeholder alt information og dokumentation vedrørende procersserne bag Bacheloropgaven. Administrationssystem med Android applikation Driving Academy Procesrapport Professionsbachelor i Softwareudvikling Lasse Abelsen, Rasmus Rudbæk Laursen & Alex Østergaard

2 Indholdsfortegnelse 1.0 Indledning Metodevalg Procesorienteret eller agilt? Boehm & Turners-metode Valg af udviklingsmetode SCRUM Praktikker Product Backlog Sprint Backlog Sprint Tidsestimering Burn down chart Roller Daglige Scrums Scrum Review Meeting Accept-test Vores brug af accept-test User Stories Task Board Spikes Valg af arkitektur Android Widget Android widget vs. hjemmeside Trends indenfor mobile applikationer Grænsefladedesign Mock-Ups og Prototyping Brug af mock-ups og prototyping Tidsplan Dagbøger Dagbog fra uge 1, 22/ til 26/ Dagbog fra uge 2, 29/ til 3/ Dagbog fra uge 3, 6/ til 10/ Dagbog fra uge 4, 13/ til 17/ Side 1 af 45

3 8.5 Dagbog fra uge 5-6, 20/ til 2/ Dagbog fra uge 7, 3/ til 7/ Dagbog fra uge 8, 10/ til 14/ Referat af møder Referat fra møde med Driving Academy 8/ Noter fra møde med Driving Academy 8/ Referat fra møde med Driving Academy 22/ Dagsorden Møde Med DA Referat fra møde med Driving Academy 13/ Dagsorden Møde Med DA 10/ Referat fra møde med Driving Academy 10/ Arbejdsfordeling Opgave kontrakt Side 2 af 45

4 1.0 Indledning Grunden til at vi har valgt at dele vores dokumentation op i to dele, er for at lette overskueligheden af projektet. Denne rapport indeholder derfor alle vores overvejelser omkring metodevalg, arkitekturovervejelser, design, tidsplaner, ugentlige dagbøger samt dagsordner og referater, fra de møder vi har afholdt sammen med vejleder og driving academy Vi bruger specielt denne rapport til at finde ud af hvilken udviklingsmetode der vil være mest hensigtmæssig at bruge. Konklusionerne i denne rapport bruger vi derfor som grundlag for vores metodevalg i produktrapporten. 2.0 Metodevalg I dette kapitel vil vi forklare vores valg af udviklingsmetode. Metodevalget har ofte stor betydning for den måde projektet skal organiseres og det var derfor en af de allerførste overvejelser vi havde. For at kunne finde frem til den metode som passer projektet bedst, så er man nødt til både at kigge ind og ud af. Valget af metode afhænger nemlig af mange faktorer, både hos projektholdet selv og hos kunden. Dette kapitel vil beskrive vores valg og overvejelser. Efterfølgende vil vi argumentere for, hvordan vi mener at have overholdt praktikkerne i den valgte metode. Vi endte med at vælge SCRUM som vores udviklingsmodel. 2.1 Procesorienteret eller agilt? Her vil vi analysere hvorvidt vores projekt bedst kan defineres som enten et procesorienteret eller agilt. Ideen bag at vælge procesorienteret eller agile udviklingsmetoder ud fra hvilket slags projekt man arbejder på, gør det nemmere at vælge den korrekte mængde dokumentation i givne situationer. Det er selvfølgelig vigtigt at der foreligger dokumentation på systemer som har en stor betydning, enten økonomisk eller med hensyn til menneskeliv, hvorimod projekter af mindre vigtighed måske kan gavnes af større fleksibilitet under udviklingen. 2.2 Boehm & Turners-metode Alle systemudviklingsmetoder har hver deres fordele. Til at finde ud af hvilken udviklingsmetode der er bedst egnet til vores projekt, har vi brugt Boehms stjerne. Side 3 af 45

5 I dette afsnit vil der blive beskrevet en metode til analyse af en projektorganisation, med henblik på at definere behovet for enten en agil eller procesorienteret tilgang til projektet. Dette afsnit vil tage udgangspunkt i en artikel af Barry Boehm og Richard Turner: Rebalancing Your Organization s Agility and Discipline heri bliver der beskrevet en metode, hvor man ved hjælp af et spindelvævs diagram kan få en ide om hvorvidt det er ideelt at arbejde enten procesorienteret eller agilt. På dette diagram er der 5 akser, som bruges til at plotte typen af projekt, man er ved at bevæge sig ud i, ind. De 5 akser hedder: Personale, Dynamik, Kultur, Størrelse og Vigtighed. Vi kommer tilbage til betydningen af disse akser. Diagrammet fungerer således at jo længere ude på diagrammet et projekt befinder sig, des bedre vil det være at bruge en process orienteret udviklingsmetode. Hvorimod det modsatte gælder hvis stregerne er tæt på centrum, her vil det nemlig være bedst at bruge en agil metode. De to har definerede homebases som udgør det ideelle miljø for hver af de to typer metoder. Jo tættere man ligger på sådan en homebase, jo større sikkerhed er der ved at vælge enten en agil eller disciplineneret metode. Med homebases menes der hhv. den yderste- og den inderste ring. Personale Aksen Personale defineres ud fra hvilket niveau medarbejderne har på Cockburns 1 modificerede Medarbejder Niveau Skala. Denne skala arbejder ud fra en ide om at der findes udviklere, der er 1 Side 4 af 45

6 helt nye og dermed ikke har den fornødne erfaring til at arbejde alene og uden en plan. Boehm og Turner har modificeret skalaen. Den modificerede version af skalaen har 5 trin i stedet for Cockburns originale 3. Ideen bag denne akse er at jo flere personer et projekt har på et højt teknisk niveau, des nemmere ville det være for projektet at implementere en agil arbejdsmetode. Dynamik Med Dynamik menes der mængden af ændringer i kravene for et projekt, der er nødvendige pr. måned. Hvis man før projektets start ved, at der vil komme en stor mængde af ændringer af kravene og disse kommer løbende under projektet, så kan det bedre betale sig at projektet er agilt, da det så er gearet til at der ofte ændres i projektet samt at dette sker løbende. Metoder, som eksempelvis XP, dikterer f.eks. at man ofte holder møder med kunden for at se på de fremskridt der er sket, samt definerer hvorvidt der er brug for at ændre kravene til projektet. Ideen bag XP er så at kunden vil få et produkt, som svarer meget bedre til forventningerne end man ellers ville med en procesorienteret udviklingsmetode. Kultur Kulturen i projektet og på arbejdspladsen er også en bestemmende faktor for hvordan et projekt bør arbejde. Hvis medarbejderne på projektet trives med kaos og med at arbejde uden en plan. Så giver det også bedre muligheder for at arbejde agilt, da de agile metoder ofte er mere rodede og ustruktureret. Størrelse Boehm og Turners teori består også i at størrelsen på et givent projekt har en betydning for hvorvidt det er ideelt at arbejde enten agilt eller procesorienteret. Det handler om at projekter, hvis de bliver for store, ikke kan styres effektivt agilt. Hvis et projekt har for mange medarbejdere tilknyttet på én gang samtidigt med at man forsøger at arbejde agilt, så kan der let opstå en situation hvor venstre hånd ikke er 100 % klar over hvad højre laver og omvendt. Med en agil arbejdsmetode er det optimalt hvis alle projektdeltagerne har en god ide om hvad de andre fortager sig da dette vil sørge for at en udvikler ikke laver en rettelse i projektet, som så senere viser sig ikke at fungere pga. det de andre projektdeltagere lavede samtidigt. Vigtighed Den sidste, men muligvis den vigtigste af de 5 akser, er vigtigheden af projektet og hvilke konsekvenser der vil være ved fejl i projektet eller for sen levering af produktet. Skalaen for vigtighed af projektet er igen en Cockburn skala, som Boehm og Turner har lånt til lejligheden. Denne skala ser på konsekvensen hvis produktet fejler eller bliver leveret for sent. Boehm og Turner arbejder så ud fra en teori om at jo vigtigere et projekt er, des mere nødvendigt er det at bruge en procesorienteret metode. Side 5 af 45

7 Skalaen har 5 niveauer: Comfort, Discretionary Funds, Essential Funds, Single Life samt Many Lives. Comfort er et niveau hvor det udelukkende er af behageligheds hensyn produktet udvikles. Essential Funds er et projekt som har stor betydning for et firma finansielt, mens Many Lifes selvfølgelig handler om livsnødvendige systemer for mange brugere. Diagrammets indretning betyder også, at et projekt ikke behøver ligge inde eller ude på diagrammet, det kan også ligge i midten. I en sådan situation mener Boehm og Turner at man kan adoptere den metode, som passer bedst til projektet, samtidigt med man kan bruge forskellige aspekter af den modsatte metode. Hvis et projekt passer utroligt godt til en agil arbejdsmetode men vigtigheden af projektet er meget stor, så kan man adoptere en lang række principper og dokumentationsformer fra f.eks. UP. For at sikre at kvaliteten af projektet bliver sådan, som man må forvente når mange menneskers liv afhænger af systemet. Der er ikke plads til alt for mange fejl i sådan en situation, derfor er hverken de procesorienterede eller agile arbejdsmetoder så faste at man ikke kan adoptere principper fra andre. Ved hjælp af dette spindelvævsdiagram burde det så være muligt for en projektleder at finde en metode, som passer til det projekt personen skal lede. At vælge en god arbejdsmetode er utroligt vigtigt for hele projektet ifølge Boehm og Turner, da dette resulterer i gladere medarbejdere og bedre produkter. 2.3 Valg af udviklingsmetode Efter at have vurderert de fem punkter og anvist dem på diagrammet, er der ikke nogen endelig konklusion på valg af udviklingsmetode. Diagrammet hælder mest mod en agil metode, men Vigtighed og Personale hælder mere til en procesorienteret udviklingsmetode. Ud fra dette har vi valgt at arbejde efter Scrum dog med visse aspekter fra UP oven i som dokumentation. Dette har vi valgt fordi projektet ligger langt ude på Vigtigheds-aksen. Samtidig ligger vi som personale også forholdsvis langt ude af aksen. Grunden til vi har vurderet os selv til at lægge langt ude af aksen, er at vi ikke har arbejdet med mobile widgets før. Side 6 af 45

8 2.4 SCRUM Praktikker Valget af udviklingsmetode er altså faldet på Scrum. Vi vil i det følgende afsnit gennemgå de praktikker man bruger når man arbejder med Scrum. Scrum indeholder følgende praktikker: Roller: Scrum Master Product Owner Team Member Møder: Daglig Scrum Sprint Planning Meeting Sprint Review Meeting Sprint Retrospect Andre emner: Product backlog Sprint Backlog Burndown Chart User Stories Udover disse praktikker, har vi tilvalgt nogle praktikker og dele af andre udviklingsmetoder. Vi har inddraget Planning Game fra extreme Programming. Dette brugte vi til tidsestimering af de forskellige opgaver. Den største fordel vi så i, at bruge planning game til estimering var, at alle estimater i planning game er relative i forhold til hinanden. Dette så vi som en stor fordel i forhold til brugen af burndown charts. Ved at alle estimater er relative, kan vi visuelt på en hurtig og let måde se, om vi er foran eller bagud i forhold til sprintet. Havde de ikke været relative, kunne forsinkelser i forhold til estimatet, kun være gældende for den enkelte opgave, og altså ikke være sigende for et helt sprint. Til brug under udvikling af systemet valgte vi også at lave et klassediagram. Dette har vi hentet fra UP. Vi gjorde brug af et klassediagram fordi vi tidligere har oplevet, hvor stor en hjælp det kan være, at have en visuel beskrivelse af opbygningen af systemet. Det hjælper med til, at holde et logisk overblik. Side 7 af 45

9 SCRUM indeholder ikke nogle praktikker for hvordan man laver prototyper og mock-ups. Vi har derfor gjort brug af horizontale prototyper fra UP Product Backlog Product Backloggen er en liste af alle de opgaver der skal laves, for at projektet er fuldendt. Det er denne liste der bliver taget fra, inden man går igang med et nyt sprint. Netop fordi man bruger opgaverne her fra som opgaver på sprints, er det vigtigt at dekomponere opgaverne så meget som muligt. Ved at gøre dette, gør man det både lettere at tidsestimere mere præcist og samtidig er det også lettere at lave en Sprint Backlog der passer i antal timer. Vi har udarbejdet en Product Backlog for alle de opgaver der indgik som en del af Driving Academy s ideelle system. Product Backloggen tager udgangspunkt i kravsspecifikationen, som vi har udarbejdet i samarbejde med Driving Academy. Resultatet er den product backlog som er lavet til hhv. Administrationssystemet og android applikationen, begge disse kan findes i produktrapporten i gennemgangen af begge programmer. Udarbejdelsen foregik på den måde, at vi efter konsultation med Driving Academy prioriterede hvert enkelt punkt i kravsspecifikationen fra 1 og op efter, hvor 1 har første prioritet, 2 anden priorietet osv. Da punkterne i kravspecifikationen var meget brede, inddelte vi dem herefter i en række underopgaver. Endelig prioriterede vi hver enkelt underopgave i samarbejde med Driving Academy, således at det ville være muligt at bestemme hvilke opgaver der skal med på et givent sprint. Grunden til, at Driving Academy var med til prioritering af hver enkelt opgave er, at det sikrer DA mest mulig udbytte af vores arbejde gennem hele projektet, eftersom vi på et hvert tidspunkt laver det der giver mest værdi. På den måde står vi ikke til slut og ikke kan nå et punkt, som er meget værdifuldt for dem, mens vi måske samtidig har spildt tid på noget mindre vigtigt Sprint Backlog Sprint Backloggen tager udgangspunkt i Product Backloggen. Den skal indeholde så mange opgaver, at det passer med man kan nå dem på den tid sprintet varer. Når man udvælger opgaver fra Product Backloggen skal man altid tage de opgaver som har højest prioritering, hvis det er muligt. Sprint Backloggen er også kilden til det Burndown chart, man har for hvert sprint Sprint Et Sprint er en periode der ofte varer 1 til 2 ugers, hvilket man på forhånd definere i projektet. I et Sprint udvikler man de funktioner som man har defineret i Sprint Backloggen. Efter et Sprint laver man et review af det udviklede kode og finder ud af hvorvidt det er klar til at indgå i f.eks. en release. Side 8 af 45

10 2.4.4 Tidsestimering Tidsestimeringen foregik uden DA s tilstedeværelse. Vi kom hver især med vores bud på estimering af hver enkelte opgave, og diskuterede herefter hvorfor vi havde estimeret den enkelte opgave som vi havde. Herefter re-estimerede vi alle på opgaven, indtil vi var enige om et bud på, hvor lang tid opgaven burde tage. Tidsestimeringen har også haft indvirkning på prioriteringen af opgaverne. Forestiller man sig en opgave på 50 timer have en værdi på '4', og en opgave på 10 timer have en værdi på '2', kan 10 timers opgaven godt vurderes højere, da kunden får mere værdi i timen på denne måde, på trods af opgavens lave værdi. Vi anslog derefter en samlet udviklingshastighed for holdet. Denne udviklingshastighed blev anslået til 60 timer per uge. I denne udviklingshastighed er der taget hensyn til at der er meget ny teknologi som vi skal lære at anvende, at vi bruger pair programming og endeligt at vi samtidig med at vi udvikler på produktet ogå skriver rapport. Det faktiske timeforbrug om ugen er derfor langt over de 60 timer. Ud fra denne udviklingshastighed og vores estimater af opgaver kan vi se at vi på de 8 uger vi udvikler på systemet ifølge den oprindelige product backlog skal nå at lave serveren, klienten og android widget en. Vi har tidsestimeret op til 250+ timer. Herudover har vi haft nogle tidsestimater vi har ikke kunnet fastsætte, der skulle spikes 2. Vi har haft omkring timer til rådighed, efter at have trukket rapportskrivning, research, jul og nytår fra. Tidsestimaterne har været realistiske, men vi har stødt ind i problemer med de nye teknologier, herunder WCF, Android og REST. Hvilket har været key-components i vores projekt. På disse punkter har vores estimater ikke været præcise, da vi har undervurderet hvor lang tid det ville tage at sætte sig ind i disse nye teknologier Burn down chart Burndown Chartet's funktion er, at vise om teamet er foran eller bagud i forhold til forventningerne. Netop dette så vi som en stor fordel, og var noget der talte meget for at vælge Scrum. Efter at have tidsestimeret på alle elementer i projektet, kan vi se hvor meget tid der er nødvendig for at lave de enkelte opgaver. Derfor vil vi meget hurtigt kunne se hvor meget vi kan nå af de opgaver vi har til rådighed. Efter det første sprint, vil det være muligt at se, om vi kan holde den hastighed som vi har beregnet, og ud fra dette vurdere 2 Se afsnittet om Spikes Side 9 af 45

11 hvor stor en del af ogaverne der er realistiske. Des flere sprints vi kommer igennem, jo mere præcis vil vores billede af projektet som helhed være. Sprint 1 Sprint Actual Expected Sprint 1 varede fra mandag d. 22. november til fredag d. 3. december. Som det kan ses på figuren ovenover, har sprintet dog kun varet 9 dage, istedet for 10. Grunden til dette var, at vi om mandagen afholdte møde med DA, og efterfølgende brugte resten af dagen på at bearbejde dokumentere og bearbejde den viden vi havde opnået gennem mødet. Vi kom altså ikke igang med nogle af opgaverne på product backloggen den dag. Sammenlagt på de 9 dage havde vi beregnet ud fra vores tidsestimater at skulle nå at lave opgaver svarende til 96 timer. Vi nåede dog ikke helt så mange som først antaget. Vi kom nogenlunde igang, men vi havde undervurderet hvor længe det ville tage at sætte os ind i de nye teknologier. Henholdsvis WCF, REST, og Android. Slutteligt endte det med vi kun fik brændt 76 timer, som det vises af den første graf. I løbet af det første sprint arbejdede vi med en række User Stories. Nedenfor har vi lavet en tabel som viser et uddrag af de stories, vi har arbejdet med. Disse tabeller vil fremgå som en del af beskrivelsen af hvert sprint for at dokumentere den rækkefølge som vi har grebet opgaverne an i. Side 10 af 45

12 Vi gennemgik bl.a. følgende stories: Backlog item Som en.. Vil jeg Sådan at Estimate Køre en eller anden form for Session Kunne se elevdatabase Kunne søge på elever Alle Bruger Bruger Køre en eller anden form for Session Kunne se elevinformationer Kunne søge på en specifik elev For at holde styr på proces og smide brugere af Det er muligt at se en elevs køre/teori planer og hvor langt en person er i forløbet Log-Ind Bruger Kunne logge ind Så systemet ved hvem WCF (SPIKE) System Kunne benytte WCF services jeg er Så alt kommunikation mellem server og klient kan krypteres (1-10) 10?? ?? Tidsestimering i timer Side 11 af 45

13 Sprint 2 Sprint Actual Expected Sprint to varede fra mandag d. 6. december til fredag d. 17. december. Efter de første to uger havde vi fået bedre styr på de nye teknologier, og det gik også bedre med at holde sprintet denne gang. Selvom vi dog var 10 timer i underskud til slut. På plus siden var vi dog kommet godt igang med WCF, og ligeledes godt igang med at lave CRUD metoder til administrationsdelen af systemet. Vi gennemgik bl.a. følgende stories: Backlog item Som en.. Vil jeg Sådan at Estimate (1-10) Tidsestimering i timer Kunne se kørelærer informationer Bruger Kunne se informationer om en kørelærer Man f.eks. kan komme i kontakt med personen 2 5 Kunne kørelærers kalender Bruger Kunne se kalenderen Jeg ved hvornår lærer er ude og køre 4 8 Kunne se en elevs kalender Bruger Kunne se en elevs kalender Det er muligt at se om en elev har nogle planer 4 8 Side 12 af 45

14 Sprint 3 Sprint Expected Actual Dette sprint varede fra mandag d. 20. december til fredag d. 31. december. På figuren er der byttet om på de to grafer da det ikke ville være muligt at se det forventede antal timer i forhold til det egentlig antal timer. Fordi denne periode gik henover Jul og Nytår, havde vi ikke meget høje forventninger til perioden. Hvor vi havde forventet 48 timer nåede vi denne uge 60 timer. Det var meget mere end hvad vi havde vurderet i første omgang. Det hænger dog sammen med, at vi i de tidligere sprints fik mere styr på teknologierne, men dog mest at vi i denne periode fik brugt mere tid på projektet end først antaget. Vi gennemgik bl.a. følgende stories: Backlog item Som en.. Vil jeg Sådan at Estimate (1-10) Tidsestimering i timer Kunne lave timeregistreringer Bruger Kunne lave timeregistreringer En time kan registreres for både en elev og en lærer der har haft eleven 5 10 Kunne udtrække timeregistreringer for en elev Bruger Kunne udtrække timeregistreringer for en elev Kunne se hvor mange timer der skal faktureres 7 12 Side 13 af 45

15 Sprint 4 Sprint Expected Actual Det afsluttende sprint varede fra mandag d. 3. januar til fredag d. 7. januar. Vi valgte med vilje ikke at tage den sidste uge med som en arbejdsuge i forhold til systemet, da vi af erfaring vidste at vi med stor sandsynlighed ville skrive rapport den sidste uge. Vi gennemgik bl.a. følgende stories: Backlog item Som en.. Vil jeg Sådan at Estimate (1-10) Tidsestimering i timer Kunne lave en timeregistering (Android) Bruger Kunne lave en timeregistering (Android) En time kan registreres for både en elev og en lærer der har haft eleven 5 20 Kunne se egen kalender (Android) Bruger Kunne se egen kalender (Android) En lærer kan få overblik over sin kalender 3 10 Kunne oprette en aftale på kalender (Android) Bruger Kunne oprette en aftale på kalender (Android) Kunne opdatere og tilføje en ny aftale sin kalender 5 20 Side 14 af 45

16 2.4.6 Roller Scrum er en process skabelon der indeholder en række praktikker og foruddefinerede roller. Disse roller er: Scrum Master o Scrum Masterens arbejde går ud på at beskytte Teamet og opretholde Scrums regler. Product Owner o Product Owneren repræsentere interessenter og forretningen. Team Member o Team Members udfører det egentlige arbejde, herunder analyse, design, implementation og test. Vi har ikke udvalgt nogen egentlig Scrum Master eftersom vi alle er indforstået Scrums regler og praktikker. Samtidig poserer Driving Academy ikke en trussel for vores arbejdsgang, da de ikke foreslår nogen former for ændringer andet end på aftale møder. Rollen Product Owner besiddes af Margareth fra Driving Academy. Margareth står pt. for den manuelle bearbejdning af den information systemet skal stå for at håndtere. Derfor er det også hende der har mest styr på hvilke funktioner systemet bør indeholde, og ved hvordan systemet bedst kommer til at tjene Driving Academy, da det er hende der kommer til at arbejde med administrationsdelen. Gruppen får rollerne som Team Members, da det naturligvis er os der står for udviklingen af systemet Daglige Scrums Daglige Scrum møder er til for at sørge for at arbejdsgangen går så smertefrit som muligt. Dette gøres ved at Scrum Masteren giver alle team members 3 spørgsmål. Disse er: Hvad har du lavet siden igår? Hvad Skal du lave idag? Er der noget der forhindre dig i at opnå målene for idag? Det er her Scrum Masterens opgave at løse eventuelle problemer. Rent praktisk har vi ikke haft en decideret Scrum Master da det ikke har været hensigtsmæssigt. Vi har dog hver morgen haft en kort diskussion om hvad vi hver især havde nået, og hvad vi gerne ville nå den pågældende dag. Ydermere har vi diskuteret eventuelle problemer med vores mål, og sammen hjulpet hinanden videre hvis der skulle være nogen Scrum Review Meeting Formålet med et Scrum Review Meeting er at gennemgå det arbejde der er færdiggjort, og det der ikke er. I vores tilfælde vil det bedste eksempel være mødet Her viste vi DA GUI en og fik feedback på deres meninger og hvad de synes skulle laves om. Som dokumenteret i referatet fra det omtalte møde, havde DA visse ønsker om ændringer, som vi sidenhen har været i stand til at imødekomme. Side 15 af 45

17 2.4.9 Accept-test En accepttest består af et møde med kunden, hvor man viser kunden programmet. Det er vigtigt at pointere at programmet ikke behøver at være færdigt. Det behøver heller ikke at være hele programmet man viser. Faktisk er det meget sjældent at man kommer med et færdigt program. Kunden får derpå lov til selv at gå programmet igennem. Imens kunden gør det fortæller denne hele tiden om, hvad han tænker om de forskellige ting, for eksempel: systemets's brugervenlighed, GUI, om der mangler nogle ting og så videre. Dette kaldes også for en tænkehøjt-test. Målet med alt dette er at få feedback fra kunden, så man kan se om programmet lever op til kundens krav eller forventninger, eller om der skal tilføjes/ændres i programmet. Man kan let have glemt nogle funktionaliteter, den gang man sammen med kunden planlagde, hvordan programmet skulle se ud, eller kunden kan have kommet i tanke om nogle funktioner, som han synes mangler. Derfor er det vigtigt at have accept-tests under hele forløbet. Også for at se om man er på bølgelængde med kunden, nogle gange kan det være at kunden har et andet indtryk af, hvordan programmet skal opføre sig og se ud, og så må man sammen finde frem til en ny løsning. Det er også derfor at det er meget sjældent at man laver accept-test på et færdigt program, hvis kunden ændre en ting han ikke er tilfreds med, og gerne vil have lavet om, kan man risikere, mere eller mindre, at skulle lave hele programmet om fra bunden Vores brug af accept-test Vi har kørt accept test på klienten af to omgange. Første gang for at se, om vi var på rette spor. Ved den første accept-test viste vi en prototype af klienten samt mockups af Android applikationen, hvor både Margareth og Morten fra DA var til stede samtidig. Vi valgte at begge burde være til stede under den første accept-test. Fordi de begge var til stede kunne de sammen diskutere og blive enige om, hvad de synes om prototypen. Hvis der var forskel på preferencer var idéen, at de sammen kunne komme frem til, hvad de synes ville være bedst for deres virksomhed. Tilfældet var dog, at de begge var meget enige om, at prototypen var lige hvad de havde tænkt sig. De havde få ønsker om ændringer, men det var småting som en attribut mere på en elev, en menu der burde hedde Hold istedet for Klasser og kunne se om der er kørt løn for timer. Det var alle mindre ændringer, som var forholdsvis lette at implementere. Side 16 af 45

18 I anden omgang valgte vi at lade dem gennemgå systemet en af gangen. Vi gav dem nogle opgaver, som de skulle løse i systemet. Det så fx sådan ud: Opret en ny elev (Kørelære)Lars skal have et nyt Hold på Tirsdag. Opret klassen for Lars og tilføj den nye elev Denne gang lod vi dem gennemgå og udføre opgaver alene, for at se om systemet var intuitivt nok og let at finde ud af. Både Margareth og Morten kunne gennemføre alle opgaverne uden problemer. Det eneste problem der var, var at de enkelte gange brugte lidt lang tid på at finde bestemte funktioner. De fandt dem dog selv, uden brug for hjælp, og inden for rimelig tid (<1 min.). Alt i alt var accept-testen for klienten en success. Grunden til det, har været at DA har været meget gode til at formulere deres forventninger og ønsker til systemet, og at vores første prototype afspejlede deres billede af det nye system. Ligesom med klienten, har vi udført accept-test af android widget en af to omgange. Første gang for at se om vores prototype afspejlede deres forventninger. Da vi udviklede widget en lidt efter administrationssystemet, var den lettere at designe fordi vi allerede havde udviklet store dele af administrationsdelen, og widget en skulle kun indeholde en brøkdel af dennes funktioner, da man i denne ikke skulle have mulighed for at administrere elever eller lign. Dette resulterede også i, at DA var meget tilfredse, og ikke havde nogle ønsker om ændringer andet end spørgsmål til udseende. Vi forklarede at designet ville komme til at se anderledes og gerne pænere ud, når vi kom længere med den, fordi den på daværende tidspunkt kun var en prototype, der viste hvordan funktioner ville være delt op. Det fik vi vist dem ved anden accept-test. Her gennemgik Margareth og Morten applikationen en af gangen. Både fordi vi kun havde en telefon at vise det på, men det havde været tilfældet alligevel, da vi også gerne her ville teste, om det vi havde lavet var intuitivt og let nok at finde ud af. På samme måde som med klienten fik de en række opgaver, vi bad dem udfører. Den ene lød som følger, og var meget specifik for widget en, og havde også til formål at vise hvorfor en widget til mobilen var smart fremfor en almindelig hjemmeside med samme funktionalitet: Find Lars Peter Jørgensen, og kald ham op Der var et enkelt problem i, at det ikke var tydeligt man kunne scrolle ned af i applikationen. Derudover var de tilfredse med resultatet. Side 17 af 45

19 User Stories Vi har valgt at benytte os af User stories, sammen med et prioriteringsskema. Prioriteringsskemaet indeholder vores product backlog. På denne måde får vi et overblik over hvilke items på product backloggen der har højest prioritet, på en hurtig og let måde, og herefter kan vi gå til den enkelte userstory for uddybning, når det enkelte punkt skal implementeres. Tager vi eksempelvis nogle af kravene til android widget en, har vi haft følgende User stories, til at guide det arbejde der skulle udføres: Backlog Item Som en.. Vil jeg.. Sådan at.. Prioritet Estimering i timer Kunne opdatere kalender Bruger 4 12 Kunne se elevers kalender Kunne oprette aftaler på kalender Bruger Bruger Have mulighed for at opdatere min kalender Kunne se en specifik elevs kalender Have mulighed for at oprette nye aftaler/tider for en elev Jeg har mulighed for at tilpasse hvis der sker ændringer. Jeg kan se hvor mange timer en elev har og hvordan de er fordelt Systemet opdater og tilføjer den nye aftale til kalenderen Task Board Et task board er et board (i vores tilfælde en væg i vores grupperum), hvorpå vi har taget alle vores stories fra vores product backlog og printet ud. Derefter er der blevet lavet tre muligheder: To Be Done: herunder har vi de stories vi endnu ikke er startet på In Progress: disse stories er dem vi går i gang med under et sprint. Ved hvert sprints begyndelse ser vi hvor meget tid vi får at udvikle i, hvorefter vi kan vælge det antal stories der passer til det tidsrum. Done: Når et sprint er slut skulle det gerne resultere i at de stories der blev valgt nu er flyttet over under done og dermed er færdige. Side 18 af 45

20 Ovenstående billede er taget lige i starten af projektperioden, lige efter vi har haft andet møde med driving academy og efterfølgende fået lavet vores product backlog. Billedet ovenfor er taget under sprint 3. Som det også fremgår af billedet er der allerede en del stories der er lavet færdige og derfor er flyttet under done. Derudover er vi her gået igang med en del andre stories som står under progress. Vi har brugt taskboardet til både, at skabe et overordnet billede af hvor langt vi er i projektet, men også for at se hvor langt vi er med det enkelte sprint. Ved at have alle vores stories på væggen, har det været nemt lige at holde et hurtigt gruppe møde hvor hver især fortæller hvilke stories man er igang med og hvilke man planlægger at lave bagefter. Side 19 af 45