Aktionen

Architekturlösungen im Team entwickeln

Aus PQWiki


SE-Disziplin

Schnelligkeit
★★☆
Einfachheit
★★☆
Agilität
★★★

Ziele

* Explizite Erarbeitung von Lösungskonzepten und Wissensverbreitung im Team
  • Identifikation der Teammitglieder mit den entwickelten Lösungen
  • Konsolidierte Architekturdefinition und -Beschreibung

Motivation/Problemstellung

In agilen Entwicklungsteams werden Architekturentscheidungen meist nicht von einer Person alleine getroffen, die eine dedizierte Architektenrolle übernimmt. Häufig wird diese Rolle im Team verteilt. Lösungen werden diskutiert und Entscheidungen von einzelnen Teammitgliedern während der Entwicklungsarbeit getroffen, oder von einzelnen Teilgebietsexperten übernommen, die dann als Architekten für einen bestimmten Bereich fungieren. Solche Lösungen entstehen unter Umständen im Verborgenen, was dazu führen kann, dass technische Einwände nicht berücksichtigt und potentiell geeignetere Lösungen übersehen werden. Außerdem besteht die Gefahr dass Lösungen nicht allen Teammitgliedern bekannt sind und getroffene Entscheidungen auf Unverständnis stoßen. Bei der Entwicklung von Architekturkonzepten können Teams von den Erfahrungen aller Entwickler profitieren. Teammitglieder identifizieren sich mehr mit Lösungen bei denen sie selbst oder viele Entwickler des Teams mitgearbeitet haben. Außerdem wird so Wissen über die Lösungen stärker verteilt, was in agilen Entwicklungsszenarien mit geringem Dokumentationsfokus zu insgesamt nachhaltigeren Lösungen führt.

Kurzbeschreibung

Architekturlösungen im Team.png
Die Auswahl einer User-Story oder eines Epics zur Bearbeitung, welches ein umfassendes Konzept benötigt oder das Auftreten neuer Anforderungen, deren Lösung noch unklar ist, sind typische Startpunkte für den Einsatz dieser Best Practice. Fragestellungen wie Synchronisation von Offline-Daten, Backup-Strategie oder Sicherstellung von Hochverfügbarkeit sind Beispiele. Die Erarbeitung einer Architekturlösung wird als explizite Aufgabe in der Iteration eingeplant. Dabei übernimmt ein Entwickler die Verantwortung für die Ausarbeitung der Architekturlösung, bezieht aber andere Entwickler oder das gesamte Entwicklungsteam mit ein. Eine Aufgabenstellung wird dabei in Teilaufgaben unterteilt, offene Fragestellungen identifiziert, Aufgaben verteilt und von verschiedenen Entwicklern ausgearbeitet. Der Konzept-Verantwortliche übernimmt die Organisation und Konsolidierung. Das Konzept wird so lange diskutiert und weiterentwickelt, bis es sich zur direkten Umsetzung eignet.

Input

Die relevanten System-Anforderungen (bspw. Backlog mit geplanten User Stories und Epics) mit einer konkrete Aufgabenstellung, für die ein Architekturkonzept benötigt wird

Output

Ein Architekturkonzept, welches unter Einbeziehung der Erfahrungen des Teams erarbeitet wurde

Rahmenbedingungen

Rolle (Ausführender)

Der Konzept-Verantwortliche: ein Entwickler des Entwicklungsteams

Werkzeuge, Hilfsmittel

Es sind keine gesonderten Werkzeuge notwendig

Vorkenntnisse und Erfahrungen

Nach Möglichkeit, technische Vorkenntnisse zur Erarbeitung der Initiallösung, Vorkenntnisse bei der Moderation von Meetings

Ort und Umgebung

Meeting-Raum für die Konzept-Meetings

Weitere Teilnehmer

Ausgewählte Mitglieder oder das gesamte Entwicklungsteam

Voraussichtliche Dauer

Unterschiedlich, je nach Komplexität der Aufgabe und Erfahrungen des Entwicklungsteams. Nicht länger als eine Iteration, sonst Unterteilung in Teilarchitekturaufgaben

Vorgehensweise

Vorbereitung

Bei der Sprint-Planung wird entschieden eine Architekturlösung für eine Anforderung im Team zu entwickeln, die in einer nächsten Iteration umgesetzt werden soll. Das Team bestimmt einen Verantwortlichen für die Architekturlösung. Dieser kümmert sich um die Organisation von Besprechungen, die Konsolidierung der Informationen und Aufbereitung der Lösung. Eine Aufgabe und entsprechender Aufwand dafür wird in der Iteration explizit eingeplant. Außerdem wird entschieden, welche Teammitglieder bei der Erarbeitung beteiligt sein sollen. Dies können das gesamte Projektteam oder aber nur einige wenige Mitglieder, beispielsweise aufgrund passender Vorerfahrungen sein. Der Verantwortliche bereitet die gemeinsame Erarbeitung des Konzeptes vor. Dies umfasst zunächst die initiale Zerlegung der Gesamtfragestellung in Einzelteile, die als einzelne Architekturaufgaben bearbeitet werden können. Mögliche Aspekte, die eine solche Zerlegung leiten können, sind die Systemteile oder Teile des geplanten Nutzungsszenarios. Anhand dieser Unterteilung erarbeitet der Verantwortliche initiale Lösungsvorschläge und eine erste Vision des Architekturkonzeptes, zusammen mit Informationen zu relevanten Technologien, Fragestellungen, offenen Punkten, kritischen Aspekten, usw. als Grundlage für die gemeinsame Diskussion. Diese Punkte sollten so weit ausgearbeitet sein, dass eine sinnvolle Diskussion ermöglicht wird.

