Suche
XP/Scrum und Architekturframeworks müssen kein Widerspruch sein

Agilität trotz komplexer Architekturen

Dr. Uwe Bombosch

Die Vorstellung, mit der Einführung eines agilen Projektvorgehens erübrige sich das methodische Entwickeln einer Architektur, kann Projekte, die es mit komplexeren Systemen zu tun haben, in die Irre führen. Geht es um die Transformation größerer Teile der IT-Landschaft, so sind Architekturframeworks ein Hilfsmittel, um der Komplexität Herr zu werden. Andererseits erwecken diese Frameworks mit dem Fokus auf Planung und Spezifikation einen so wasserfallartigen Eindruck, dass sie mit agilem Vorgehen unvereinbar scheinen. In diesem Artikel wird am Beispiel von TOGAF und Scrum/XP gezeigt, dass dieser scheinbare Antagonismus auflösbar ist – unter Einschränkungen, aber auch mit Gewinn.

Agile Projektmethoden wie etwa eXtreme Programming (XP) oder Scrum wirken anziehend auf Architekten, Projektleiter und Fachverantwortliche, die sich in Wasserfallprojekten müde spezifiziert haben, ohne je wirklich zufrieden mit dem letztendlich Umgesetzten zu sein. Verspricht Agilität doch eine rasche, sich dann stetig erweiternde Bereitstellung von Funktionalität, eine leichte Steuerbarkeit und Transparenz von Projekten, die punktgenaue Erfüllung der Vorstellungen des Fachbereichs sowie eine Steigerung der erzielten Qualität – all dies mit einer gewissen Leichtigkeit, ohne den Ballast langwieriger Vorüberlegungen und Dokumentationspflichten.

Agilität ohne Architektur?

Tatsächlich betont schon das agile Manifest aus dem Jahr 2001 die Priorität laufender Software gegenüber ausgefeilten Spezifikationen, und gibt Offenheit gegenüber Änderungen den Vorzug vor Planbefolgung. In Büchern findet man mitunter missverständliche Sätze wie „The real software architecture evolves (better or worse) every day of the product, as people do programming“ [1, S. 284]. Kein Wunder also, dass mancher Anhänger agiler Prinzipien, die lähmenden Spezifikationsphasen des Wasserfalls vor Augen, die Architektur auf Überlegungen am Scrum-Planungstag oder Diskussionen beim Pair Programming beschränkt sehen möchte. Eine solche minimalistische Auslegung von Architektur ist bei einem Team von bis zu zehn erfahrenen Entwicklern durchaus praktikabel und vielleicht sogar empfehlenswert. Wie aber steht es mit der Skalierung auf größere Teams und komplexere Systeme?

In den letzten Jahren haben Unternehmen auch massivere Umgestaltungen ihrer IT-Landschaft oder IT-Produktpalette in die Hände agiler Projekte gegeben. Viel Geld und Sorgfalt wird dabei aufgewendet, Praktiken des Projektmanagements wie Daily Scrum oder Retrospektiven einzuüben und Rollen wie die des Product Owners zu etablieren. In verblüffendem Kontrast zu dieser Sorgfalt steht mitunter die Sorglosigkeit darüber, wie die Architektur der Lösung zustande kommen mag, ganz so, als erledige sich die Komplexität dieser Aufgabe mit der Einführung des agilen Projektmanagements von selbst. Leicht gerät die Entwicklung ins Stocken, weil wesentliche Fragen um das Wie und Was-genau ungeklärt sind, deren Komplexität sich nicht durch „Brainstorming“ am Scrum-Planungstag ordnen lässt.

Architektur ist im Wesentlichen eine vorausschauende Disziplin, und damit dem agilen Credo zunächst verdächtig. Die Notwendigkeit zur Vorausschau ergibt sich jedoch zum einen aus Gründen, die der Softwareentwicklung immanent sind, so mag zum Beispiel die schnellste, simpelste Umsetzung einer User Story unter dem Gesichtspunkt der Nachhaltigkeit trotzdem schlecht sein, denn die bedenkenlose Auswahl solcher Lösungen kann ein Projekt dauerhaft in eine „Refaktorierungslähmung“ versetzen. Zum anderen aber ist die Entwicklung nicht der einzige Prozess auf der Landkarte des Geschäftsumfeldes, und auch andere Prozesse fordern die Klärung planender Fragen:

  • Budgetplanung: Welche Kosten müssen im zweiten Halbjahr für die Entwicklung eingeplant werden?
  • Ressourcenplanung: Welche Hardware/Lizenzen müssen Anfang 2011 bereitgestellt werden?
  • Operative IT: In welchen Technologien müssen die Betriebsteams bis 2011 geschult werden?
  • Anforderungsmanagement: Wie kann die strategische Anforderung, 2011 Mainframes in Bestellungsprozessen abzulösen, umgesetzt werden?

Diese Fragen stellen sich selbstverständlich ebenso im Umfeld agiler Projekte, und die Architektur ist daher auch als eine vermittelnde, wissensbildende Hilfsdisziplin unabdingbar. Bleibt also zu klären, wie diese Disziplin zu gestalten und mit Leben zu füllen ist, damit die Verbindung mit agiler Entwicklung gelingen kann (Abb. 1).

Abb. 1: Architektur als Vermittler
Geschrieben von
Dr. Uwe Bombosch
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.