Archiv

Posts Tagged ‘Kanban’

Kanban Board mit JIRA

Ein physisches Kanban Board ist grundsätzlich immer zu empfehlen. Was aber tun, wenn die Mitarbeiter des Projektes nicht am gleichen Ort arbeiten. Oder wenn Kollegen mitarbeiten, die mehrere örtlich verschiedene Arbeitspätze haben? Dann empfiehlt sich eine Online Applikation wie z.B. Trello oder Jira. Im Folgenden beschreibe ich kurz, wie man eine Kanban Board mit JIRA aufsetzen kann.

Step 1: Projekt erstellen

  1. Menü: Projects / Create Project
  2. Im Dialog „Agile Kanban“ auswählen.
  3. Dem Projekt einen Namen und Key geben z.B. „Mein Kanban Projekt“ und „MKP“.

Das Projekt ist jetzt angelegt, das Kanban Board wird angezeigt. Es wird der GreenHopper Simplified Workflow benutzt. Die Tasks lassen sich per Drag & Drop auf dem Board verschieben.

Step 2: Anpassen des Kanban Boards

  1. Auf den Button mit dem Zahnrad (Administration) klicken / Configure
  2. Jetzt wird das GUI „Configure <project name>“ angezeigt. Hier auf den Tab „Columns“ klicken. Rechts werden zwei Buttons angezeigt: „Add Status“ sowie „Add Column“. Sollte „AddStatus“ nicht angezeigt werden, so haben Sie vermutlich zu wenig Rechte. Wenden Sie sich dann an den Administrator und lassen sich für Ihr neu erstelltes Projekt mehr Rechte geben.
  3. Initial werden drei Spalten angezeigt:
    a) Todo
    b) In Progress
    c) Done
    Diese sind mit den vordefinierten Standard Status verknüpft:
    Jira_Default_Board
  4. Nun kann man mit dem Buttons „Add Status“ und „Add Columns“ die entsprechenden Spalten hinzufügen. Wenn man den Status und Spalten die gleichen Namen gibt, werden diese auch gleich automatisch gemappt. Überflüssige Status lassen sich auch löschen oder umbenennen.Nach dem Hinzufügen ist es sinnvoll, die Reihenfolge der Spalten anzupassen.
  5. Da sich in Jira eine Spalte nicht in „DOING“ und „DONE“ aufsplitten lässt, habe ich dafür eigene Status/Columns erstellt. Hier die Liste meiner Spalten (diese kann von Projekt zu Projekt verschieden sein und kann auch nachträglich angepasst werden):
    1. Backlog
    2. Next
    3. Analysis DOING
    4. Analysis DONE
    5. Dev DOING
    6. Dev DONE
    7. Test DOING
    8. Test DONE
    9. Ready for Release
    10. Done
  6. Sobald die Spalten aufgesetzt sind, sollte man noch das WIP Limit (Max) pro Spalte definieren
  7. Auch das Arbeiten mit Swimlines wird von JIRA resp. Greenhopper unterstützt. Hierzu habe ich auf den Tab „Swimlanes“ geklickt und „Base Swinlandes on Stories“ ausgewählt.

Step 3: Erstellen von Tasks

Jetzt sind wir mit der Anpassung des KANBAN Boards fertig und können anfangen Issues zu erfassen. Damit die Tasks gleich der richtigen Story zugeordnet werden, empfehle ich wie folgt vorzugehen:

  1. Erstellen einer Story mit dem Button „Create issue“ in der Menüleiste. Als Issue Type unbedingt „Story“ auswählen.
  2. Sobald die Story erfasst ist, zum Issue Navigator wechseln und die entsprechende Story auswählen. Dann kann man mit einem Klick auf den Button „More“ den Befehl „Create Sub-Task“ auswählen und den Task erfassen. Der Task wird nun automatisch auf dem Kanban Board in der Swimlane der zugehörigen Story einsortiert und angezeigt. Cool!
Advertisements

Was ist Kanban in der IT – und was ist es nicht? (Teil 1)

Ist Kanban eine Softwareentwicklungs-Methode, ein Prozess, ein Framework oder eher eine Projektmanagement-Methode? Ist Kanban eine Alternative zu Scrum? Wie kann ich das einordnen?

Diese und andere Fragen beschäftigen mich seit längerem, dieser Artikel soll helfen, einige der Fragen zu beantworten.

