Added result from sprint meeting

This commit is contained in:
2025-10-19 21:01:30 +02:00
parent e138e3246b
commit 8f47b6a1a8

View File

@@ -0,0 +1,90 @@
# 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