Seit der Veröffentlichung des „Agile Manifesto“ im Jahr 2001 hat sich das agile Vorgehen innerhalb der Softwareentwicklung in kürzester Zeit zum State of the Art entwickelt. Unzählige Organisationen versuchen, die Vorteile der Agilität für sich zu nutzen. Bei der Etablierung und Optimierung ihrer individuellen Herangehensweise an Agilität konzentrieren sich viele Organisationen allerdings vor allem auf die organisatorischen Strukturen und Prozesse innerhalb ihrer Softwareentwicklungsteams. Mit dieser Fokussierung gehen sie jedoch den zweiten Schritt vor dem ersten. Schließlich muss die zu entwickelnde Software agile Entwicklungsprozesse überhaupt erst ermöglichen.
Von Jürgen Dinsing & Karsten Besserdich
Was benötigt man für eine agile Transformation? Viele Unternehmen denken in diesem Zusammenhang vor allem an die organisatorische Wandlungsfähigkeit ihrer Entwicklungsteams. Schließlich werden deren Strukturen, Hierarchien und Prozesse während der Einführung des agilen Konzepts konsequent an die neue Arbeitsweise angepasst. Diese Flexibilität allein reicht allerdings nicht aus, um alle Vorteile der Agilität ausschöpfen zu können.
Was außerdem nötig ist zeigt sich vor allem dann, wenn nicht nur ein agiles Pilotteam ein ebenso überschaubares wie klar abgegrenztes Projekt bearbeitet, sondern eine Skalierung der Agilität angestrebt wird. Wenn mehrere agile Teilteams an einem gemeinsamen Softwareprojekt arbeiten sollen, kann dies nur dann optimal funktionieren, wenn die Abhängigkeiten der Teams untereinander so gering wie möglich sind und sie somit möglichst eigenständig arbeiten können. In vielen Projekten ist die Softwarearchitektur allerdings so verzahnt, komplex und undurchschaubar angelegt, dass Zusammenhänge und Strukturen für den Einzelnen nur schwer zu erfassen sind. In einem solchen Fall können Entwicklungsteams, die an einem Teil der Software arbeiten, nicht sicher vorhersagen, ob ihre Änderungen auch andere Bestandteile beeinflussen werden. Auf diese Weise werden fortwährende Abstimmungen der Teams untereinander notwendig, die die Geschwindigkeit der Entwicklungsarbeit deutlich drosseln.
In vielen Projekten ist die Softwarearchitektur so verzahnt, komplex und undurchschaubar, dass Zusammenhänge und Strukturen nur schwer zu erfassen sind.
In agilen Frameworks wie Scrum ist Geschwindigkeit jedoch ein hohes Gut. Schließlich sollen am Ende einer Iteration möglichst viele Funktionalitäten fertiggestellt sein, die testbar und im Idealfall sogar einsetzbar sind. Wenn jedoch Abhängigkeiten und die dadurch nötige Koordination und Kommunikation die Teams immer wieder ausbremsen, ist die Gefahr groß, dass selbst kleine Änderungen nicht mehr in einer Iteration realisiert werden können. In einem solchen Fall wäre agiles Arbeiten nicht mehr möglich – selbst wenn die Strukturen und Prozesse der Projektteams bereits an eine agile Arbeitsweise angepasst wurden und die Teammitglieder das agile Mindset verinnerlicht haben.
Modulare Systeme ermöglichen eine agile Softwareentwicklung
Um die Potenziale der Agilität vollständig zu heben, muss auch die Softwarearchitektur auf die agile Arbeitsweise vorbereitet sein. Dies gelingt am besten durch den Aufbau eines modularen Systems aus verschiedenen Teilkomponenten, deren Abhängigkeiten untereinander möglichst gering sind. Eine Teilkomponente ist hierbei als klar abgegrenzte Programmeinheit mit einer fest definierten Aufgabe zu verstehen, die lediglich über eine einfache und stabile Schnittstelle lose an die restlichen Module gekoppelt ist.
Bei den Teilkomponenten handelt es sich im weitesten Sinne um eine eigenständige Software. Deren Umfang und Komplexität ist allerdings so gering, dass sie auch für ein kleines agiles Team beherrschbar ist. Dementsprechend sollte jede Teilkomponente autonom von einem Team betreut werden. Daher sollten die Teilkomponenten beispielsweise auch über einen eigenen Releasezyklus verfügen, damit die Teams die Länge ihrer Iterationen selbst bestimmen können und Abhängigkeiten zu anderen Teams möglichst vermieden werden.
Vorrangiges Ziel sollte zudem sein, dass jegliches Wissen zu einer Teilkomponente im jeweiligen Team zusammengefasst ist. Folglich sollte auch das Know-how aus den Bereichen Betrieb und Wartung in den Teams verankert werden. Dieser Schritt verkürzt nicht nur die Kommunikationswege, sondern optimiert auch die Zusammenarbeit zwischen den klassischerweise getrennten Bereichen Entwicklung, Betrieb und Wartung. Die Modularisierung der Software schafft somit die Voraussetzung dafür, dass sich die Softwareentwicklungsorganisation nicht mehr an der Struktur der Prozesse, sondern an der Struktur der Software ausrichtet.
Einzig ein modulares System schafft die Voraussetzungen, um agilen Teams die für ihre Arbeit nötige Eigenständigkeit zu gewähren.
Bei aller Modularisierung ergeben die einzelnen autonom arbeitenden Teilkomponenten für sich allein genommen allerdings noch kein funktionierendes Ganzes. Die Aufgabe, die verschiedenen Module sinnvoll miteinander zu verknüpfen, übernimmt stattdessen eine Kernkomponente, die wie die anderen Komponenten klar abgegrenzt ist und über einen eigenen Releasezyklus verfügt. Die Kernkomponente spielt zudem eine wichtige Rolle im Rahmen der Testverfahren: Nur innerhalb der Kernkomponente werden die angebundenen Komponenten integrativ getestet. Dadurch können sich die Teams der restlichen Teilkomponenten auf die Unit-Tests innerhalb ihres eigenen Moduls konzentrieren, sodass sich die Abhängigkeit von den anderen Teams weiter reduziert.
Ob es sich bei der zu entwickelnden Software um einen Neubau oder ein bereits bestehendes System handelt, ist im Hinblick auf die Wahl der passenden Architektur im Übrigen unerheblich: Hier wie dort schafft einzig ein modulares System die Voraussetzungen, um den agilen Teams die für ihre Arbeit nötige Eigenständigkeit zu gewähren. Selbstverständlich ist das Refactoring einer bislang eher monolithisch aufgebauten Software ein deutlich komplexeres Unterfangen als die Neuentwicklung eines modularen Systems auf der sprichwörtlichen „grünen Wiese“.
In solchen Projekten ist unserer Erfahrung nach ein iteratives Refactoring empfehlenswert. In diesem Verfahren werden zunächst innerhalb der bestehenden Softwarearchitekturen mögliche Komponenten unter technischen wie fachlichen Gesichtspunkten identifiziert. Anschließend werden diese Modul für Modul als abgegrenzte Teilkomponenten neu erstellt. Sobald eine Teilkomponente ihren Zweck eigenständig erfüllen kann, werden die Anfragen fortan an die neue Komponente umgeleitet, während die noch nicht erneuerten Bestandteile zunächst innerhalb der alten Architektur verbleiben. Auf diese Weise verschieben sich im Laufe der Zeit immer mehr Systembestandteile in die neue modulare Architektur, während das Altsystem immer kleiner wird und schließlich ganz verschwindet.
Dieses iterative Vorgehen hat gegenüber einem kompletten Neubau den Vorteil, dass die Komplexität und das Risiko in den einzelnen Arbeitsschritten überschaubar bleiben. Darüber hinaus ist eine vollständige Neuentwicklung sehr zeitintensiv. Während der Dauer des Neubaus wird jedoch auch das Altsystem weiterentwickelt, sodass die Neuentwicklung immer wieder auf diese Neuerungen reagieren muss. Die neue Software wird somit immer wieder umgebaut, bevor sie überhaupt live gegangen ist.
Fazit
Die Unabhängigkeit der Teams ist ein wesentlicher Erfolgsfaktor im Hinblick auf ein effizientes agiles Arbeiten. Folglich unternehmen zahlreiche Organisationen erhebliche Anstrengungen, um ihre Teams von Abhängigkeiten zu entlasten. Der organisatorische Aspekt, der die Strukturen und Prozesse innerhalb der agilen Teams und in der Abstimmung untereinander umfasst, ist allerdings nur eine Seite der Medaille. Wie soll man schließlich eine tatsächliche organisatorische Unabhängigkeit herstellen, wenn weiterhin technische Abhängigkeiten bestehen? Aus diesem Grund sollte innerhalb einer agilen Transformation auch die Softwarearchitektur konsequent auf Agilität ausgerichtet werden. Modulare Systeme, deren Komponenten so klar voneinander abgegrenzt sind, dass die Teams in ihnen möglichst unabhängig voneinander arbeiten können, bieten hierfür die besten Voraussetzungen.
Autoren
Jürgen Dinsing ist seit mehr als 25 Jahren in der Softwareentwicklung tätig – als Entwickler, Projektleiter und Berater für Themen wie Softwarearchitektur und Vorgehensmodelle, meist agile Prozesse. In der Position des Projektmanagers und Key-Accounts kümmert sich Jürgen Dinsing um verschiedene Projekte im Umfeld DevOps und organisiert die Solution-Partnerschaft der mgm mit der Firma Atlassian.
Karsten Besserdich ist geschäftsführender Gesellschafter der Besserdich und Redmann GmbH sowie Bereichsleiter für ORACLE-Beratung und Cloud-Technologien. Er ist mehrfach zertifizierter ORACLE-Spezialist mit den Schwerpunkten Datenbankarchitekturen, Datenbankentwicklung, Datenbankadministration, Performanceoptimierung sowie Datawarehousing. Darüber hinaus setzt er sich seit 2013 intensiv mit dem agilen Framework SCRUM auseinander. Karsten Besserdich ist seit mehr als 16 Jahren in diesen Bereichen vorzugsweise in mittleren und großen Kundenprojekten tätig.
Bildquelle: Fotolia / alotofpeople
