GitLab - Från krav till implementation

TL;DR

  • Epics = användarkrav (varför)
  • Issues = systemkrav (vad)
  • Milestones = tid/iterationer (när)
  • Branch/MR = implementation (hur)
  • Sub-issues = detaljnedbrytning vid behov
  • Iteration cadence = 1 vecka (standardrytm för hur ofta milestones skapas och avslutas)

Detta dokument beskriver en rekommenderad arbetsmodell i GitLab som visar hur man går från övergripande användarkrav till konkret implementation i kod. Exemplet utgår från ett vanligt scenario: inloggning (login).

Målet är att skapa en tydlig spårbar kedja:

Användarkrav → Epics → Systemkrav (Issues) → Delkrav (Sub-issues) → Implementation (Branch + MR)

1. Övergripande nivå – Epic (Användarkrav)

Vad är en Epic?

En Epic representerar ett användarbehov eller ett övergripande mål. Den ska inte beskriva implementation, utan syftet med funktionaliteten.

Exempel (Login)

Epic: Användare ska kunna autentisera sig i systemet

Beskrivning:

Som användare vill jag kunna logga in i systemet för att få tillgång till skyddade resurser och personlig funktionalitet.

Typiska egenskaper:

  • Funktionellt mål
  • Teknikoberoende
  • Kan brytas ner i flera systemdelar

2. Mellannivå – Issues (Systemkrav)

Vad är ett issue?

Ett issue representerar ett konkret systemkrav eller funktion som behövs för att uppfylla en epic.

Exempel (kopplat till Login Epic)

Issue 1: Skapa autentiseringsendpoint

  • POST /login endpoint
  • Tar emot användarnamn och lösenord

Issue 2: Validera användaruppgifter

  • Kontrollera att input är korrekt
  • Hantera felmeddelanden

Issue 3: Generera JWT-token

  • Skapa token vid lyckad inloggning
  • Inkludera user-id och claims

Issue 4: Lösenordshantering

  • Hasha lösenord vid jämförelse
  • Säker lagring och verifiering

3. Nedbrytning – Sub-issues (detaljkrav)

Vad är en sub-issue?

En sub-issue är ett separat issue som är kopplat som barn till ett större issue. Den används när ett systemkrav är för stort eller komplext.

Exempel (för Issue: Generera JWT-token)

Sub-issue 3.1: Skapa tokenstruktur

  • Definiera payload (userId, exp, role)

Sub-issue 3.2: Implementera signering

  • Använd hemlig nyckel
  • Implementera signeringslogik

Sub-issue 3.3: Hantera token expiration

  • Sätt giltighetstid
  • Hantera utgångna tokens

4. Planering över tid – Milestones (Iterationer)

Vad är en Milestone?

En milestone används för att tidsbinda arbete och skapa iterationer (t.ex. sprintar). Den kopplar ihop planering och genomförande över tid.

Syfte:

  • Skapa iterationer (Iteration 1, 2, 3...)
  • Följa progression i projektet
  • Samla issues som ska färdigställas inom ett tidsintervall

Exempel (Login-projekt)

Milestone: Iteration 1 – Grundläggande autentisering

  • Skapa login-endpoint
  • Validera användare
  • Generera JWT

👉 Alla relaterade issues kopplas till denna milestone

Arbetsregel:

  • Varje issue ska alltid kopplas till en milestone
  • Milestone används för att se "vad ska vara klart när"

5. Implementation – Branch och Merge Request

Vad händer här?

Detta är den tekniska implementeringen kopplad till ett issue (eller sub-issue).

Arbetsflöde:

1. Skapa branch från issue

Exempel:

  • feature/login-jwt-token
  • feature/login-endpoint

2. Implementera funktionalitet

  • Skriv kod i branch
  • Följ definierade krav från issue/sub-issue

3. Skapa Merge Request (MR)

  • Koppla MR till issue
  • Beskriv vad som är implementerat

4. Review och merge

  • Kod granskas
  • Merge till main
  • Issue stängs automatiskt eller manuellt

6. Hela kedjan (sammanfattning)

‌‌‌‌‌

7. Viktiga principer

✔ Ett tydligt syfte per nivå

  • Epic = varför
  • Issue = vad
  • Sub-issue = detaljerat vad
  • Branch = hur

✔ Spårbarhet är centralt

All kod ska kunna spåras tillbaka till:

krav → issue → kod

✔ Undvik överkomplexitet

  • Använd sub-issues endast när det behövs
  • Håll issues hanterbara

8. Rekommenderad studentpraxis

  1. Börja alltid med Epic (om funktion är större än en enkel uppgift)
  2. Bryt ner i issues
  3. Bryt endast ner vidare i sub-issues om nödvändigt
  4. Implementera alltid via branch + MR

9. Syftet med modellen

Denna struktur hjälper till att:

  • Skapa tydlig kravhantering
  • Undvika “kod först”-arbete
  • Ge spårbarhet i projekt
  • Efterlikna professionell mjukvaruutveckling

🗓️ Veckoflöde – Exempel (1 iteration = 1 vecka)

Detta är ett konkret exempel på hur en iteration (milestone) kan se ut i praktiken över en vecka.

📅 Måndag – Planering

  • Ny milestone (Iteration X) startas
  • Issues väljs ut från backlog
  • Varje issue kopplas till milestone
  • Fördelning av arbete
  • Nya branches planeras (men inte alltid skapade än)

👉 Fokus: Vad ska göras denna vecka?

🛠️ Tisdag–Onsdag – Implementation

Per-issue-loopen (branch → commits → MR) sker i Jobba med Git under "Per-issue arbetsflöde i GitLab".

👉 Fokus: Bygga funktioner stegvis

🔀 Torsdag – Integration & Review

  • Skapa Merge Requests
  • Code review (egen eller peer)
  • Fix av feedback
  • Merge av färdiga features

👉 Fokus: Få kod in i main på ett kontrollerat sätt

🧪 Fredag – Avslut & Reflektion

  • Stäng färdiga issues
  • Kontrollera milestone-status
  • Säkerställ att allt är merge:at
  • Kort reflektion: vad blev klart, vad återstår?

👉 Fokus: Avsluta iteration och förbereda nästa

🧠 Sammanfattning

  • Måndag = planera
  • Tisdag–Onsdag = bygga
  • Torsdag = integrera
  • Fredag = avsluta

Varje vecka är en komplett utvecklingscykel (iteration)