Kleinere Teams sind in der Softwareentwicklung oft erfolgreicher. Dr. Milan Milanović erklärt, wie die Optimierung der Teamgröße zu effizienterer Kommunikation und besserer Codequalität führt. 

Von Dr. Milan Milanović

Eure Softwarearchitektur ist immer so komplex wie eure Organisation

Habt ihr schon mal von Conways Gesetz gehört? Es ist eine Theorie, die 1967 vom Informatiker Melvin Conway entwickelt wurde und besagt: „Organizations, who design systems, are constrained to produce designs which are copies for the communication structures of these organizations.“ Mit anderen Worten, die Struktur eines Softwaresystems wird oft durch die Struktur und Kommunikationsmuster innerhalb des Teams beeinflusst, das es aufbaut. 

Dies kann zu einer optimaleren Softwarearchitektur für das zu lösende Problem führen, da sich das Team auf seine eigenen organisatorischen Bedürfnisse konzentrieren kann anstatt auf die Bedürfnisse des Systems. Dies bedeutet, dass eine Organisation mit kleinen, verteilten Teams eine modulare Servicearchitektur produzieren wird, während eine Organisation mit großen, zusammengelegten Teams eine monolithische Architektur hervorbringt. Im weiteren Sinne definiert die Personalabteilung unsere Softwarearchitekturen. 

Um dies zu mildern, können wir das Inverse-Conway-Manöver verwenden. Anstatt unsere bestehende Organisationsstruktur unsere Softwarearchitektur diktieren zu lassen, sollten wir zunächst die ideale Architektur für unsere Software festlegen und dann unsere Teams und Kommunikationsstrukturen organisieren, um sie mit dieser gewünschten Architektur in Einklang zu bringen. Dies kann zu besserer Software führen. 

Wenn sich Organisationsstrukturen ändern, muss die Softwarearchitektur möglicherweise weiterentwickelt werden, um diese Änderungen widerzuspiegeln. Beispielsweise müssen, wenn zwei Teams zusammengeführt werden, die von ihnen verwalteten Komponenten enger integriert werden. 

Bei der Entscheidung über die Architektur ist es wichtig, nicht nur technische Anforderungen, sondern auch Team- und Organisationsdynamiken zu berücksichtigen. Beispielsweise könnte die Annahme einer monolithischen Architektur technisch einfacher für ein kleines Start-up sein, aber mit dem Wachstum des Unternehmens und der Verstärkung der Teams könnte diese Architektur zu einem Engpass führen. 

Dennoch sehen wir, dass viele Organisationen Conways Gesetz ignorieren und denken, dass Organisationsstrukturen und Softwarearchitektur voneinander losgelöst sind, was letztendlich zu Überraschungen führt.

Organisationsdiagramme (Manu Cornet, bonkersworld.net)

Wie die Organisationsstruktur die Codequalität vorhersagt

Ein Team von Forschern für Microsoft Research veröffentlichte 2008 eine Studie, die zeigt, wie die Organisationsstruktur die Softwarequalität beeinflusst. Ihre Fallstudie über Windows Vista ergab, dass organisatorische Maßnahmen bessere Prädiktoren für die Codequalität sind als traditionelle. 

Zu den traditionellen Messgrößen gehören Code Churn, Codekomplexität, Fehler vor der Veröffentlichung, Abhängigkeiten und Codeabdeckung. 

Organisatorische Messgrößen sind: 

1. Anzahl der Ingenieure, die an einem Code gearbeitet haben und noch im Unternehmen beschäftigt sind. Je mehr Personen den Code berührt haben, desto geringer ist die Qualität.
   
   
2. Anzahl der Ex-Ingenieure: Dies ist die Gesamtzahl der einzelnen Ingenieure, die einen Code berührt haben und das Unternehmen zum Zeitpunkt der Veröffentlichung des Softwaresystems verlassen haben. Ein signifikanter Verlust von Teammitgliedern wirkt sich auf den Wissenserhalt und damit auf die Qualität aus.
   
   
3. Änderungshäufigkeit: Dies ist die Gesamtzahl der Bearbeitungen des Quellcodes, aus dem der Code besteht. Je mehr Komponenten bearbeitet werden, desto höher ist die Instabilität und desto geringer ist die Qualität.
   
   
4. Tiefe des Master Ownership: Der Grad des Code Ownership (oder der Codeverantwortung) hängt von der Anzahl der vorgenommenen Änderungen ab. Je geringer der Grad, desto besser die Qualität.
   
   
5. Prozentualer Anteil der an der Entwicklung beteiligten Organisationen: Das Verhältnis der verschiedenen internen Organisationen, die den Code berührt haben. Je niedriger der Anteil, desto lokaler ist die Codeverantwortung, was zu geringeren Koordinationsproblemen und besserer Codequalität führt.
   
   
6. Grad des organisatorischen Code Ownership: Der Prozentsatz der Bearbeitungen durch die Organisation, die den Code Owner einschließt, oder, falls es keinen spezifischen Owner gibt, von der Organisationseinheit, die den Code hauptsächlich verantwortet. Je kohärenter die Mitwirkenden (organisatorisch) sind, desto höher ist die Qualität.
   
   
7. Gesamt-Ownership der Organisation: Dies ist das Verhältnis des Prozentsatzes der Personen in der verwaltenden Organisation im Verhältnis zur Gesamtzahl der Ingenieure, die den Code bearbeiten – je kohärenter die Beiträge (Bearbeitungen) sind, desto höher ist die Qualität.

Von hier aus können eine stärker lokalisierte Codeverantwortung und eine geringere Koordination zwischen verschiedenen Organisationseinheiten die Codequalität verbessern. Um die Softwarequalität zu verbessern, sollten Unternehmen daher eine Optimierung ihrer Organisationsstruktur in Erwägung ziehen, indem sie die lokale Verantwortung für den Code fördern, die Anzahl der Mitwirkenden an bestimmten Codeabschnitten minimieren und die Herausforderungen der organisationsübergreifenden Koordination verringern.

Der Einfluss der Organisationsstruktur auf die Softwarequalität (Microsoft Research)

Warum gewinnen kleine Teams?

In seinem im Jahr 2000 veröffentlichten Buch The Tipping Point versuchte Malcolm Gladwell herauszufinden, warum sich manche Ideen schnell unter den Menschen verbreiten und andere nicht und welche Faktoren diese Verbreitung beeinflussen. Einer der entscheidenden Punkte, die ihm auffielen, waren die Vorteile von Gruppen mit weniger als 150 Personen (The Rule of 150). 

Er verknüpfte dies mit der Arbeit des britischen Anthropologen Robin Dunbar, der eine kognitive Grenze für die Anzahl der Personen vorschlug, mit denen man stabile soziale Beziehungen aufrechterhalten kann (und das sind 150 – die Dunbar-Zahl). Ein weiteres Gesetz, das dies ebenfalls beeinflusst, ist Metcalfes Gesetz, das besagt, dass die Kommunikation umso schwieriger wird, je mehr Personen einem Netzwerk hinzugefügt werden. 

Die Aufrechterhaltung einer effektiven Kommunikation in großen Gruppen erfordert Arbeit. Unser Verstand kann nur eine begrenzte Anzahl von Beziehungen gleichzeitig verarbeiten. Forschern zufolge können wir nur mit höchstens fünf Personen tiefe Beziehungen unterhalten und mit weiteren 15 Personen einige weniger intensive.

The Tipping Point, Malcolm Gladwell

Gladwell verwendet dieses Konzept, um zu illustrieren, warum kleinere Gruppen oft effektiver und produktiver sein können: 

• Kommunikation: In kleineren Gruppen ist Kommunikation oft leichter zugänglich, transparenter und effizienter. Jeder kann jeden anderen kennen, was zu einem besseren Verständnis, weniger Verwirrung und effektiverer Teamarbeit führt.
  
  
• Beziehungen und Vertrauen: Kleinere Gruppen können engere Beziehungen und Vertrauen zwischen ihren Mitgliedern fördern. Mit weniger Personen ist es möglich, tiefere Bindungen zu schaffen, die Zusammenarbeit, Innovation und gemeinsame Verantwortung für Ziele und Ergebnisse fördern.
  
  
• Ownership: In kleineren Gruppen ist die Rolle und der Beitrag jedes Einzelnen deutlicher sichtbar. Dies kann zu einem stärkeren Gefühl persönlicher Verantwortlichkeit führen, und die Menschen sind weniger geneigt, sich in der Menge zu „verstecken“.
  
  
• Schnelligkeit und Agilität: Kleinere Organisationen sind in der Regel beweglicher und in der Lage, Entscheidungen schneller zu treffen. Sie können sich schneller an Veränderungen und Herausforderungen anpassen, was in unbeständigen oder sich schnell verändernden Situationen von Vorteil sein kann.
  
  
• Kultur und Gemeinschaft: Eine robuste und einheitliche Kultur ist oft einfacher in kleineren Gruppen zu etablieren und aufrechtzuerhalten. Geteilte Werte und Normen können leichter verstanden und aufrechterhalten werden, wenn die Gruppengröße unter 150 liegt. 

Auch Fred Brooks hat dies in seinem Buch The Mythical Man-Month erkannt, in dem er feststellt, dass „ein verspätetes Softwareprojekt durch die Hinzufügung von Arbeitskräften verzögert wird“ (auch Brooks-Gesetz genannt). Dies ist auf den erhöhten Kommunikationsaufwand und die Zeit zurückzuführen, die neue Mitglieder benötigen, um produktiv zu werden. 

Amazon verließ sich auch auf dieses Wissen, indem es die „Two Pizza Rule“ von Jeff Bezos einführte. Diese besagt, dass Teams klein genug sein sollten, um mit zwei Pizzas satt zu werden. 

Natürlich können auch größere Gruppen erfolgreich sein, aber es könnte unterschiedliche Management- und Kommunikationsstrukturen benötigen, um dort ebenso effektiv zu sein.

Kommunikationslinien und Teamgröße

Dieser Artikel ist eine Übersetzung des Artikels Your software architecture is complex as your organization von Dr. Milan Milanović, CTO vom US-Software-Unternehmen 3MD und Experte für Softwareentwicklung mit umfangreicher akademischer und industrieller Erfahrung. Sein erfolgreicher Newsletter Tech World With Milan bietet Softwareingenieuren und -architekten, technischen Managern und allen anderen IT-Interessierten Expertenwissen aus der Softwarebranche und darüber hinaus. 

Bild: Freepik.com