Die Ursprünge des Lean-Denkens liegen in der Produktion und es gibt ein großes Interesse daran, Parallelen zwischen den aktuellen Praktiken der Softwareentwicklung und denen der Produktion zu finden. Die Poppendiecks zum Beispiel zitieren häufig Beispiele klassischer Fertigungsunternehmen (Ford, GM, Dell, Toyota), um zu verstehen, warum agile Methoden ein sehr effektiver Ansatz für die Softwareentwicklung sind. Seltsamerweise zögern sie (und viele, viele andere), sich voll und ganz auf das Konzept einzulassen, dass die Fertigungsindustrie und die Softwareentwicklung tatsächlich viele Gemeinsamkeiten haben.
In ihrem Buch "Lean Software Development: An Agile Toolkit" heißt es:
"Die Praktiken der schlanken Produktion, d.h. spezifische Richtlinien für die Vorgehensweise, lassen sich jedoch nicht direkt von einer Fertigungsanlage auf die Softwareentwicklung übertragen. Viele Versuche, schlanke Produktionsverfahren auf die Softwareentwicklung anzuwenden, waren erfolglos, weil die Erstellung guter Software kein Produktionsprozess ist, sondern ein Entwicklungsprozess.
Entwicklung ist etwas ganz anderes als Produktion. Stellen Sie sich die Entwicklung als das Erstellen eines Rezepts und die Produktion als das Befolgen des Rezepts vor. Es handelt sich um sehr unterschiedliche Aktivitäten, die mit unterschiedlichen Ansätzen durchgeführt werden sollten. Die Entwicklung eines Rezepts ist ein Lernprozess, bei dem es um Versuch und Irrtum geht. Sie würden nicht erwarten, dass der erste Versuch eines Profikochs mit einem neuen Gericht der letzte Versuch ist. Der Grundgedanke bei der Entwicklung eines Rezepts besteht darin, viele Variationen eines Themas auszuprobieren und das beste Gericht zu finden.Sobald ein Koch ein Rezept entwickelt hat, bedeutet die Zubereitung des Gerichts, dass er das Rezept befolgt. Dies ist vergleichbar mit der Herstellung, bei der das Ziel darin besteht, ein "Rezept" mit einem Minimum an Variationen getreu und wiederholt zu reproduzieren.
Nun, Tom und Mary, erlauben Sie mir, Ihnen zu widersprechen! Der Hauptzweck des modernen Fließbands besteht nicht darin, Massen von ein und derselben Ware "mit einem Minimum an Abweichungen" zu produzieren. Bei den Automobilherstellern ist dies sogar so weit von der Wahrheit entfernt, wie es nur geht. Die Mercedes-Benz Fließbänder in Sindelfingen bei Stuttgart zum Beispiel produzieren Hunderttausende von Varianten der C-, E- und S-Klasse. Allein bei der E-Klasse gibt es etwa 8.000 Cockpitvarianten und 10.000 Sitzvarianten; es gibt mit ziemlicher Sicherheit keine zwei identischen Autos, die am selben Tag vom Band rollen. Was damit beginnt, dass ich (wenn ich ein Mann des dreizackigen Sterns wäre) ein Auto im Autohaus bestelle, führt zu einem enormen logistischen und organisatorischen Aufwand, um die richtigen Komponenten am richtigen Ort und zur richtigen Zeit am Fließband verfügbar zu haben (wobei die Zulieferer die richtigen Teile zur richtigen Zeit liefern, um die Lagerkosten zu minimieren). Heben Sie die Hand, wenn dies Ihrer Vorstellung von einem "Rezept mit einem Minimum an Variationen" entspricht.
Die Softwareentwicklung hinkt in ihrem Reifegrad mehr als ein Jahrhundert hinter der Fertigung hinterher; sie gleicht eher einem Handwerksbetrieb, der einmalige Lösungen herstellt, als einem richtigen Ingenieurbüro. Die derzeitige Praxis des komponentenbasierten Software-Engineerings läuft darauf hinaus, nur die Einzelteile zu beschaffen, die für den Zusammenbau eines einzigen Autos erforderlich sind. Einige dieser Teile passen nicht perfekt, und es ist einiges an Schneiden und Feilen erforderlich, um sie passend zu machen (d.h. anzupassen), und einige Teile wurden speziell für dieses eine Auto entwickelt. Und selbst wenn eine Bibliothek mit elementaren, passgenauen Komponenten vorhanden ist ("kein Zuschneiden und Feilen erforderlich"), müssen diese immer noch von Hand zusammengebaut werden und es gibt immer noch eine Menge Details, die dabei berücksichtigt werden müssen.
Vergleichen Sie dies mit der Bestellung eines Autos von der Stange, indem Sie es in abstrakten, lösungsorientierten Begriffen beschreiben und nur so viel angeben, wie wirklich benötigt wird: "Besorgen Sie mir einen SLK 55 AMG, mit 18-Zoll-Rädern und verchromten Außenspiegelgehäusen." Und das ist es, was ich mir als Programmierer wünsche: in abstrakten, lösungsorientierten Begriffen zu sagen, was ich will, und das gewünschte System oder die gewünschte Komponente automatisiert produzieren zu lassen.
Wenn das alles zu magisch klingt, handelt es sich in Wirklichkeit um ein Paradigma für die Softwareentwicklung, das auf (i) der Entwicklung von Implementierungskomponenten für eine gemeinsame Architektur, (ii) dem Konfigurationswissen, das abstrakte Anforderungen mit spezifischen Konstellationen solcher Komponenten verknüpft, und (iii) der automatisierten Implementierung dieses Konfigurationswissens basiert. Diese Schritte sind auch im Automobilbau zu beobachten: Das Prinzip der austauschbaren Teile (Hall, 1826) führte zur Einführung des Fließbands (Olds 1901 und verfeinert durch Ford 1913) und zur Automatisierung durch Industrieroboter in den 1980er Jahren.
Wenn Sie noch nicht überzeugt sind, lassen Sie mich mit dem unvermeidlichen Verweis auf Ruby on Rails schließen. Es ist zwar nicht auf dem Niveau einer echten Fertigung, aber auch hier gibt es eine Möglichkeit, ein System ('Familienmitglied') in Form von Konstrukten einer höheren Abstraktionsebene ('has_many', 'validates_presence_of'), einer Reihe von Implementierungskomponenten ('ApplicationController') und Generatoren zu spezifizieren, um alles miteinander zu verbinden ('./script/generate'). Und Junge, das funktioniert. Wunderbar. Stellen Sie sich nur vor, wie der nächste Schritt aussehen wird!
