Gerade komme ich von einem Vortrag zurück, den JUGS
und andrena
gemeinsam organisiert haben: "Agilität und Softwarearchitektur - Freunde oder Feinde".
Im allgemeinen meide ich Vorträge und Diskussionen über agile Softwareentwicklung - aus der leidvollen
Erfahrung heraus, daß man sich dabei immer wieder in Allgemeinplätzen verliert und
längst bekannte Standpunkte zum zweiundvierzigsten Male austauscht. Aber in diesem Fall war eine Ausnahme
fällig, denn als Softwarearchitekt in einem neuen Scrum-Team war es an der Zeit für eine Positionsbestimmung.
Braucht ein Scrum-Team überhaupt einen ausgewiesenen Architekten? Wenn ja, von welchen schlechten Angewohnheiten
aus der Wasserfall-Welt sollte er dringend ablassen? Und wie entsteht dieses wolkige Etwas namens
Architektur, wenn man immer nur die nächsten ein oder zwei Monate detailliert plant?
Johannes Stammel, der Vortragende, verwies auf weitere Quellen zum Thema:
Erst jüngst hatte ich den Artikel
Der agile Architekt
von
Nils Arndt zum gleichen Thema gelesen, in dem Schlüsse für die Architektenrolle
gezogen werden, die mir durchaus sympathisch sind:
- So wie es in einem Scrum-Team einen Spezialisten fürs UI geben kann, so kann und darf es auch jemanden geben,
der sich mit Vorliebe für Architekturthemen beschäftigt.
- In sehr kleinen Teams können diese Aufgaben natürlich auch von den Entwicklern des Teams übernommen werden.
In etwas größeren Teams sorgt der Architektur-Spezialist im Team für die "Einheitlichkeit und Gleichförmigkeit der Lösung".
- Die Architektur wird von Sprint zu Sprint kontinuerlich weiterentwickelt. Entscheidungen werden im
last responsible moment gefällt.
- Overengineering und Abstraktionswut haben in agilen Projekten keinen Platz.
- Der Architekt arbeitet entwicklungsnah und faßt selbst mit an.
- Architekturdokumentation fällt schmaler aus als bei anderen Ansätzen.
- Architektur wird schon kommuniziert, während an ihr gearbeitet wird, um Feedback einzuholen.
- Der Architekt organisiert Know-how-Transfers zu Architekturthemen.
- Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.
- Der Architekt ist Kommunikator - er vermittelt zwischen Entwicklern, product owner, Managern.
- Bei divergierenden Auffassungen im Scrumteam ist es Aufgabe des Architekten, eine Entscheidung herbeizuführen.
Revision: r1.2 - 16 Sep 2013 - 21:19 - ClausBrod