Grupparbete

Information

• Betygsskala: IG/G
• Deadline: fredagen 13 mars 2026 kl. 22.00
• Feedback: under schemalagda demos och löpande under kursens gång
• Mål från kursplanen Agilt projektarbete som examineras:
  • 4. genomföra agila aktiviteter som till exempel standup, retrospektiv- och sprintplaning
  • 5. använda agil metod
  • 6. tillämpa användning av verktyg som underlättar ett agilt arbetssätt
• Mål från kursplanen JavaScript som examineras:
  • 6. utveckla system med JavaScript baserat på en kravspecifikation
  • 8. tillämpa och organisera kod
  • 11. använda JavaScript
• Starta inlämningsuppgiften via GitHub Classroom-länken som finns på sidan Länkar. ‼️ OBS! Se info nedan.
• Inlämning:
  1. Commit:a och pusha koden till repot på GitHub. Verifiera att det du har på datorn även syns på GitHub.
  2. Klistra in länken till repot på itslearning i inlämningsboxen.

Viktiga saker om denna inlämningsuppgift

• Det här grupparbetet examineras i både kursen "Agilt projektarbete" (10 YHP) och "JavaScript" (40 YHP).

• Det går inte att bli godkänd på ett grupparbete utan en grupp (eller "komplettera" efteråt genom att göra ett eget arbete), så tänk på att delta aktivt i gruppen.

• Det kommer under tiden för grupparbetet att dyka upp ett antal "händelser" som kommer att påverka ert grupparbete. Detta för att simulera en verklighet där inte allt alltid exakt går som planerat.

• Säkerställ att alla i gruppen har genomfört samtliga Git fördjupningsövningar för ett smidigt samarbete. Gör dessa gärna tillsammans.

• Gruppkontraktet är ett måste. Detta kommer att göras på lektionen på tisdagen den 10 februari.

• I kursen ska ni veckovis hålla en informell demo. Det är en del av den agila processen, där man visar upp sitt arbete för s.k. "stakeholders" - personer som påverkas av "produkten" och som kan komma med input på den. Lektionerna är obligatoriska. Se det också som ett inspirationstillfälle.

Viktigt

På tisdagens intro-lektion kommer vi att genomföra en "mini-sprint" i grupperna:

• Bryta ner uppgiften i en initial backlog
• Göra en planning poker
• Vi kommer inte att göra någon demo, däremot kan de grupper som vill få dela med sig av sin backlog (bra att se vad andra tänkt!)
• Hålla ett retrospektiv i gruppen
• Ha vårt första "daily standup" inför onsdagen

Vi kommer också att göra klart gruppkontraktet i slutet på lektionen.

Uppgiftsbeskrivning - översikt

Uppgiften är att bygga ett digitalt "escape room". Ni får själva komma på tema, och hur det ska se ut/fungera. Ni måste inte skapa "3D-världar", utan det kan t.ex. vara att man får någon sorts "rebus" att lösa. Tänk inte Battlefield, tänk mer "Flexbox Froggy".

Det ska finnas lika många "rum"/problem att lösa som ni är gruppmedlemmar. Rummen ska tematiskt hänga ihop/spelflödet ska kännas naturligt.

Starta inlämningsuppgiften som grupp

En (1) person i gruppen startar inlämningsuppgiften, och skriver dit gruppnamnet som finns på itslearning/i dokumentet på Teams.

Resten av gruppen går sedan med i samma grupp.

Gör ditt bästa för att inte gå med i fel grupp. Råkar du ändå göra det så får du skriva till mig på Teams.

Lektionstid till grupparbetet

Vi går nu också in i en "nöta in kunskaper"-fas på denna kurs, så resterande lektioner kommer att vara "Våga fråga" (om sådana dyker upp, jag meddelar dagen innan kl. 14 om det finns något i frågelådan) och handledning. Ni kan alltså använda lektionstiden till ert grupparbete.

Kravspecifikation

