3. Features im Detail - Dxme98/Dokumentation GitHub Wiki

Features im Detail

Diese Seite dient als "geführte Tour" durch die TaskTrackr-Anwendung.

Anstatt jedes einzelne Feature aufzulisten, fokussiert sich diese Übersicht auf einige Kernfunktionen, die das Projekt definieren. Die folgenden Abschnitte zeigen die Abläufe (User-Flows) dieser Features mit Screenshots aus der Live-Anwendung.

Das Rechtesystem

Jedes Projekt startet mit zwei Standard-Rollen:

  1. "Owner" (Eigentümer): Hat alle administrativen Rechte.
  2. "Base" (Basis-Mitglied): Die Standardrolle für jedes neue Mitglied.

Diese Standard-Rollen können umbenannt, aber nicht gelöscht werden.

Dynamische & Projekttyp-spezifische Rechte

Das Besondere am TaskTrackr-Rechtesystem ist seine Flexibilität:

  • Eigene Rollen erstellen: Projekt-Owner können beliebig viele neue Rollen erstellen (z.B. "Entwickler", "Tester", "Leser").
  • Projekttyp-spezifische Rechte: Das System erkennt den Projekttyp. Ein "Scrum"-Projekt  hat andere, komplexere Rechte (z.B. SPRINT_STARTEN) als ein "Basic"-Projekt (z.B. TASK_ERSTELLEN). Beim Erstellen einer Rolle werden nur die Rechte angezeigt, die für den jeweiligen Projekttyp relevant sind.

Dieser Screenshot zeigt die Rollen-Verwaltung in der Praxis. Neben den Standard-Rollen ("Owner", "Base") sind hier die benutzerdefinierten Rollen zu sehen, die klar als "Custom" markiert werden. Als Beispiel wurden hier die Rollen "Developer" und "Scrum Master" mit ihren spezifischen Rechten für dieses Projekt angelegt.

Zuweisung der Rollen

Nachdem die Rollen erstellt wurden, können sie (mit den entsprechenden Rechten) einfach in der Projektverwaltung den Mitgliedern zugewiesen werden.

Umsetzung der Berechtigungen (Rechteverweigerung)

Das Rechtesystem wird im gesamten Backend durchgesetzt. Dieser Screenshot zeigt einen User, der nur die Rolle "Developer" besitzt, der das Recht INVITE_USER nicht hat.

Schutz vor logischen Deadlocks

Um die Integrität der Projektverwaltung sicherzustellen, sind folgende "Guardrails" implementiert:

  • Schutz vor verwaisten Rollen: Eine Rolle kann nicht gelöscht werden, solange ihr noch Mitglieder zugewiesen sind.
  • Schutz vor verwaisten Projekten: Der letzte "Owner" eines Projekts kann seine Rolle nicht ändern oder entfernt werden.
  • Schutz vor Selbst-Eskalation: Ein "Nicht-Owner" kann sich nicht selbst zur Rolle "Owner" befördern.
  • ...und diverse weitere Validierungen, die die Datenkonsistenz auf Service-Ebene sicherstellen.

Der Scrum-Workflow (End-to-End)

Dieses Feature zeigt den Kern-Lebenszyklus eines agilen "Scrum"-Projekts in TaskTrackr: von der Erstellung einer User Story über die Planung eines Sprints bis hin zum Sprint-Abschluss und der Visualisierung im Scrum Board.

1. User Stories erstellen

Der erste Schritt im Scrum-Prozess ist das Füllen des Backlogs. Der Screenshot zeigt das Erstellen einer neuen User Story.

2. Product Backlog

Alle erstellten User Stories landen im Product Backlog. Diese Ansicht dient als zentrale Sammelstelle für alle Anforderungen.

3. Sprint Planning (Arbeit auswählen)

Im "Sprint Planning" wird der nächste Arbeitszyklus definiert. Der Screenshot zeigt, wie der Scrum Master (oder das Team) einen neuen Sprint anlegt, Daten festlegt und Stories aus dem Backlog zuweist.

4. Sprint starten

Nach dem Planning ist der neue Sprint erstellt. Mit einem Klick auf "Sprint starten" wird der Sprint für das gesamte Team aktiviert.

