© DrHitch/Shutterstock.com
Agile Architektur mit .Net

2 Agiles Architekturvorgehen


„The best architectures, requirements and designs emerge from self-organizing teams“

Ganz im Sinne des agilen Manifests und dessen Prinzipien gilt die Aussage, dass die Architektur des zu entwickelnden Systems gemeinsam im Team festgelegt und diskutiert werden soll. Das hat den großen Vorteil, dass die Architektur und damit auch das Produkt letztendlich vom gesamten Team mit getragen und damit potenziell erfolgreicher werden. Menschen können sich für ihre eigenen Ideen viel stärker begeistern und werden sie auch Dritten gegenüber entsprechend verteidigen. Damit erhöht sich die Identifikation mit dem System nicht unerheblich, und das Team wird eher bereit sein, für seine Vision zu kämpfen.

2.1 Agiler Architekturlebenszyklus

Um zu verstehen, wie sich die Architektur eines Systems innerhalb eines agilen Projekts in den verschiedenen Phasen entwickelt, wird zunächst der Lebenszyklus einer solchen Softwarearchitektur näher betrachtet.

Agile Projekte beginnen meist mit einer initialen Phase, die oft als Iteration 0 bezeichnet wird. In dieser Phase entsteht eine erste Vision der Anwendung samt ersten Anforderungen. Ausgehend davon entsteht eine erste grobe Architekturvision. Architektur und Anforderungen beeinflussen sich dabei gegenseitig und müssen immer wieder gegeneinander geprüft und angepasst werden. Der gesamte Vorgang dauert mehrere Tage. Wichtig ist hier, nicht zu sehr ins Detail zu gehen und im Architekturtrack nur die Dinge zu modellieren, die in dieser Phase unbedingt nötig sind. Konkrete Artefakte sollten mindestens ein Systemkontext und ein grobes Verteilungsdiagramm sein. Dabei sind insbesondere die Schnittstellen zu den Nachbarsystemen ausführlich zu beschreiben [2].

Zusätzlich sollten auch in dieser Iteration wesentliche Szenarien [3] gefunden und beschrieben werden. Damit können erste Qualitätsanforderungen an das System definiert werden. Zudem dienen die Szenarien später während des Projekts immer wieder als Anhaltspunkt für Architektur-Reviews und können dort als Abnahmekriterien gelten. Ausgehend von den Szenarien kann auch ein entsprechender Qualitätsbaum (s. ISO 9126 oder auch ATAM [4]) erstellt werden.

Nachdem die Iteration 0 abgeschlossen und die geforderten Artefakte erstellt wurden, schließen sich die Iterationen 1 bis n an. Diese gliedern sich aus Architektursicht jeweils in vier Phasen:

  1. Architektur/Modellierung für die aktuelle Iteration
    Zu Beginn jeder Iteration wird so viel modelliert, wie für die aktuelle Phase notwendig ist. Das ist wichtig für die Planung der Iteration und die Abschätzung der Aufwände. Dieser Prozess sollte nicht länger als einen Tag in Anspruch nehmen.
  2. Entwicklung
    Das Programmieren der Funktionalität sollte den größten Teil der Iteration ausmachen. Idealerweise orientieren sich Entwickler hierbei an Best Practices, Clean-Code-Prinzipien und Methoden wie Test-driven Development (TDD).
  3. Nachmodellierung (optional)
    Während einer Iteration kann es notwendig werden, bestimmte Teile des Systems genauer zu modellieren, bevor mit deren Umsetzung begonnen wird. Dafür brauch...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang