Was ist GitLab?

Gitlab ist ein digitales Projektmanagement Tool, welches einen großen Fokus auf Software legt. Ihr eigener Claim lautet

From project planning and source code management to CI/CD and monitoring, GitLab is a complete DevOps platform, delivered as a single application. Only GitLab enables Concurrent DevOps to make the software lifecycle 200% faster.

wichtige Begriffe

GitLab ist sehr umfassend und wird auch ständig weiterentwickelt und angepasst. Hier ein kleines Glossar mit den wichtigsten Begriffen.

Repository

Besonders relevant für die Entwicklung ist das Repository, quasi ein Cloudspeicher, in dem der (Programm-)Code für unsere digitalen Produkte (Website (opens new window), Blog (opens new window), ...) verwaltet wird.

Projekte

In GitLab gibt es sogenannte Projekte und jedes Projekt bildet quasi ein Aufgabenbereich ab.

Issues / Tickets

Besonders relevant sind die Issues (auch Tickets genannt), welche die zu erledigende Aufgaben zw. Anforderungen darstellen.

Diese können transparent mit einem Kanban Board (opens new window) dargestellt werden.

Falls du Bilder bzw. Designs hochlädst, nutze bitte die Design Funktion (opens new window) von GitLab.

Issues (Tickets) im Projektmanagement

Es ist wichtig, dass wir effizient und sinnvoll mit Issues umgehen und gleichzeitig, durch diese, eine transparente, nachvollziehbare Arbeitsweise schaffen. Das ist die Basis für agiles, selbstorganisiertes Arbeiten. Die Vorgehensweise kann sich von Projekt zu Projekt unterscheiden, für die Art und Weise ist der Projektverantwortliche zuständig.
Jeder Workflow sollte jedoch einige Grundprinzipien beinhalten. Zu nennen wären da:

1. die Person, welche etwas möchte (also eine Aufgabe für einen Kolleg:inn hat), erstellt den Issue im passenden Projekt
2. der Issue sollte die nötigen Informationen beinhalte um ihn bearbeiten zu können und/oder klare Fragestellungen an die bearbeitende Person richten
3. im besten Fall wird eine Userstory (opens new window) genutzt
4. der Issue wird soweit mit passen Labels versehen, (wie es der erstellenden Person möglich ist). In jedem Fall soll ein Zustandslabel vergeben werden
5. weitere Infos (wie Fälligkeitsdatum, referenzierte Issues, Gewichtung/Prio, ...) sollen soweit möglich angegeben werden
6. die Möglichkeiten, die GitLab bietet, sollen genutzt werden (Design Uploads, auf Kommentare Antworten, Issuereferenzierung , ...)

Standard Issue Beschreibung (Vorlage)

Für jedes Projekt kann eine Vorlage für Issues (Template) erstellt werden, welches die Erstellung der Issues vereinfachen und effizienter gestalten soll.
Dies kann über (Projekt) => Einstellungen > Allgemein > Standard-Beschreibungsvorlage für Tickets eingerichtet werden:

Für das Website-Projekt wird z.B. folgende Vorlage verwendet:

📝 Userstory

Als möchte ich <Ziel/Wunsch>, um

✅ Aufgaben

• [ ] Aufgabe 1

🖼 Design

❓ Zu klären / Ungewissheit

🔗 Weiter Infos

### 📝 Userstory
Als <Rolle> möchte ich <Ziel/Wunsch>, um <Nutzen>

#### ✅ Aufgaben
- [ ] Aufgabe 1

#### 🖼 Design 
-  

#### ❓ Zu klären / Ungewissheit 
- 

#### 🔗 Weiter Infos
- 

Lebenszyklus eines Issues

Issues durchleben quasi während ihrer aktiven Zeit verschiedene Zustände (deshalb auch Zustandslabel).
Hier beispielhaft erklärt:

