© Liashko/Shutterstock.com
Entwickler Magazin
Jenseits des Elfenbeinturms: Scrum für Softwarearchitekten

Der agile Architekt

Scrum kennt die Rollen Product Owner, Scrum Master und Entwickler, aber nicht die Rolle „Architekt“. In einer klassischen Teamhierarchie wird die Softwarearchitektur allein durch den Architekten verantwortet. Im selbstorganisierten Scrum-Entwicklungsteam dagegen gibt es keine Rangfolge, und die Entwickler sind gleichberechtigt. Wie entsteht die Softwarearchitektur in einem Scrum-Team im Unterschied zur traditionellen Methodik?

Nils Arndt


Im sequenziellen und dokumentorientierten Vorgehen des Wasserfallmodells entsteht eine Softwarearchitektur als Big Design Up Front (BDUF). Eine solche klassische Architektur, die in einer frühen Projektphase nach der Anforderungsanalyse entworfen wird, hat den Anspruch, vollständig und ausgereift zu sein – quasi in Stein gemeißelt. Als Hauptmotivation für die Erstellung einer umfangreichen und detaillierten Dokumentation vor dem Start der Implementierungsphase gilt die Möglichkeit, Fehler oder Lücken in der Anforderungsspezifikation zu einem Zeitpunkt zu erkennen, zu dem sie sich noch relativ kostengünstig beseitigen lassen.

Die Vorgehensweise bei der Anwendung des Wasserfallmodells hat den Begriff des Elfenbeinturmarchitekten geprägt. Fernab vom Entwicklungsteam und -geschehen entwerfen solche Architektur- und Dokumentationsspezialisten detaillierte Modelle und Prozesse, die sie am Ende der Entwurfsphase präsentieren und den häufig zu Codeknechten degradierten Entwicklern zur Implementierung übergeben, ohne dass diese effektiv Gelegenheit gehabt hätten, an wesentlichen Designentscheidungen mitzuwirken.

Klassische Softwarearchitektur – untauglich in der Anwendung

In der Praxis stellt sich oft schnell heraus, dass eine nahezu komplett vor der Implementierungsphase entstandene Architekturbeschreibung das bleibt, was sie ist: graue Theorie. Die Gründe hierfür sind vielfältig:

Die Anforderungen an die Software ändern sich ständig: sowohl vor, während als auch nach der Entwicklungsphase. Häufig setzt der Erkenntnisprozess des Auftraggebers erst dann ein, wenn die Software zum ersten Mal ausgeliefert wird. Das BDUF-Paradigma trägt diesem Umstand nicht Rechnung.Entwickler billigen nur widerstrebend Designentscheidungen, an denen sie nicht mitwirken durften. Je größer die Codeferne des Architekten, desto geringer das Maß an Akzeptanz.Entwickler hegen eine ausgeprägte Aversion gegen aufgeblähte Dokumentationen.Technische Probleme werden in der Regel nicht ohne Prototypen oder technische Durchstiche erkannt. Architekten, die nicht auf Augenhöhe mit dem Entwicklungsteam arbeiten und selbst implementieren, gehen daher oft von falschen Annahmen aus. Dadurch steigt das Projektrisiko erheblich.Vollständigkeit oder hoher Detaillierungsgrad einer Architektur sind keine Zeichen von Qualität. Die verfügbare Informationsmenge über System und Kundenanforderungen wächst mit der Projektdauer. Die Wahrscheinlichkeit ist daher hoch, trotz umfangreicher Entwurfsdokumentation wesent...

Entwickler Magazin
Jenseits des Elfenbeinturms: Scrum für Softwarearchitekten

Der agile Architekt

Scrum kennt die Rollen Product Owner, Scrum Master und Entwickler, aber nicht die Rolle „Architekt“. In einer klassischen Teamhierarchie wird die Softwarearchitektur allein durch den Architekten verantwortet. Im selbstorganisierten Scrum-Entwicklungsteam dagegen gibt es keine Rangfolge, und die Entwickler sind gleichberechtigt. Wie entsteht die Softwarearchitektur in einem Scrum-Team im Unterschied zur traditionellen Methodik?

Nils Arndt


Im sequenziellen und dokumentorientierten Vorgehen des Wasserfallmodells entsteht eine Softwarearchitektur als Big Design Up Front (BDUF). Eine solche klassische Architektur, die in einer frühen Projektphase nach der Anforderungsanalyse entworfen wird, hat den Anspruch, vollständig und ausgereift zu sein – quasi in Stein gemeißelt. Als Hauptmotivation für die Erstellung einer umfangreichen und detaillierten Dokumentation vor dem Start der Implementierungsphase gilt die Möglichkeit, Fehler oder Lücken in der Anforderungsspezifikation zu einem Zeitpunkt zu erkennen, zu dem sie sich noch relativ kostengünstig beseitigen lassen.

Die Vorgehensweise bei der Anwendung des Wasserfallmodells hat den Begriff des Elfenbeinturmarchitekten geprägt. Fernab vom Entwicklungsteam und -geschehen entwerfen solche Architektur- und Dokumentationsspezialisten detaillierte Modelle und Prozesse, die sie am Ende der Entwurfsphase präsentieren und den häufig zu Codeknechten degradierten Entwicklern zur Implementierung übergeben, ohne dass diese effektiv Gelegenheit gehabt hätten, an wesentlichen Designentscheidungen mitzuwirken.

Klassische Softwarearchitektur – untauglich in der Anwendung

In der Praxis stellt sich oft schnell heraus, dass eine nahezu komplett vor der Implementierungsphase entstandene Architekturbeschreibung das bleibt, was sie ist: graue Theorie. Die Gründe hierfür sind vielfältig:

Die Anforderungen an die Software ändern sich ständig: sowohl vor, während als auch nach der Entwicklungsphase. Häufig setzt der Erkenntnisprozess des Auftraggebers erst dann ein, wenn die Software zum ersten Mal ausgeliefert wird. Das BDUF-Paradigma trägt diesem Umstand nicht Rechnung.Entwickler billigen nur widerstrebend Designentscheidungen, an denen sie nicht mitwirken durften. Je größer die Codeferne des Architekten, desto geringer das Maß an Akzeptanz.Entwickler hegen eine ausgeprägte Aversion gegen aufgeblähte Dokumentationen.Technische Probleme werden in der Regel nicht ohne Prototypen oder technische Durchstiche erkannt. Architekten, die nicht auf Augenhöhe mit dem Entwicklungsteam arbeiten und selbst implementieren, gehen daher oft von falschen Annahmen aus. Dadurch steigt das Projektrisiko erheblich.Vollständigkeit oder hoher Detaillierungsgrad einer Architektur sind keine Zeichen von Qualität. Die verfügbare Informationsmenge über System und Kundenanforderungen wächst mit der Projektdauer. Die Wahrscheinlichkeit ist daher hoch, trotz umfangreicher Entwurfsdokumentation wesent...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang