Diese Frage lässt sich nicht so einfach beantworten, denn es handelt sich dabei um das Themengebiet der Skalierung von agilem Software Engineering.

Während agiles Software Engineering in kleinen Projekten (Scrum) möglich ist, muss für mittlere und größere Projekte dafür gesorgt werden, das mehrere Teams in einem Projekt effektiv zusammenarbeiten können. Auch hier soll sich auf die reibungslose Zusammenarbeit innerhalb von Teams und teamübergreifend konzentriert werden.

Wenn jedes einzelne Team jeweils in der Lage sein soll, für den Nutzer relevante Funktionen umzusetzen, dann müssen in einem Team auch alle Rollen und Kompetenzen vorhanden sein, um dies tun zu können. Soll beispielsweise eine Java-Webanwendung entwickelt werden, muss das Team in der Lage sein, die grafische Benutzeroberfläche (GUI), die Geschäftslogik, die Datenbankanbindung und die Webserviceschnittstellen zu entwerfen, zu implementieren, zu testen und zu dokumentieren.

Welche Kompetenzen genau in einem Team vorhanden sein müssen, ist abhängig vom Projektauftrag, der Organisation und den eingesetzten Technologien. Auf diese Weise können verschiedene Teams unabhängig voneinander komplette Bestandteile des Systems erstellen. Werden Teams hingegen entsprechend der Rollen zusammengestellt, beispielsweise je ein Team für GUI-Entwicklung, Datenbankentwicklung und Geschäftslogikentwicklung, gibt es teamübergreifende Abhängigkeiten zwischen den Ergebnissen und die für den Kunden sichtbaren Produktfunktionen werden nicht in einem Team, sondern über mehrere Teams hinweg erstellt.

Große, komplexe Anwendungen bestehen häufig aus vielen verschiedenen Komponenten und haben Schnittstellenbeziehungen zu vielen anderen Systemen. Um die agilen Prinzipien auch in solchen großen Projekten gut anwenden zu können, müssen die daran arbeitenden Teams entsprechend organisiert werden. Im Folgenden werden dazu drei Organisationsformen für agile Teams vorgestellt, dessen Wirkungsweise gleich von mir näher beschrieben wird:

  • Funktionsteams
  • Komponententeams
  • Mischform aus Funktionsteams und Komponententeams

Stellen wir uns vor es wird mehr als ein Product Backlog bearbeitet, wie du in der Abbildung sehen kannst.

In dieser Abbildung gibt es zwei parallele Product Backlogs, die jeweils einzeln für sich stehen. Wichtige Systemkomponenten sind Komponente 1, Komponente 2 und Komponente 3, die jeweils von einem eigenen Komponententeam entwickelt, gepflegt und weiterentwickelt wird. Die Komponententeams sind jeweils Experten auf ihrem Gebiet. Zur Umsetzung von Funktionen aus den Product Backlogs müssen Arbeiten an den jeweiligen Systemkomponenten durchgeführt werden. Ein Softwarearchitekt verfeinert die Product Backlog-Elemente aus Backlog A und Backlog B in entsprechende Teilaufgaben. Diese werden als Elemente zu den Komponenten-Backlogs hinzugefügt. Die Komponententeams verwalten ihr Komponenten-Backlog eigenständig. In dieser Organisationsform ist nicht gewährleistet, dass die Priorität der einzelnen Product Backlogs auf die Komponenten-Backlogs abgebildet wird. Im schlimmsten Fall werden bestimmte Elemente aus einem Product Backlog immer wieder nach hinten gestellt, weil aus Sicht des Komponententeams dringendere Aufgaben im eigenen Backlog stehen. Mit der Organisation ausschließlich in Komponententeams besteht die Gefahr, dass der Arbeitsablauf eines Produkts oder Projekts gefährdet wird, weil es kein Team gibt, das sich über alle Komponenten hinweg dafür zuständig fühlt.

Im Gegensatz zu Komponententeams sind Funktionsteams nicht für einzelne Systemkomponenten verantwortlich, sondern jeweils für Produktfunktionen, die sich über mehrere Systemkomponenten verteilen können.

In der folgenden Abbildung veranschauliche ich dazu ein kleines Beispiel.

Für zwei parallele Product Backlogs gibt es jeweils ein zuständiges Team. Werden zu einem Backlog-Element Aufgaben in verschiedenen Systemkomponenten identifiziert, werden dazu jeweils eigene Backlog-Elemente erstellt. Diese technischen Aufgaben werden jetzt jedoch nicht in ein Komponenten-Backlog geschrieben, sondern bleiben im jeweiligen Product Backlog und die Zuständigkeit dabei beim Team. Das Team muss dazu die Kompetenzen für die Arbeit an einzelnen Bausteinen besitzen. Auf diese Weise kann bezogen auf jedes Backlog eine ideale und störungsfreie Abarbeitung der Backlog-Items erfolgen. Im Gegensatz zu den Komponententeams liegt hier der Fokus nicht auf den einzelnen Komponenten, sondern deren Zusammenspiel in den jeweiligen Projekten.

Die Abhängigkeiten zwischen den Aktivitäten der einzelnen Teams gibt es nun nur noch bei der Arbeit an den Systemkomponenten. Da sich nun jedoch kein eigenes Team mehr um die Pflege und Weiterentwicklung der einzelnen Komponenten kümmert, besteht hier die Gefahr, dass die jeweils verteilte, unabhängige Weiterentwicklung der Komponenten durch unterschiedliche Teams zu hohen technischen Schulden führt.

Eine Mischform aus Komponententeams und Funktionsteams ist in der folgenden Abbildung dargestellt.

Hierbei ist die Bearbeitung von Product Backlog-Elementen in Funktionsteams (Team 1 und Team 2) organisiert, die jeweils für sich Elemente eigenständig in allen Komponenten umsetzen. Der störungsfreie Arbeitsablauf an einem Produkt ist damit sichergestellt.

Zusätzlich gibt es aber noch Komponententeams, die jeweils sogar ein eigenes Komponenten-Backlog bearbeiten. In den Komponententeams sind daher Spezialisten zusammengefasst, die über ein sehr hohes Detailwissen zu den Komponenten verfügen. Die Aufgabe der Komponententeams ist die Integrität der einzelnen Komponenten sicherzustellen, diese zu pflegen und geeignet weiterzuentwickeln. Ein Komponenten-Backlog enthält dazu in der Regel sehr technische Elemente. Auf diese Weise ist die kontinuierliche Pflege der Komponenten gewährleistet, obwohl mehrere Teams gleichzeitig an ihnen arbeiten.

Darüber hinaus können Mitglieder von Komponententeams gezielt einzelnen Produktteams zugewiesen werden und dort als Teammitglied mitarbeiten. Auf diese Weise können Komponentenspezialisten ihr Wissen über Komponenten in Funktionsteams tragen und an andere Kollegen weitergeben. Außerdem sammeln sie durch die Mitarbeit in Funktionsteams Erfahrungen und Feedback, das sie mit in ihr Komponententeam zurücknehmen, sowie Änderungs- und Anpassungswünsche, die sie mit in das Komponenten-Backlog aufnehmen können.

Tags:
0 Comments

Leave a reply

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

* Die Checkbox für die Zustimmung zur Speicherung ist nach DSGVO zwingend.

Ich akzeptiere

Nehmen Sie Kontakt zu mir auf

Möchten Sie, dass ich in Ihrem Unternehmen Anforderungsmanagement 4.0 einführe?

Benötigen Sie allgemein Unterstützung im Thema Requirements Engineering und/oder IT Projektmanagement?

Lassen Sie uns gemeinsam herausfinden, wie ich Sie unterstützen kann oder ob ich auf einer Ihrer vakanten Stellen passe.

Sending

©2018 Pierre Holger Braun (Wirtschaftsinformatiker, Requirements Engineer, Projektmanager, Software Engineer & Blogger)

Log in with your credentials

Forgot your details?