1 Die Projektmanagementmethode Kanban

Im folgenden Auszug aus dem Leitfaden Projektmanagement – erarbeitet im Modul „Gestaltungsprojekt” des DiTra-Studiengangs im Wintersemester 2023/24 – wird die Projektmanagementmethode „Kanban” erklärt. Dafür wird zu Beginn kurz die Hintergrundgeschichte und Entwicklung dieser Methode vorgestellt, danach wird die Grundfunktionsweise und die Anwendung der Managementmethode in „GitLab” – einer Web-Anwendung, die die Verwaltung von Softwareprojekten unterstützt – angesprochen. Am Ende dieses Auszuges können Vorlagen für ein eigenes Kanban-Board und mögliche Strukturen gefunden werden. Hinweise, die in diesem Leitfadenauszug enthalten waren, sind im Folgenden eingerückt, und enthalten weitere hilfreiche Informationen.

Die Kanban-Projektmanagement-Methode ist ursprünglich in Japan (Kanban Tool 2020) entstanden. So entwickelte Toyota in den 1940er Jahren mithilfe von Taiichi Ohno ein Produktionssteuerungssystem, welches unter anderem die Überproduktion, aber auch die große Rohstofflagerung vermeiden sollte (Bohinc 2019, S. 221). Angelehnt an Supermarktsysteme der Vereinigten Staaten zu der Zeit wurde nun eine andere Vorgehensweise erstellt (Kanban Tool 2020): Fertiggestellte Produkte und Rohstoffe wurden mit Karten versehen und sobald ein Produkt verkauft oder ein Rohstoff verwendet wurde, wurde die nun überschüssige Karte zurück an das Produktionsteam übergeben. Dieses wiederum sammelte die Verkaufskarten bis zu einer bestimmten Anzahl, ehe sie wieder mit der Produktion begannen.

Hinweis: Der Begriff „Kanban” wird aus den beiden japanischen Worten Kan - „visuell” - und Ban - „Schild” - zusammengesetzt (Kanban Tool 2020). Zusammen übersetzt bedeutet es so viel wie „Signalkarte” (Kusay-Merkle 2018, S. 52).

Das Grundprinzip der sogenannten Pull-Methode, die bei Kanban angewendet wird, kann man sich ähnlich wie bei einem Café-Besuch vorstellen (Kusay-Merkle 2018, S. 255): Bei einer Bestellung erhält der*die Kund*in ein Ticket, sodass der*die Barista weiß, dass der*die Kund*in nun einen Kaffee möchte, und bereitet ihn aufgrund dieser Nachfrage vor. Dieses Ticket signalisiert aber auch, dass sich nun weniger Kaffee in der Barista-Maschine befindet, und diese nach einer bestimmten Anzahl an Tickets wieder nachgefüllt werden muss.

Durch diese erfolgreiche Funktionsweise der Methode konnte Toyota seine Verluste senken (Kanban Tool 2020). Mit der Zeit wurde Kanban auch in anderen Industrien eingeführt, besonders im Bereich der Softwareindustrie hatte die Methode Erfolg. Auch Agile Management und Scrum übten beträchtlichen Einfluss auf Kanban aus. Außerdem kamen um das Jahr 2009 herum für Kanban viele wegweisende Textveröffentlichungen und Konferenzen auf – wie beispielsweise das Buch „Scrumban – Essays on Kanban Systems for Lean Software Development” von Corey Ladas veröffentlicht im Jahr 2008 oder die „Lean Kanban Konferenz” von David Anderson, organisiert im Mai 2009 – die mitunter Kanban zu dem geformt haben, wie es heute bekannt ist.

Auf welchen Grundlagen basierend Kanban nun funktioniert, wie dies in GitLab angewendet werden kann, und welche Tipps es zur Teamorganisation aus meinen persönlichen Erfahrungen mit der Methode gibt, wird nun in den folgenden Kapiteln vorgestellt.

2 Kanban und seine Grundfunktionsweise

Kanban hat folgende Vorteile (Kusay-Merkle 2018, S. 52-53; Anderson und Carmichael 2016, S. 17):

• Die Menge an begonnener Arbeit kann begrenzt und übersichtlich gehalten werden

• Feedbackmechanismen und Prozessverbesserungsmöglichkeiten werden häufig implementiert