5. Das Scrum Board (Arbeit visualisieren)

Sobald der Sprint gestartet ist, wird das Scrum Board freigeschaltet. Alle zugewiesenen User Stories erscheinen hier (standardmäßig in "Sprint Backlog").

6. Die User Story im Detail

Ein Klick auf eine User Story öffnet die Detail-Ansicht für die tägliche Arbeit (Kommentare, Blocker, Status-Änderungen).

  • Regel 1: Zuweisungen sind nur in der "Sprint Backlog"-Spalte möglich.
  • Regel 2: Nur zugewiesene Mitglieder (oder Admins) können den Status ändern.

7. Sprint-Arbeit abgeschlossen (Vor Sprint-Ende)

Dieser Screenshot simuliert den Zustand am Ende des Sprints. Die meisten User Stories befinden sich nun in der "Done"-Spalte.

8. Sprint-Reports (Live-Performance-Analyse)

Parallel zur Arbeit generiert TaskTrackr jederzeit einsehbare Live-Reports, die den aktuellen Fortschritt, die Team-Performance und Informationen über abgeschlossene Sprints visualisieren.

9. Sprint beenden (Sprint-Abschluss)

Der letzte Schritt im Zyklus ist der formale Abschluss des Sprints.

  • Abgeschlossene Items: Werden als permanent "Done" markiert.
  • Nicht abgeschlossene Items: Werden automatisch zurück in das Product Backlog verschoben.
  • Bereit für das nächste Planning: Der Status dieser unfertigen Stories wird zurückgesetzt.

10. Vergangene Sprints (Archiv)

Abgeschlossene Sprints werden archiviert. Die Detailansicht listet genau auf, welche Stories erfolgreich abgeschlossen wurden und welche nicht beendet wurden.

Zeigt nicht beendete Stories

Zeigt erfolgreich abgeschlossen Stories

11. Das Product Backlog nach dem Sprint

Dieser Screenshot beweist die Logik aus Schritt 9 (Sprint beenden):

  • Nicht abgeschlossene Stories: Die Story "Scrum-Board Visualisierung" ist automatisch wieder im Product Backlog verfügbar und bereit für das nächste Planning.

Feature 3: Event-Driven Aktivitätsverlauf

Über simple CRUD-Operationen hinaus ist die Anwendung teilweise Event-getrieben. Jede wichtige Business-Aktion (z.B. "Sprint starten", "Task erstellen", "User zuweisen") löst ein internes Event aus.

Diese Events werden in einem zentralen, projektweiten Aktivitätsverlauf protokolliert, um 100%ige Nachvollziehbarkeit zu gewährleisten: Wer hat was wann getan?

Das Besondere an diesem Feature ist seine Flexibilität:

  • Universell: Der Aktivitätsverlauf ist in beiden Projekttypen (Basic & Scrum) verfügbar.
  • Typspezifisch: Das System ist intelligent genug, um projekttypspezifische Events zu protokollieren (z.B. SPRINT_BEENDET oder BLOCKER_ERSTELLT).

Analyse des Aktivitätsverlaufs

Die folgenden Screenshots zeigen den kompletten Verlauf des Scrum-Flows, der in "Feature 2" vorgestellt wurde – von der Erstellung der User Stories bis zum Abschluss des Sprints, protokolliert als Event-Log.

Man sieht hier auch, wie Aktionen aus Feature 1 (z.B. admin hat dxme die Rolle Developer zugewiesen) ebenfalls im Log erfasst werden.

(Einige der Einträge sind Testfälle – bitte ignorieren :D)

Der Log erfasst präzise jede Berechtigungsänderung. Man sieht hier die Erstellung, Löschung und Zuweisung von Rollen.

Der Verlauf geht nahtlos zur Sprint-Planung über. Er protokolliert die Erstellung jeder einzelnen User Story sowie die Erstellung des Sprints selbst.

Dies ist der detaillierteste Teil des Logs. Er erfasst jede einzelne Aktion innerhalb des Sprints – vom Starten, über das Hinzufügen von Kommentaren/Blockern, das Ändern des Status bis hin zum beenden des Sprints.