1. Eine Idee entsteht und wird (ggf. nach dem besprechen im #idea-Channel (Slack) oder im Brainstorming) in einem Issue festgehalten.
   • Dieser sollte das Label Idea bekommen.
2. Die Umsetzung des Issue rückt in nahe Zukunft (z.B. mit dem nächsten Milestone/Iteration) und der Zustand (bzw. das Label) wird von idea zu To Do geändert. Außerdem soll die Person, welche den Issue umsetzt (ggf. auch mehrere) als Beauftragte Person hinzugefügt werden.
3. Wenn es an die Umsetzung des Issues geht, ändert sich sein Zustand (Label) von To Do auf Doing.
4. Ist der Issue zu Abnahme bereit, ändert die (zuletzt) bearbeitende Person wer mit dem Issue beauftragt ist auf die Person, welche den Issue abnehmen kann (meistens Ersteller:in) und ändert das Zustandslabel von Doing auf To Test.
5. Nun entscheidet die verantwortliche Person:
   • ist der Issue korrekt umgesetzt wird der Zustand von To Test auf Tested geändert und ggf. der/die Beauftragt:e auf die Person geändert, welche den Issue letztendlich abschließt (Deploy der Website, Druck eines Designs, Post auf Social Media, ...).
   • gibt es Änderungswünsche des/der Ersteller:in, wird geht es erneut zurück zu Schritt 2.
6. Im letzten Schritt schließt die Person welche den Issue erstellt hat diesen Issue (und entfernt das Label Tested), sofern dieser fertig bearbeitet wurde (Definition Of Done (deployed, gepostet, ...).

Gewichtung

Gewichtung(en) sollen die Wichtigkeit von Issues beschreiben.
Dabei haben wir die 3 Priorisierungen:

1. Superwichtig
2. Bei Zeiten
3. Kann warten

Labels

Labels sind quasi Schlagworte mit welchen wir Issues, Meilensteine und ähnliches thematisch (_ Themenlabels_) und arbeitstechnisch (Zustandslabels) klassifizieren und zuordnen können.

Zustandslabels

Als Zustandslabel bezeichnen wir die Labels, welche den Bearbeitungsfortschritt eins Objekts (Issue, MereRequest, Meilenstein, ...) angeben.
Dieses Label soll am besten von der beauftragten (bzw. bearbeitenden) Person selbst gesetzt werden. Die Zustandslabel die wir definiert haben lauten:

• ~Idea - Idea
• ~"To Do" - To Do
• ~Doing - `Doing
• ~"To Test" - To Test
• ~Tested - Tested

Die Labels sind größtenteils selbsterklärend und beschreiben z.B. die Reise eines Issues auf dem Kanbanboard von links (der Erstellung) nach rechts (der Fertigstellung/Abnahme).

Die Zustandslabels sind größtenteil Projektübergreifen (in der Placing-Me-Gruppe organisiert, damit das Gruppen Kanbanboard auch sinnvoll genutzt werden kann).

Themenlabels

Themenlabels beschreiben die Thematische Zuordnung. Diese werden von den Projektverantwortlichen (z.B. Daniel & Ramona => Vertrieb, Mathis => Website, ...) selbst gepflegt und verwaltet.
Diese Labels sollten nicht zu spezifisch gewählt sein und für mehrere Objekte (Issues, Meilensteine, ...) Sinn ergeben.
Ein Solches Label könnte zum Beispiel Arbeitnehmer im Projekt Vertrieb sein. Oder Frontend im Projekt Website.
Themenlabels sollen möglichst schon bei der Erstellung von Tickets/Issues von der Erstellenden Person gesetzt werden und von der Bearbeitenden Person vervollständigt werden (sofern nötig).

Kabanboard

Das Kanbanboard ist die Ticketübersicht (Issueboard) für die einzelnen Projekte, bzw. für die gesamte Placing-Me Gruppe (https://gitlab.com/groups/placing-you/-/boards/502082).
Die standard Spalten des Kanbanboards sind normalerweise an die Zustandslabels angelehnt und lauten:

• Offen -> ohne Zustandslabel
• Idea -> Issue ist noch in de Ideenphase / muss besprochen und geschätzt werden
• To Do -> Issue wird geplant (für die Zukünftige Bearbeitung)
• Doing -> Issue ist in Bearbeitung
• To Test -> Issue kann/soll von der beauftragten Person getestet/abgenommen werden
• Tested -> Der Issue wurde abgenommen und kann deployed/abgeschlossen werden
• Closed -> Kein Zustandslabel (und geschlossen)

Außerdem können weitere Board erstellt werden, welche mit spezifischen Filtern ausgetattet werden können.
Dafür muss man in das entsprechende Projekt / in die Gruppe auf die Ticketübersicht-Ansicht wechseln und kann dann oben links über dem Board eine neue Ansicht erstellen:

übergeordnetes Thema

2.1 Tools und Software intern