(Collective) Code Ownership neugedacht - Teil1
Über Risiken der Wissensverteilung am Beispiel der Corona-Warn-App

Kennen Sie als Projektverantwortlicher für eine Softwareentwicklung ihre Teamstruktur? Wissen Sie, wer woran arbeitet? Wissen Sie, ob der/die jeweilige Entwickler:in die besten Wissensvoraussetzungen hat?
"Müssen Sie nicht", sagen die Befürworter einer agilen Entwicklung, denn "das Team organisiert sich selbst". Und übrigens herrsche das Prinzip der "Collective Code Ownership", d. h. jeder sei für alles verantwortlich im Code [1].
Mit etwas Nachdenken kommt man ins Grübeln, z. B. weil "Collective Code Ownership" dem Prinzip der Modularisierung und effizienten Entwicklung widerspricht [2]. Aber das Prinzip ist nicht nur zweifelhaft, es richtet auch Schaden an. Es tritt u. A. das "Diffusion of Responsibility"-Phänomen ein [3], bei dem sich keiner mehr so richtig verantwortlich fühlt. Einzelne Entwickler:innen verlieren den Durchblick, weil viele der Kolleg:innen den gleichen Code mit verändert haben. Dabei vermischen sich die verschiedenen Entwicklungsstile zu einer Code-Kakophonie, und der kognitive Aufwand zum Verstehen des Codes steigt bis zur Nichtnachvollziehbarkeit an. Wie wahr ist doch, dass viele Köche den Brei verderben können! Eine Erosion der Qualität des Arbeitsergebnisses wird unvermeidbar und letztlich daran erkennbar, dass eskalierende Bugfixing-Aufwände auftreten.
Nun ist es naheliegend nach den Alternativen zum "Collective Code Ownership" zu fragen. Was sind stattdessen gute Verantwortungs- und Wissensverteilungen in einem (agilen) Team? Woran erkennt man früh genug, dass ein Team nicht (mehr) effektiv zusammenarbeitet? Welche weiteren Alarmsignale gibt es für problematische Projekte und was sind die Antworten darauf?
Wir werden in diesem Artikel keine rein theoretischen Betrachtungen anstellen, sondern die deutsche Corona-Warn-App als aktuelles und relevantes Beispiel analysieren. Die Analyse der Entwicklung der Corona-Warn-App wurde mit den durch die Open-Source-Entwicklung zugänglichen Daten auf GitHub, aber ohne die Mitwirkung der mit der Entwicklung beauftragten Unternehmen durchgeführt. Für die Analyse haben wir die DETANGLE-Analyse-Suite verwendet, die eine Auswertung der GitHub Issues/Pull Requests, der beteiligten Entwickler:innen und die darauf zurückzuführenden Code-Änderungen über die gesamte Code-Historie der beiden Apps erlaubt. Die Daten aus dem nicht-öffentlichen SAP JIRA Issue Projekt konnten nicht herangezogen werden. Eine detaillierte Beschreibung des Vorgehens ist unter [4] zu finden.
Dabei haben wir die Wissensstrukturen der beiden iOS- und Android-Entwicklerteams Schritt für Schritt untersucht, um gute und risikobehaftete Muster wie z. B. Knowledge Balances, Knowledge Islands und Knowledge Tangles zu erkennen. Erfahrungsgemäß lassen sich die Schlüsse und Empfehlungen aus einer solchen Analyse sowohl von selbstorganisierten Softwareteams, als auch von Projektverantwortlichen für eine effektivere Zusammenarbeit und Führung nutzen.
Risiken durch Austausch der Entwicklerteams
Die beiden Apps (iOS und Android) werden von zwei unterschiedlichen Entwicklerteams entwickelt, was angesichts der unterschiedlichen Technologien wie Programmiersprachen und verwendeten Bibliotheken sinnvoll erscheint. Überraschend weist die Auswertung unserer Analysedaten auf einen Austausch des gesamten Entwicklerteams während des Jahres 2020 hin. Das trifft sowohl auf die iOS- als auch auf die der Android-App zu. Diese Schlussfolgerung leiten wir aus der zeitlichen Entwicklung zweier Analyse-Informationen ab:
- Anzahl der Commits pro Entwickler:in über die Zeit (Abb. 1) und
- Vergleich der anonymisierten Entwicklerlisten über die Zeit.
Abb. 1 zeigt die Anzahl der Commits in das GitHub Code-Repository von Quartal 2 bis Quartal 4 des Jahres 2020 für die iOS-App-Entwicklung.
In Abb. 1 lassen sich drei wesentliche Stellen auf der X-Achse ausmachen:
- links die Commits im 2. Quartal 2020 (Q2)
- rechts die Commits im 4. Quartal 2020 (Q4) und
- in der Mitte die Commits zwischen den Quartalen (3. Quartal 2020 (Q3))
Es wird sofort ersichtlich, dass die Anzahl der Commits in Q3 am geringsten war, was mit der Urlaubszeit im Sommer erklärt und somit als normal eingestuft werden kann. Wirklich auffallend ist aber, dass die Mitglieder der Teams in Q2 völlig andere sind als die in Q4, was an den unterschiedlichen Farben erkennbar wird (jede Farbe ist einer/m spezifischen Entwickler:in zugeordnet). Über die Gründe für den Austausch haben die Autoren keine Kenntnis.
Es mag vereinzelt Entwickler:innen geben, die durchgehend von Q2 bis Q4 Teil der Entwicklung waren, aber die Akteure mit den meisten Commits sind vor und nach der Sommerzeit nicht die gleichen. Wenig überraschend wäre es, wenn der Verlust an bestehendem Projektwissen zunächst mit einem erheblichen Rückschlag in der Projekteffizienz einherging.
Im Folgenden fokussieren wir unsere Analysen und Aussagen, wenn nicht anders beschrieben, auf den Entwicklungsstand der Corona-Warn-App, der in Q4 2020 vorlag.
Auffallende Wissensinsel in den Teams
Des Weiteren wurde die Verteilung der Entwicklungsaufwände pro Entwickler:in für beide Apps betrachtet (zur Erläuterung der Messung des Entwicklungsaufwandes sei auf [5] verwiesen).
Das ist nicht nur für ein Produkt wie die Corona-Warn-App sehr kritisch.
Bei der Betrachtung der Abb. 2 (linkes Teilbild) fällt auf, dass über die Hälfte des Android-Entwicklungsaufwands auf eine:n Entwickler:in entfällt (insgesamt sind 28 Entwickler:innen beteiligt). Das deutet auf eine stark ausgeprägte Wissens-/Fähigkeiteninsel hin, die aus einer/m einzigen Entwickler:in (committer41) besteht. Das ist nicht nur für ein Produkt wie die Corona-Warn-App, mit seiner enormen sozioökonomischen Relevanz sehr kritisch. Ein Ausfall dieses Committers könnte Folgen mit problematischer Tragweite haben. Es bleibt zu hoffen, dass es sich bei dieser/m "Star"-Entwickler:in nicht auch noch um eine:n externe:n Mitarbeiter:in handelt.
Der Befund für die iOS-Entwicklung (Abb. 2, rechtes Teilbild) ist etwas besser, aber die Aufwände sind ebenfalls nicht sehr ausgewogen verteilt. Nur 3 von 21 Entwickler:innen machen mehr als 61 Prozent des Entwicklungsaufwandes aus. Dabei spielt committer62 auch noch eine eigenständige Rolle als Tester:in. Idealerweise verteilen sich die Aufwände der Testentwicklung auf viele Entwickler:innen. Unter Berücksichtigung dieses Aspekts ist ein Entwicklungsaufwand von über 50 Prozent nur noch zwei Entwickler:innen (committer2 und committer24) zuzuweisen.
Die Autoren empfehlen die Analyse der Entwicklungsanteile Einzelner regelmäßig zu messen (das ergibt sich nicht aus den abgerechneten Stunden!), um das Risiko von Personenabhängigkeiten rechtzeitig zu erkennen und gegensteuern zu können.
Fragen zur Effektivität der Wissensverteilung
Man wird Gründe oder Zwänge gehabt haben, um einen so umfangreichen Austausch in den Projektteams vorzunehmen. Ob das erhoffte Ergebnis sich eingestellt hat, können wir auch nicht aus der Ferne einschätzen. Folgende Fragen sollten sich die Teams und Projektverantwortlichen stellen:
- Ist die aktuell unausgewogene Aufwandsverteilung unkritisch oder sollte man zeitnah gegensteuern?
- Ist das Entwicklungs-Wissen dennoch so verteilt, dass für das Projekt kein größeres Risiko besteht?
- Arbeiten die Entwickler:innen nach dem Austausch so gut zusammen, dass das Team auch effektiv und wertschöpfend entwickelt?
- Welche Muster der Wissensverteilung und welche Auswirkungen sind erkennbar?
Beurteilungskriterien für die Team- und Wissensstruktur
Die grundsätzlich Herausforderung bei jedem Entwicklungsprojekt ist die Sicherstellung einer effektiven und robusten Team- und Wissensstruktur. Nach mehreren Untersuchungen haben wir festgestellt, dass Zweier-Teams intuitiv eine gute Art des Knowledge-Sharing und der Wissensstruktur entwickeln [6]. Wir bezeichnen dieses Muster, wenn genau zwei Entwickler:innen an einer nicht zu kleinen gemeinsamen Menge an Quelldateien arbeiten, als "Knowledge Balance". Eine solche ideale Verteilung von Wissen und Können ergibt sich in der Realität nicht immer zwangsläufig und wird auch nicht immer gesucht. Wir empfehlen deshalb, diesen Aspekt bei größeren und dringenden Projekten rechtzeitig zu analysieren. Aus unseren Analysen und Erfahrungen haben wir in Tabelle 1 einige Muster (Knowledge Patterns) der Wissensverteilung zusammengestellt:
Tabelle 1: Knowledge Patterns und Erläuterungen
Knowledge Pattern | Erklärung |
---|---|
Knowledge Balancesehr gut | Eine Ansammlung an Quellcode-Dateien, an denen exakt zwei Entwickler:innen arbeiten.Diese Art der Zusammenarbeit ist als sehr positiv zu bewerten. Eine hohe Anzahl an Knowledge Balances ist ein Gütezeichen für eine Team- bzw. Wissensstruktur. |
Knowledge Islandproblematisch | Eine Menge an Quellcode-Dateien, an denen ein:e Entwickler:in allein arbeitet.Große oder übermäßig viele Knowledge Islands sind angesichts möglicher Ausfälle der/s jeweiligen Entwickler:in als negativ einzustufen. Vor allem, wenn es sich dabei um kritische Anteile der Codebasis handelt. |
Knowledge Coordinatorgut | Drei (oder mehr) Knowledge Balances, an denen ein:e Entwickler:in immer beteiligt ist, während die anderen drei (oder mehr) Entwickler:innen im großen Umfang nur an einer Knowledge Balance beteiligt sind.Die/der an allen Balances beteiligte Entwickler:in stellt eine:n Koordinator:in dar, der/die die anderen Entwickler:innen aussteuert. Insbesondere für das Ramp-up von neuen Teammitgliedern und deren weiterem Aufbau sind Koordinator:innen unerlässlich. Daher ist das Pattern grundsätzlich als positiv zu bewerten. Aber mit Einschränkungen, wie wir weiter unten erläutern. |
Knowledge Tangleskritisch | Entwickler:innen arbeiten auf chaotische Art und Weise "zusammen" (s. auch den letzten Abschnitt im vorliegenden Artikel).Das ist das Muster, das oftmals im Falle von Collective Code Ownership oder einer schlechten Software-Architektur entsteht. |
Zur visuellen Erkennung dieser Muster der Wissensverteilung nutzen wir Netzwerkdiagramme aus den Daten der DETANGLE-Analyse. Die Diagramme erlauben erste qualitative Hinweise zu möglichen Herausforderungen hinsichtlich einer zu inhomogenen Wissensverteilung. Abb. 3 zeigt ein Beispiel für die iOS Corona-Warn-App in Q4/2020.
Quellcode-Dateien werden dabei als Rechtecke dargestellt, Entwickler (Committer) sind als Kreise abgebildet. Eine Kante zwischen einem Entwickler und einer Quellcodedatei bedeutet, dass der Entwickler an der Datei im besagten Zeitraum gearbeitet und Änderungen durchgeführt hat.
Wir fokussieren uns dabei auf Daten, die sich aus den Änderungen an gemeinsamen Quellcode-Dateien für neue Features ergeben. Nicht berücksichtigt werden Merges der Commit-Historie, die auf Pull Requests zurückgehen, da diese meist in Zusammenhang mit Reviews stehen und die Daten hinsichtlich der Wissensverteilung "verwässern" würden.
Die Diagramme sind angesichts von mehr als 20 Entwickler:innen ohne weitere Filter recht unübersichtlich. Trotzdem sticht leicht erkennbar die erwähnte große Wissensinsel (committer62, oben Mitte) hervor. Des Weiteren kann man durch die Abb. 3 und 4 die Zahlen zur bereits erwähnten Aufwandsverteilung, dass committer2, committer62 und committer24 mehr als 61 Prozent des Entwicklungsaufwandes bei der iOS-App-Entwicklung ausmachen, bestätigen.
Abb. 5 zeigt das Netzwerkdiagramm für die Android-Variante der Corona-Warn-App. Auch hier lassen sich Wissenskonzentrationen als Cluster in der Mitte und am Rand leicht ausmachen. Der visuelle Eindruck von Wissensinseln wird durch die Zahlen zur inhomogenen Aufwandsverteilung (Abb. 2) bestätigt. Diese Aufwands- und Wissensverteilungsanalysen sollten im Bereich des Software-Engineering zu den Projekt-KPIs gehören. Sie ermöglichen es, Ursachen für Projektrisiken frühzeitig zu identifizieren und entsprechend gegenzusteuern.
Bewertung der Effektivität der Wissensverteilung
Um geeignete Gegenmaßnahmen ergreifen zu können, muss aber die Effektivität der vorliegenden Wissensstruktur im Detail beurteilt werden. Dazu werden wir bestimmte Sichten bzw. Filter auf diese Netzwerkdiagramme anwenden:
- Issue-Typ (z. B. nach Bugs oder Features/Enhancements): Quellcode-Dateien, Entwickler:innen und Kanten werden nur dann angezeigt, wenn an den Dateien nur im Rahmen eines Issues von dem ausgewählten Issue-Typ gearbeitet wurde.
- Knowledge Patterns: es wird nach gewissen Mustern gefiltert wie z. B. den Knowledge Islands und Knowledge Balances
Eine Wissensverteilung ist dann effektiv, wenn:
- Entwickler:innen zu einem Ramp-up bzw. zur Wissenserweiterung befähigt werden. Sie sollen über ein anfängliches Bugfixing hinaus einen Kenntnisstand erlangen können, der sie dazu befähigt, in einem hohen Maße zur Implementierung neuer Features beizutragen. Letztendlich sollen so viele Entwickler:innen wie möglich über ein globales Systemwissen verfügen, um selbst Verbesserungen (z. B. Refactorings) im Code oder größere Architekturänderungen eigenständig durchführen zu können.
- Dabei der nötige Koordinationssaufwand und die anfallenden Kommunikationspfade zwischen Entwickler:innen begrenzt bleiben.
- Und die anfallenden Entwicklungsarbeiten dennoch soweit wie möglich verteilt und parallel ablaufen können.
Am Ende der Betrachtungsperiode (Q4/2020) war die Mehrzahl der Entwickler:innen (jeweils 15 von 21 bei der iOS-App und 15 von 28 Entwickler:innen bei der Android-App) am Bugfixing beteiligt. Aber einen relevanten Blick bilden die aussagekräftigen Bilder der Featureentwicklung. In Abb. 6 (für iOS) sind Knowledge Islands und Knowledge Balances visuell sehr gut zu sehen.
Aus den Analysedaten ergeben sich folgende Erkenntnisse für die iOS-App und deren Featureentwicklung :
- Nur 11 (von 21) Entwickler:innen sind wertschöpfend tätig mit der Entwicklung von Features bzw. Enhancements.
- Eine:r der bereits erwähnten Hauptentwickler:innen (committer2) bildet eine große Wissensinsel (rot eingekreist in der Mitte).
- Es gibt vier weitere kleinere Wissensinseln (rot eingekreist).
- Alle Entwickler:innen arbeiten mit der/m Hauptentwickler:in mehr oder weniger intensiv zusammen und bilden mit ihm kleine oder größere Knowledge Balances (die mit einem grünen Rechteck markiert wurden).
- Besagte Hauptentwickler:in (committer2) nimmt die Rolle des Koordinators bei der Featureentwicklung ein.
Daher ließe sich qualitativ schlussfolgern, dass neun dieser elf Entwickler jeweils zusammen an der Feature-Entwicklung beteiligt sind. Diejenigen vier, die selber Wissensinseln darstellen, verfügen bereits über mehr Systemwissen, so dass sie eigenständig an einer größeren Menge an Quelldateien arbeiten können. Andere Entwickler arbeiten hauptsächlich mit dem Koordinator bei der Feature-Entwicklung zusammen.
Man könnte also durchaus den positiven Schluss ziehen, dass im Projektteam diverse Entwickler entweder aufgebaut werden und/oder bereits über fortgeschrittenes Systemwissen verfügen. Es wäre sogar möglich, dass selbst das eigenständige Wissen in den Knowledge Islands des Koordinators und der besagten vier weiteren Entwickler durch das gemeinsame Wissen in den Knowledge Balances und dem einhergehenden Knowledge Sharing ausgeglichen wird.
Die DETANGLE-Analyse der Android-App kommt zu sehr ähnlichen Ergebnissen wie bei der iOS-App und wird deshalb an dieser Stelle nicht weiter erläutert.
Lesen Sie weiter im zweiten Teil >>
- Agile Alliance: Collective Code Ownership
- heise developer: Collective Code Ownership: Ein Anti-Pattern?
- Wikipedia: Verantwortungsdiffusion
- Cape of Good Code, Blog: Details zum Vorgehens bei der Analyse
- Youtube: K. Sokolov & A. Wuchner, JCON 2020: Feature and Time-Based Software Analysis
- Cape of Good Code, Blog: Kooperation und Knowledge Sharing für Agile Remote Entwicklung