Der Arbeitsplatz im B\u00fcro \u00e4hnelt manchmal einer papiernen W\u00fcste. Hier und da machen sich abstehende neon-gelbe Pappzettel bemerkbar. Sie wirken wie Oasen in der W\u00fcste und versuchen so die Unmenge an unterschiedlichen Aufgaben zusammenfassend darzustellen. In den meisten F\u00e4llen ist es wirkungslos, weil sie vom weiteren Papierstapel zugedeckt werden.<\/p>\n
Nicht so bei Kanban<\/a> – einem Vorgehen in der Softwareentwicklung, welches die kleinen Ged\u00e4chtnisst\u00fctzen als Medium in der Ticketverwaltung einsetzt. Diese gelben Zettelchen werden auf eine Tafel (sog. Whiteboard) geklebt und zeigen den Fortschritt des Projektes an.<\/p>\n Ein sch\u00f6nes Beispiel f\u00fcr diese Praxis<\/a> liefert stackoverflow. Eine wei\u00dfe Tafel ist aufgeteilt in Spalten: Backlock (Ideenpool), ’selected‘ (Vorauswahl – nicht unbedingt notwendig), Entwicklung (unterteilt in: ‚in Bearbeitung‘ und ‚fertig‘), Testen (mit \u00e4hnlicher Unterteilung wie Entwicklung) sowie Freischaltung. Die Anzahl und Namen der Spalten d\u00fcrfen ein wenig modifiziert werden, aber bleiben fast immer dazu vergleichbar.<\/p>\n Im Backlog stauen sich Ideen und Tickets. Hier werden sie auch meist vorsortiert und nach Priorit\u00e4t geordnet. Die Priorit\u00e4ten kommen meist auch in der Farbe der Zettel zum Ausdruck. Eine Farbe bekommt immer den Vorrang: sie signalisiert eine St\u00f6rung, die sofort beseitigt werden muss. (Auch Psychologen sagen: „St\u00f6rungen haben Vorrang“, weil sie eine normale Entwicklung verhindern.)<\/p>\n Die Tickets (zu erledigende Aufgaben, die aus mehreren Tasks bestehen k\u00f6nnen) werden von den Zust\u00e4ndigen „gezogen“ (das Pull-Prinzip). Jeder Zust\u00e4ndige oder jedes Team kann prinzipiell nur ein Ticket bearbeiten. Manchmal sind auch 2 m\u00f6glich. Diese Begrenzung, die auch f\u00fcr den Chef gilt, nennt sich: Work in Progress (WiP). Es ist somit nicht m\u00f6glich, einem bestimmten Angestellten unter Zwang etwas zuzuordnen oder mehr zuzuordnen als das WiP es erlaubt. Das sch\u00fctzt nicht nur ihn, sondern auch sein Kollegen, weil „gepushte“ Aufgaben oft zurecht von den Zust\u00e4ndigen als „f\u00fcr sp\u00e4ter“ zur\u00fcckgelassen wurden: sei es wegen Abh\u00e4ngigkeiten, aktueller Arbeitsbelastung oder mangelnder Reife eines Tickets. (Schnell unter Druck an Kollegen vorbei abgearbeitete Tickets sorgen oft f\u00fcr Fehler, Zerst\u00f6rung der gemeinsamen Wissensbasis und Stress.)<\/p>\n Das sch\u00f6ne ist, dass auch die Chefs (meist BWLer mit tausenden von innovativen Ideen) eine Spalte f\u00fcr ihre Ideen bekommen (wo die Tickets st\u00e4ndig ihre Priorit\u00e4t wechseln d\u00fcrfen) und eine, die f\u00fcr die Dauer der Ausgestaltung und zur genauen Beschreibung, wie es \u00fcberhaupt umgesetzt werden soll. Diese vorselektierten Beschreibungen des Was und der Wie wird zur Umsetzung von den Programmierern angenommen. Manchmal kann es sogar passieren, dass die Zettelchen zur\u00fcckwandern (weil zu ungenau). Bei gr\u00f6\u00dferen Vorhaben wird es intern wom\u00f6glich erst im gesamten Team besprochen und designed bevor auch eine Zeile Code entsteht. Erst, wenn man glaubt, alles erledigt zu haben, schiebt man es zu „fertig“. Der Tester nimmt es an und erkennt m\u00f6glicherweise M\u00e4ngel. Der Schwarze Peter muss nun zur\u00fcck – aus diesem Grund sollte man auch nicht mehr als ein Ticket annehmen (wegen des m\u00f6glichen R\u00fccklaufs).<\/p>\n Was ist der Vorteil von dem Ganzen?<\/p>\n Wo sind die Schwachstellen?<\/p>\n Ich finde, es ist eine genial-einfache Idee, die man ausprobieren sollte. Es ist nicht starr und gut anpassbar in vielen Bereichen.<\/p>\n Eine Liste von Software f\u00fcr Kanban finden sie hier<\/a>.<\/p>\n\n
\n