Kanban 1: Warum Kanban für die Softwareentwicklung total sinnvoll ist

Dieser Artikel stammt aus unserem Blog, der nicht mehr betreut wird. Für Neuigkeiten zu oose und interessante Inhalte zu unseren Themen, folgt uns gerne auf LinkedIn.

1. Die Softwareentwicklung hat mittlerweilen begriffen, das Softwareentwicklung nicht alleine ein kreativer Prozess ist, sondern aus einer Reihe systematischer Schritte besteht (z.B. Requirements-Engineering, Testentwurf, Architktur, Realisierung). Kreative Prozesse brauchen als Rahmenbedingungen ein fundiertes Management des Prozesses sowie eine konsequente Zielorientierung (siehe z.B. John Martin, Managing Problems Creatively). Der Kanban-Ansatz biete genauso so ein Management-Ansatz zur Prozesssteuerung. Daraus ergibt sich keine Einschränkung für die Art der zu bearbeitenden Inhalte, der Ansatz trägt lediglich dem Umstand Rechung, dass die Verarbeitungsressourcen (bei der SWE sind das die Teammitglieder) eine beschränkte Ressource sind. Es geht also primär um das Management der Auslastung der Teammitarbeiter und nicht um die Frage, was genau diese tun.
2. Kanban gesteuerte Systeme unterstützen Änderungen am Produkt während des Produktionsprozess, da Entscheidungen spätmöglichst getroffen werden können, ohne, dass aufwändige Umplanungen nötig werden oder übermäßige Lager/Abfälle entstehen. Änderungen werden also wirtschaftlich möglich. Amazon kann dank Kanban noch bis kurz vor Versand Aufträge ändern lassen.
3. In der Softwareentwicklung werden zwar keine physischen Gegenstände bewegt, aber nicht in das Produkt integrierte Anforderungen, Frameworks etc. erzeugen einen hohen Aufwand in der Verwaltung. Dabei ist nicht die Verwaltung auf einem Rechnersystem relevant, sondern der Aufwand der entsteht, diese Informationen bis zum Einsatz zu bewerten sowie aktuell und konsistent zu halten. Ist im Fall physischer Artefakte in der Produktionsindustrie der gebunde Produktwert (Material + Arbeistleistung) sowie der Lagerraum teuer, ist es bei der Softwareentwicklung der gebunde Produktwert (Erstellungsaufwand, kombiniert mit relativ zügiger Alterung) sowie der Verwaltungsaufwand (Bewertung, Filtererstellung, Konsistenzsicherung). Es macht also auch in der Softwareentwicklung Sinn, möglichst nur nach Bedarf zu produzieren.
4. Auch in der Softwareentwicklung gibt es viele Aktivitäten die immer wieder und in gleichen Abläufen erfolgen (Erstellung von Dialogen, Realisierung von Datenverarbeitung etc.). Selbst in der Produktion von Autos wird die Verbindung zweier Teile nicht neu erfunden, sondern gibt es z.B. Schrauben, die das immer wieder gut lösen. Es ist ein alter Hut, das die Entwicklung von Frameworks vom Bedarf der Produktion getriggert werden sollte, in dem Moment wo das Wissen über den konkreten Bedarf da ist. Anders ausgedrückt, es braucht Kanban-Token für Frameworks.
5. Fließfertigung mit strenger Taktung ist ein merkmal heutiger agiler Vorgehensmodelle (wie z.B. APM). Kanban-geregelte Systeme berücksichtigen, dass die Entwicklungsgeschwindigeiten varieren, es Störungen gibt und daher eine Vorausplanung nur begrenzt Bestand hat. Iterative Umplanung ist da nur ein Kompromiss. Die Regelung eines Systems mit Kanban ermöglicht ein System auf unvorhergesehene Ereignisse zu reagieren ohne Ressourcen unnötig zu belegen. Projekte werden mit Kanban im wahren Sinne agil.

Auch Kanban-Systeme enthalten geplante lokale Ineffizenz. Critical-Chain scheint mir aber nützlich bei der Betrachtung von "Einmallieferungen" (sprich sowas wie komplette Teilsystemzulieferungen oder ähnliches).
Abschließend kann ich aus eigener Erfahrung sagen, dass komplexe Systeme dazu tendieren sich wie Kanban gesteuert zu verhalten. Als Regelungsansatz wird das genutzt, um diesen Mechanismus explizit zu machen. Ich denke es steckt eine Menge nützlicher Ideen in der Diskussion (insbesondere wenn ich davon ausgehe, dass ich nicht einfach Universalressourcen habe).

Und ich denke es braucht noch viel mehr als nur Kanban im Projekt.
Jan Gentsch

 

Teil 2: Warum Kanban für Softwareentwicklung Quatsch ist