Utviklingsmetode

Fordeler ved SCRUM

• En smidig arbeidsmodell er bra, fordi studentene har lite erfaring med store prosjekter. Det at arbeidsmodellen er smidig og at man deltar i daily scrum og sprint retroperspective skaper en kontinuerlig forbedring i hvordan gruppen jobber sammen.
• Kommunikasjon i laget blir forbedret ved å bruke Scrum. At alle kan se hverandres arbeid og har mulighet til å ta del i hvilke inkrementer som skal gjøres, øker motivasjonen i laget. Prosjektet skal utføres av studenter og er derfor viktig at alle studentene kan bidra med visjoner for oppgaven på sikt, og hva slags inkrementer som skal gjøres og når disse skal gjøres, ved at alle deltar på sprint planning, daily scrum og sprint retroperspektiv.
• Gradvis gjennomførte inkrementer er en fordel for akkurat dette prosjektet. Dette er gruppens første store prosjekt og har ikke jobbet så mye i lag enda. Derfor er det viktig å se resultater for å få en sterkere følelse av hva slags type inkrementer som tar lengre tid.
• Kollektivt eierskap skaper tillit innad i laget gjennom at hele laget. I tillegg til at kollektivt eierskap fører til at ferdigheter ikke blir holdt tilbake, men på områdene hvor studentene ikke har like mye kunnskap, kan flere se over arbeidet eller ta for seg og forandre på andre sitt arbeid.

Ulemper ved SCRUM¨

• Størrelsen på gruppen er på 4 studenter. Dette er ikke optimalt for Scrum arbeidsmodell. Prosjektet er mer sårbart ved færre medlemmer og det er mindre arbeidskraft til å fullføre inkrementene. Da Det også så å si mister muligheten til å par-programmere.
• Ingen ekstern eier av prosjektet fører til at en av gruppas studenter må oppføre seg som produkt eier og at scrum Master også må være dev.
• Mye tidsfordriv kan oppstå om laget ikke er vant til å jobbe konkret og effektivt på daily scrum eller sprint planlegging.

SCRUM oppsett

Produkteier Produktet blir laget som en bachelor oppgave og har ingen eier av produktet, men en av utviklerne; Gabriel vil delvis operere som et produkt eier på møtene som sprint planlegging og defineringen av produkt backloggen. Gabriel er blitt valgt til å også utføre oppgaven som produkteier, fordi han brenner mest for å lage et mindre spill avhengende applikasjon og ønsker mer penger til veldedighet. Arbeidsmengden hans som en utvikler vil være delvis lavere slik at han kan fokusere på gjennom hele perioden hva slags applikasjon de ønsker å lage.

Scrum master Scrum master skal ha overordnende ansvar for at gruppen er på tid, og at arbeidsmengden fra sprint til sprint er realistisk for at utviklerne ikke blir utslitt og på samme tid rekker å fullføre prosjektet innen tidsfristen som er satt. Scrum master; Oskar kommer til å fungere som en utvikler samtidig, men til en viss grad mindre arbeidsmengder slik at han ikke mister fokus på arbeidsoppgavene til scrum master. Oskar er valgt, fordi han har tidligere hatt ledende roller og har en karismatisk personlighet.

Sprint planlegging

Vi har valgt at sprintene våre skal vare 2 uker av gangen. Vi har valgt 2 uker, fordi at siden vi har lite erfaring med store prosjekter og denne typen utviklings metode ønsker vi å ha korte sprinter. Om vi feilberegner arbeidsmengden til sprinten eller har dårlig samarbeid i laget ønsker vi at sprintene skal være kortere slik at vi kjappere kan hente oss inn igjen med en ny sprint. Grunnen til at vi ikke har enda kortere sprinter handler også om at vi ønsker å ha tid nok til å kunne grundig utføre inkrementene på slik at de blir utført på måten vi ønsker. I tillegg er 2 uker en gunstig lengde slik at teamet rekker å kunne diskutere nøye i sprint planning hvilke inkrementer som faktisk betyr mye for utvikling av en vm tipping applikasjon.

Den daglige Scrummen skal vare mellom 15-20 minutter og være godt ledet av scrum master slik samtalen ikke faller av sporet. Alle skal snakke om hva man har jobbet med, hva man skal jobbe med, og diverse problemer vedkommende har møtt på. Til slutt skal også alle snakke kort hvis de har noe på hjertet om erfaringer og tips knyttet til det å jobbe smidig og tett med hverandre. Det siste punktet handler om at gruppa skal bli bedre kjent, kunne stole på hverandre, og at gruppen skal forbedre arbeidsproduktiviteten i laget.

Sprint review skal være produktiv og saklig, men foregår på et menneskelig nivå. Det vil si disse møtene kan innledes med småprat med kjeks eller frukt, men ha en tydelig grense på når møte starter og når møte er ferdig. I møte skal man første gå igjennom inkrementene man ikke har fått gjort og eventuelle grunner til dette. Ellers skal møte bestå av en fremvisning av prosjektet. Hvis det er mulig skal man ha en person som interesserer seg for prosjektet til å være på noe av møte til å kunne teste appen i sanntid. Og vedkommende kan gi tilbakemelding på hva som er appellerende og hva som ikke fungerer. Dette kan være at for eksempel «det er ikke gøy å vedde på antall mål i en kamp». Vi ønsker i starten å ha hyppigere sprint Retrospective en hva som kan ansees som normalt. Vi skal ha sprint retrospective etter hver sprint de første 4 sprintene. Deretter hver andre sprint om vi synes det er mer passende. På denne måten kan vi på en skikkelig måte dele opplevelser og kunnskaper til teamet og ta de i betraktning for jobbingen og til sprint plannin