Agile Softwareentwicklung: Software wachsen lassen statt sie zu bauen

Der Ausdruck „Software erstellen“ bzw. „bauen“ taucht häufig im Zusammenhang mit Tools wie Compilern oder Continuous-Delivery-Chains auf. Bei diesen Werkzeugen liegt das Hauptaugenmerk auf der Reproduzierbarkeit. Wenn alle Dinge gleich bleiben, müssen sie immer das gleiche Ergebnis hervorbringen. Wir sprechen von einer Software-Factory. Allerdings geht es beim „Bauen“ von Software eher um die Tools als um den Entwicklungsprozess selbst. Der Entwicklungsprozess kann auch als „Architekturarbeit“ oder „Softwaredesign“ bezeichnet werden. In diesem Fall weist der Prozess mehr Ähnlichkeit mit dem Wachstum einer Pflanze als mit dem Bau eines Hauses auf.

Das Konzept des „Erbauens“ von Software deckt sich sehr gut mit dem linearen Wasserfallmodell:

• Das Endergebnis und die Bauweise stehen von Anfang an fest.
• Alle Schritte und Komponenten werden nacheinander ausgeführt, die Integration erfolgt zum Schluss.

Dieses Vorgehen ist erfolgreich, weil das Thema bekannt und sehr gut reproduzierbar ist.

Andererseits erfordert Software in der Regel ein agiles oder zumindest inkrementelles, iteratives Vorgehen. In diesem Fall passt die Vorstellung, Software „wachsen“ zu lassen, viel besser:

• Es gibt kein vordefiniertes Endprodukt, da die Software während der Entwicklung angepasst wird.
• Es wird so früh wie möglich ein lauffähiges Produkt entwickelt, um die Feedback-Schleife in Gang zu setzen.

Dieses Vorgehen ist erfolgreich, weil das Endergebnis kontinuierlich angepasst und optimiert wird.

Bauen versus wachsen: Eine Einstellungssache

Im Alltag stellt sich häufig die Frage nach dem Blickwinkel. Im vorliegenden Fall unterscheidet sich der Blickwinkel zwischen Bauen und Wachsenlassen stark. Dieser grundlegende Unterschied spiegelt sich in mehreren Rollen wider.

Der Entwickler

Der Entwickler fördert die Entstehung einer Architektur, die sich mit der Zeit weiterentwickeln kann und bei Bedarf Anpassungen zulässt, statt vordefinierte Projektanforderungen erfüllen zu müssen.

Aus diesem Grund richtet sich der Entwickler nach Grundprinzipien wie „YAGNI“ („You Aren’t Gonna Need It“, zu Deutsch: „Du wirst es nicht brauchen“). Dabei wird nur das absolute Minimum dessen entwickelt, das heute an Anforderungen bekannt ist. Ein weiteres Prinzip ist das Konzept des „Emergent Design“. Dabei wird nicht von vornherein antizipiert, wie die Architektur aussehen könnte, sondern man lässt diese mit der Zeit durch sich herausbildende Lösungen entstehen.

Einfach gesagt ist die oberste Priorität, den Code im Laufe der Zeit nach und nach anpassen zu können. Es macht keinen Sinn, überall im Code Extention-Points vorzusehen (YAGNI!), wenn man bei künftigen Änderungsanforderungen die entsprechenden Code-Stellen auch ersetzen könnte.

Radikale und häufige Richtungswechsel können so berücksichtigt werden, ohne für den Entwickler zum Alptraum zu werden. Es wird alles getan, damit das Team auf sich verändernde Anforderungen reagieren kann.

Entdecke außerdem meinen anderen Blog-Artikel: Erfolgreiche digitale Produkte dank Lean Startup & Experimentieren

Durch den Ansatz des „Wachsenlassens“ fördert der Entwickler die Entstehung einer Architektur, die sich mit der Zeit weiterentwickeln kann und bei Bedarf Anpassungen zulässt.

Der Product Owner / Product Manager

Auf die gleiche Weise passt der Product Owner (oder Product Manager je nach Unternehmen) seine Arbeitsweise an. Anstatt schon zu Projektbeginn eine ideale, hypothetische Lösung im Kopf zu haben, implementiert er die einfachst mögliche Lösung, die funktioniert, und führt dann auf Basis kontinuierlicher User-Feedbacks Iterationen durch. Täglich implementiert der Product Owner / Product Manager die kleinstmöglichen Features und testet sie, bevor er sie weiterentwickelt bzw. „wachsen lässt“. Die Devise lautet „Du weißt nichts“, denn letztendlich zählt nur die Wahrheit der User. Das Team muss diese so schnell wie möglich erreichen – wie ein Samen die Sonne – um möglichst zügig Rückmeldung zu erhalten, welche die Software besser macht und ihr hilft zu wachsen. Ohne Anwender-Feedback arbeitet man in einem Vakuum und investiert womöglich seine begrenzt verfügbare Energie in etwas, das sich am Ende als sinnlos erweist.

Stetige Anpassung statt starrer Richtung

Software wachsen zu lassen bedeutet letztendlich, den Entwicklungsprozess an seine vielseitige, flexible und einfach zu aktualisierende Wesensart anzugleichen. Diese Denkweise ist essentiell und findet sich in jeder Rolle wieder. Statt von Anfang an alle Parameter zu definieren, fördern wir die Weiterentwicklung. Wie lässt sich das in der Praxis umsetzen? Das beschreibe in meinem zweiten Artikel, in dem es um die konkrete Realisierung in deinen Projekten geht.

Wie macht man das in der Praxis? Der nächste Artikel wird sich mehr auf die konkrete Umsetzung in Ihren Projekten und Produkten konzentrieren.