• Der Workflow der Arbeit wird positiv unterstützt

• Die Arbeit wird sichtbar und transparent dargestellt

• Verbesserungen können gemeinschaftlich umgesetzt werden

• Prozessregeln werden definiert

Wie bereits erwähnt basiert Kanban auf dem sogenannten Pull-Prinzip (Anderson und Carmichael 2016). Das bedeutet, dass alle noch zu bearbeitenden Aufgaben auf einem „Stapel” oder in einem Vorrat liegen, von denen sich jeweils eine Person nach einer abgeschlossenen Aufgabe eine neue Aufgabe zuteilen beziehungsweise ziehen kann. Um deren aktuellen Status und den insgesamten Workflow darzustellen, wird ein Board zur Hilfe herangezogen, auf dem diese Arbeitskarten in verschiedene Bearbeitungsstatus transparent verschoben werden können (Kusay-Merkle 2018, S. 253). Dabei zieht die für eine Aufgabe zuständige Person die Aufgabe meist selbstständig in diese Kanban-Board-Übersicht, und reguliert somit selbst die eigene Arbeitslast (Kusay-Merkle 2018, S. 261).

Im Folgenden werden nun die einzelnen wichtigsten Komponenten für ein Kanban-Board vorgestellt.

2.1 Kanban – Spalten

Als Grundlage benötigt Kanban auf einem Board verschiedene Spalten (als visuelle Repräsentation der Bearbeitungsschritte) sowie beschriftete Karten mit Arbeitsaufgaben (als visuelle Repräsentation einer zu bearbeitenden Einheit), die durch die jeweiligen Spalten von links nach rechts geschoben werden – je nachdem, in welchem Bearbeitungszustand sie sich gerade befinden (Kusay-Merkle 2018, S. 268). Diese Spalten können je nach Art des Arbeitsprozesses und Gebrauch angepasst werden – in der einfachsten Variante bieten sich drei Spalten zur Verwendung an. Diese drei Spalten können von links nach rechts in die Bereiche „Offen”, „In Arbeit” und „Erledigt” nach dem Vorbild von Bohinc (2019, S. 222) eingeteilt werden. Außerdem kann eine vierte Spalte mit dem Namen „Backlog” verwendet werden: Dort können oft wiederkehrende Aufgaben nach fertiggestellter Bearbeitung wieder abgelegt werden, oder Ideen für neue Aufgaben gesammelt werden, ohne sie fest ins „Offen”-System bereits integrieren zu müssen (Kusay-Merkle 2018, S. 277).

Hinweis: Es kann auch die Spalte „Retrospektive” eingeführt werden, die sich bei praktischen Gruppen-Projekten in meiner akademischen Laufbahn als sehr hilfreich erwiesen hat. Hier können Aufgaben gesammelt werden, die noch einmal im Team besprochen werden sollten. Darunter fallen beispielsweise Aufgaben, deren Bearbeitung von einer oder mehreren Personen überprüft und abgenommen werden sollten. Es können aber auch Aufgaben gesammelt werden, für die Feedback oder Hilfestellungen benötigt werden. Es lohnt sich aber, diese entsprechend der Thematik zu kennzeichnen, um innerhalb von Teammeetings passend auf die Aufgabenkarte eingehen zu können.

In der „Offen”-Spalte werden alle Aufgaben gesammelt, die noch nicht angefangen wurden, aber derzeit zur Bearbeitung ausstehen (Bohinc 2019, S: 222). Dabei können entweder alle für das Projekt benötigten Karten zu Beginn des Projektes in diese Spalte eingefügt werden, oder sie werden Stück für Stück je nach Projektphase (beispielsweise aus der Retrospektiven-Spalte) dort hineingesetzt – je nachdem, was sich als übersichtlicher für das Projekt ergibt. Es könnte aber beispielsweise hilfreich sein, die Karten erst Stück für Stück (beispielsweise für einen vier-Wochen-Zyklus) in diese Spalte einzufügen, um eine Übersicht über die zu bearbeitenden Karten zu behalten.

Die „In Arbeit”-Spalte beinhaltet alle Aufgaben, die sich derzeit in Bearbeitung finden (Bohinc 2019, S. 222). Das bedeutet, sobald jemand eine sich (selbst) zugeteilte Aufgabe beginnt, wird die dementsprechende Karte in diese Spalte verschoben. So ist es möglich, einen Überblick über die aktuell bearbeiteten Aufgaben zu gewinnen.