Kanban ist ursprünglich eine Technik aus dem Toyota-Produktionssystem und dient der Selbststeuerung der Material- und Produktflüsse nach dem Hol-Prinzip. David Anderson griff diese Idee für die IT Branche auf und entwickelte sie weiter. 2007 veröffentlichte er sein Konzept auf mehreren Konferenzen, er gilt somit als Begründer von Kanban (für „Wissensarbeiter“).

  • Kanban ist eine evolutionäre Changemanagement Methode, welche mit kleinen Schritten zur Verbesserung eines bestehenden Prozesses führt. Diese vielen kleinen Verbesserungsschritte werden „Kaizen“ genannt, ein Begriff aus dem Japanischen. Man spricht auch vom kontinuierlichem Verbesserungsprozess resp. Continuos Improvement.
  • Kanban ist ein Pull-System (Hol-Prinzip): Das bedeutet, dass neue Aufgaben nicht in das System gedrückt werden (push), sondern, dass neue Aufgaben hineingezogen werden, sobald das System die Kapazität dafür hat.
  • Kanban beschränkt die Anzahl der parallelen Arbeiten, d.h. der Work in Progress (WIP) wird begrenzt. Man spricht auch von WIP-Limits.
  • Kanban selbst ist keine agile Methode, Kanban kann uns aber helfen eine agile Methode einzuführen.
  • Man könnte Kanban als Meta-Methode ansehen, welche mit anderen Vorgehensmodellen z.B. Wasserfall, Scrum, RUP (Rational Unified Process) kombiniert werden kann. Es ist also möglich, mit dem gerade existierenden Prozess zu starten und Kanban einzuführen!

Was ist Kanban nicht?

Kanban ist keine Softwareentwicklungs-Methode, kein Framework und es ist kein Prozess.

Ziele von Kanban

Mit Kanban soll eine nachhaltige Arbeitsgeschwindigkeit bei hoher Qualität erreicht werden. Optimierung der Durchlaufzeit anstatt der Optimierung der Auslastung. Verbesserung des bestehendes Prozesses in vielen inkrementellen Schritten. Mit Kanban sollen Aufgaben vor allem abgeschlossen und nicht nur angefangen werden. Alle Aufgaben der Wertschöpfungskette sollen visualisiert werden, hierdurch wird der bestehende Arbeitsprozess für das Team transparent gemacht. Engpässe und Probleme sollen aufgedeckt und gelöst werden, Durchlaufzeiten sollen vorhersagbar werden.

Die vier Grundprinzipien von Kanban

  1. Starte dort, wo Du gerade bist.
  2. Komme mit den anderen überein, dass inkrementelle, evolutionäre Veränderungen angestrebt werden.
  3. Respektiere den bestehenden Prozess, Verantwortlichkeiten und Titel.
  4. Fördere Leadership auf allen Ebenen.

Das vierte Grundprinzip ist erst später hinzugekommen. Leadership gibt es auf allen Ebenen. Mit Leadership ist hier nicht Führung gemeint, sondern vielmehr Leadership im Sinne von John P. Kotter:

Manager sind eher Verwalter, Leader dagegen Visionäre. Management steht eher für das perfekte Organisieren der Abläufe, planen und kontrollieren. Leadership bedeutet dagegen, die Geführten mit Visionen zu inspirieren und zu motivieren. Leadership schafft Kreativität, Innovation, Sinnerfüllung und Wandel.

Kurz gesagt: Ein Leader kann jeder sein! Es wäre doch toll, wenn von den Mitarbeitern, welche die Arbeit direkt ausführen, auch die Verbesserungsvorschläge kommen würden.

Kanban Praktiken

David Anderson beschreibt in seinem Buch „Kanban – Evolutionäres Change Management für IT-Organisationen“ die wichtigsten Kanban Praktiken:

  1. Visualisiere den Fluss der Arbeit (Workflow).
  2. Begrenze die Menge der begonnenen Arbeit (Work in Progress).
  3. Führe Messungen zum Fluss durch und kontrolliere ihn.
  4. Mach die Regeln für den Prozess explizit.
  5. Implementiere Feedback-Zyklen
  6. Verwende Modelle, um Chancen für Verbesserungen zu erkennen.

Der fünfte Punkt „Implementiere Feeback-Zyklen“ ist 2012 in Mayrhofen bei einer Konferenz hinzugekommen: Vortrag von David Anderson „How Deep is your Kanban“. Die PDF-Datei des Vortrags ist hier zu finden.

Zusammenfassung

Ich hoffe, ich konnte im ersten Teil meiner Artikelreihe grob erklären, was Kanban für Wissensarbeiter darstellt – was es ist, und was nicht. Ein Kanban Board alleine macht noch kein Kanban aus, dazu gehört mehr (z.B. WIP-Limits, Serviceklassen, Metriken, Exit-Kriterien).

In den nächsten Artikeln zu Kanban möchte ich über folgende Inhalte schreiben:

  • Organisation und Aufbau des Kanban Boards
  • Soll ich ein physikalisches Kanban Board verwenden oder lieber Software Kanban Board? Was ist, wenn die Teams örtlich verteilt sind? Welche Tools gibt es?
  • Wie starten wir mit Kanban?
  • Welche Service Klassen gibt es?
  • Begrenzung der angefangenen Arbeit mit WIP-Limits
  • Personal Kanban
  • Communitiy und Konferenzen rund um Kanban
  • Metriken wie z.B. WIP-Tracking mit dem Cumulative Flow Diagram, Durchlaufzeit, Termintreue, Durchsatz, Fehlerrate