Schlagwort

toyotaproduktionssystem

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.

5.5.2005

Extreme Programming:
Auf ein Neues

InfoWeek 9/2005

von Frank Westphal und Tammo Freese
erschienen in der InfoWeek 09/2005

Vor noch fünf Jahren galten seine Ideen zur Softwareentwicklung als unglaublich extrem. Heute sind viele der Extreme Programming (XP) Praktiken akzeptiert. Mit einer von Grund auf neu geschriebenen, zweiten Auflage seines Bestsellers "Extreme Programming Explained" zeichnet Kent Beck ein aktuelles Bild: Die vielleicht effektivste und zugleich menschlichste Softwareentwicklungsmethodik ist gerade noch effektiver und menschlicher geworden.

Das neue Extreme Programming schlägt leisere Töne an. Die Kinderkrankheiten hat es hinter sich gebracht, es ist erwachsen geworden. Im Kern finden sich nach wie vor die vier groß geschriebenen Werte: Einfachheit, Kommunikation, Feedback und Mut. Schon seit frühesten Tagen lag XP als fünfter Wert Respekt zu Grunde, der in der neuen Fassung nun explizit seinen Einzug ins Wertesystem feiert.

Mehr pragmatisch und weniger dogmatisch

Die wohlbekannten XP-Praktiken sind aus den gesammelten Erfahrungen der vergangenen Jahre sowohl verbessert, vereinfacht und konkretisiert als auch verallgemeinert worden. Fanden sich im ursprünglichen XP nur ein Dutzend Praktiken, hat sich die Anzahl mit der Überarbeitung verdoppelt. Der Grund zur scheinbaren Zunahme der schlanken Methode ist, dass die Menge der Praktiken jetzt in Pflicht und Kür aufgeteilt ist: Während die primären Praktiken meist isoliert anwendbar sind und deshalb in jedem Prozess zu einer sofortigen Verbesserung führen können, setzen die weiterführenden Praktiken auf den Grundstock auf und führen den agilen Prozess schließlich an seine Leistungsgrenzen. Nichtzuletzt durch diese Abschwächung gelingt es dem runderneuerten XP, einerseits die Eingangsschwelle für jedermann zu senken und andererseits in Anwendungsbereiche vorzudringen, für die es initial nicht geeignet schien. Als Beispiele seien hier nur große und verteilte Projekte genannt.

Bei Programmierern beliebt

Vieles hat sich durch XP verändert: Einige XP-Praktiken werden mittlerweile im Studium vermittelt. Automatisiertes Testen ist zum festen Bestandteil der Entwicklungskultur geworden. Zur inkrementellen Verbesserung des Softwaredesigns stehen Entwicklungsumgebungen mit automatisierter Refactoringunterstützung zur Verfügung. Und Pair Programming wird heute viel einfacher akzeptiert. Während sich das leichtgewichtige XP bislang nicht gegen schwergewichtige Prozesse durchsetzen konnte, scheint es vor allem in kleineren Unternehmen Erfolg zu haben. Der Grund dafür ist sicherlich, dass dem vorherrschenden chaotischen "Code und Fix" Vorgehen vieler Softwareunternehmen mit XP's gesundem Menschenverstand schnell zu einem massiven Produktivitätsgewinn verholfen werden kann.

Im Management wenig Durchdringung

War XP auch die erste agile Methode, die von einer breiten Masse wahrgenommen wurde, steht ihr Bekanntheitsgrad in keinem Verhältnis zu ihrem Verbreitungsgrad. Ganz anders sah dies aus, als das erste Buch erschien. Zu Zeiten der Dotcom-Ära gedieh XP überaus prächtig, schließlich passte seine Philosophie hervorragend in die damalige Projektlandschaft von kleinen schnellen Teams in einer Welt mit sich rapide verändernden Anforderungen. Mit dieser Ära ging teils auch der für innovative, sich selbst organisierende Projektteams nötige kulturelle Nährboden verloren. Die Verbreitung von XP fand darin ihre organisatorischen Grenzen. Und während der Name gerade in Programmiererkreisen große Aufmerksamkeit erzeugte, stieß er im Management übel auf. Zudem war XP aus Sicht der Programmierer beschrieben, so dass die Änderungen in der Projektabwicklung aus Management- und Kundensicht nicht als Chancen, sondern lediglich als Risiken wahrgenommen wurden. Dieses Bild will mit dem neuen XP korrigiert werden. Denn mit seinem erweiterten Rollenmodell werden auch Nicht-Programmierer in das XP-Team eingebunden.

Lean Thinking

Auffällig ist, wie viele Anleihen aus dem Lean Manufacturing herausgearbeitet wurden. Gerade die Parallelen zum Toyota Produktionssystem, der Just in Time Fertigungsstrategie des führenden japanischen Autobauers, können ein Weg sein, den XP-Ideen im Management zu einer höheren Akzeptanz zu verhelfen. Über viele Jahre standen nur solche Fragen wie die Effizienz von Pair Programming, Testgetriebener Entwicklung oder eines Kunden vor Ort im Zentrum der Diskussion. Dabei bekäme es der weiteren Akzeptanz besser, würde sich die Aufmerksamkeit in heutigen Zeiten des Kostendrucks mehr auf übergeordnete Themen wie Wertschöpfungsketten, Return on Investment, Zero Defects und Time to Market verlagern. Denn durch die Einführung neuer Praktiken wie der Ursachenforschung zur Fehlerprävention sowie der Anwendung der Theory of Constraints zur Vermeidung von Flaschenhälsen gelingt es XP, die nötige, am japanischen Kaizen orientierte Philosophie der kontinuierlichen Prozessverbesserung zu etablieren. Wie weit man jedoch mit dem extremen Programmieren gehen will, bleibt insbesondere nach Aufweichung der Praktiken jedermann selbst überlassen. XP stellt in sich eh kein Ziel dar, sondern ist und bleibt ein Weg zur Verbesserung der Softwareentwicklung.