Die „Erledigt”-Spalte sammelt alle Aufgaben, die erfolgreich abgeschlossen worden sind (Bohinc 2019 S. 223). Hat man die sich zugeteilte Aufgabe abgeschlossen (und ist diese falls nötig vom Team als „fertiggestellt” bestätigt worden), wird die jeweilige Karte in diese Spalte gezogen. Hier ist also eine Übersicht über die abgeschlossenen Aufgaben des Projekts möglich.

Wird die Spalte „Backlog” verwendet, können hier alle Karten mit Aufgaben gesammelt werden, die entweder als Idee für zukünftige Aufgaben dienen (Kusay-Merkle 2018, S. 277), oder die bei regelmäßig wiederkehrenden Projekten – wie beispielsweise der Produktion einer Magazin-Ausgabe – Aufgaben enthalten, die bei jedem Zyklus oder Projektschritt erneut anfallen. Hiermit kann ein Qualitätsabgleich mit abgeschlossenen erfolgreichen Projekten ermöglicht werden, indem beispielsweise die Aufgaben des vorherigen Projektes mit dem neuen Projekt abgeglichen werden. Auch können die dort abgelegten Karten auf ihre Relevanz im (erneuten) Arbeitsablauf überprüft werden, und entweder ergänzt, verändert oder gelöscht werden – wichtig ist dabei nur, ein geregeltes System für diese Veränderungen im Team zu finden, um Verwirrungen im Backlog zu vermeiden. Hier ist ein Beispiel, wie ein simplifizierter Aufbau eines Kanban-Boards aussehen kann:

2.2 Kanban - Karten

Die Karten – auch manchmal Tickets genannt – stellen jeweils die zu erledigenden Aufgaben dar (Anderson und Carmichael 2016, S. 48; Bohinc 2019, S. 222). Dabei entspricht eine Karte jeweils einer Aufgabe, die es zu erledigen gilt. Basierend auf meinen Erfahrungen mit Kanban würde ich empfehlen, die Aufgabenkarten und deren enthaltenen Aufwand geschickt zu wählen – diese sollten weder zu groß mit vielen Zwischenschritten noch zu klein mit schnell bearbeitbaren Aufgaben gewählt werden. Ansonsten könnten die Spalten des Kanban-Boards bei kleinen Aufgaben und somit vielen Karten schnell unübersichtlich werden. Umgekehrt könnten Karten bei zu vielen Zwischenschritten und Unteraufgaben lange an einer Position verharren, was Frustration auslösen könnte, und durch eine Vielzahl an versteckten Zwischenschritten die Transparenz beeinträchtigt.

Folgende Inhalte haben sich nach meinen Erfahrungen als sinnvolle Informationen auf einer Aufgabenkarte ergeben:

• Der*die Verantwortliche für die Aufgabe (durch sich selbst oder das Team zugeteilt)

• Eine kurze Aufgabenbeschreibung

• Mögliche Unterpunkte, die es zur Erfüllung der Aufgabe zu erledigen gilt (Zwischenschritte)

Hinweis: Eine hilfreiche und schnelle Funktion zur Kennzeichnung von Karten wären nach meiner Erfahrung beispielsweise Tags, die entweder innerhalb von digitalen Kanban-Programmen einer Karte zugeteilt werden können, oder per buntem Sticker auf einem analogen Board festgehalten werden. Damit kann auf einen Blick das jeweils behandelte Thema einer Aufgabenkarte erkannt werden, oder die Karte für die „Retrospektive” beispielsweise für benötigten Support oder für Teamrückmeldungen markiert werden.

Für das Verschieben von Karten sollten bestenfalls Regeln erstellt werden: Ab wann gilt eine Aufgabenkarte als so weit abgeschlossen, sodass sie in die nächste Spalte vorrücken darf? Und benötigen die Karten eine Instanz wie beispielsweise eine leitende Person innerhalb des Teams, welche die Karten prüft, ehe diese weitergeschoben werden darf? Dies sollte je nach Projektanforderungen und Teamvorstellung im Vornherein festgehalten werden.

2.3 Kanban – Tipps für die Teamorganisation

