Evolution statt Verschlimmbesserung

Dr. Gernot Starke

„Änderung“ als Normalfall

Typische Softwareentwickler und –architekten verbringen wahrscheinlich einen Großteil Ihres Berufslebens mit Veränderungen bestehender Software: Erweitern, ändern, korrigieren oder „patchen“ – und das meistens unter Zeit- und/oder Budgetdruck. Wenn Teams nicht ausdrücklich in die Verbesserung innerer Qualität investieren, führen diese ständigen Veränderungen in der Praxis oftmals zu schleichendem Verfall – unsere Systeme degradieren ungewollt. Dadurch werden Änderungen einerseits immer schwieriger, andererseits auch immer teurer und riskanter.

Sie möchten solchen Verfall vermeiden und Ihre Systeme systematisch verbessern? Sie benötigen Überblick über die wirklichen Probleme Ihres Systems, möchten die Vielzahl potentieller Verbesserungen nachvollziehbar und verständlich priorisieren? Ausserdem möchten Sie noch das Management von der Nützlichkeit langfristig angelegter Verbesserungsmaßnahmen überzeugen, und unsere typischen IT-, Technik- und Programmierprobleme in allgemein verständliche Argumente übersetzen? Dazu stelle ich Ihnen eine Reihe etablierter Praktiken und Vorgehensmuster vor, basierend auf der (Open-Source) Methode „architecture improvement method“ aim42 [1].

Ziel von aim42 ist es, Software über lange Zeit änderungsfreundlich zu halten, und dafür zu sorgen, dass Erweiterungen und Anpassungen kostengünstig und risikoarm bleiben.

Inhärent iterativ

Eine Grundregel von aim42 lautet „Verbessere iterativ“. Dahinter steckt die Beobachtung, dass Verbesserung von Softwaresystemen in der Regel schwierig ist, und a priori nicht exakt planbar. Wir müssen ergo, völlig analog zur normalen Entwicklung, Verbesserung in kleinere Schritte zerlegen, und kontinuierlich Feedback über den Erfolg (oder Misserfolg) unserer einzelnen Verbesserungsmaßnahmen in unsere weitere Arbeit einfließen lassen.

Aim42 schlägt Iteration in drei Phasen (Analyze, Evaluate, Improve) vor, gestützt von einigen Querschnittsaufgaben (Crosscutting) – siehe Abbildung 1.

Die aim42-Phasen können Sie in Ihrem normalen Entwicklungsvorgehen nahtlos integrieren und mit Ihrem Tagesgeschäft (neudeutsch: der Feature-Entwicklung) verzahnen. Dazu enthält der „Crosscutting“-Teil von aim42 passende Planungs- und Managementpraktiken.

In den aim42-Phasen durchlaufen Sie iterativ immer wieder folgende Teilaufgaben:

1. Sie finden ein Problem oder dessen Ursache(n),
2. bewerten dieses Problem hinsichtlich seiner Kosten und
3. identifizieren Lösungsmaßnahmen dafür.
4. Sie verzahnen die Lösungsmaßnahmen mit Ihrem Tagesgeschäft, integrieren die Verbesserungsmaßnahmen somit in normale Entwicklungsaufgaben.
5. Sie wenden die Lösungsmaßnahme an und
6. analysieren ob das ursprüngliche Problem damit behoben ist.

Diese Schleife läuft in ähnlicher Form in jeglicher Art von Konstruktions- oder Optimierungsprozessen ab. Nach meiner Erfahrung kranken viele Systeme in der Praxis daran, dass die technisch Verantwortlichen vor der Bewertung der Kosten von Problem und Maßnahmen zurückschrecken. Stattdessen argumentieren sie über „Prinzipien der Softwaretechnik“ oder „technische Konzepte“ – und scheitern damit bei Management oder Auftraggebern.

Systematisch verbessern

„Verschlimmbesserung (Substantiv, feminin): Beabsichtigte Verbesserung, die real aber eine Verschlimmerung oder Verschlechterung einer Sache, eines Prozessen usw. bewirkt.“ Nach [2]

