02.11.21

Redaksjonsmøte (Torsdag 8. februar)

Dato: 11.02.21

Tid: 12:00-14:15

Sted: Discord

Fremmøtte: Vegard Haugland, Jonas Valen, Inge Halvorsen, Daniel Liland

Formål

• Å levere en komplett og utarbeidet obligatorisk oppgave innen fristen 12.02.2021 klokken 16:00.
• I dette dokumentet følger krav og retteskjema.

Deloppgave 1: Organiser teamet

Gruppen trenger et gruppenavn, som også blir navnet på github-repositoriet deres. Kartlegg hvilken kompetanse de ulike medlemmene av teamet har, og ta med en kort oppsummering i innleveringen. Dere skal så fordele roller dere bestemmer dere for (kan feks være teamlead, kundekontakt osv). Skriv en kort begrunnelse for hvilke roller dere bestemmer dere for og hvorfor. Sett opp et project board. En mulighet er å bruke GitHub project board eller trello. Dette må settes opp, og det er viktig at alle i gruppen vet hvordan de bruker verktøyene dere velger.

Kommentar

** Teamet har fått navnet Unsinkable-II.**

De ulike medlemmene har lastet opp sin kompetanse til readme i GitHub.

Temet har fordelt seg i følgende roller

CCO – Inge Halvorsen

Som CCO skal Halvorsen ha hovedansvar for møter, referat og møteinnkallelser. Vi har valgt å bruke denne rolle for å sikre at alle møter har referat, at gruppen til en hver tid er oppdatert på de møter som kommer, og sporbarhet.

CIO – Daniel Liland

Som CIO har Liland ansvar for prosess og planlegging av prosjektet. Vi har valgt å ha en ansvarlig for prosessplanlegging fordi det er nødvendig at en person er ansvarlig for at vi har en felles oppdatert oversikt over prosjektet, og følger planen vi har laget i plenum.

CTO – Jonas Valen

Som CTO har Valen ansvar for at programmet blir utviklet etter de planer og prosesser som allerede er avklart i gruppen. Vi har valgt å ha en ansvarlig for programutvikling fordi kodestandard og syntaks skal følge den strukturen vi har blitt enige om i plenum.

Gamemaster – Vegard Haugland

Som Gamemaster har Haugland ansvar for at spillet følger de spilleregler som er satt for spillet. Vi har valgt å ha en ansvarlig for spillereglene fordi spill logikk er vanskelig å ha oversikt over.

Redaksjon – Samlet gruppe

Før hver innlevering må gruppen samles for å ferdigstille obligatoriske oppgaver. Til dette har gruppen satt ned en redaksjon bestående av samtlige gruppemedlemmer. Redaksjonen møtes før hver innlevering. Vi har valgt å sette ned dette ansvarsområdet fordi det er viktig at alle i gruppen har eierskap til det produktet som blir levert til karaktersetting.

Ansvarlig for GitHub – Daniel Liland

Som ansvarlig for GitHub har Liland laget en prosedyre for nedlasting og opplasting av filer mot Git. Vi har valgt å bruke denne rollen fordi det kan være vanskelig å sammenfatte opplastinger til Git på en god måte om alle i gruppen velger å gjøre det alene. Projectboard er ferdigstilt på GitHub.

Deloppgave 2: Velg og tilpass en prosess for laget

Dere må finne ut om dere vil følge en bestemt prosjektmetodikk (XP, Scrum, Kanban, parprogrammering, testing osv), evt hvilke elementer fra ulike prosjektmetodikker dere vil ha med. Diskuter i teamet hvilke metoder som hjelper teamet med å utvikle fungerende og veldokumentert programvare under prosjektet. Diskuter også hvilke tilpasninger som trengs for å fungere godt i et slikt studentprosjekt. Involver gjerne TA i diskusjonen om mulige problemer. Vurder viktige aspekter ved prosessen, for eksempel hvordan organisere møter, definisjon og tildeling av oppgaver, oppfølging av arbeid, hvilke programvare utviklingsaktiviteter som trengs (og når), hvilke prosjekterings aktiviteter som trengs (og når). Skriv en kort beskrivelse av prosessen i prosess- og prosjektplanen. Diskuter i teamet hvordan dere skal organisere dere under prosjektet.

