„Ein Bild sagt mehr als tausend Worte“ heißt es in einem Sprichwort und die meisten werden mir zustimmen. Diejenigen, die nicht zustimmen würden, dürfen dennoch weiterlesen, möglicherweise ändert sich ab hier ihre Einstellung dazu 😉
Vor knapp einem halben Jahr habe ich zusammen mit den Kollegen ein Kanban-Board entwickelt, das den aktuellen Bedürfnissen der Firma entsprach.
Wow wo wow… Halt, was ist ein Kanban-Board?
Na gut, ich hole weiter aus…
Das Kanban-Prinzip
In meiner sehr frühen Vergangenheit als Student, habe ich von einem Produktionsprozess gehört, der von Toyota Anfang der 50er Jahre entwickelt wurde, um die Bestände innerhalb eines Produktionsprozesses zu reduzieren. Das hat viel mit „gebundenem Kapital“, „lean Production“ und anderem BWL-Zeugs zu tun. Das möchte ich hier jetzt nicht auswalzen.
Toyota beschreibt das Prinzip so, dass die einzelnen Fertigungsabschnitte ihre notwendigen Bestände abholt und nicht anliefern lässt, also ein Pull-Prinzip. So reduziert sich zwangsläufig die Durchlaufzeit innerhalb der Produktion und es werden die damals üblichen Staus in der Produktion vermieden.
Schon während des Studiums hatte ich das Gefühl, dass dies ein Prinzip sein könnte, um Software signifikant schneller entwickeln zu können. Noch grün hinter den Ohren und mit naivem Eifer, wendete ich dieses Prinzip bei der Erstellung meiner Diplomarbeit an (Oh Wunder, das Thema hat etwas mit Softwareentwicklung zu tun). Und siehe da, entgegen des damaligen Softwareentwicklungstrends, war ich früher fertig als geplant. (Toll, Schulterklopfen… Nun aber wieder zurück zum Thema bitte)
Kanban in der IT
Einige Jahre später stieß ich bei einer Recherche auf einen Artikel, ich weiß gar nicht mehr genau wo, in dem über einen Entwicklungsprozess geschrieben wurde, der das Kanban-Prinzip aufgriff und für die IT zurechtformulierte. Das ist nötig, da es ja in der IT nun mal keine „Lagerbestände“, sondern nur Code und Features gibt.
Ich war überaus begeistert davon zu lesen, dass Kanban Einzug in die IT hielt. Dummerweise sah ich dann das Datum des Artikels. Es war doch schon einiges vor meinem privaten Diplomexperiment. Ich war also nicht der Erste meiner Art, zu dumm, nichts zum Angeben.
Wiederum einige Zeit später, wurde ich von meinen Vorgesetzten gefragt, welchen Entwicklungsprozess ich verwenden würde um innerhalb der gegebenen Entwicklungsparameter einen besseren „Produktionsdurchsatz“ zu erzielen. Das war meine Stunde. Ich schlug sofort Kanban vor, weil ich wusste, dass dieser Prozess optimal für bestehende Entwicklungen, bei sog, brown fields, anzuwenden ist. Die Argumente gegen SCRUM waren schnell mit Hilfe der Präsentationen von it-agile gefunden und vorgetragen. Was nun noch fehlte, war das …
… Kanban-Board
Mit Hilfe diverser Kanban-Dokumentationen war schnell ein Board erstellt, das den ersten Ansprüchen genügen sollte. Wir nahmen uns vor, das Board und auch den Prozess im Laufe der Zeit zu verbessern. Glücklicherweise gibt es das Daily Meeting, sprich jeden Morgen Treffen vor dem Board, so dass die Optimierung binnen kürzester Zeit begann.
Daily Business
Zuerst brauchte man eine extra Bahn für das Daily Business. Ein Berich, in den die Bugs bzw Tickets zur laufenden Anwendung rein kamen. Damit sollte dokumentiert werden, wie anfällig oder auch wie sicher das System läuft. Außerdem konnte dann der Product Owner (PO) die aktuelle Auslastung des Teams sehen.
Testing
Auf dem klassischen Board findet man immer wieder die Spalte für den Entwicklungsschritt „Testen“. Da sieht man dann wie viele Tests gerade durchgeführt werden und welche davon erledigt sind. Das sah in unseren Augen aber eher nach unnützer Information aus, weil unsere Tests voll automatisiert durchgeführt werden. Selbst die Oberflächentests werden mit entsprechenden Frameworks automatisch durchgeführt. Somit sahen wir nicht mehr die Notwendigkeit eine solche Spalte aktiv zu führen. Der Sinn der Spalte „Test“ reduziert sich auf das geplante Prüfen der Features durch einen physischen Tester, der versuchen darf, das System zum Absturz zu bringen. Sprich er führt die sog. Smoketests durch.
Dokumentation am Board
Eines Tages, wir waren wieder in der Laune etwas zu verbessern, stellten wir uns die Frage, warum so viele kleine Zettelchen am Board hängen. Klar, weil viel zu erledigen ist, aber die Frage danach, wohin die Zettelchen gehörten, warf noch mehr Fragezeichen auf. Bis zu diesem Zeitpunkt versuchten wir immer eine imaginäre horizontale Linie als Grenze zwischen den User Stories zu sehen. Je mehr Tasks aus den User Stories purzelten, desto unübersichtlicher wurde das Board. Es war also nicht die Anzahl der Stories, die einen „Stau“ verursachten, sondern die Struktur des Boards sorgte für Missfallen. Eine Lösung musste her, die durch Zufall schon in meiner Hand lag.
Jedes Daily wird mit der Sichtung der Begleitpapiere eingeleitet. Darunter befinden sich u.A. die Modelle, Diagramme, Konzeptbeschreibungen usw. usf. „Warum nehmen wir nicht einfach diese Begleitpapiere, splitten sie in die User Stories auf und hängen diese direkt als ‚Story Bag‘ an das Board?“, war die Frage. Gefragt, getan. Der PO schnappt sich die Anforderungsanalyse, schneidet wie gewohnt die Stories heraus, modelliert die Anforderung und hängt sie, nachdem die Story gezogen wurde in die Linie des Work in Process (WIP). Die Modelle werden Teil der User Story, hängen als Dokumentationshilfe immer mit am Board und helfen so zum Verständnis beizutragen.
Sehr coole Sache, denn nun kann das Team die Story vom Board nehmen, die Tasks identifizieren und zusammen mit der Story wieder an das Board hängen. Abgearbeitete Tasks landen wie gewohnt im „Development-Done“, aber die Story selbst bleibt im „Develpoment-In Proc“. So kann man sehr schön verfolgen, wie sich die Anzahl der Tasks reduziert und damit die Sicht auf das Modell frei gibt.
Fazit 1
Egal wie gut der Prozess in den Büchern beschrieben ist, es gibt immer noch Möglichkeiten ihn für die eigenen Zwecke anzupassen. Das sollte man auch tun, denn zum Einen verbessert sich das Verständnis für den Prozess selbst und zum Zweiten entsteht eine Art persönlicher Bindung zum Prozess. Man identifiziert sich damit.
Fazit 2
Durch das dokumentieren der Story in Form eines Modells steigt bei jedem das Verständnis vom Gesamtsystem. Zudem können Querverweise in den Stories besser besprochen werden, wenn die Modelle mit am Board hängen.
~Jan