Göm menyn

TDP005 Projekt: Objektorienterat system

Statusrapporter

Veckovis statusrapport

Som kan ses i schemat ska alla grupper skicka in en statusrapport till sin handledare varje måndag från och med att kravspecifikationen färdigställts. Statusrapporten är en produkt av ett kortare möte inom gruppen där projektets status och framtid diskuteras. Statusrapporten ska vara 5-10 meningar (utöver backlog) och innehålla följande:

  • En kort beskrivning av vilka krav som arbetats med under veckan, och status på dessa krav. Återkoppla mot förra veckans planering.
  • Översiktlig planering av vilka krav ni kommer att arbeta med under veckan, samt vad ni har för mål under veckan. Detta innebär i princip att ni säger "vi tänker hinna klart med de X första kraven i vår backlog".
  • Er uppdaterade backlog.

Statusrapporten skickas in via e-post från er studentmail till handledaren med rubrik "TDP005: Statusrapport N" (byt ut N mot rapportens nummer). Bifoga också den uppdaterade kravspecifikationen.

Backlog

En backlog är ett verktyg för att underlätta planering som ofta används inom Scrum. I det här projektet kommer vi använda en minimalistisk variant för att ni ska kunna få några av fördelarna med en backlog utan att behöva lägga särskilt mycket tid på den.

En backlog är i princip en prioriterad lista över de krav som ska färdigställas under projektet. Listan ska vara sorterad efter prioriteten, vilket innebär att det som ni tycker är viktigast att göra ska vara högst upp på listan. Fördelen med detta är att man enkelt kan se vad som ska göras härnäst. När man inte har något att göra kan man helt enkelt titta på sin backlog, välja det översta kravet på listan och arbeta med det.

I och med att listan över krav är sorterad efter prioritet är det också enkelt att använda den för översiktlig planering i projektet. Man kan helt enkelt dela upp listan i ett antal delar. Varje del motsvarar då vad man tänker sig hinna med under en viss tid i projektet (i det här fallet: en vecka). När man gjort detta kan man enkelt se två saker: dels att man hinner med allt inom ramen för projektet och dels kan man se när man ligger efter sin planering. Märker man att planeringen man gjort inte fungerar kan man då enkelt planera om genom att flytta element mellan de olika delarna i backloggen.

Exempel

  • Vi planerade att implementera krav 2.3 och 2.8 förra veckan. Vi blev klara med krav 2.3, men vi blev inte helt klara med 2.8.
  • Under den här veckan ska vi i första hand bli klara med krav 2.8. Vi räknar med att vi lyckas bli klara med det senast på tisdag. Efter det ska jag arbeta med krav 2.4, och min labpartner ska arbeta med 2.5. Vi hoppas bli klara till på torsdag med det, så att vi kan implementera krav 3.1 under fredagen.
  • Backlog (varje horisontell linje motsvarar en vecka):

    Varje rad motsvarar ett krav. Först kommer kravets nummer, följt av en kort "titel" på kravet. Egentligen skulle man kunna strunta i titeln, eftersom kraven står i sin helhet i kravspecifikationen. Däremot blir det mycket enklare att läsa backloggen om man har en kort text som gör det enklare att komma ihåg vad exempelvis krav 2.8 innebar.

          - 2.8: Spelaren ska kunna styra sin karaktär på skärmen med hjälp av piltangenterna.
          - 2.4: Rita upp fiender på skärmen.
          - 2.5: Rita upp hinder på skärmen.
          - 3.1: Fiender ska röra sig i förbestämda mönster.
          ----------
          - 2.9: Fiender ska skjuta projektiler åt slumpmässiga håll.
          - 3.8: Fiender ska sikta på spelarens karaktär när de skjuter.
          - 4.1: Fienderna ska röra sig mot spelarens karaktär när de är tillräckligt nära.
          - 5.2: Lägg till en powerupp som ger spelaren mer hälsa.
          ----------
          - 4.8: Implementera en typ av fiende med mer hälsa än de ordinarie.
          ....
        

Sidansvarig: Filip Strömbäck
Senast uppdaterad: 2017-10-13