Noen viktige elementer

Møter og hyppighet av dem

Kommunikasjon mellom møter

Arbeidsfordeling

Oppfølging av arbeid

Deling og oppbevaring av felles dokumenter, diagram og kodebase

Skriv en kort beskrivelse av hvordan teamet ditt planlegger å organisere prosjektet den første tiden.

Metodikk

En tilnærming av SCRUM, men med en flytende overgang mot KANBAN. SCRUM virker som en logisk metodikk da man kan legge sprinter opp mot obligatoriske innleveringer. Gruppen dokumenterer hvilken deler av SCRUM som blir brukt, og ikke brukt.

Hva vi ønsker å ta med fra SCRUM sin modell

Sprint: Det å ha sprint inn mot obliger virker som en logisk modell å følge fremover.

Parprogrammering: Ingen av oss er kjent med parprogrammering, så vi ønsker å lære mer om dette konseptet i praksis.

Struktur: Strukturen som SCRUM tilbyr virker veldig appellerende for gruppen.

Hva vi ønsker å se bort fra utifra SCRUM sin modell

Rollemodell: Vi følger ikke rollemodellen, og har designet vår egen. Dette er grunnet i at vi har såpass få medlemmer i teamet, og at vi liker å ha presist definerte roller. Prosess og prosjektplan må opprettes, ta kontakt med Vegard og Daniel.

Forklaring

Unsinkable-II møtes på ukentlig basis, med minst ett (1) møte i uken ved gruppetime mandag. Det er satt opp mulighet, og blir anbefalt med to (2) møter i uken, da især møte før en obligatorisk innlevering. Det er fullt mulig å ha møter utenfor denne rammen. Alt arbeid som blir gjort for Unsinkable-II skal gjøres mens man er tilstedeværende på egnet kanal på Discord. Det er lagt opp til en lav terskel for å spørre om hjelp og støtte. Unsinkable-II er et studentprosjekt, og har som formål at alle skal kunne lære, og utvikle seg gjennom prosessen. Mellom møtene kommuniserer Unsinkable-II over Discord.

Gruppen har en flat struktur, der alle gruppemedlemmer er oppfordret til å delta aktivt i hverandres ansvarsområder. Der likevel veldefinerte ansvarsområder, noe som fører til at gruppen kan konsentrere seg om enkeltstående oppgaver, uten å være redd for dobbeltarbeid.

All kode går gjennom review. Gruppemøter er organiserte og det er åpent for diskusjon rundt løsninger. Gruppemøtene har vært preget av en god tone, der konstruktiv kritikk og et ønske om å strømlinjeformet arbeidshverdag har vært gjennomgående.

Det er lagt opp til at gruppen samler felles dokumenter i en GoogleDrive, samt laster opp dokumentasjon til GitHub av hensyn til innleveringer og retting.

Det er ønsket utforske en tilnærming til TDD. Gruppen er lite kjent med denne arbeidsprosessen, men stiller seg positivt til å utforske mulighetene denne formen for utvikling kan bringe.

Deloppgave 3: Få oversikt over forventet produkt

Dere skal lage en digital versjon av roborally. Denne versjonen skal inkludere de fleste av RoboRallys funksjoner som prosesskort, mekanismer på spillebrettet og mulighet for å spille flere sammen. Dere skal lage en spesifikasjon som inneholder: En kort beskrivelse av det overordnede målet for applikasjonen En liste over brukerhistorier til systemet basert på MVP-kravene. For hver brukerhistorie, skal dere ha akseptansekriterier og arbeidsoppgaver, samt beskrivelse av hvilke krav brukerhistorien oppfyller (dette lager dere kun for historier dere er ferdige med, holder på med, eller skal til å begynne med) En prioritert liste over hvilke brukerhistorier dere vil ha med i første iterasjon (altså frem til levering av denne oppgaven, se deloppgave 4 for forslag). (Frivillig) Krav til MVP er gitt i neste deloppgave. Dersom dere ønsker å utvide denne listen med ytterligere funksjonalitet, skal det også med som en del av denne spesifikasjonen.

