Die Beziehung zwischen Teamorganisation und Anwendungsarchitektur

Diese Beziehung ist als Conways Gesetz bekannt, das 1967 von Melvin Conway formuliert wurde und wie folgt lautet: \u201eOrganisationen, die Systeme entwerfen […], sind darauf beschr\u00e4nkt, Designs zu produzieren, die Kopien der Kommunikationsstrukturen dieser Organisationen sind.\u201c

Die Kommunikation innerhalb des Teams ist h\u00e4ufig und flie\u00dfend, mit regelm\u00e4\u00dfigen Planungsmeetings, Dailies, Retrospektiven und Demos. Dies erm\u00f6glicht dem Team ein hohes Ma\u00df an Abstimmung und agiler Koordination, was f\u00fcr die Entwicklung einer Komponente grundlegend ist. Wenn Sie pl\u00f6tzlich beschlie\u00dfen, dieses Team in 2 Teams aufzuteilen, entsteht ein Bruch in der Kommunikation. Die Kommunikation mit anderen Teams ist viel seltener, da eine der Ideen von Teams darin besteht, sie von externen Einfl\u00fcssen zu isolieren, damit sie sich auf ihren Bereich konzentrieren k\u00f6nnen. Diese Reduzierung der Kommunikation zwischen den Teams macht die Aufgabe, eine einzelne Komponente zu pflegen, komplexer. In diesen F\u00e4llen gibt es zwei M\u00f6glichkeiten: 1) Die Komponente in 2 aufteilen, eine pro Team, was den Teams erlaubt, sich zu entkoppeln und autonomer zu arbeiten. 2) Eine einzelne Komponente beibehalten, was die Einrichtung einer Reihe von Koordinationsmechanismen und Meetings zwischen den Teams erfordert, mit der damit verbundenen Mehrbelastung. Dar\u00fcber hinaus sind die Teams voneinander abh\u00e4ngig, was Geschwindigkeit und Autonomie reduziert und die Produktivit\u00e4t beeintr\u00e4chtigt (da sie so eng zusammenarbeiten m\u00fcssen, k\u00f6nnte man fast sagen, dass es praktisch immer noch nur ein Team gibt).

Traditionell wird die Teamreorganisation oft von oben durchgef\u00fchrt, und nicht immer von Personen mit tiefem Wissen \u00fcber die Anwendungsarchitektur. Immer wieder sah ich Teams um Kunden herum reorganisiert werden, sodass bei einem neuen Kunden ein neues Team gebildet wurde. Und in einigen F\u00e4llen endeten wir damit, den Code zu forken, damit das neue Team unabh\u00e4ngig und agil sein konnte. Mit allem, was das mit sich bringt: den Code zu duplizieren, mit all seinen Bugs und technischen Schulden;

Um eine architektursensibelere Reorganisation durchzuf\u00fchren, die die Anwendung nicht negativ beeinflusst, gibt es das sogenannte umgekehrte Conway-Man\u00f6ver. Dieses besteht darin, das Team so zu organisieren, dass es die Architektur der zu erreichenden Anwendung nachbildet. Um diese Art von Reorganisation zu entwerfen, ist es unerl\u00e4sslich, auf die Zusammenarbeit von Software-Architekten zu z\u00e4hlen, die bei der Gestaltung unter Verwendung von Software-Architekturprinzipien helfen. Teams k\u00f6nnen als System betrachtet werden, mit verschiedenen Komponenten mit ihren Verantwortlichkeiten, deren Kommunikation \u00fcber gut definierte Schnittstellen erfolgt.

Wenn Sie sich f\u00fcr dieses Thema mehr interessieren, empfehle ich das Buch Team Topologies von Matthew Skelton und Manuel Pais. Und wenn Sie Hilfe oder Beratung ben\u00f6tigen, wie Sie eine Reorganisation angehen k\u00f6nnen, k\u00f6nnen Sie mich hier kontaktieren.