GitLab Erklärungen
- Issue/Task-Erstellung in GitLab
- Product-Backlog
- Erstellung eines Sprints
- Erstellung eines Wikis
- Zeiterfassung in GitLab
Ab dem Wintersemester 2025/2026 wird die Projektstrukturierung und der Scrum-Prozess in GitLab durchgeführt. Für die wichtigsten, grundlegendsten Funktion gibt es nachfolgend als Einstiegshilfe einige Erklärungen.
Issue/Task-Erstellung in GitLab
Für die Erstellung von Issues (User-Stories) oder Tasks (Aufgaben) wird in der Projektnavigationsleiste der Reiter "Issues" angeklickt und nachfolgend die Option "New issue" ausgewählt.
Anschließend öffnet sich ein neues Fenster mit vielen Option. Hierbei kann ein Typ, ein Titel, eine Beschreibung und viele weitere unterschiedlichen Funktionen festgelegt werden.
Als "Type" stehen drei Optionen zur Auswahl:
- "Incident" - Ein Zwischenfall/Störung
- "Issue" - Im SWP eine User-Story (siehe User-Stories)
- "Task" - Eine Aufgabe
Im unten gezeigtem Beispiel wird ein Issue gewählt und mit einem Titel (Name der User-Story) und einer Beschreibung (Akzeptanzkriterien) versehen.
Zusätzlich ist es möglich den Status (bspw. "To do", "Done", "In progress" etc), den Bearbeiter (ein oder mehrere Gruppenmitglieder), ein oder mehrere Labels, einen Meilenstein (siehe: ), Schätzungen und viele weitere Funktionen einzustellen. Anschließend werden die Angaben mit dem "Create issue" Button bestätigt.
Es besteht im Anschluss direkt die Option sogenannte "Child items" hinzuzufügen. Dies ist besonders sinnvoll wenn die User-Story relativ umfangreich ist und somit besser in kleinere Arbeitspakete (bzw. Aufgaben) zerteilt werden sollte. Hierfür wird der "Add"-Button und entweder "New task" oder "Existing task" ausgewählt. Somit können entweder neue Aufgaben formuliert (wie im kommenden Beispiel) oder bestehende hinzugefügt werden.
Hier wurde als Aufgabe das Feld für die Eingabe definiert. Anschließend wurde die Eingabe mit "Create task" bestätigt.
Nachdem alle Informationen eingepflegt und ausführlich beschrieben wurden, ist das Issue vorerst fertig.
Status bei Issues
In GitLab werden standardmäßig fünf verschiedene Statusformen angeboten. Diese Optionen sind:
- To do (wird bei der Issue Erstellung standardmäßig ausgewählt)
- In progress
- Done
- Won't do
- Duplicate
Diese Statusformen werden genutzt um eine Sortierung und/oder Priorisierung der Issues zu ermöglichen. Zusätzlich dienen diese aber auch als Orientierung für das gesamte Projektteam. Somit weiß jedes Gruppenmitglied was erledigt ist und was noch erledigt werden muss.
Zur Status Änderung wird einfach die "Edit"-Option betätigt und anschließend öffnet sich ein Optionsmenü. Die gewünschte Option muss nur noch bestätigt werden und der neue Status wird festgelegt.
Meilensteine und Epics
Im Laufe des Softwareprojektes werden eine Menge an Issues erstellt. Damit der Überblick, über die Vielzahl an Issues, nicht verloren geht wird im Softwareprojekt mit Meilensteinen (siehe Meilensteine) und Epics gearbeitet. In GitLab werden beide Funktionen mit "Labels" umgesetzt. Diese Option ist im Reiter "Manage" und anschließend unter "Labels" vorzufinden.
Die Erstellung von Epics sind kongruent zur Erstellung der Meilensteine-Label. Zur Veranschaulichung wird das Epic-Label "Lobby" erstellt.
Bei der Issue-Erstellung/Bearbeitung können die erstellten Labels jetzt mit den neuen/bestehenden Issues verknüpft werden. Dies erfolgt trivial zur Status-Option.
Product-Backlog
Die erstellten Issues werden automatisch nach der Erstellung dem Product-Backlog (siehe Product-Backlog) hinzugefügt. Der Product-Backlog ist eine Liste mit allen erstellten und unbearbeiteten Issues. Dieser ist im GitLab unter dem Reiter "Issue boards" vorzufinden.
Pflege/Priorisierung des Product-Backlogs
Die Pflege des Product-Backlogs (siehe Pflege) ist in GitLab sehr einfach durchzuführen. Hierfür werden die Issues einfach per "Drag and Drop" (Ziehen und Ablegen) in die gewünschte Ordnung bzw. Priorisierung gebracht. Im ersten Beispiel war die Reihenfolge der Issues #1,#3,#4,#5,#6,#7 und für das Projekt unsortiert. Nach der Sortierung ist die Reihenfolge der Issues #7,#6,#5,#4,#3,#1 (Sortierung willkürlich gewählt und dient nur zu Anschauungszwecke).
Erstellung neuer Listen
In GitLab können die Listen auch genutzt werden um beispielsweise Meilensteine oder Epics darzustellen (siehe Meilensteine und Epics). Auch der Status der Issues kann dargestellt werden (siehe Status)
Erstellung eines Sprints
In GitLab erfolgt die Erstellung eines Sprints in sogenannten "Milestones" (Meilensteine). Diese Option ist in der Projektnavigationsleiste unter dem Reiter "Milestones" vorzufinden. Um einen neuen Sprint zu erstellen wird die "New Milestone"-Option ausgewählt.
Damit ein neuer Sprint erstellt werden kann, wird der Sprint mit einem Titel, einem Start- sowie Enddatum und einer Beschreibung versehen. Das Sprintziel sollte in der Beschreibung festgehalten werden. Im unten aufgeführten Beispiel ist die Registrierung und die Anmeldung das angestrebte Sprintziel. Gespeichert wird der Sprint durch die "Create milestone"-Funktion
Sprint-Backlog
Jetzt wurde erfolgreich ein Sprint erstellt. Jedoch fehlen bisher noch die Issues die benötigt werden um das Sprintziel zu erreichen. Dafür wird erneut der Reiter "Issue boards" (der Product-Backlog) angesteuert. Anschließend wird die Funktion "New list" ausgewählt.
Hierbei werden wieder verschiedene Optionen angeboten. Für die Erstellung eines Sprints bzw. der Durchführung der Sprintplanung, wird die Option "Milestone" und der eben erstellte Sprint als "Value" ausgewählt. Anschließend wird der Vorgang durch die "Add to board"-Funktion bestätigt.
Somit wurde erfolgreich ein sogenannter Sprint-Backlog (siehe Informationen zu Scrum) erstellt. In der Sprint-Planungsphase wird vom kompletten Projektteam festgelegt, welche Issues im Sprint umgesetzt werden sollen um das selbst definierte Sprint-Ziel zu erreichen. Nachdem das Team sich geeinigt hat, werden die Issues aus dem Product-Backlog, per "Drag and Drop" (Ziehen und Ablegen) in dem Sprint-Backlog abgelegt.
Schätzungen
Anschließend müssen die Issues geschätzt werden (siehe Schätzen). Dieser Vorgang dient der Schärfung des Verständnisses des gesamtem Projektteams. Hierbei ist es wichtig sich auf eine Werteskala (bspw. Fibonacci) zu einigen (diese sollte über die gesamte Projektdauer beibehalten werden). Die Ergebnisse werden dann direkt in den Issues unter dem Punkt "Weight" festgehalten.
Die Sprint-Planung ist somit abgeschlossen und der fertiggestellte Sprint ist unter dem Reiter "Milestones" vorzufinden.
Erstellung eines Wikis
Im Softwareprojekt müssen viele Daten dokumentiert (siehe Anforderungsanalys und Entwurf sowie Dokumentation) werden und unter anderem auch ein Projekttagebuch (siehe Projekttagebuch geführt werden. Dies wird in der Wiki-Funktion von GitLab umgesetzt. Diese Option ist in der Projektnavigationsleiste unter dem Reiter "Wiki" vorzufinden.
Im GitLab-Wiki muss die erste Seite die sogenannte "Home"-Seite sein. Sonst wird das Wiki nicht korrekt erzeugt. Die Seite wird mit der "Create page"-Funktion erstellt.
Um weitere Seiten zu erstellen, wird in der "Page"-Hierachie das "+" unter Home ausgewählt. Nach Erstellung der neuen Seite, wird diese wieder mit der "Create page"-Funktion erstellt.
Zeiterfassung in GitLab
Im Rahmen des Softwareprojekts sollt ihr eure Arbeitszeit präzise festhalten. Dazu könnt ihr direkt auf angelegten Issues/Tasks/User Stories in dem Bereich Time tracking eure Arbeitszeit Aufgabenspezifisch eintragen. In dem Fenster könnt ihr eintragen wie viel Zeit ihr gearbeitet habt, an welchem Tag ihr gearbeitet habt, um nachträgliches verbuchen von Arbeitszeit zu ermöglichen, und eine kleine Zusammenfassung angeben. Sollte bereits Zeit erfasst worden sein, muss über das Plus (siehe Bild oben rechts im roten Rahmen) Zeit gebucht werden.