„Systematisch“ verwende ich als Gegensatz zu „ad-hoc“: Ich habe zu viele Situationen erlebt, in denen Teams ad-hoc und mit signifikantem Aufwand Teile eines Systems verbessert haben – ohne die vordringlichen oder wirtschaftlich relevanten Probleme dieses Systems überhaupt adressiert zu haben.

In aim42 sprechen wir von Issues. Das ist ein neutraler Oberbegriff für Probleme, Ursachen und Risiken. Issues verursachen bei betroffenen Stakeholdern jeweils eine Art „Schmerz“ – den wir in aim42 am liebsten in Geld ausdrücken. Sie können vereinfachend auch „Schlimmheit“ des jeweiligen Problems dazu sagen.

Jedes Issue können Sie durch eine oder mehrere Lösungsmaßnahmen (die wir in aim42 Improvements nennen) adressieren. Beachten Sie, dass Issues und Improvements in einer m:n Beziehung zueinander stehen: Ein Improvement adressiert ggfs. mehrere Issues – manchmal löst ein Issue ein Problem, schafft dabei aber gleichzeitig neue. Dieser schwierigen Beziehung zwischen Issues und Improvements widmet aim42 einen eigenen Abschnitt, die so genannten „Crosscutting activities“.

Bitte trennen Sie ganz deutlich zwischen den Issue-Kosten (der Höhe der „Schmerzen“, die durch ein Problem verursacht wird) und den Improvement-Kosten (die Aufwände oder Kosten die dieser konkreten Lösungsmaßnahme)

Nochmal in kurz: Probleme verursachen Kosten, Verbesserungsmaßnahmen auch.

Daher: Lösen Sie diejenigen Probleme oder Risiken, die wesentliche Stakeholder massiv behindern oder hohe Kosten verursachen - und nicht solche, deren Lösung dem Team aktuell gerade am besten in den Kram passt. Wenn der Schmerz nicht hoch genug ist, sollten Sie das betreffende Problem einfach akzeptieren. Vielleicht nicht schön, aber wirtschaftlich!

Neben diesen Kernbegriffen gehören zu aim42 noch einige fundamentale Regeln, die sozusagen das Manifest der systematischen Verbesserung von Software bilden:

• Trenne Problem von Lösung: Als Softwerker gehen wir meist zu schnell in den Lösungsmodus über: Angesichts eines Problems überlegen wir sofort, wie wir das lösen können. Ab dann sprechen wir primär über genau diesen Lösungsansatz, statt uns näher mit dem zugrundeliegenden Problem zu beschäftigen (ja, das hatte ich weiter oben bereits erwähnt – aber es ist so (!) wichtig, dass ich es absichtlich wiederhole).
• Entwickle mehrere (!) Lösungs- oder Handlungsalternativen zu jedem signifikanten Problem, damit wir breiteren Entscheidungsspielraum gewinnen.
• Löse nur solche Probleme, die sich lohnen. Entwicklungsteams haben in der Regel keine Zeit, alle Probleme zu lösen, oder sämtliche Aspekte eines Systems zu verbessern, sondern müssen sich aus Zeit- oder Budgetgründen auf einige wesentliche konzentrieren.
• Verwende betriebswirtschaftliche Kriterien zur Planung und Steuerung von Verbesserung.
• Explizites Feedback nach jedem Verbesserungsschritt: Wir müssen die Wirksamkeit von Verbesserungsmaßnahmen systematisch überprüfen. Einerseits benötigen wir als Entwicklungsteam diese Rückmeldung, um unsere Annahmen zu verifizieren, andererseits müssen wir andere Stakeholder von der Sinnhaftigkeit und Effektivität unserer Maßnahmen überzeugen.

So – jetzt haben Sie einen groben Überblick, und es wird Zeit für einige Details der aim42-Phasen. Ich beschränke mich hier auf Auszüge – die Online-Referenz [3] enthält mehr als 90 detaillierte Praktiken und Patterns.

Analyze: Bestandsaufnahme

„To effectively find issues, you need an appropriate amount of understanding of the system, its technical concepts, code structure, inner workings, major external interfaces and its development process.“ (nach [4])

Grundlage der systematischen Verbesserung sollte immer eine gründliche Bestandsaufnahme des Systems und der damit zusammenhängenden Prozesse (Entwicklung, Test, Betrieb etc.) bilden.

