Nach der Scrum-Philosophie besteht ein Software-Entwicklungsprojekt idealerweise aus einem einzigen Team mit sieben Personen, die alle im selben Raum arbeiten. In der Praxis sieht es häufig anders aus: Das Projektteam ist so groß, dass eine Unterteilung in mehrere (Sub-)Teams angebracht ist. Darüber hinaus sind die Projektteams nicht selten über verschiedene Standorte verteilt. Die Notwendigkeit für große und verteilte Projektteams ergibt sich aus dem Umfang und der Komplexität der Anforderungen, die in einem engen Zeitrahmen realisiert werden müssen und der Frage, wo im Unternehmensverbund Ressourcen mit passenden Qualifikationen verfügbar sind.

Um die Verantwortlichkeiten der einzelnen Teams festzulegen, existieren verschiedene Ansätze. Im vorliegenden Artikel beschreiben wir unsere Erfahrungen mit zwei Teamformen: Komponententeams und Feature Teams. Unsere Erfahrungen beziehen sich auf mehrere nach Scrum durchgeführte Softwareprojekte mit jeweils bis zu fünf Teams in drei verschiedenen Ländern und einer Projektlaufzeit von bis zu zwei Jahren. Diese Projekte hatten zum Ziel, medizintechnische Anwendungen im Bereich der Strahlentherapie zu realisieren.

Erfahrungen mit Komponententeams

In den ersten Projekten bildeten wir Komponententeams. Dieser Ansatz erscheint logisch, da sich die Teamstruktur einfach an der Struktur der zu entwickelnden Applikation orientiert. Eine Applikation besteht aus einer Menge von interagierenden Komponenten, durch deren dynamisches Zusammenspiel die Anwendung so funktioniert, wie es vorgesehen ist. Bei diesem Ansatz übernimmt jedes Team die Verantwortung für eine oder mehrere Komponenten. Nur das jeweils zuständige Team darf Änderungen in einer Komponente vornehmen.

Diesem Ansatz folgend könnte es beispielsweise ein Datenbank-Team geben, das sich um die Definition des Datenbankschemas und die Programmierung der Datenzugriffsschicht kümmert, ein Geschäftslogik-Team, das die Implementierung der Geschäftslogik übernimmt und ein Front-end-Team, welches die Bedienoberfläche der Applikation bereitstellt.

Mehrere Teams koordinieren

Die meisten Features einer Applikation betreffen allerdings mehrere Komponenten, wobei es häufig vorkommt, dass diese Komponenten unterschiedlichen Teams zugeordnet sind. In diesen Fällen ist eine teamübergreifende Koordination erforderlich: Zunächst müssen sich die beteiligten Teams auf eine gemeinsame technische Lösung verständigen. Dies geschieht häufig durch die Mitwirkung eines übergeordneten Architekten. Als nächstes vereinbaren sie die Realisierungsreihenfolge und Bereitstellungstermine für die Komponenten. Und schließlich müssen geeignete Maßnahmen gefunden und abgestimmt werden, wenn sich die Zulieferung einzelner Komponenten verspätet. Da es sich um teamübergreifende Aktivitäten handelt, ist der Projektleiter (oder ein Mitglied des Kernteams) bei der Planung und Steuerung involviert. Bild 1 veranschaulicht diesen Ansatz.

Bild 1: Teamaufteilung nach Komponententeams.

Beispiel

Ein einfaches Feature könnte sein, die Anwendung um ein zusätzliches Informationsfeld zu erweitern. Dafür muss das Datenbank-Team ein Attribut in einer Datenbanktabelle ergänzen und die Datenzugriffsschicht entsprechend erweitern. Das Front-end-Team implementiert den Code, um diese neue Funktionalität der Datenzugriffsschicht aufzurufen und die Daten im User Interface zu repräsentieren. Auch wenn diese Änderung trivial erscheinen mag, so müssen die dafür nötigen Arbeitspakete teamübergreifend geplant werden. Abweichungen vom abgestimmten Vorgehen, etwa durch eine verspätete Bereitstellung einer Schnittstelle, können mitunter drastische Auswirkungen haben: Wenn das Datenbank-Team die Erweiterung der Datenzugriffsschicht nicht fristgerecht abschließen kann, ist das Front-end-Team blockiert und die Fertigstellung des gesamten Features verzögert sich.

Die Projektstruktur überdenken

Generell folgen alle unsere Projekte einem agilen Vorgehensmodell. Die Projektlaufzeit ist in einzelne Iterationen unterteilt, die jeweils das Ziel haben, eine bestimmte Menge an Features in vollem Umfang – Design, Implementierung, Unit Test, Integrationstest und Dokumentation – zu realisieren. Die Iterationen der einzelnen Teams verlaufen synchron, d.h. der Beginn und die Dauer jeder Iteration sind für alle Teams einheitlich. Innerhalb dieses Rahmens machten wir bei den Projekten, die wir mit Komponententeams realisierten, die folgenden Beobachtungen, die uns im Lauf der Zeit zum Nachdenken brachten, ob es nicht einen besseren Ansatz gibt, das Projekt zu strukturieren: