# Entwicklermeeting - Agenda

## Begrüßung und Statusupdate

- Aktueller Stand des Projekts 
  - Gesamtfortschritt & Meilenstein Status 
    - Meilensteine: 
      - LDAP Integration: 100%
      - Documentation:  62% (+12%)
      - Frontend:     85% (+29%)
      - Backend CRUD:   94% (+3%)
    - Gesamt: 85,25% (+11,75%)
  - Pflichtenheft Epics: 
    - Epic 1: 
      - ~~Schreibender und lesender Zugriff auf LDAP, inklusive Schemaerweiterung~~
      - ~~Einfache Übersichtsseiten („alle Geräte pro Nutzer“)~~
    - Epic 2: 
      - ~~Assets anlegen, bearbeiten und löschen~~
        - Im letzten/aktuellen Sprint erledigt
      - Assets zu Nutzern zuordnen 
        - An sich umgesetzt; Drop-Down Implementation steht noch aus
    - Epic 3: 
      - ~~Suchen und Filtern von Assets~~
        - Im aktuellen Sprint erledigt
    - Epic 4: 
      - ~~Inventarisierung von Geräten (durch Inventarisierer)~~
        - Im aktuellen Sprint erledigt
      - ~~Rollenverwaltung über LDAP-Gruppen~~
        - Im aktuellen Sprint erledigt
  - Umgesetzte Features seit dem letzten Meeting 
    - Pflichtenheft wurde erfolgreich agil umgestaltet (wie im letzten Meeting besprochen und im Unterricht vorgestellt)
    - Claims-basierte Autorisierung ("CanInventorize", "CanManageUsers", ...)
    - Gruppenansicht Funktionalität (Erstellen, Updaten, Löschen)
    - Inventarisierung 
      - Bar Codes (Scannen, downloaden, zum Batch Printing hinzufügen)
      - Sticker Batch printing (Drucken von mehreren Bar Codes auf einem A4 Blatt)
    - AssetId Counter zählt automatisch hoch
    - Lighthouse und K6 Tests
    - Rework der Homepage
    - Support für Light Mode

## Lernerlebnisse bzgl. Pull Requests und Merge Konflikten

### Wie beugt man Merge-Konflikten vor?

- Branch aktuell halten 
  - Regelmäßig den Branch auf Main rebasen
  - Keine Merges von Main auf den Branch durchführen
- Kurze Lebensdauer von Branches 
  - Änderungen bereits ohne Branch ausprobieren und umsetzen, zum Committen aber den Branch anlegen und in diesen wechseln
  - Branches sollte man möglichst regelmäßig (mit Pull Request und Code Review) nach main mergen
- Kleine, fokussierte Commits 
  - Jeder Commit setzt (idealerweise) 1 Sache um
  - Möglichst wenige Dateien anfassen
- Pull Requests möglichst einfach halten 
  - Nicht zu weit von Aufgaben abweichen 
    - Abweichungen sind Ok, sollten aber die Arbeiten der anderen berücksichtigen.
  - Wenn man an etwas verändert, wo jemand anderes wahrscheinlich aktiv ist, im Issue einen Kommentar hinterlegen und durch das Taggen der Person Bescheid geben - oder direkte Kommunikation aufsuchen (Discord, etc.)
  - Meinungsverschiedenheiten hinsichtlich Clean Coding nicht mit der Umsetzung einer eigentlichen Aufgabe vermischen 
    - Sonst droht, dass PRs aufgrund von Diskussionen lange offen bleiben und sich Merge Konflikte stauen, bzw. Aufgaben nicht abgeschlossen werden können
- Aufgabenverteilung sinnhaft gestalten 
  - Aufgaben so verteilen, dass die vermutlich betroffenen Dateien sich so wenig wie möglich überschneiden
  - Aufgaben gut mit Unteraufgaben strukturieren, sodass man kleine, übersichtliche Merges hat
- Aufgaben, die in Bearbeitung sind, konsequent auf "In progress" setzen

## Weitere Themen

| Thema | Vorgestellt durch | Zeit (Minuten) | Beschreibung | Ergebnis |
|-------|-------------------|----------------|--------------|----------|
|       |                   |                |              |          |
|       |                   |                |              |          |

## Retrospektive

- Was ist gut gelaufen?
- Was ist schlecht gelaufen?
- Welche neue Ideen habt ihr?
  - Ergebnis: Keine neuen Vorschläge
- Welche Handlungen sollen wir ergreifen?
  - Ergebnis: Keine Handlungsvorschläge

## Sprint-Planung

- Diesmal kein Verteilen der Aufgaben; selbstständige Entnahme der Aufgaben
- Trotzdem aber: Besprechen der verbleibenden Aufgaben aus dem Kanban Board
- Einsatz von [Planning Poker](https://planningpokeronline.com/) zur Schätzung des Arbeitsaufwands

## Festlegung des nächsten Termins

- 02.11.2025 18:00