In dieser „Analyze“ Phase sammeln Sie, im Idealfall unterstützt von einem kleinen Verbesserungsteam, bekannte Probleme in Breitensuche: Dazu gehören beispielsweise Fehler im System, ungeeignete Technologien, überhöhte Kopplung, schlechte Schnittstellen oder sonstige Dinge. Andererseits gehören auch mangelnde Sicherheit, Stabilität, Performance oder fehlende Systemfunktionalität dazu, ebenso ungeeignete Betriebs- oder Entwicklungsprozesse. Einige weitere Praktiken finden Sie in Kasten “Beispiele von Praktiken der Analyze-Phase” aufgeführt.

Ein typischer Fehler von technik-orientierten Entwicklungsteams ist es, sich bei der Analyse rein auf Codeprobleme zu beziehen – weshalb in solchen Fällen oft wesentliche konzeptionelle oder strukturelle Probleme unerkannt und implizit bleiben.

Während der Suche nach Problemen tritt in der Analyze-Phase ein relevanter Nebeneffekt auf: Die Beteiligten finden intuitiv Lösungsansätze oder –ideen: Halten Sie diese Ansätze fest, sie bilden ein gutes Fundament für die spätere Improve-Phase.

Evaluate: Vergleichbar machen

Stellen Sie die Vergleichbarkeit von Problemen und Lösungsmaßnahmen sicher, indem Sie deren betriebswirtschaftliche Werte (etwa in Euro oder Aufwandsgrößen) schätzen oder ermitteln. Diese Schätzungen bilden die Grundlage betriebswirtschaftlich orientierter Priorisierung von Problemen und möglichen Verbesserungsmaßnahmen.

Falls Sie nun entsetzt anmerken, dass Sie doch auf Basis technischer Kriterien verbessern möchten, schlechte Kopplung oder fehlende Kohäsion auflösen, Modularität verbessern usw., dann möchte ich Sie an eine der Grundregeln von aim42 erinnern: Nur verbessern, was sich aus wirtschaftlichen Erwägungen her lohnt.

In der Evaluate-Phase müssen Sie also zwei Dinge schätzen:

• Die Kosten von Issues, also die „Schlimmheit“ oder „Schmerzkosten“
• Die Aufwände oder Kosten von Lösungsmaßnahmen.

Typischerweise bedeutet „Schätzen“ in der IT „Aufwandsschätzung“ – das ergänzt aim42 um die Abschätzung von Schmerz- oder Issue-Kosten. Treffen Sie solche Abschätzungen grundsätzlich als Intervallschätzungen – wobei die Breite der Intervalle die Größe Ihrer Unsicherheit ausdrückt.

In diesem Artikel möchte ich mich auf die Schätzung von Issue-Kosten („Schmerzkosten“) beschränken, da Sie Aufwandsschätzungen sicherlich aus Ihrem beruflichen Alltag ohnehin kennen. Finden Sie zuerst heraus, welche Faktoren dieses Problem beeinflussen, beispielsweise die Zahl der betroffenen Personen, die durch das Problem verlorene Zeit, oder der durch das Problem verursachte Mehraufwand. Ein kleines Beispiel finden Sie im zweiten Kasten Beispiele „Schätzung der Kosten eines Problems“.

Eine wichtige Praktik aus aim42 sind offen gelegte Annahmen (“Explicit Assumptions”). Nur explizite Annahmen bilden eine gute Grundlage für offene Kommunikation mit betroffenen Stakeholdern: Im Beispiel aus Kasten 2 könnten wir darüber diskutieren, ob wirklich alle Entwickler häufig den Build-Prozess starten, oder ob die Wartezeit in Wirklichkeit bei 10 statt bei 15 Minuten liegt.

Die Schätzungen von Issue-Kosten der Evaluate Phase dienen dazu, die erkannten Probleme ihrer Schwierigkeit, Wichtigkeit oder Schmerzen nach zu sortieren. Sie können dadurch die wirklich gravierenden Probleme explizit machen.

Querschnittliche Aufgaben

