en
de

Architektur eines agilen, verteilten Entwicklungsprojekts

5 November 2013
| |
Lesezeit: 4 Minutes

Agile Software-Entwicklung ist in aller Munde und steht auch in Industrieunternehmen, die bisher eher ein klassisches Wasserfallmodell bevorzugten, hoch im Kurs. Seit kurzem ist „Agile Architektur“ immer häufiger das Thema von Veröffentlichungen und Vorträgen.

Bisher habe ich aber noch keine befriedigende Antwort auf die Frage erhalten, ob und wie genau sich die Arbeit eines „agilen“ Architekten von der „konventionellen“ Architekturarbeit unterscheidet.

Dieser Beitrag gibt einen Einblick in meine Arbeit als Architekt in einem agilen Entwicklungsprojekt mit verteilten Teams.

Projekt-Setup

Projekt-Setup bei verteilten Software-Entwicklungsprojekten

Ich arbeite seit fast einem Jahr in einem Projekt zur Entwicklung und Einführung eines neuen Software-Produkts, das die Kernfeatures zweier bestehender Produktplattformen bündeln soll. Diese Plattformen werden in verschiedenen geografisch und organisatorisch getrennten Bereichen des Unternehmens entwickelt und sind jede für sich bereits am Markt erfolgreich.

Einer der Bereiche wurde erst vor kurzem akquiriert. Kultur, Methodik und verwendete Technologien beider Teams unterscheiden sich daher deutlich voneinander. Das Produkt hat einige Integrationspunkte in verschiedene Backendsysteme und Prozesse, für die Schnittstellen abzustimmen und zu implementieren sind. Es sind weitere Unternehmensbereiche beteiligt.

Meine Rolle in dem Projekt ist die des Systemarchitekten und technischen Projektleiters. Ich arbeite eng mit dem Product Owner und Business-Analysten zusammen.

Die Entwicklungsteams arbeiten unabhängig voneinander im Scrum-Modus.

Die Sprint-Zyklen (2 Wochen, manchmal 3) waren anfangs nicht aufeinander abgestimmt, was sich vor allem für die übergreifende Qualitätssicherung als problematisch erwiesen hat. Beide Teams haben neben den Entwicklungsaufgaben für unser Projekt auch noch das Tagesgeschäft zu erledigen.

Vorausplanung: agil oder nicht agil?

Sprintplanung

Die Herausforderung für mich als teamübergreifenden Systemarchitekten besteht zum großen Teil darin, die nahe bis mittelfristige Zukunft und die in diesem Zeitraum anfallenden Entwicklungsaufgaben stets im Blick zu behalten. Das sind im Wesentlichen die nächsten beiden Sprints für jedes Team.

Das mag für manche Puristen nicht „agil“ sein, aber für diesen Zeitraum halte ich eine grobe Vorausplanung für unerlässlich. Es ist wichtig, die Abhängigkeiten zwischen den Backlog Items beider Teams zu kennen und die Prioritäten in den Sprints entsprechend so festzulegen, dass jedes Team die notwendigen Voraussetzungen zur Umsetzung seiner Stories vorfindet.

Für die Entwicklung benötigte Architekturkonzepte und Schnittstellenspezifikationen müssen dokumentiert und vor Sprintbeginn von allen beteiligten Seiten mehr oder weniger formal abgenommen worden sein. Gibt es erst während der Sprintplanung oder – noch schlimmer – während des Sprints Diskussionen um unklare Anforderungen oder nicht abgestimmte Details, kann das zur Verzögerung der entsprechenden Entwicklungspakete um einen oder mehrere Sprints führen und die gesamte Planung durcheinanderwerfen.

Dabei arbeite ich selbst nicht im Scrum-Modus, sondern treibe kontinuierlich parallel zu den Entwicklungsteams die Architekturthemen voran. Da ich in Personalunion auch die Rolle des Technischen Projektleiters ausfülle, bin ich auch für Sprint- und Projektplanung (mit)-verantwortlich. Das hilft dabei, den Überblick über die anstehenden Aufgaben zu behalten und die Architekturarbeit mit der Entwicklung zu synchronisieren.

Pragmatische Dokumentation

Dieses Vorgehen spiegelt sich auch in der Form der Architekturdokumentation wieder, die genauso wie Architektur und Code den sich ändernden Anforderungen unterworfen ist. Daher gilt hier das Prinzip „So viel wie nötig, so wenig wie möglich“.

Nötig ist mindestens das, was an Konzepten und Spezifikation für die Umsetzung benötigt wird. Ein stets aktueller Überblick über die Gesamtarchitektur aus funktionaler und Komponentensicht ist sehr hilfreich. Die Dokumentation der Architektur erfolgt so durch die Entwicklungs-Stories getrieben. Erst jetzt, da die Architektur mehr oder weniger steht, mache ich mich daran, die wichtigsten Artefakte zu einem zentralen Softwarearchitekturdokument zusammenzufassen.