• Så många rum/problem som ni är gruppmedlemmar.
• Sammanhängande "storytelling"/spelflöde och design. Samarbete & kommunikation.
• Ni ska ha med en timer som räknar upp tiden per rum.
• Ni ska ha med en timer som räknar ihop totaltiden.
• Varje rum ska ha minst en "artefakt" som man samlar på sig. Det kan vara ett objekt (en blomma, en väska…), en bokstav (tänk "hänga gubbe" eller "Ordel"), eller vad som helst… Dessa artefakter ska sedan bilda ett "slutpussel" som man måste lösa. Om spelaren har samlat på sig "fel" artefakt från ett rum, så går slutpusslet inte att lösa - men man ska ändå kunna försöka.
• Om man har samlat på sig fel artefakt så ska det specifika rummet gå att spela om, utan att man behöver spela om alla andra rum.
• Ni ska ha med en "progress bar" som visar hur många rum man har "knäckt"/tagit sig förbi.
• Det ska gå att spara "progress", dvs. om jag har löst rum 3/5 så ska jag inte behöva börja om med rum 1, om jag stängt ner webbläsaren. Dvs. ni behöver hålla reda på vilket rum som är aktuellt.
• Det ska finnas en highscore-lista med top 3 spelare.
• Man får poäng baserat på hur snabbt man löser ett rum. Exakt hur många poäng är upp till er. Poängräkningsstrategin ska vara samma i alla rum.
• Man ska kunna "logga in" med sitt namn (så att det sedan sparas i highscore).
• Det ska visas ett "Välkommen, namn!"-meddelande någonstans på sidan.
• Det ska finnas en "Om"-sida som beskriver spelet liksom teamet som gjort spelet. Ni kan t.ex. ha med länkar till era GitHub-profiler. (Syftet här är att ni ska ha ett case att visa upp). Ni kan t.ex. också ta med tekniker ni har använt och vad ni har lärt er. Tänk "LIA-pitch".
• Varje rum ska ha en beskrivning och ett namn. Denna information ska läsas in via JSON, och den ska visas upp innan man startar med respektive rum.
• Ni kan också med fördel lagra t.ex. "spelvariabler" i JSON-filen, exempelvis poängräkning eller liknande, om det behövs.
• Sidan ska vara på EN sida (index.html), så ni får jobba med att visa/dölja information. Här behöver ni också kommunicera kring hur ni gör det! Ska det "injectas" HTML, eller ska sektioner döljas med CSS? Eller en kombination av båda?
• Spelet ska vara tillgängligt och gå att navigera med tangentbordet.
• Det ska gå att "reset:a" spelet (dvs. radera alla ev. framsteg).
• Det ska gå att spela om spelet efter att man gjort klart det en gång.
• Det ska gå att rensa highscore-listan via något specialhack, t.ex. trycka på en dold/osynlig knapp eller dubbelklicka en gång på highscore-rubriken och sen skriva in ett "lösenord" i en alert. Fritt fram att vara kreativ. Dokumentera i er README dock hur man gör.
• Det ska finnas en game over-sidan, som visar lyckat resultat eller misslyckat resultat.

Planeringskrav

• Ni ska bryta ner projektet i en backlog.
• Ni ska göra projektet enligt den agila processen.
• Om ni använder GitHub Projects (rekommenderat pga. commit-kopplingen), Trello, Jira eller något annat verktyg är upp till gruppen.

Git-krav

• Varje person ska ha gjort minst 2 pull requests till main-branchen, och varje person ska ha "review:at" minst 2 pull requests under projektets gång. Dokumentera i er daily att ni gjort det.
• Försök att hålla er till en gemensam commit-standard, t.ex. med gitmojis eller "Conventional commits". Det måste inte vara perfekt, men det är bra att komma in i den vanan.
• Försök att hålla er till att koppla varje "feature"/bug/sak ni gör till en issue i GitHub Projects.

Tekniska krav

• Ni ska jobba i moduler (filer) så att er kod inte krockar.
• Ni ska använda TypeScript i projektet.
• Sidan ska vara publicerad på GitHub Pages.
• Ni ska ha en gemensam kodstandard (ESLint eller motsvarande).

Dokumentation

• Ni ska ha skrivit en README som beskriver ert projekt på "framsidan" av ert GitHub-repo.

Tips

• Testa ofta, spara inte "integrationen" av alla rum/delar till sista veckan.
• Är ni proffs testar ni varje vecka, inför demon, att hela flödet funkar. Tidskrävande ja, men testning är ofta en del av ett lyckat projekt 😃 Fördela ansvaret så att det inte landar på en person.

Bedömningsmall

• Sidan ska ha en enhetlig design där det är tydligt att gruppen kommunicerat och samarbetat kring projektet.
• Projektet ska kännas som en helhet, inte ett "individuellt arbete" där varje rum tydligt är en isolerad enhet.
• Gruppen ska ha visat att man tagit helhetsansvar för slutresultatet, och inte att varje person jobbat enskilt.

Pedagogiska kommentarer

• Händelserna är till för att simulera verkligheten; saker kan ändras under projektets gång.
• Dvs. stressa inte, och allt kommer inte att bli perfekt.
• Planeringen kommer inte att vara perfekt från början, och den kommer aldrig att bli perfekt. Gilla läget!
• Syftet är att varje person har chans att jobba på ett "pussel" med logiken, men att ni måste samarbeta kring spelflöde, design och känsla.
• Ta hjälp och hör av er med låg tröskel. Även om arbetet är "självständigt i gruppen" så betyder det inte att man måste klura ut alla funderingar själv.