„Ä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.

Abbildung 1: 3+1 Phasen von aim42
Abbildung 1: 3+1 Phasen von aim42

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:

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.

Textkasten 1: Beispiele von Praktiken der Analyze-Phase

Beispiele von Praktiken der Analyze-Phase

  • Stakeholder-Map
  • Stakeholder Interview
  • Kontextanalyse: Issues bei externen Schnittstellen
  • System-/Strukturanalyse: Analyse von Kopplung/Modularisierung im Großen, eingesetzten Patterns und/oder querschnittlichen Konzepten
  • Codeanalyse: Analyse von Code im Detail
  • Laufzeitanalyse, Profiling
  • Datenanalyse: Analyse von Datenstrukturen, -inhalten, - verteilung/replikation, -persistenz, -konsistenz
  • Prozessanalyse: Analyse von Entwicklungs-/Entwurfs-/Test-/Release- und/oder Betriebsprozessen
  • Ursachenforschung (Root-Cause-Analysis)

Weitere Details siehe (1)[].

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:

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.

Textkasten 2: Beispiele „Schätzung der Kosten eines Problems“

Beispiel „Schätzung der Kosten eines Problems“

Das Problem ist der übermäßig langsame Build- und Deploy-Prozess eines Entwicklungsteams. Das Team entwickelt Java-basierte Client-/Server Anwendungen, die auf einem Tomcat deployed und getestet werden.

Jeder Build-/Deploy- und Testzyklus dauert aktuell gute 15 Minuten (!) – wovon die eigentlichen Unit- und Integrationstests nur einen verschwindend kleinen Bruchteil (max 1 Minute) ausmachen.

Die ersten Annahmen betreffen die (Kosten)Faktoren: Einerseits ist das die Zahl der betroffenen Entwickler (hier: ca. 30 Personen) sowie die Häufigkeit, in der sie den Build-Prozess starten (hier: im Schnitt 4-mal täglich). Weiterhin nehme ich an, dass die Entwickler während des Build-Laufes keine anderen Tätigkeiten (wie Dokumentation) ausführen, weil die Kontextwechsel zu aufwändig sind.

Nehmen wir für Personalkosten von Java-Entwicklern ein Intervall von 50–100€/h an, so können wir die Problemkosten wie folgt abschätzen: 30 Personen x 4 x 14 Min ergeben 1680 durch den langsamen Build „verschwendete“ Minuten, also 28 Stunden. Multipliziert mit dem geschätzten Stundensatz ergeben sich Problemkosten von 1400€ – 2800€ pro Tag.

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.

Abbildung 2: Verbessern im Tagesgeschäft
Abbildung 2: Verbessern im Tagesgeschäft

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.

Textkasten 3: Langfristige Improvement-Ansätze aus aim42

Langfristige Improvement-Ansätze aus aim42

Längerfristige, strategische Ansätze für Verbesserungen benötigen in der Regel mehr Zeit als die kurzfristigen Praktiken (wie beispielsweise Refactorings), zeigen allerdings auch mehr übergreifende, fundamentale Wirkung. Grundsätzlich folgen diese Ansätze der Idee des „value based improvements“, also der Steuerung von Verbesserungen anhand betriebswirtschaftlicher Größen. Einige Beispiele:

  • Change-by-Split: Zerlege das System in unabhängige Teilsysteme, jeweils für unterschiedliche (disjunkte!) Benutzer- oder Consumer-Gruppen. Die Intention ist hier, kleinere und damit besser verständliche und leichter änderbare Systeme zu erhalten.
  • Improve-Cohesion: Verbessere die Modularisierung im Großen, indem zusammengehörige Teile auch in Code und Architektur enger zusammengezogen werden.
  • Isolate-Core-Domains: Verbessere die Modularisierung, indem fachlich zusammengehörige Teile in „bounded contexts“ oder „sub-domaines“ konzentriert werden (resp. weitere Praktiken des Domain-Driven Design im bestehenden System umgesetzt werden). Ein Spezialfall von Improve-Cohesion.
  • Change-by-Extraction: Extrahiere Teile des Systems, mit der Intention der Verkleinerung.
  • Strangulate-bad-parts: Löse schlechte Teilsysteme/Komponenten schrittweise durch verbesserte Implementierungen ab.
  • Frontend-Switch: Spezialfall des „Strangulate-Bad-Parts“ – leite Anfragen vom UI sukzessive auf verbesserte Teilsysteme weiter, und mache damit die „bad parts“ schrittweise überflüssig.
  • Big-Bang-Rewrite: Entwickle das gesamte System neu, komplett unabhängig vom Bestehenden. Meine persönliche Einschätzung: Bei„Big Bang“ Ansätzen drohen diverse Management-Risiken (etwa: Anforderungsanalyse, Staffing, Motivation der beteiligten Mitarbeiter, Übergang von Alt-Neu), die meiner Ansicht nach oftmals unterschätzt werden. Siehe [5]

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.

Abbildung 3: Grundbegriffe methodischer Verbesserung
Abbildung 3: Grundbegriffe methodischer Verbesserung

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

  1. aim42 Website: http://aim42.org  ↩

  2. https://de.wiktionary.org/wiki/Verschlimmbesserung/  ↩

  3. aim42 bei Github, online: https://github.com/aim42/, insbesondere das Referenzhandbuch: http://aim42.github.io/  ↩

  4. Praktiken der Analyze–Phase http://aim42.github.io/#Analyze/  ↩

  5. Der großartige Joel Spolsky (Erfinder von StackOverflow und Trello!) über Big–Bang–Ansätze: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/  ↩

  6. http://bit.ly/cpsa-advanced-improve/, Übersicht bei http://www.isaqb.org/certifications/advanced-level/  ↩

  7. Systematisch verbessern lernen: https://www.arc42.de/info-improve/  ↩