Nun haben Sie in der Analyze-Phase Probleme und Lösungsmöglichkeiten gesammelt und im Evaluate mit betriebswirtschaftlichen Einheiten abgeschätzt. In den Crosscutting-Aufgaben stellen Sie die Lösungsoptionen den Problemen gegenüber – regeln die m:n Beziehung zwischen Issues und Improvement-Möglichkeiten. Weiterhin koordinieren Sie die Verbesserungsmöglichkeiten mit ihrem Tagesgeschäft.

Improvement

Größere Umbaumaßnahmen an Ihrem System werden Sie langfristig angehen müssen. Diese strategischen Maßnahmen nennen wir in aim42 „approaches“. Kleinere oder kurzfristige Maßnahmen können Sie einfach mit der Feature-Entwicklung verzahnen, diese nennen wir „practices“. aim42 skizziert für beide Kategorien viele Möglichkeiten. Wesentlich ist auch in der Improve-Phase die Betrachtung in die Breite: Neben der Verbesserung in Code gehören auch Verbesserungen in Prozessen oder Technologien zu den relevanten Optionen!

In Kasten 3 (Langfristige Improvement-Ansätze aus aim42) finden Sie einige Möglichkeiten für langfristige Verbesserungsmaßnahmen. Den Zusammenhang zwischen approaches, practices und Ihrem Tagesgeschäft zeigt Abbildung 2.

Je nach ihrer Situation ändern und verbessern Sie Quellcode, Konzepte oder beteiligte Entwicklungs- oder Betriebsprozesse. Sie reduzieren technische Schulden und/oder optimieren Qualitätseigenschaften, beispielsweise Wartbarkeit, Verständlichkeit, Sicherheit oder Performance. Alle diese Verbesserungen beziehen sich dabei auf Probleme oder deren Ursachen, die Sie in der Analysephase erkannt und anschließend bewertet haben – so stellen Sie sicher, keine Veränderung um ihrer selbst Willen durchzuführen.

Solides Fundament

aim42 basiert einerseits auf vielen publizierten und etablierten Praktiken sowie der langjährigen Praxiserfahrung von rund einem Dutzend Committer aus unterschiedlichen Unternehmen und Branchen. In der Methodik stecken primär bewährte Ansätze aus unterschiedlichen Disziplinen des Software-Engineering, zusammengestellt und teilweise adaptiert mit dem Fokus auf „Verbesserung“.

Zugrunde liegt ein klares Begriffsmodell, das die Kernelemente jeglicher Verbesserungen systematisch definiert (Issue, Improvement und Cost haben Sie weiter oben bereits kennen gelernt), siehe Abbildung 3.

In vielfältigen Verbesserungs-, Evolutions- und Modernisierungsprojekten, angefangen bei Herstellern von Standardsoftware und Anbietern von Online-Diensten bis hin zu IT-Anwenderunternehmen aus Finanzwesen, Logistik, Automobilzulieferung, Maschinenbau, NGOs und Verbänden haben die aim42-Committer in zahlreichen Beratungsmandaten aim42 Ansätze erfolgreich eingesetzt.

Open-Source

aim42 wird in Open-Source Manier auf Github [3] gepflegt. Ziel ist es, eine umfassende Referenz über Praktiken und Patterns im Bereich Evolution, Wartung, Modernisierung und Verbesserung von Software zu erhalten – frei zugänglich, vollständig technologie- und herstellerneutral. Das aim42 Team freut sich über Vorschläge, Kritik oder Beiträge („pull requests welcome“), siehe [3]. Ich selbst betreibe unter [1] eine Website zum Einstieg.

Ausblick

aim42 lebt – ständig fließt neue Praxiserfahrung in die Methodik und die einzelnen Praktiken ein. In den letzten Monaten haben wir viel Aufwand in die Neustrukturierung der IMPROVE Phase investiert – und dort die Bereiche der mittel- und langfristigen Ansätze deutlich aufgeräumt.

Auch außerhalb des Open-Source Projektes hat aim42 viel Anklang gefunden – so bietet der iSAQB e.V. seit zwei Jahren eine Advanced-Ausbildung zu diesem Thema an, siehe [6] und [7]. Ihnen wünsche ich für Ihre eigenen Evolutions- und Modernisierungsprojekte viel Erfolg – möge die Macht der Verbesserung mit Ihnen sein.

Literatur & Links