Um sicherzustellen, dass kein Teammitglied während eines Projektes überlastet ist und ein guter Arbeitsfluss oder Flow erhalten bleibt, sollten Limits gesetzt werden (Anderson und Carmichael 2016, S. 58): Das bedeutet, es sollte festgelegt werden, wie viele Karten ein Teammitglied maximal gleichzeitig bearbeiten darf, wie viele jeweils zugeteilte Karten maximal pro Spalte darin liegen dürfen, und ab welchem Minimal-Limit neue Aufgabenkarten in das System eingeführt werden sollten. Über die Höhe und Strenge der Limits solltet passend je nach Projekt und dessen Anforderungen nachgedacht werden.

Wichtig ist es auch, regelmäßige Teamtreffen zu organisieren, um unter anderem den aktuellen Zustand des Projektes und des Boards zu besprechen, aber auch um Möglichkeiten für Feedback und Gespräche zu bieten (Anderson und Carmichael 2016; Kusay-Merkle 2018) – wie genau diese Meetings ablaufen könnten und welche Gestaltungsmöglichkeiten es gibt, kann in den von diesem Leitfaden-Auszug verwendeten Quellen nachgelesen werden. Durch diese Treffen sind alle Teammitglieder auf dem neuesten Stand, und Unklarheiten können schnell besprochen und gemeinschaftliche Verbesserungen umgesetzt werden. Auch kann es nach meinen Erfahrungen je nach Projekt sinnvoll sein, wenn innerhalb des Teams eine Kanban-verantwortliche Person ernannt wird – diese Person wäre dann für die saubere Führung des Boards zuständig. Außerdem kann diese verantwortliche Person die Teamtreffen zur Board-Besprechung leiten, sollte keine andere Teamorganisationsform getroffen worden sein.

Hinweis: Teamtreffen können an Scrum orientiert umgesetzt werden. Dabei könnten unter anderem folgende Fragen (pro Teammitglied) jedes Mal besprochen werden (Kusay-Merkle 2018, S. 302):

• Was habe ich gemacht?

• Was plane ich in nächster Zeit zu tun?

• Gibt es Hindernisse, Probleme oder Störungen?

3 Die Anwendung von Kanban innerhalb von GitLab

Kanban ist also eine nützliche Methode, um ein Projekt erfolgreich zu managen und zu steuern. Im Folgenden wird nun ein Beispiel gegeben, wie Kanban innerhalb von GitLab angewendet werden kann. Zur Veranschaulichung werden ergänzend Screenshots aus dem ursprünglichen Projektkontext des Leitfadens – nämlich der Einrichtung eines GitLab-Systems für das API-Magazin – verwendet. Aus diesem Grund beziehen sich die Inhalte der Screenshots auf redaktionelle Aufgaben. Da das GitLab-System bei der Leitfadenerstellung auf Englisch eingestellt worden ist, sind auch die Begriffe folgend auf Englisch gehalten.

Das Kanban-Board kann bei dem korrekt ausgewählten Projekt innerhalb von GitLab (in Fall des folgenden Screenshots wäre es das „API-PROJEKTMANAGEMENT”-Projekt (blau markiert)) auf der linken Seite unter „Plan” 🡪 „Issue Boards” (lila markiert) gefunden werden. Danach muss auf der linken Seite über den kleinen Button links neben der Suchleiste das richtige existierende Board in der Übersicht ausgewählt werden – in dem Fall des folgenden Screenshots besaß das API-Team zwei Boards und „Internal Kanban Board” enthielt die korrekte Kanban-Übersicht (grün markiert).

Die einzelnen Aufgabenkarten bzw. Issues können nun entweder in dieser Ansicht angesehen werden, oder gelistet unter „Plan” 🡪 „Issues” aufgerufen werden.

3.1 Schneller Austausch zu Aufgaben

