QCon San Francisco 2008 - Architekten und Agilisten

Die QCon San Francisco 2008 Konferenz wurde mit einer interessanten Keynote von Rebecca Parsons und Martin Fowler eröffnet. In ihren Vorträgen sprachen sie über die oft angespannte Beziehung zwischen traditionellen Architekten und der agilen Entwicklung und darüber, wie diese Beziehung zum Vorteil sowohl des agilen Entwicklungsteams als auch der Architekten verbessert werden kann. Zu diesen Vorteilen gehören der projekt- und abteilungsübergreifende Wissensaustausch, die gemeinsame Nutzung der langjährigen Erfahrung der Architekten mit den Entwicklern und die Arbeit nur an der Architektur, die tatsächlich benötigt wird. Im ersten Teil ging es um die Bedrohung der Rolle des traditionellen Architekten durch die agile Entwicklung und um das Misstrauen zwischen Entwicklern und Architekten. Obwohl viele der Elfenbeinturm-Architekten-Stereotypen ein Körnchen Wahrheit enthalten mögen, liegt die Ursache oft nicht bei den Architekten selbst. Viele Organisationen bringen Architekten in eine Position, die es ihnen schwer oder unmöglich macht, erfolgreich zu sein:

• Ziele wie das Erreichen von 30% Wiederverwendung - wie kann man das messen und fördern?
• Architekten dürfen keinen Code schreiben - wie sollen die Architekten also mit der neuesten Technologie Schritt halten?
• Die Architekten sind den Entwicklern oft 30:1 oder mehr unterlegen - da bleibt keine Zeit, sich in Projekte einzubringen oder die Entwickler zu betreuen.

Traditionell lässt dies den Architekten nur sehr wenige Optionen, wie die Festlegung einer Referenzarchitektur und die Forderung, dass sich alle Projekte daran halten müssen, selbst wenn die Architektur nicht für das spezifische Projekt geeignet ist. Dies kollidiert nicht nur mit der agilen Entwicklung, sondern kann dieses Modell sogar bedrohen. Es ist nicht verwunderlich, dass dies zu Misstrauen zwischen Architekten und agilen Teams führt. Aber diese gegnerische Beziehung ist nicht notwendig. Im zweiten Teil des Vortrags ging es darum, wie die agile Entwicklung es den Architekten ermöglicht, erfolgreich zu sein:

• Sichtbarkeit des Fortschritts durch Lieferung funktionierender Software in jeder Iteration, so dass der Architekt einbezogen werden und reagieren kann.
• Aktualisierte Spezifikationen der Funktionalität durch automatisierte Tests.
• Extrahieren von wiederverwendbaren Komponenten aus funktionierendem Code, anstatt zu versuchen, wiederverwendbare Komponenten im Voraus zu erstellen, die möglicherweise nie verwendet werden. Wiederverwendung "im Nachhinein" statt "von vornherein".

Wie können Sie also die Architekten in den agilen Entwicklungsprozess einbeziehen? Indem Sie die Architekten wie einen weiteren Stakeholder behandeln, genau wie den normalen Kunden. Die architektonischen Anforderungen müssen genau wie alle anderen Anforderungen priorisiert werden. Und Anforderungen wie "das System muss wartbar sein" müssen spezifisch und umsetzbar werden, wodurch die Arbeit der Architekten konkreter und wertvoller wird.