Wie wir lernen, dem Team zu vertrauen Zusammenarbeit beim Trunk-based Development

Anbieter zum Thema

Turbine Kreuzberg GmbH

PresseBox - unn | UNITED NEWS NETWORK GmbH

FIS Informationssysteme und Consulting GmbH

Softwareentwicklung in Teams setzt oft auf Feature Branching. Das ist nicht ideal und manchmal eine echte Fehlerquelle. Trunk Based Development führt häufig zu besseren Ergebnissen und macht das Programmieren im Team reibungsloser.

Wer in letzter Zeit an einem größeren Softwareprojekt gearbeitet hat, weiß, wie Teams in der Regel zusammenarbeiten: Die Entwickelnden erstellen einen „Branch“ neben der „Mainline“ (auch Main oder Master Branch), wenn eine neue Funktion programmiert wird. Sobald diese fertig ist, wird der Branch wieder mit der Mainline zusammengeführt.

Das Feature Branching hat sich in den vergangenen Jahren de facto als Norm durchgesetzt. Der größte Vorteil liegt auf der Hand: Die Developer können neue Funktionen ausprobieren und weiterentwickeln, ohne an der Mainline etwas kaputtzumachen. Mehrfache und gegenseitige Überprüfungen der Branches vor dem Zusammenführen mindern das Risiko von Fehlern und mangelhaften Code-Architekturen.

„Die Norm“ entspricht allerdings nicht unbedingt dem Optimum:

• 1. Die Entwicklung auf Grundlage von Feature-Branching isoliert die Entwickelnden und den Code vom Rest des Teams.

• 2. Die Developer müssen ständig zwischen verschiedenen Kontexten hin- und herwechseln, vor allem, weil mehrere Teammitglieder den Code ständig überprüfen und korrigieren müssen.

• 3. Ein großer Teil der Entwicklung ist für den Rest des Teams lange Zeit unbekannt. Dadurch drohen späte Codekonflikte.

• 4. Die Entwicklung mit separaten Funktionszweigen ist für einzelne Entwickler und Entwicklerinnen optimiert, nicht aber für Teams.

Gemeinsam als Team coden, nicht alle für sich

Die Lösung ist denkbar einfach: gemeinsam als Team programmieren – und zwar nicht als Gruppe isolierter Entwicklerinnen und Entwickler, sondern wirklich als Team im ständigen Austausch.

Doch eine Gruppe ist noch lange kein Team, nur weil mehr als eine Person gleichzeitig an einem Ziel arbeitet. Wie kann man also wirklich als Team programmieren? Ganz einfach: Indem man (fast) immer zu zweit programmiert und (fast) nie PR-Reviews durchführt, indem man diese Paare ständig durchmischt (von Tag zu Tag) und indem man seinen Code so oft wie möglich in die Mainline („Trunk“) integriert.

Dies also ist „Trunk Based Development” (TBD); ein anderer – und auf lange Sicht hilfreicher – Ansatz für bessere Zusammenarbeit von (kleineren) Developer-Teams. Die Idee ist simpel: Alle Beteiligten übertragen mehrmals am Tag den Code in die Mainline. Branches sind die seltene Ausnahme. Wenn nicht mindestens zu zweit programmiert wird, setzt das Team auf Mob-Programming. Außerdem prüfen ein Pre-Commit-Hook und automatisierte Checks, ob alle Rapid Tests für die aktuelle Mainline erfolgreich sind.

Wille, Vertrauen und automatisierte Überprüfung

Bevor man jedoch auf TBD setzt, müssen einige Voraussetzungen erfüllt werden:

• 1. Das Team muss bereit sein, Gewohnheiten zu ändern, und die individuellen Vorstellungen vom Programmieren in der Gruppe überdenken.

• 2. Alle arbeiten ständig in der Mainline. Das erfordert ein hohes Maß an Vertrauen in die Individuen sowie in ihre Fähigkeiten und ihr Fachwissen. Dazu zählt die Fähigkeit zur testgetriebenen Entwicklung von Funktionalität in kleinen Inkrementen (Stichwort: Test Driven Development).

• 3. Schnelle und automatisierte Tests müssen die Mainline durchgängig prüfen und frühzeitig Alarm schlagen.

Zuerst ein Probelauf – und dann einfach nicht mehr aufhören

Für die Einführung ist es ratsam, zunächst mit einem oder mehreren Probeläufen zu starten –wenn möglich in zwei unterschiedlichen Teams, um die Erkenntnisse direkt mitzunehmen.

Im ersten Team ist oft noch mehr Überzeugungsarbeit nötig, um auch die Vorteile des TBD-Ansatzes aufzuzeigen. Der Start in die Pilotphase eignet sich daher besonders für ein oder zwei Sprints. So kann man bewerten, ob der Ansatz für die eigenen Teams generell funktioniert und an welcher Stelle er an die eigenen Bedürfnisse angepasst werden muss.