Um einen schnellen Austausch zu Aufgaben (beispielsweise bei Fragen oder Hinweisen) zu unterstützen, hat es sich bei meinen Kanban-Erfahrungen mit GitLab als hilfreich erwiesen, die Kommentarfunktion innerhalb von GitLab zu nutzen. Dazu wird die Detailansicht einer Aufgabe geöffnet, indem auf das jeweilige Issue in GitLab geklickt wird. Unter dem Punkt „Activity” kann ein Kommentarfeld gefunden werden, in welchen Text eingegeben werden kann. Dieser kann mithilfe von Markdown¹ oder den vorgegebenen Möglichkeiten in Form von Symbolen formatiert werden. Der jeweils gesendete Kommentar kann im Activity-Bereich innerhalb des Issues gefunden werden. Auf die dort gefundenen Kommentare kann geantwortet oder reagiert werden.

Einige Kommentar-Tipps für GitLab:

• Ein Teammitglied kann mit „@ + Name” für eine Benachrichtigung zum gesendeten Kommentar markiert werden.

• Die „Preview” – Option kann verwendet werden, um vor dem Absenden des Kommentars dessen Format zu überprüfen.

• Mithilfe des Büroklammer-Symbols können dem Kommentar Dateien angehängt werden.

• Zum nachträglichen Bearbeiten eines Kommentars kann auf das Stift-Symbol geklickt werden.

3.2 Verwendung von Tasks und Issues

Meistens werden Issues erstellt, soll eine neue Aufgabe bewältigt und in Form einer Kanban-Karte abgelegt werden. Diese sollten wie bereits erwähnt einen sinnvollen Arbeitsumfang umfassen. Da aber die meisten Issues einzelne Aufgabenschritte oder zusammenhängende Unteraufgaben beinhalten, kann es schnell unübersichtlich werden, wenn diese auf GitLab innerhalb der Aufgabenbeschreibung im Issue festgehalten werden.

Dafür kann es hilfreich sein, einem Issue sogenannte „Tasks” hinzuzufügen.

Hinweis: Im deutschsprachigen GitLab heißt diese Funktion „Aufgabe”, deswegen Vorsicht vor Verwirrungen mit diesem Leitfadenauszug, wird das deutschsprachige GitLab verwendet!

Um eine Task hinzuzufügen, wird auf das gewünschte Issue geklickt, und der Bereich „Child Items” aufgerufen. Wird nun auf „Add” geklickt, können dem Issue neue oder bereits existierende Tasks hinzugefügt werden. Dadurch entsteht eine Art Liste innerhalb des Issues, in welcher die zu erledigenden Arbeitsschritte zu finden sind. Werden die einzelnen Tasks per Doppelklick geöffnet, können dort – ähnlich wie bei Issues – Möglichkeiten für eine Beschreibung, Kommentare, Markierungen, Daten und mehr gefunden werden. Jedoch bleiben all diese Informationen innerhalb des jeweiligen Eltern-Issues versteckt, und sind beispielsweise nicht auf der Kanban-Board-Übersicht sofort einsehbar.

Hinweis: Die Tasks sind zwar nicht im Kanban-Board zu sehen, sie können aber in einer Liste gesammelt aufgerufen werden, wird in GitLab der Bereich „Issues**“** (siehe 1 im folgenden Screenshot) aufgerufen. Dort kann – wird auf die Suchleiste geklickt – mithilfe von Suchfiltern (siehe 2) nach Tickets beziehungsweise Issues („Type is Issue”) oder Tasks („Typ is Task”) spezifisch in Form einer Auflistung gesucht werden.

4 Ablauf von Teamtreffen & Retrospektiven anhand von Kanban und GitLab

Um einen regelmäßigen Austausch zum derzeitigen Bearbeitungszustand des Boards zu gewährleisten, ist es sinnvoll, ein wiederkehrendes Teamtreffen in regelmäßigen Abständen durchzuführen (Anderson und Carmichael 2016). Die Häufigkeit sollte je nach Projekt, Anforderungen oder Team gewählt werden.

Hinweis: Nach meinen Kanban-Erfahrungen kann es hilfreich sein, ein knappes Protokoll während eines solchen Meetings zu führen, um wichtige Anmerkungen oder besprochene Punkte nicht zu vergessen.

