Best Practices fürs Software-Projektmanagement Arbeit mit dem Kanban Board in der Praxis

Kanban ist heutzutage in aller Munde, wenn es um Software-Entwicklung geht – dabei stammt das Prinzip bereits aus den 1940ern vom Automobilkonzern Toyota. Aber wie funktioniert Kanban und was sollte man in der Praxis beachten?

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

Ganz kurz gesagt ist Kanban ein Projektmanagement-Werkzeug, mit dem sich einerseits die Arbeit eines Teams visualisieren und andererseits organisieren sowie optimieren lässt. Natürlich fällt auch das in den Bereich der agilen Methoden und Schlagwörter wie Scrum sind meist nicht weit entfernt. Das Schöne an Kanban: Man kann ganz klein damit anfangen, braucht weder wochenlange Schulungen noch spezielle Kanban-Moderatoren.

Im Grunde genügen für den Anfang ein Whiteboard und die Möglichkeit, sich mit den anderen Teammitgliedern zu treffen. Natürlich funktioniert Kanban auch komplett virtuell mit entsprechenden Software-Tools, etwa der Open-Source-Lösung Kanboard. Aber als erstes Best Practice können Sie sich schon mal das persönliche Meeting notieren.

Kanban lässt sich grob mit „Per Karte dargestellt“ übersetzen. Und diese Kärtchen landen auf dem Mittelpunkt des ganzen Systems, dem Kanban-Board. Zunächst einmal eine ganz simple Übersicht: Auf dem Kanban-Board finden sich die unterschiedlichen Prozessphasen, Stages genannt, von links nach rechts in Spalten sortiert. Die einzelnen Aufgaben, die die Mitarbeiter erledigen, landen als Kärtchen auf diesem Board und wandern von links nach rechts durch den Prozess.

Somit kann jeder jederzeit sehen, welche Arbeiten wo und von wem bearbeitet werden oder wurden – womit der Punkt Visualisierung der Arbeit bereits erledigt ist. Das eigentlich Besondere an Kanban ist aber, dass es ein Pull-System ist: Normalerweise formuliert beispielsweise in einem ersten Prozessschritt ein Designer eine ganze Reihe an Features, die dann als Arbeitspakete weitergereicht werden – die Aufgaben werden zum nächsten Mitarbeiter gepushed. Wer kennt ihn nicht, den großen Aktenstapel, der abgearbeitet werden will – deprimierend, oder nicht?

Bei Kanban zäumt man das Pferd von hinten auf – dazu erst mal eine kleine Analogie vom Kanban-Erfinder Toyota: Ein Supermarktkunde wird vom Markt nicht einfach pauschal mit 20 Einkaufswagen Lebensmitteln überschüttet. Vielmehr geht der Kunde in den Markt und nimmt exakt das mit, was er bis zu seinem nächsten Besuch verbrauchen will. Und der Supermarkt wiederum bestellt die Warenmengen nach, die bis zum Eingang der Lieferung gekauft werden. Letztlich bestimmt also der Kunde, wie sich der Prozess gestaltet – obwohl er traditionell am Ende der Kette steht.

Nun lassen sich Kunde und Markt als Prozess und vorheriger Prozess betrachten und auf die Software-Entwicklung mappen: Im obigen Beispiel würde sich der Mitarbeiter lediglich die Akten abholen, die er auch sinnvoll gleichzeitig bearbeiten kann. Abholen könnte er sich alle Aufgaben, die vom Vorprozess als „fertig“ gekennzeichnet wurden. Das verhindert den deprimierenden Aktenstapel und ermöglicht anderen Mitarbeitern, sich an dem Stapel zu bedienen. Bestenfalls sorgt diese Art der Arbeitsteilung für schnellere Durchlaufzeiten und bessere Qualität einzelner Akten – und letztlich zu einer organisatorischen Entlastung für einzelne Mitarbeiter.

Kanban in der Praxis

Nun zeigen wir Ihnen erst den typischen Aufbau des Kanban-Prozesses in der Software-Entwicklung und geben anschließend ein paar Tipps zur Umsetzung der einzelnen Schritte.

In einem ersten Schritt visualisieren Sie am Board den Workflow Ihrer Entwicklung, und zwar eher grob, also beispielsweise User Experience/Design, Implementierung, Review, Delivery. Insbesondere bei der großen Stage Implementierung lässt sich natürlich noch weiter untergliedern. In einem kleineren (etwa persönlichem) Maßstab, könnte ein Kanban-Board auch die ziemlich allgemeingültigen Stages Pending, To-Do, Doing, Done beinhalten. Und die einzelnen Arbeitspakete fließen dann durch diese Phasen.

Weiters sollten Sie die akute Arbeitsbelastung beschränken. In der Kanban-Welt spricht man hier meist von Work in Progress, kurz WIP. Ein WIP-Limit legt fest, wie viel Arbeit in einer Stage gleichzeitig vorhanden sein darf, sprich wie viele Kanban-Karten letztlich gleichzeitig in einer Spalte auf dem Board Platz finden. Beispielsweise könnten Sie die Anzahl zu behebender Bugs entsprechend der Menge der Mitarbeiter begrenzen – so sorgen Sie für einen gewissen Qualitätslevel.

Auch im nächsten Schritt steht die Qualität im Vordergrund: Für jede Stage definieren Sie genau, welche Aspekte eines Arbeitspakets erledigt sein müssen, bevor es in diese Phase eintreten darf. Das könnte beispielsweise eine simple Checkliste sein, um etwa ein fertiggestelltes Feature in die Review-Phase zu entlassen: Linux-Test, Windows-Test, OSX-Test, Android-Test, iOS-Test.

(ID:45378566)