Herausforderung Brownfield, Teil 7: Veränderungen iterativ angehen

Inhaltsverzeichnis

In diesem siebten und letzten der Teil der Serie über die Herausforderungen in Brownfield-Projekten geht es um Hinweise, wie Software-Teams die Aufgaben angehen können. Das Etablieren von Selbstorganisationskreisen, regelmäßiges Üben und tägliche Reviews sind hierbei besonders hilfreich.

Wer schon mal versucht hat, sein Leben zu verändern, hat womöglich die Erfahrung gemacht, dass sich die Umsetzung deutlich schwieriger gestaltet als die dazugehörige Theorie. Die angestrebten Veränderungen sind oft so vielfältig, dass man meist nicht in der Lage ist, sie "in einem Rutsch" umzusetzen. Schlimmer noch: Mit jedem Versuch, solche umfangreichen Veränderungen einzuführen, erleben Menschen Frustration, und sie glauben am Ende vielleicht sogar, nicht dafür geschaffen zu sein. Mit üppigem Selbstvertrauen ausgestattete Menschen mögen sogar zu dem Schluss kommen, dass die angestrebte Veränderung unmöglich durchzuführen sei.

Mehr Infos

Herausforderung Brownfield

Im Rahmen einer Artikelserie beleuchten die Initiatoren der "Clean Code Developer"-Initiative, Stefan Lieser und Ralf Westphal, die Herausforderungen an Clean Code Developer in Brownfield-Projekten.

• Teil 1: Was sind die Probleme?
• Teil 2: Das Sicherheitsnetz aufspannen
• Teil 3: Das Sicherheitsnetz erweitern
• Teil 4: Komplexität bewältigen durch Partitionierung
• Teil 5: Explizite Architektur als Ziel für Refaktorisierungen
• Teil 6: Partitionen durch Refaktorisierung evolvierbar machen
• Teil 7: Alle Veränderung in kleinen Schritten durchführen

In einer ähnlichen Situation stecken Entwickler, wenn sie vor der Herausforderung stehen, ein Brownfield-Projekt zu retten. In den vorangegangenen Teilen der Serie haben die Autoren so viele Maßnahmen empfohlen, dass diese sich nicht in einem einzigen, großen Schritt umsetzen lassen. Schon die Einführung von Versionskontrolle, Continuous Integration und automatisiertem Testen stellt so hohe Anforderungen an den Veränderungsprozess, dass das nur in kleinen Schritten umzusetzen ist. Die Empfehlung lautet daher, die Veränderungen iterativ anzugehen.

Wiederkehrende Feedback-Runden

Im iterativen Vorgehen steckt jedoch mehr als das bloße Vorgehen in kleinen Schritten: Es geht darum, einen Feedback-Kreis zu schließen. Beispielhaft sei die Versionskontrolle herangezogen. Deren Einführung ist relativ einfach umzusetzen. Nach der Auswahl und der Installation eines konkreten Produkts wird allerdings häufig die Überprüfung vergessen, ob die gesetzten Ziele erreicht werden. Schließlich führt man eine Versionskontrolle nicht zum Selbstzweck ein. Wird über den tatsächlichen Zweck nicht reflektiert und die Einführung nicht bewertet, entstehen höchstens halbherzige Umsetzungen. Erst durch das Schließen des Kreises mit Feedback und Reflexion, besteht die Chance, zu wirklich guten Umsetzungen zu kommen.

Bevor man einen Veränderungsprozess beginnt, ist es nützlich, ein Modell davon zu entwickeln, wie Veränderungen vor sich gehen. Veränderungen beginnen mit einer Idee oder Hypothese. Irgendwer aus der Entwicklermannschaft wacht morgens auf und hat eine tolle Idee. Vielleicht denkt er, es wäre cool, eine Versionskontrolle einzuführen. Sein Vorhaben müssen dann die beteiligten Rollen diskutieren. Vielleicht gibt es Argumente, die dagegen sprechen. Vielleicht existieren aber auch andere Hypothesen. Wenn das Vorhaben als gut eingestuft wird, bleiben jedoch viele gute Ideen schon am Anfang stecken, da niemand ernsthaft mit der Umsetzung beginnt. Stattdessen hört man: "Ja, das müsste mal jemand machen."

Die Realisierung der Idee ist folglich der logische nächste Schritt. Da anfangs niemand weiß, ob die angedachte Form der Umsetzung tatsächlich erfolgreich sein wird, handelt es sich zunächst um ein Experiment. Das sollte allen Beteiligten klar sein, denn es impliziert die Möglichkeit des Scheiterns. Nicht jede diskutierte und für gut befundene Idee hält dem Realitätstest stand. Und manche Dinge kann man nicht durch noch so langes Diskutieren und Darübernachdenken herausfinden, sondern man muss es einfach ausprobieren. Daher ist jede Umsetzung zunächst nur ein Experiment, das darauf ausgelegt ist, eine Hypothese zu überprüfen. Lautet die Hypothese, dass der Einsatz einer Versionskontrolle die Nachvollziehbarkeit von Änderungen erleichtert, lässt sich letztlich nur durch das Experiment herausfinden, ob die Hypothese korrekt ist.

Um sicherzustellen, dass die ursprünglich mit der Idee verbundenen Erwartungen eintreten, muss man das Experiment auswerten. Auch dieser Schritt fällt häufig unter den Tisch. Es wird zwar eine Versionskontrolle eingesetzt, doch die praktische Arbeit damit ist so mühsam, dass am Ende nicht der volle, zu erwartende Nutzen realisiert wird. Statt darüber zu reflektieren, wird häufig jahrelang mit einem suboptimalen Produkt gelebt. Doch erst mit der Bewertung schließt sich der Kreis. Häufig entstehen aus der Bewertung neue Ideen oder Hypothesen. Es könnte beispielsweise sein, dass die Versionskontrolle die Arbeit im Home Office nicht gut unterstützt. Wird das im Rahmen der Reflexion thematisiert, lässt sich ein neues Experiment einleiten, das beispielsweise ein anderes Tool verwendet, um auszuwerten, ob damit die Heimarbeit besser unterstützt wird.