Im Folgenden wird ein Vorschlag orientiert an meinen bisherigen Kanban-Erfahrungen für den Ablauf eines solches Team-Meetings gegeben – selbstverständlich kann dieser je nach Anforderung angepasst werden. Weitere und detailliertere Informationen und Anregungen zu Teammeetings lassen sich auch aus den im Quellenverzeichnis aufgeführten Texten entnehmen. Je nach Teamgröße und -organisation kann es hilfreich sein, wenn eine Person, beispielsweise der*die Kanban-Verantwortliche, die insgesamte Meeting-Führung übernimmt. Um zusätzlich einen guten Flow während des Meetings aufrecht zu erhalten, können die unten aufgelisteten Punkte (2) - (4) von der jeweils zuständigen Person am Stück berichtet werden, ehe das nächste Teammitglied diese Punkte im Bezug auf die eigene Arbeit anspricht.

(1) Board Review:

Das Board wird gemeinsam aufgerufen und betrachtet, sodass jedes Teammitglied weiß, auf welchem Stand sich das Projekt und der Workflow gerade befinden.

(2) Work in Progress:

Nun teilt jedes Teammitglied mit, an was er oder sie gerade arbeiten. Dabei kann entweder reihum jeder das Wort ergreifen, oder die Kanban-verantwortliche Person arbeitet sich gemeinsam mit den restlichen Mitgliedern durch alle aktuell zu bearbeitenden Tickets innerhalb des Kanban-Boards. Sinnvoll ist es hier, die Tickets nach dem*der jeweiligen Verantwortlichen zu sortieren, sodass eine Person alle zuständigen Aufgaben auf einmal vorstellen kann.

(3) Difficulties:

In diesem Schritt werden die Schwierigkeiten mit den jeweiligen Aufgaben besprochen. Gerne können hier auch Hilfestellungen oder Unterstützungen seitens anderer Teammitglieder angesprochen werden, wenn dies nicht zu sehr von der Thematik ablenkt. Gibt es keine Probleme, kann dies mit einem kurzen Satz seitens des Teammitglieds bestätigt werden, um diesen Punkt der Agenda der Vollständigkeit halber abzuhaken.

(4) Outlook:

Nach den Schwierigkeiten können zukünftige Aufgaben besprochen werden, die bis zum nächsten Meeting von jedem Teammitglied bearbeitet oder angefangen werden sollten. Dies kann auch in der Gruppe besprochen werden, beispielsweise wenn ein Teammitglied eine Aufgabe fertig bearbeitet von einem anderen Mitglied benötigt, um das eigene Ticket abzuarbeiten.

Hinweis: Nach meinen Erfahrungen sollte vorab besprochen werden, ob und in welche Spalten Teammitglieder Karten selbstständig verschieben dürfen, und welche innerhalb dieser Treffen verschoben werden sollten. Außerdem können Kennzeichnungen wie Tags die Transparenz dieses Prozesses unterstützen – beispielsweise indem markiert wird, welche Karte ein Teammitglied selbst als abgeschlossen sieht, oder welche Karte in ihrer neuen Spaltenposition vom Team bestätigt wurde. Wichtig ist hier, ein System für das Team zu finden, das für alle verständlich ist.

Diese Punkte können ein Meeting produktiv und strukturiert gestalten. Zusätzlich ist es sinnvoll, eine gemeinsame Retrospektive an regelmäßigen Terminen durchzuführen. Nach meinen Erfahrungen können folgende Punkte eine Retrospektive hilfreich gestalten:

1. Was lief seit dem letzten Treffen gut?

2. Was war eine Herausforderung (Ticketspezifisch oder Projektbezogen)?

3. Wo werden seitens des Teams Verbesserungsmöglichkeiten gesehen?

4. Welche Handlungen und Best Practices möchte das Team von nun an festlegen, sodass die Arbeit bis zum nächsten Meeting flüssiger und besser verläuft?

Außerdem kann es sehr aufbauend wirken, wenn innerhalb dieser Treffen die Teammitglieder sich gegenseitig ermuntern und positiv für die Arbeit zusprechen. Gerne können beide Agenden (das Bearbeiten des Kanban-Boards und die Retrospektive) kombiniert werden. Dabei kann es sinnvoll sein, den Ablauf schriftlich festzuhalten, sodass kein Programmpunkt innerhalb eines Meetings vergessen wird.

Hinweis: Um einen noch geregelteren Arbeitsablauf inklusive regelmäßigen Meetings zu haben, kann ergänzend eine agile Projektmanagementmethode wie Scrum angewendet werden, um beispielsweise Rollenverteilungen oder Team-Meetings noch strukturierter zu gestalten.

5 Vorlagen für ein Kanban-Board und Tickets

