-
Notifications
You must be signed in to change notification settings - Fork 0
Projekthandbuch
Hier sind Richtlinien des Projekts für die Teammitglieder dokumentiert
Diese Richtlinien bieten eine umfassende Anleitung für die Nutzung unseres G4-Get2Gether-Project, um das Verständnis und die Benutzung für aller Teammitglieder zu generalisieren. Folgende Ansichten sind in dem Project zu finden:
- Kanban
- Backlog
- Roadmap by Phase
- Backlog done
Der allgemeine Workflow beim Erstellen von Aufgaben sieht wie folgt aus:
- Zuerst wird ein Issue erstellt. Der Status dieses Issues kann auf Draft (noch nicht ausformuliert) oder ToDo (bereit zur Bearbeitung) gesetzt werden. Der Issue sollte als Story deklarieren werden, indem eine Label-Kombination hinzugefügt wird (Bsp.: Story + ).
- Der erstellten Story kann eine textbasiert Taskliste hinzugefügt werden (siehe Doku). Diese Taskliste enthält die sogenannten Subtasks.
- Um im Kanban-Board auch die Subtasks anzuzeigen können, müssen die Tasks separat erstellt werde. Hierfür müssen Issues mit dem Label ("Tasks") erstellt werden. die #-Nummer muss in der Taskliste der übergeordneten Story hinterlegt werden.
Im Kanban-Board sind alle Stories (inkl. Tasks) und Bugs für den aktuellen Sprint aufgelistet, welche aus 4 Feldern besteht:
- Draft: Issues die noch nicht ausgearbeitet sind, werden hier untergeordnet. (Nächstes Feld: Todo)
- Todo: Issues die noch nicht bearbeitet werden, werden hier untergeordnet. (Nächstes Feld: In Progress)
- In Progress: Issues die von einem Teammitglied bearbeitet werden, werden hier untergeordnet. (Nächstes Feld: Done)
- Done: Issues die Abgeschlossen sind, werden hier untergeordnet. (Nächstes Feld: - )
Workflow:
Die Issues können von einem Feld auf das Nächste durch Drag und Drop gezogen werden. Einzig der Schritt von "In Progress" zu "Done" erfolgt durch den Button "Close issue" (siehe Bild).
Im Backlog befinden sich alle Issues die sich nicht im Status "Done" befinden. Eine neue(r) Story/Task/Bug wird in dieser View angelegt (siehe oben). Dabei sind folgende Pflichtfelder auszufüllen:
- Title: Kurze Beschreibung des Issues
- Labels: Kombination aus Art(Story/Task/Bug) und Bereich(Design/Frontend/Backend/Project Management)
- Status und Phase (Auswahl aus einer Liste)
In dieser View wird der aktuelle Fortschritt der Arbeit in einem Zeitdiagramm dargestellt. Dabei werden die Issues nach "Phasen" gruppiert, um einen übersichtlichen Einblick in den Projektfortschritt zu ermöglichen.
In dieser View sind alle Issues aufgelistet, die den Status "Done" besitzen. Hier sollten keine neuen Issues erstellt werden.
All commit-messages should follow a specific format:
<Type>-#<IssueId>: <Message>
ℹ️ If no corresponding issue exists, then use 0
for the IssueId.
Valid types:
-
FE
: Commits, that mainly affect the frontend -
BE
: Commits, that mainly affect the backend -
DC
: Commits, that only affect the documentation -
CH
: Miscellaneous commits (chore), e.g. modifying.gitignore
BE-#1: Init Backend FE-#2: Init Frontend DC-#0: Updated README CH-#0: Updated .gitignore
🏡 Home
- Fachliche Anforderungen
- Nicht funktionale Anforderungen (Hier sind die nicht funktionalen Anforderungen dokumentiert)
- Event-Storming
- Komponentendiagramm
- Kundenanforderungen
🎨 Design
📑 Glossar