9.12.2004

Toyota als Leitbild
für die Softwareentwicklung

Diese Woche auf SPIEGEL ONLINE gelesen: Jürgen Stockmar, Ex-Vorstandsmitglied von Opel, über die Probleme der deutschen Automobilindustrie. Ein erstaunlicher Artikel, der uns vor Augen hält, was der Softwarebranche unmittelbar bevorsteht.

Blinker links: Toyota rollt an die Spitze

Was spielt sich gerade im Automobilbau ab? Toyota steigt mit einem unaufhaltsamen Tempo zum Automobilhersteller Nummer eins auf. Und das nicht allein, weil sie bei den heute aktuellen Technologien führen. Aus dem SPIEGEL-Interview erfahren wir, dass der japanische Autobauer selbst bei Zukunftsthemen wie der Brennstoffzelle die Nase vorn hat und die Technologie bereits fast vollständig mit Patenten besetzt hätte.

Ihren Vorsprung verdanken die Japaner dem legendären Toyota Produktionssystem. Ursprünglich zu Krisenzeiten entwickelt, folgt Toyota hier dem Prinzip einer inszenierten Dauerkrise:

  • Just-in-Time Produktion. Es wird nur das gefertigt, was benötigt wird, wenn es benötigt wird und in der Menge, in der es benötigt wird.
  • Ständige Verbesserung (Kaizen). Es gibt stets noch etwas zu verbessern.

Die Qualitätsstatistiken geben dem Autobauer Recht. Toyota ist die ungeschlagene Nummer eins bei der Kundenzufriedenheit und der überaus erfolgreiche Beweis dafür, dass sich Qualität und Produktivität nicht gegenseitig im Weg stehen.

Just-in-Time in der Softwareentwicklung

Was können wir Softwerker daraus lernen? Schon heute zeichnet sich bei uns eine ähnliche Kluft ab: Auf der einen Seite gibt es die Entwicklungsteams, die eine Änderung an ihrer Software machen, alles neu bauen, das System deployen, die Anwendung starten, sich durch ein paar Bildschirmmasken hangeln und einige Mausklicks und Eingaben probieren, um dann etwa im Server-Logfile nachzuschauen, ob System.out.println() oder Log4J die erwarteten Werte ausspuckt. Im besten Fall verbringt man ein Gros seiner Zeit im Debugger. Reine Verschwendung.

Während es auf der anderen Seite die Teams gibt, die eine Änderung machen, nur die abhängigen Klassen neu bauen und ihre Suite automatisierter Tests starten, um binnen Sekunden zu wissen, ob ihr Code noch wie erwartet funktioniert. Ich habe Projekte besucht, wo Entwickler im ersten Fall wirklich nur drei Änderungen pro Stunde machen konnten, weil allein der Application Server mehrere Minuten benötigte, um seinen fetten Hintern hochzubekommen. Die Projekte, die im Gegensatz dazu 20 oder mehr Änderungen pro Stunde und auch größere Umstellungen machen können, stehen im klaren Vorteil.

Noch interessanter wird es, wenn wir uns die Effekte zweiter Ordnung vergegenwärtigen: Im ersten Fall sind Test und Integration einfach nur mühsam. Was in der Praxis natürlich dazu führt, dass man versucht Zeit zu sparen, indem man noch weniger häufig testet und integriert. Was wiederum zur Folge hat, dass die Aufwände weiter ansteigen. Eine Teufelsspirale. Man fühlt sich dabei unweigerlich an die Lagerhaltung bei Massenproduktion erinnert. Es werden große Stapel unfertiger Software aufgehäuft. Software-in-Process, die noch nicht in Produktion gehen und damit auch kein Geld erwirtschaften kann, weil sie noch getestet, integriert, qualitätsgesichert oder dokumentiert werden muss. Solche Software ist totes Kapital.

Im zweiten Fall können wir die Cycle Time von dem Zeitpunkt, wenn eine neue Anforderung geplant ist, bis zu dem Zeitpunkt, wenn das neue Feature in Produktion gehen kann, von Monaten und Wochen auf Tage und Stunden reduzieren. Zum Beispiel durch Testgetriebene Entwicklung und ganz entsprechend der Just-in-Time Produktion im Automobilbau. Solche Software bildet eine Option, mit der wir schon frühzeitig Einnahmen erzielen können. Im Idealfall kann sich die Entwicklung auf diese Weise sogar selbstfinanzieren. In jedem Fall lässt sich viel früher das für die Weiterentwicklung so kostbare Anwenderfeedback einholen.

Ich bin davon überzeugt, dass Just-in-Time Entwicklung zukünftig eine noch bedeutendere Rolle spielen wird. Die Frage, wer Software wertschöpfend entwickeln kann und wer nicht, wird dann vielleicht entscheiden, wer den Anschluss behält und wessen Jobs gen Osten wandern.

Schlagwörter:

blättern: RSS-Newsfeed erhältlich
zurück: Testgetriebene Entwicklung

Verwandte Seiten