Durchführung


Ist eine Konzeptvision erarbeitet, organisiert der Verantwortliche einen Termin für das erste Konzeptmeeting. Die zuvor ausgewählten Teammitglieder werden dabei einbezogen. Das Konzeptmeeting besteht aus folgenden Teilen:
  • Präsentation: Der Verantwortliche stellt das Thema, die Zergliederung in Einzelteile, die erste Architekturvision, sowie die weiteren erarbeiteten Punkte dem Entwicklungsteam vor.
  • Diskussion: Das Team diskutiert die vorgestellten Themen. Änderungsbedarfe, Widersprüche und Verbesserungsvorschläge werden besprochen bis das Team einen Konsens gefunden hat. Die besprochenen Änderungen werden aufgenommen und in den Initialvorschlag integriert. Das Ergebnis ist ein abgestimmter Konzeptentwurf.
  • Aufgabenverteilung: Anhand der Themenunterteilung werden Architekturaufgaben im Team verteilt. Die jeweiligen Teammitglieder sind dann für weitere Ausarbeitung Ihrer Teilthemen verantwortlich.

Nach dem ersten Konzeptmeeting erarbeiten die einzelnen Teammitglieder Detaillösungen für ihre jeweiligen Aufgaben. Diese Lösungen sollten nach Möglichkeit so weit ausgearbeitet werden, dass eine unmittelbare Umsetzung basierend darauf möglich ist. Um die Konfidenz für die Eignung eines Lösungskonzeptes zu erhöhen, kann die Erstellung von Prototypen eingesetzt werden. Dazu wird für einen schmalen Fokus eine möglichst realistische Situation nachgestellt, in der das Konzept umgesetzt und der Einsatz der angedachten Technologien ausprobiert wird.

Haben alle Teammitglieder Ihre Teil-Architekturaufgaben fertig bearbeitet, organisiert der Konzeptverantwortliche das nächste Konzeptmeeting, in dem die Teammitglieder Ihre jeweiligen Lösungen vorstellen und diese erneut gemeinsam diskutiert werden. Wird dabei erneut Bedarf für eine weitere konzeptionelle Ausarbeitung festgestellt, werden abermals Aufgaben verteilt und von Teammitgliedern erarbeitet. Dies wird so lange wiederholt bis das Konzept weit genug ausgearbeitet und bei der Diskussion ein Konsens erzielt wurde. Danach werden entsprechende Aufgaben für die Umsetzung des Konzeptes definiert und eingeplant.

Nachbereitung

Der Konzeptverantwortliche konsolidiert die erarbeiteten Teillösungen und ergänzt die Dokumentation der wichtigsten Aspekte des Konzeptes, so dass diese später vom ganzen Team nachvollzogen werden können. Insbesondere die Erfassung der Gründe, warum Entscheidungen auf eine bestimmte Weise getroffen wurde, ist dabei von Relevanz.

Werden im Verlauf der Entwicklung getroffene Architekturentscheidungen geändert, sollten diese an den Konzeptverantwortlichen kommuniziert, von diesem an das Projektteam weitertransportiert und die Konzeptdokumentation aktualisiert werden.

Gütekriterien/Empfehlungen

[[Recommendation::Die Anerkennung von Architekturarbeit als relevante Entwicklungstätigkeit ist eine notwendige Voraussetzung für den Einsatz dieser Best Practice. Die Erarbeitung von Architekturlösungen bringt keinen direkt sichtbaren Mehrwert für den Kunden. Daher kann es schwierig sein, die notwendige Zeit dafür einplanen zu können. Dies ist insbesondere in Situationen mit hohem Zeitdruck der Fall. Dennoch sollte die Erarbeitung von Architekturlösungen nach Möglichkeit durchgesetzt werden, eine Vernachlässigung kann zur Aufnahme von technischen Schulden (vgl. [1]) führen und damit zu höheren Aufwänden zu einem späteren Zeitpunkt, sowie insgesamt weniger nachhaltigen Lösungen und potentiellen Wartungsproblemen.]]

Risiken

Die Anwendung hat folgende Risiken
  • Erschwerte Entscheidungsfindung durch gleiche Rechte aller Teammitglieder. Hier ist die geschickte Moderation des Konzeptverantwortlichen notwendig.
  • Dominanz einzelner Teammitglieder kann dazu führen, dass Einschätzungen anderer nicht berücksichtigt werden. Hier ist die geschickte Moderation des Konzeptverantwortlichen notwendig.
  • Falsche Auswahl der Teammitglieder für spezielle Fragestellungen. Die Auswahl sollte an Vorkenntnis in dem betreffenden Bereich orientiert sein.
  • Konsolidierung und Dokumentation des Konzeptes zu umfangreich - Verursacht hohen Aufwand und verringert potentiell das Commitment
  • Konsolidierung und Dokumentation des Konzeptes zu gering - Wichtige Aspekte gehen verloren und werden nicht berücksichtigt.

Einordnung in das PQ4Agile-Qualitätsmodell

Schlagworte

Architekturlösung, Architekturkonzept, Entwicklungsteam

Weiterführende Informationen

Literatur

-