Als Richtwert eignet sich in den ersten Wochen, die Anzahl der Fehler in der Mainline zu notieren. Wichtig: Die Fehler sollten eigentlich durch die automatisierten Tests aufgefangen werden. Dennoch kann das Team dadurch das Gefühl, die Kontrolle bei ausbleibenden Peer-Reviews der Merge-Requests zu verlieren, mit einer Zahl benennen beziehungsweise quantifizieren. Die Erfahrung zeigt, dass die Angst nach einigen Wochen oft nachlässt und gleichzeitig das Vertrauen in die automatisierten Prüfungen und vor allem die Fähigkeiten der Fachkräfte wächst.

Der Probelauf in einem zweiten Team läuft dann oft sehr viel einfacher. Nach Vorstellung der Gesamterfahrung des ersten Teams zu TBD kann der Wechsel zum neuen Ansatz in den Raum gestellt werden. So kann das Team selbst entscheiden, ob und wie das für einen Sprint getestet werden kann.

Die Vorteile von Trunk Based Development

Gemeinsam als Team zu programmieren hat oft seine Tücken, aber auch viele Vorteile:

Reibungslose Abläufe: Kein Wechsel mehr zwischen verschiedenen Kontexten, um Überprüfungen durchzuführen. Somit können sich alle auf den Produktionsfluss konzentrieren.

Bessere Anpassung der Entwicklung: Durch die frühe Integration werden Konflikte schneller sichtbar in Code, Logik und Architektur. Dadurch können die Developer auch schneller darauf reagieren.

Geteilte Verantwortung: Die Verantwortung für das Produkt wird breiter im Team verteilt. Niemand ist nur für einzelne Zweige zuständig, sondern alle sind immer an der Arbeit aller beteiligt.

Mehr Zusammenhalt: Die gemeinsame Verantwortung führt zu besserem Zusammenhalt in der Gruppe. Alle bauen gemeinsam etwas auf, statt dass jeder und jede einen in sich geschlossenen Teil beisteuert.

Geteiltes Wissen: Die wechselnden Programmierpaare tauschen im täglichen Arbeiten ganz automatisch Fachwissen aus. Dadurch erhöht sich der Wissensstand des gesamten Teams.

Front- und Back-End rücken zusammen: Front- und Back-End-Developer kommunizieren mehr miteinander und arbeiten ab einem bestimmten Punkt direkt zusammen. Auf diese Weise lernen sie die jeweils andere Domäne unmittelbar besser kennen.

Alles eine Frage der Einstellung

Überzeugungsarbeit kann sich also lohnen: Ein Team, das mit TBD ein Projekt umsetzen möchte und sich entsprechend darauf einlässt, ist die beste Voraussetzung für den Erfolg des Ansatzes. Eine zögerliche Minderheit, die sich gegen die Einführung des neuen Systems sträubt, macht die Sache schon schwieriger. Mit einem Teamsplit kann diese Minderheit in ihrem Tempo abgeholt werden.

Wichtig bei TBD ist die Kommunikation: Es wird Herausforderungen mit diesem Ansatz geben–solange diese aber umfangreich im Team diskutiert werden, lassen sie auch gemeinsam beseitigen. So können sich alle auf TBD einlassen und gemeinsam eine Vertrauensbasis aufbauen. Um Widerstand und Ablehnung von vornherein zu minimieren, sollte die Umstellung als Probelauf angelegt werden. Zwar mag die Einführung eines neuen Prozesses anfangs aufregend sein, stößt aber auch oft auf wenig Gegenliebe, sobald der neue den gewohnten Prozess ersetzen soll. Denn es ist schwierig, über einen langen Zeitraum erlernte Verhaltensmuster zu ändern.

Ein gutes Bild dafür ist das „Tal der Verzweiflung“: Konsequente Systemänderungen senken zunächst die Produktivität und Motivation der IT-Fachkräfte, da sie damit beschäftigt sind, sich an Veränderungen anzupassen. Eine offensichtlich beschränkte Testphase, zum Beispiel angelegt für den nächsten Sprint, hält das Tal der Verzweiflung möglichst flach. Tiefgreifende Änderungen brauchen eine Weile und nur mit gegenseitiger Unterstützung kann man gemeinsam das Tal der Verzweiflung durchschreiten. Der Weg zur Akzeptanz dauert immer seine Zeit.

Trunk-based Development bedeutet für die meisten Teams eine fundamentale Änderung. Dorthin zu kommen, setzt voraus, dass das Team noch höhere Anforderungen an eine professionelle Arbeitsweise erfüllt: Pair-Programming und testgetriebene Entwicklung sind zwingend notwendige Bedingungen. Allein damit eröffnet sich dem Team das Potenzial, besseren Code zu schreiben. Der Wechsel auf TBD ermöglicht zusätzlich einen weniger von Unterbrechungen geplagten Arbeitsfluss. Durfte man diesen Flow im Team einmal erleben, möchte man nie mehr zurück.

* Moritz Deißner ist Technical Director bei Turbine Kreuzberg. Der studierte Informatiker verfügt über mehr als zehn Jahre Erfahrung in den Bereichen Fintech und E-Commerce. Aktuell liegt sein Fokus auf der Entwicklung transaktionaler Plattformen.

(ID:48534584)