06. Jul 2021
Was Klemmbausteine mit der agilen Software-Entwicklung zu tun haben
In der Software-Entwicklung sind agile Prozesse und Methoden für viele bereits gang und gäbe. Aber auch in anderen Branchen macht die iterative und inkrementelle Vorgehensweise durchaus Sinn und selbst im Alltag stößt man manchmal auf Situationen, in denen das agile Vorgehen weiterhilft. So ging es vor Kurzem Christoph Geiser, Product Owner bei XITASO, beim Bauen eines Modells. Welche Vorteile das iterative und inkrementelle Vorgehen bietet und was das mit Klemmbausteinen zu tun hat, zeigt er im Folgenden.
Christoph Geiser
Product Owner
Vor Kurzem habe ich wieder mal ein Modell aus Bausteinen zusammengebaut. Auch mit Mitte 30 finde ich das immer noch faszinierend. Weniger, um damit zu spielen, als vielmehr, weil mich der Prozess des Aufbauens und das Erkunden der Funktionen eines Modells begeistern. Dieses Mal sollte es ein Konzertflügel werden.
Agiles Vorgehen – auch außerhalb der Software-Entwicklung
Beim Bauen bin ich in der Anleitung auf einen Abschnitt gestoßen, der mich an den agilen Entwicklungsprozess erinnert hat, den wir bei XITASO schätzen und jeden Tag aktiv leben.
In diesem Abschnitt werden die für die Funktion des Flügels notwendigen Hämmerchen gebaut. Beim Drücken der Tasten am Flügel werden dabei die Saiten des Instruments angeschlagen. Man muss nun also zwölf Hämmerchen bauen. Zwölfmal die exakt gleichen sechs Bauschritte.
Also habe ich mir überlegt, wie ich hier am besten vorgehe: Ich könnte alle Tasten parallel bauen. Also zuerst zwölfmal Schritt 1, dann zwölfmal Schritt 2 und so weiter. Nach Abschluss von Schritt 6 wären alle zwölf Hämmerchen komplett fertig und könnten eingebaut werden. Der andere Ansatz wäre, die Hämmerchen seriell zu bauen, sprich: Schritt 1 bis 6 nacheinander für je ein Hämmerchen umsetzen – und das Ganze zwölfmal.
Welche der beiden Varianten ist sinnvoller?
Um das herauszufinden, habe ich mir zuerst den Zeitaufwand vor Augen geführt und mich gefragt, ob ich bei einer der beiden Varianten schneller fertig bin. Eher nicht – der Aufwand ist in beiden Fällen der Gleiche.
Unterscheidet sich das Ergebnis bei den beiden Methoden? Auch das ist nicht der Fall, denn am Ende habe ich zwölf Hämmerchen in meiner Klaviatur, egal auf welche Weise ich diese baue. Oder doch nicht? Wenn man nämlich etwas genauer hinschaut, findet man tatsächlich einen Unterschied: Wenn ich alle zwölf Hämmerchen parallel baue, so stelle ich erst im Bauschritt 6 alle Teile fertig. Erst dann kann ich die Hämmerchen einsetzen und habe eine funktionierende Klaviatur.
Baue ich die Hämmerchen aber seriell, also eins nach dem anderen, so habe ich schnell das erste Hämmerchen fertiggestellt. Dieses kann ich direkt einbauen und habe so schon nach kurzer Zeit funktionsfähige Teile der Klaviatur. Es handelt sich also eigentlich um einen iterativen und inkrementellen Prozess.
Iteratives und inkrementelles Vorgehen
Und genau dieser Prozess ist es, mit dem wir in der agilen Softwareentwicklung schnell Ergebnisse erzielen: Wir modellieren und bauen Software so, dass wir schrittweise vorgehen und unseren Kunden nach jedem Schritt ein funktionsfähiges Produkt vorstellen können. Bei Bedarf gibt es dann noch weitere Iterationen.
Ein anderes oft verwendetes Bild für ebendiesen Prozess ist der Autobau. Mein Kollege Baptiste Grand, Agile Coach bei XITASO, erklärt im Rahmen unserer Webinar-Reihe „Agile Wednesday„, was es damit auf sich hat:
Sie sehen gerade einen Platzhalterinhalt von Youtube. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr InformationenDas Tolle daran: Nach jedem Zwischenschritt habe ich ein Produkt, das mein Ziel – nämlich den Transport von a nach b – bereits erfüllt. Genauso wie ich an meinem Flügel bereits frühzeitig die ersten Tasten nutzen kann. Das Bild zum Autobau stammt von Henrik Kniberg. Wer mehr über den Hintergrund wissen möchte, dem empfehle ich seinen Artikel „Making sense of MVP (Minimum Viable Product) – and why I prefer Earliest Testable/Usable/Lovable„.
Mein Fazit
Die agile Vorgehensweise hat viele Vorteile. Nicht nur für uns als Software-Entwickler*innen, sondern vor allem auch für unsere Kunden. Vielleicht kennen Sie es selbst: Was ist ärgerlicher, als ein Projekt in Auftrag zu geben und erst Monate später ein Ergebnis zu sehen. Im schlimmsten Fall ist das Produkt dann noch ganz anders als erwartet und hat möglicherweise Funktionen, die man gar nicht benötigt. Viel besser ist es also doch, schnell erste Ergebnisse zu sehen und ein Produkt schon früh selbst testen und benutzen zu können.
Das bietet außerdem den Vorteil, dass das Feedback durch den Kunden viel früher einbezogen werden kann. Denn wenn der Kunde das Produkt frühzeitig ausprobieren und benutzen kann, erkennt er rechtzeitig, ob der eingeschlagene Weg der richtige ist, oder ob Korrekturen notwendig sind. Es ist deutlich besser, wenn der Eisberg frühzeitig erkannt wird und eine Kursänderung noch möglich ist.
Seit dem Bau des Flügels habe ich bereits zwei weitere Sets aufgebaut. Und jedes Mal, wenn ich mehrere gleiche Elemente bauen soll, muss ich grinsen. Denn ich weiß genau, welches der effizientere Weg ist. Dass ich manchmal Elemente dennoch parallel baue, liegt einfach daran, dass es mir Spaß macht, das Gesamtwerk erst am Ende bewundern zu können.