Agile Prinzipien gelten auch für Architekten

Zum großen Teil bekannte Prinzipien der (agilen) Entwicklung gelten auch – oder umso mehr – für Architekten.

  • KISS – Keep it simple [&] stupid! Je komplizierter etwas gebaut ist, desto schwieriger ist es später zu ändern.
  • YAGNI – You ain’t gonna need it! Was du nicht brauchst, musst du nicht bauen und im Zweifel auch nicht ändern. Was erst später gebraucht wird, kann bis dahin vielleicht ganz anders aussehen.
  • Auch für Architekturdokumentation gilt: KISS und YAGNI. Und DRY (don’t repeat yourself) sowieso.
  • Schnittstellen müssen vor Sprintbeginn spezifiziert und diese Spezifikation muss von allen abgenommen werden, die mit der Schnittstelle arbeiten. Die Diskussion der Anforderungen mit den beteiligten Teams ist ein wichtiger und wertvoller Teil der Architekturarbeit. Auch – oder gerade – in derselben Entwicklungsorganisation.
  • Embrace change – In einem agilen Prozess darf und soll man bereits Bestehendes ändern. Wenn eine Schnittstelle abgenommen ist, heißt das nicht, dass ich im nächsten Sprint nicht wieder etwas ändern darf – mit Augenmaß versteht sich. Hier ist manchmal bei Teamleitern Überzeugungsarbeit zu leisten, die Angst vor „Waste“ haben.
  • Die Sprints der beteiligten Teams sollten wenn möglich einigermaßen synchron laufen. Das vereinfacht die Planung und reduziert Aufwand bei der übergreifenden Qualitätssicherung.

Agile Architekten

Die Arbeitsweise des oder der Architekten variiert sicherlich je nach Projektsetup und Rolle im Projekt – Beipiel: übergreifender Systemarchitekt vs. Lösungsarchitekt als Teil eines Entwicklungsteams. Hierzu kann sicher – wie auch zur agilen Entwicklung insgesamt – kein Patentrezept formuliert werden. Architekten in einem agilen Projekt müssen aber definitiv zu einem gewissen Maß ebenfalls agil arbeiten, wenn auch nicht notwendigerweise im gleichen Modus wie die Entwicklungsteams.

Ein gesundes Maß an Dokumentation und „Zeremonie“ sowie ein ausreichender Planungshorizont zur Abstimmung von zentralen Architekturkonzepten und Schnittstellen sind meines Erachtens unerlässlich, sobald mehr als ein Team beteiligt ist.

Die Dokumentation kann dabei auf die zur Abstimmung der Kernkonzepte und Schnittstellen notwendigen Artefakte sowie einen groben Architekturüberblick beschränkt bleiben. Wenn die Architektur eine gewisse Reife erreicht hat, kann aus den dann vorhandenen Artefakten ein Gesamt-Architekturdokument erstellt werden.

Haben Sie ähnliche oder andere Erfahrungen als Architekt in einem verteilten Entwicklungsprojekt gemacht? Lassen Sie es mich wissen!

Kommentare (4)

Avatar

osc

6 November 2013 um 22:57

Hi Benno,
schöner Blog! Ich arbeite gerade in einem Projekt mit 9 agilen Teams. Hast Du vielleicht ein Template eines Architekturdokuments?

Gruss, Oliver

Benno Vogel

Benno Vogel

8 November 2013 um 11:49

Hallo Oliver,

Danke fürs Lesen. Welche Erfahrungen machst Du denn in Deinem Projekt?

Wie in meinem Beitrag beschrieben, bin ich sehr pragmatisch vorgegangen und habe jeweils die Artefakte erzeugt, die für Spezifikation, Diskussionen und Konzeptarbeit erforderlich waren.

Was dabei herauskam, deckt grob die 4+1 Sichten ab:
– Funktionale Architektur (Diagramm)
– Systemarchitektur (Diagramm)
– Use Cases (hauptsächlich für die QS benötigt)
– Einige Klassen- und Sequenzdiagramme
– Konzeptpapiere und Service-Spezifikationen

Aus diesem Fundus stelle ich jetzt das SAD zusammen.

Wir haben ein eigenes Template für Architekturkonzepte entwickelt, aber das ist auch ziemlich generisch.

Bei Gelegenheit zeige ich Dir gerne mal, was wir an Artefakten in dem Projekt erstellt haben.

Viele Grüße
Benno

Avatar

Michael

9 Februar 2014 um 10:06

Hi Benno,
ich bin auf Deinen Blog gestossen, als ich mich im Netz zu den Themen „verteilte Visualisierung“ und „verteilte Teams“ umschaute.
Ich arbeite gerade beratend für einen Kunden, der seine PM Methodik in der IT Abteilung eines Krankenhausbetreibers verändern möchte. Hier wird kaum Software entwickelt. Projektinhalt sind eher SAPlastig oder betreffen die Infrastruktur des Krankenhauses.