Kommentar

Hva er det overordnede målet for applikasjonen?

• Applikasjonen skal være et spillbart spill. Med dette menes at spillet skal følge fastsatte regler.
• Det må være mulig å vinne, og tape spillet. Det skal videre være mulig å kjøre spillet på OSX, Windows, og Linux.
• Det er også satt krav om støtte for flere spillere samtidig.
• Liste over brukerhistorier (3-4?)

Vegger

• Som laser ønsker jeg å stoppe når jeg møter en vegg for å oppfylle spill logikk.
• Som spiller ønsker jeg at roboten skal bli stoppet av en vegg, nå roboten beveger seg mot den, for å oppfylle spill logikk.
• Som spiller ønsker jeg å kunne se veggene på brettet, slik at jeg kan planlegge fremtidige runder i spillet.
• Som spiller ønsker jeg å kunne se hvor veggene er, slik at jeg kan styre roboten mot flagg.
• Som spiller ønsker jeg å vite hvor veggene er, slik at jeg ikke blir stående fast.

Akseptansekriterier

• En vegg fungerer som en barriere.
• En vegg er en barriere. ingenting i spillet skal kunne gå gjennom en vegg.
• Det er mulig å se veggene på brettet, dette betyr at vegger har en annen farge enn spillbrettet, og at veggene ikke blir dekket over av andre spillelementer.

Arbeidsoppgaver

• GUI for brett
• Logisk modell for brett. Brettet er modellert i spillet.
• Grafikk for vegg, som ikoner o.l.
• Logisk modell for vegger, dimensjoner.
• Koblinger mellom vegg og brett.
• Tester som tester om vegg fungerer som planlagt.
• Om robot robot på (0,0) beveger seg i retning av vegg på (0,1) skal den ikke kunne nå (0,2).
• Om laser i (0,0) skyter i retning av vegg på (0,1) skal den ikke være tilstede på (0,2).

Brukerhistorier

1. Som en brikke, ønsker jeg å kunne bevege meg rundt på brettet, slik at jeg kan nå mine mål.
2. Som en brikke ønsker jeg å kunne gi beskjed dersom jeg avslutter min runde stående på et flagg
3. Som brikke ønsker jeg ikke å kunne forlate brettet
4. Som et hull, ønsker jeg å være tilgjengelig på brettet, slik at en brikke kan falle ned i meg.

Akseptansekriterier

• Brikke kan flytte seg Nord, Sør, Øst, Vest.
• Brikke kan gi en respons når den treffer et flagg
• Brikken kan ikke forlate brettet
• Når brikken treffer et hull forandrer den ikon
• Brett viser for bruker med brikke, flagg, og hull

Arbeidsoppgaver

Brukerhistorie 1:

• Sette opp GUI for å kunne vise brett ➡ Libgdx
• Bruke Libgdx sitt api
• Koble input taster til bevegelse

Brukerhistorie 2:

• Bruke Libgdx sin innebygde logikk til å sjekke tilstanden til brikken, og endre brikken henholdsvis

Deloppgave 4: Kode

Det vi har implementert så langt i henhold til oppgaven

1. Vise et spillebrett
2. Vise brikke på spillebrett
3. Flytte brikke (vha piltaster eller wasd)
4. Robot besøker flagg
5. Robot vinner ved å besøke flagg

I tillegg har vi lagt til funksjon for

• Robot kan falle ned i hull
• Robot kan ikke flytte seg utenfor kart

Testing

Disse testene er gjort manuelt, da frontend er veldig vanskelig å teste. Dette er gjort med innbygd funksjon i IDE og breakpoints. Vi tenker å bevege oss over i JUnit tester når vi kommer til forretningsregler senere i prosjektet.

• Det er testet at robot beveger seg ved bruk av piltaster.
• Det er testet at robot vinner når den treffer et flagg.
• Det er testet at robot dør når den treffer et hull.
• Det er testet at robot ikke kan bevege seg utenfor kart.
• Spillet kjører fra IDE i Windows, Mac, og Linux.

Inge Halvorsen
Sekretær