Im Folgenden sind als Ergänzungen Vorlagen für das Kanban-Board und die Tickets innerhalb von GitLab zu finden, die sich in ähnlicher Form bei meinen vorherigen Projekten als hilfreich erwiesen haben.

Hier ist nochmal ein Beispiel, wie ein sinnvolles Kanban-Board innerhalb von GitLab aufgebaut sein könnte:

Hier ist außerdem ein Beispiel, wie eine sinnvolle Kanban-Aufgabenkarte in Form eines Issues aufgebaut sein kann, und welche Funktionen von GitLab ein Issue noch effektiver gestalten können:

Hilfreiche Tipps zur Nutzung der Kanban-Boards:

• Der „Title” (siehe 1) des Issues sollte dabei auf die Thematik der Kanban-Aufgabenkarte mit einem Blick schließen lassen.

• Die „Description” (siehe 2) sollte der genaueren Beschreibung der Aufgabe dienen. Beinhaltet sein können unter anderem Hintergrundinformationen, der konkrete Aufgabenablauf, und Namen relevanter Personen.

• Falls benötigt, können optional unter „Designs” (siehe 3) eigene erklärende Screenshots und Bilder hochgeladen werden.

• Unter „Child items” (siehe 4) können die bereits angesprochenen Tasks samt Beschreibung aufgelistet werden. Es ist sinnvoll, diese mit Labels wie „In Bearbeitung” oder „Beendet” zu versehen, um einen Überblick über die Aufgaben innerhalb eines Tickets zu behalten. Außerdem können innerhalb dieser Tasks beispielsweise eigene Beschreibungen festgehalten werden.

• Falls erwünscht, können Issues darunterfolgend unter „Linked items” (siehe 5) auch optional miteinander verlinkt werden. Dies kann besonders sinnvoll sein, wenn unterschiedlichen Arbeitstickets Relationen zueinander haben.

• Unter „Activity” (siehe 6) kann optional wie bereits erwähnt ein Austausch über das Ticket per Kommentar stattfinden. Außerdem können weitere Personen getaggt werden, oder Problemstellungen und zu ergänzende Arbeitszustände festgehalten werden.

• Zusätzlich sollte jedes Ticket mit einem oder mehreren „Assignees” (siehe 7) versehen werden, sowie die passenden „Labels” (siehe 8) und „Milestones” (siehe 9) zugeordnet bekommen. Ein „Due date” (siehe 10) kann optional für manche Tickets sinnvoll sein, um sich an einen festgelegten Zeitrahmen orientieren zu können.

Sind all diese Informationslücken für ein Ticket gefüllt, ist eine Kanban-Karte erfolgreich erstellt worden.

Hinweis: Um eine bessere Übersicht über den aktuellen Bearbeitungszustands einer spezifischen Aufgabe zu behalten, kann in der Aufgabe ein Verweis über den derzeitigen Zustand in den Kommentaren hinterlassen werden.

Mit all diesen Informationen sollte sich die Kanban-Methode auf ein Projekt innerhalb von GitLab gut anwenden lassen. Ergänzend kann nach weiteren Tipps und Arbeitsweisen in anderen Kanban-Texten gesucht werden, dieser Einblick sollte jedoch ein gutes Grundverständnis über die Anwendungsweise vermittelt haben.

Literatur

ANDERSON, Daniel und CARMICHAEL, Andy, 2016. Essential Kanban Condensed. 1. Auflage. Seattle, Washington: Lean Kanban University Press. ISBN: 978-0-9845214-2-5

BOHINC, Tomas, 2019. Grundlagen des Projektmanagements: Methoden, Techniken und Tools für Projektleiter. 7. Auflage. Offenbach: GABAL Verlag. ISBN: 978-3-86936-912-9

KANBAN TOOL, 2020. Die Kanban-Geschichte. Kanban Tool. (online) 14.05.2020. [Zugriff am 09.10.2024]. Verfügbar unter: https://kanbantool.com/de/kanban-guide/die-kanban-geschichte

KUSAY-MERKLE, Ursula, 2021. Agiles Projektmanagement im Berufsalltag: für mittlere und kleine Projekte. 2. Auflage. Berlin, Heidelberg: Springer Gabler. ISBN: 978-3-662-62810-2