Agile Softwarearchitektur
Dieser Artikel zeigt auf, wie agile Softwareentwicklungsteams den wichtigen Aspekt der Softwarearchitektur handhaben und integrieren können.
Agile Softwarearchitektur ist ein Begriff, der unter IT-Fachleuten viel Aufmerksamkeit erregt. Sehen wir uns an, was er bedeutet und wie Ihr Unternehmen agiler werden kann, wenn es um IT-Lösungen geht.
Die Definition der Softwarearchitektur
Wir beginnen als erstes mit der Definition des Begriffs “Softwarearchitektur”. Die eher traditionelle, sprich nicht-agile Definition lautet
“Eine Gruppe von Prinzipien und Einschränkungen wie Software Lösungen innerhalb gegebenen Grenzen (normalerweise eines Unternehmens) implementiert werden müssen.”
Als Fürsprecher der Agilität könnten wir diese oft-verwendete definition als potentiell problematisch ansehen. Einschränkungen und Grenzen, diese beiden Wörter erfordern schon eine starre, rigide Struktur, welche die funktionalen und nicht-funktionalen Anforderungen eines Softwaresystems ebenso rigide beschreibt.
In traditionell geführten Softwareprojekten werden diese Anforderungen praktisch in Stein gemeisselt, bevor die Entwicklungsarbeit beginnt. Und sie werden bis zum Abschluss der Arbeit nicht verändert. Als eine rigide Struktur ist eine solche Softwarearchitektur gegenüber Veränderungen sehr empfindlich. Aber als agile Softwareentwickler wollen wir in der Lage sein, uns schnell zu bewegen und Veränderungen anzunehmen.
Es lässt sich nicht leugnen, dass bestimmte Einschränkungen und Grenzen hilfreich sind, um zu definieren, was wir implementieren wollen.Für unsere agilen Zwecke müssen wir jedoch in der Lage sein, die Unbeweglichkeit dieser Einschränkungen und Grenzen aufzulösen, damit wir sie während des Verlaufs unseres Entwicklungsprojekts anpassen können.
Wie können wir traditionelle Softwarearchitektur in agile Softwarearchitektur verwandeln? Wenn wir uns daran erinnern, dass eines der wichtigsten Prinzipien der Agilität besagt, dass Menschen wichtiger als Prozesse sind (siehe auch das Agile Manifest), dann wird klar, dass wir hierfür die Rolle der Person, welche Softwarearchitektur betreibt, nämlich die des Softwarearchitekten, betrachten müssen.
Was ist Traditionelle Softwarearchitektur?
Der traditionelle Softwarearchitekt analysiert die Softwareanforderungen eines geplanten Systems und trifft auf der Basis dieser Anforderungen technische Entscheidungen. Er muss hierfür in der Lage sein, das grosse Ganze zu sehen, insbesondere was den zukünftigen Betrieb des Systems betrifft. Er muss zudem Compliance-Vorschriften kennen und beachten und er sollte auch in der Lage sein, Design-Dokumente zu erstellen.
Üblicherweise ist der traditionelle Softwarearchitekt nicht sehr stark an der eigentlichen Entwicklung, also der Programmierung, beteiligt. Er würde die Architektur abliefern und sich dem nächsten Projekt widmen, bevor mit der Entwicklung überhaupt begonnen wird. Ein Softwarearchitekt, welcher nicht direkt und laufend in dem Entwicklungsproject involviert ist wird auch nicht in der Lage sein, die betroffene Softwarearchitektur zu modifizieren wenn sich etwas im Projekt ändern sollte. Ist dies vielleicht eines der Gründe, weshalb traditionelle Softwarearchitekturen so rigide sind?
Was ist Agile Softwarearchitektur?
In der Agilität sind die Teams und deren Zusammenhalt wichtig. Wenn ein traditioneller Softwarearchitekt nicht in der eigentlichen Entwicklung der Software involviert ist, wie kann dieser dann in ein agiles Entwicklungsteam integriert werden? Nun, die meisten Softwarearchitekten sind erfahrene Entwickler, die in diese neue Rolle befördert wurden. Dies bedeutet, dass sie die nötigen Fähigkeiten besitzen, um Software zu entwickeln, selbst wenn ihre neue Rolle als Softwarearchitekt diese Tätigkeit nicht aktiv benötigt.
Wenn wir uns ein agiles Team ansehen, dann könnten wir einen erfahrenen Entwickler in unser Team einbetten, ihn “agilen Softwarearchitekten” nennen und ihn darum bitten, mit dem Team gemeinsam eine Softwarearchitektur zu entwickeln, während er gleichzeitig in unserem Team verbleibt und mit uns die Software entwickelt.
Als Mitglied des Teams wird er die Entwicklung aus erster Hand miterleben und er wird ein Gefühl für das Projekt und die Software bekommen. Er wird von dem Team und den Stakeholdern direkt Feedback erhalten und wird in der Lage sein Anhand dieser ganzen Eindrücke die Softwarearchitektur zu modifizieren und anzupassen. Somit ist er in der Lage, lebende Dokumente für eine agile, zukunftsfähige Softwarearchitektur zu erstellen.
Wie funktioniert die agile Softwarearchitektur?
Diese agile Softwarearchitektur kann nun angewandt und in agile Artefakte wie Scrum User Stories portiert werden. Diese werden nach Bedarf entsprechend erstellt und aktualisiert. Dies ist ein iterativer Prozess, genauso wie die meisten anderen Prozesse eines agilen Projektes.
Der agile Softwarearchitekt überwacht die sich möglicherweise verändernden Anforderungen kontinuierlich und hilft dem Team diese mit einer sich möglicherweise verändernden technologischen Situation auf eine Linie zu bringen, alles im Diskurs mit anderen agilen Rollen, wie dem Product Owner.
Der Architekt berät und betreut somit das Team und ermöglicht es ihm, seine Softwarearchitektur gemeinsam zu bestimmen. Er muss natürlich weiterhin in der Lagei sein, das grosse Ganze zu sehen; aber er muss es auch mit dem abgleichen, was während des laufenden, iterativen Entwicklungsprozesses passiert.
Wir unterstreichen diese beratende und betreuende Rolle weil es wichtig ist zu bedenken, dass ein agiles Entwicklungsteam ein sich selbst verwaltendes Team ist. Ein agiler Softwarearchitekt ist somit kein Teamleiter oder Team Manager, selbst wenn er eventuell mehr Erfahrung besitzt als die anderen Entwickler des Teams. Was vorher technische Entscheidungen waren sollten jetzt als Vorschläge kommuniziert und mit dem Team besprochen werden.
Wir müssen uns daran erinnern, dass die agile Softwareentwicklung eine gemeinsame Anstrengung ist, die kein Teammitglied dominieren oder alleine bewältigen kann. Das agile Prinzip der Erstellung von funktionsfähigen Inkrementen, d. h. funktionalen Prototypen, ermöglicht es dem Softwarearchitekten und dem Team, fundiertere Entscheidungen zu treffen, indem es ihnen ermöglicht, zu sehen, wie sie sich auf das System auswirken.
Wie fördert man eine agile Softwarearchitektur in einem Unternehmen?
Wann beginnt also eine agile Softwarearchitektur? So früh wie möglich! Sobald die ersten User Stories verfügbar sind sollte sich das Team zusammensetzen um gemeinsam zu erörtern wie sich diese Anforderungen in technische Softwareanforderungen umsetzen lassen. Dieser Prozess könnte einige User Stories verfeinern, und die Machbarkeit anderer widerum in Frage stellen.
Verschieben Sie Ihre eigentliche Entwicklung nur nicht, weil Sie das Gefühl haben, dass Ihre Softwarearchitektur noch nicht fertig ist. Betrachten Sie seine Gestaltung vielmehr als einen fortlaufenden Prozess!
Einige Teams haben auch eine grundlegende Referenzarchitektur, die sie im Laufe des Projekts anpassen. Ihre agile Softwarearchitektur so einfach und schlank wie möglich zu halten, ermöglicht deren einfache Anwendung, Kommunikation und Modifikation. Diese drei Punkte sind immens wichtig, wenn Sie agile Prinzipien in Ihrem Softwareentwicklungsprozess anwenden möchten.
Fazit
Abzuschließend können wir bekräftigen, dass eine gute Softwarearchitektur für die Softwareentwicklung immer von entscheidender Bedeutung sein wird, sei sie agil oder traditionell. In einem agilen Softwareentwicklungsprozess ist die Architektur jedoch nie wirklich “fertig”, während sie in einem traditionell geführten Entwicklungsprojekt zu Beginn des Projekts fest in Stein gemeißelt wird.
Darüber hinaus empfehlen wir, die Rolle des Softwarearchitekten an den agilen Prozess anzupassen, indem er oder sie in das agile Entwicklungsteam eingebettet wird, sodass Erfahrungen aus erster Hand, mit dem Feedback des Teams, den laufenden Softwarearchitektur-Designprozess beeinflussen können. Abschließend sei noch erwähnt, dass eine schlanke Softwarearchitektur unerlässlich ist, um einen reibungslosen agilen Entwicklungsprozess zu erreichen.
- Microservices - 18.01.2024
- IT-Sicherheitsrisiken - 22.12.2023
- Java Champion - 06.12.2023
- Microservices - 18.01.2024
- IT-Sicherheitsrisiken - 22.12.2023
- Java Champion - 06.12.2023