Nun haben wir in verschiedenen Workshops mit den Führungskräften die „Werkzeugkästen“, die PRINCE 2 und Scrum bereithalten, evaluiert und anhand des Ist-Zustandes ein Katalog von Möglichkeiten, Maßnahmen und Zielen erarbeitet.

Ein Knackpunkt scheint mir zu sein, dass die Mitarbeiter der IT Abteilung oft für Meetings in die einzelnen Krankenhäuser fahren müssen. Das Board mit den identifizierten Arbeitspaketen (Product und Sprint Backlog) eines Projekts steht aber in der IT Abteilung. Eine Einbeziehung dieser Tools und so eine Interaktion und Kommunikation der KrankenhauskollegInnen ist so schwer möglich. Aus räumlichen Gründen können die Meetings auch nicht in der IT Abteilung stattfinden. Hm…Hast Du etwas Ähnliches schon vorgefunden? Wie geht man damit um? Wie visualisiert man auch für den sog. „weissen Bereich“ den Projektfortschritt?

Ein weiterer Punkt ist, dass die Projektergebnisse in Sharepoint dokumentiert werden sollen. D.h. im Umkehrschluss: Wenn man mit Scrummethoden arbeiten will, müssen bestimmte Schritte doppelt gemacht werden (AP Karte im Sprint Backlog auf Done hängen und in Sharepoint auf erledigt setzen). Auch sehr unschön…
Welche Möglichkeiten siehst Du nach Deiner Erfahrung, Werkzeuge der agilen Methoden hier zum Einsatz zu bringen?

Gruß
Michael

    Benno Vogel

    Benno Vogel

    10 Februar 2014 um 11:21

    Hi Michael,

    vielen Dank für Deinen Kommentar.
    Kollaboration ist ein wichtiger Aspekt, den du hier ansprichst – der ist an sich einen eigenen Post wert!

    Wenn ich dich richtig verstehe, pflegt die IT ein Hardware-Storyboard mit echten Story Cards zum Anfassen. Ich halte sehr viel von diesen „analogen“ Boards, weil sie einen direkten und natürlichen Überblick auf den Projektstatus erlauben.

    Allerdings sind sie aus meiner Sicht für das Arbeiten an mehreren Standorten denkbar ungeeignet, genau aus den Gründen, die du angeführt hast: Man kann sie nicht an mehren Standorten bedienen und nicht mitnehmen. Und möchte oder muss man den Projektfortschritt elektronisch dokumentieren und/oder auswerten, handelt man sich doppelten Pflegeaufwand ein.

    Meine Empfehlung ist daher, auf ein elektronisches Board umzustellen. Das Look & Feel eines analogen Boards wird hier so weit wie möglich erhalten. Es gibt inzwischen schon recht brauchbare digitale Lösungen in Form von großen Touch Screens, die man z.B. im StandUp fast genauso wie das analoge Board verwenden kann. Und das auch in einer Videokonferenz über Standorte hinweg.

    Es geht aber auch sehr gut mit einer reinen Software-Lösung, Screen Sharing und/oder Projektor. Damit habe ich jedenfalls bisher sehr gute Erfahrungen gemacht.

    Meines Wissens gibt es diese digitalen Boards auch mit direkter Integration von SharePoint, Jira und anderen Werkzeugen. Damit wären sogar mehrere Fliegen mit einer Klappe zu schlagen, denn der doppelte Pflegeaufwand würde damit hinfällig und Auswertungen stünden immer aktuell zur Verfügung.

    Ich habe selbst bereits mit Scrum for Team System als TFS-Template gearbeitet. Zwar ohne digitales Board an der Wand aber in einem großen, über mehrere Standorte verteilten Team. Inzwischen gibt es für den TFS ein recht brauchbares Scrum-Template direkt von Microsoft.

    Alternativ wäre Jira Agile (aka GreenHopper) zu nennen, das ich ebenfalls bereits eingesetzt habe. Genau wie beim TFS lässt sich das Jira Agile Template sehr flexibel auf den tatsächlich gelebten Prozess anpassen. Für Jira gibt es auch eine TFS-Integration.

    Etwas leichtgewichtiger ginge es z.B. mit http://kanbanflow.com. Vielleicht wäre das was für einen Testlauf….

    Ich hoffe, dir damit ein wenig geholfen zu haben.

    Viele Grüße und weiterhin viel Spaß und Erfolg in agilen Projekten!
    Benno

×

Updates

Schreiben Sie sich jetzt ein für unsere zwei-wöchentlichen Updates per E-Mail.

This field is required
This field is required
This field is required

Mich interessiert

Select at least one category
You were signed up successfully.

Erhalten Sie regelmäßige Updates zu neuen Blogartikeln

Jetzt anmelden

Oder möchten Sie eine Projektanfrage mit uns besprechen? Kontakt aufnehmen »