Zuerst veröffentlicht auf Informatik-Aktuell: Teil1 & Teil2.
Als Projektverantwortlicher für eine Softwareentwicklung
“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.
Mehr Insights zur Architektur-Qualität der Corona-Warn-App gibt es in unseren Blog unter: Corona-Warn-App – Auf dem Weg zu kritischen Technischen Schulden?
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:
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:
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.
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 [4] verwiesen).
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.
Abb. 2: Vergleich der Entwicklungsaufwände zwischen Android- (links) und iOS-Entwickler:innen (rechts) in Q4/2020
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.
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:
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 [5]. 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
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.
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. 4: Grün umrandete Dateien wurden von committer2 in Q4/2020 bearbeitet
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.
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:
Eine Wissensverteilung ist dann effektiv, wenn:
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 :
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.
Für die weitere Analyse werden die eher qualitativen visuellen Eindrücke der Netzwerkdiagramme ergänzt durch die quantitative Auswertungen der Daten. Es werden dafür zwei, den jeweiligen Mustern entsprechende Indices, der Knowledge-Island-LOC-Index und den Knowledge-Balance-LOC-Index gemessen.
Knowledge-Island-LOC Index (KIL)
Das ist der prozentuale Anteil der Lines of Code (LOC) der Quellcode-Dateien, an denen genau ein:e Entwickler:in gearbeitet hat, im Vergleich zu den LOC aller Quellcode-Dateien, an denen in einem bestimmten Zeitraum generell entwickelt wurde. Die Zahl wird pro Gesamtsystem oder pro Verzeichnis gemessen.
Knowledge-Balance-LOC Index (KBL)
Das ist der prozentuale Anteil des LOC der Quellcode-Dateien, an denen genau zwei Entwickler:innen gearbeitet haben, im Vergleich zu den LOC aller Quellcode-Dateien, an denen in einem bestimmten Zeitraum generell entwickelt wurde. Dabei können pro Quellcode-Datei aus dem gleichen Verzeichnis auch unterschiedliche Paare an Entwickler:innen gearbeitet haben.
Die beiden Knowledge-Island-LOC (KIL) und Knowledge-Balance-LOC (KBL) Index-Werte ergeben zusammen einen Wert unter 1.0 (d. h. unter 100 Prozent). Das Delta zu 1.0 (100 Prozent) ergibt den LOC-Anteil an Dateien in einem Verzeichnis, an denen mindestens drei Entwickler:innen aktiv beteiligt waren. Die KIL- und KBL-Werte für die gesamte iOS-App sind nun in Abb. 7 dargestellt.
Abb. 7: Veränderung der KIL- und KBL-Werte der iOS-App von Q2 bis Q4/2020.
Daraus lassen sich die obigen Schlüsse quantitativ bestätigen:
Im Vergleich dazu betrachten wir nun die Werte für die Android-App in Abb. 8:
Abb. 8: Veränderung der KIL- und KBL-Werte der Android-App von Q2 bis Q4/2020
Selbst unter dem eingeschränkten Zugang zum SAP JIRA-Projekt und der fehlenden Möglichkeit, mit den Entwickler:innen zu kommunizieren, würden wir folgende Empfehlungen zur Verbesserung der Effektivität bei der Entwicklung neuer Features in der Corona-Warn-App aussprechen:
Tabelle 2: Empfehlungen zur Verbesserung der Wissens- und Aufwandsverteilung in der iOS- und in Android-Version der Corona-Warn-App
Die KIL- und KBL-Werte mit Bezug zur Featureentwicklung lassen sich auch auf Quellcodeverzeichnisse herunterbrechen wie in Abb. 9 für Q4/2020 dargestellt. Auf der horizontalen Achse werden die KIL-Werte und auf der vertikalen Achse die KBL-Werte für Quellcode-Verzeichnisse aufgetragen. Jeder Kreis stellt ein Quellcode-Verzeichnis dar, wobei die Kreisfläche die LOC aller geänderten Quellcodedateien in dem Verzeichnis spiegelt. D. h. je größer der Kreis, desto mehr LOC machen die Quellcodedateien aus, die in dem Verzeichnis in dem betrachteten Zeitraum zur Featureentwicklung verändert wurden.
Abb. 9: Quellcode-Verzeichnisse und deren KIL- und KBL-Werte (iOS in Q4/2020)
Das Diagramm ist in folgende vier Quadranten mit jeweils unterschiedlicher Rahmenfarbe unterteilt:
Grün: Verzeichnisse, deren Knowledge-Island-Wert gering ist (unter 30 Prozent) und zusätzlich einen mittleren bis hohen Anteil (mindestens 30 Prozent) an Knowledge-Balance-Dateien aufweisen. Es handelt sich also dabei um eine sehr gute Wissensstruktur.
Gelb: Verzeichnisse, deren Knowledge-Island-Wert mittel bis hoch ist (über 30 Prozent), die aber durch einen mittleren bis hohen Anteil (mindestens 30 Prozent) an Knowledge Balances ausgeglichen werden. Diese Verzeichnisse weisen eine immer noch gute Wissensstruktur auf.
Rot (rechter Quadrant):Verzeichnisse, deren hoher Knowledge-Island-Wert nicht durch Knowledge Balances ausgeglichen wird. Hier haben wir es mit kritischen Knowledge Islands zu tun.
Dunkelrot (linker Quadrant):Verzeichnisse, an denen mindestens drei Entwickler:innen gearbeitet haben, die weder kritischen Knowledge Islands noch guten Knowledge Balances zugerechnet werden können. Diese Verzeichnisse bedürfen einer weiteren kritischen Überprüfung, wie viele Entwickler:innen tatsächlich daran gearbeitet haben, und ob es sich eher um eine “geordnete” oder “chaotische” Arbeitsweise der Entwickler:innen an gemeinsamen Quellcode-Dateien handelt.
Die Gründe, diese Verzeichnisse dennoch als dunkelrot, also als sehr kritisch anzusehen, werden mit der Betrachtung des Prinzips der “Collective Code Ownership” unten erörtert.
Diese Kategorisierung lässt sich exemplarisch an Extrembeispielen nachvollziehen. Eines davon sind die “grünen” Verzeichnisse oben links (KIL-Wert von 0, KBL-Wert von 1). Diese Kreise repräsentieren Verzeichnisse, in denen ausschließlich zu zweit entwickelt wurde. Im Gegensatz dazu stellen die Kreise rechts unten im Diagram (KIL-Wert von 1, KBL-Wert von 0) “rote”, kritische Knowledge-Island-Verzeichnisse mit einer/m einzelnen Entwickler:in dar.
Nun betrachten wir die Auswahl an Verzeichnissen, die wir bereits in unserem Blog in Bezug auf Architektur-Qualität, Dokumentation und technische Schulden als verbesserungsbedürftig ausgemacht haben [6] . Dabei handelt es sich um die Risk- und Exposure-Submission-Verzeichnisse des iOS-App-Quellcodes, die Features zur Risikobewertung und zur Handhabung von Covid-Test-Ergebnissen abdecken. Diese Verzeichnisse weisen eine globale Kopplung dieser Features auf und sollen auch aus Sicht der Wissensverteilung betrachtet werden.
Die Betrachtung derer Knowledge-Index-Werte lässt mehrere Schlussfolgerungen zu:
Für diese Verzeichnisse lässt sich messen, ob mehrere bis viele Entwickler:innen darin auf chaotische Art und Weise “zusammen” gearbeitet haben. Denn aus unseren Projekterfahrungen wissen wir, warum solche Quellcodeverzeichnisse kommende Wartungsaufwände “magisch” anziehen. Das sind Quellcodedateien, an denen viele Entwickler:innen immer wieder mal mehr oder mal weniger Änderungen durchführen mussten. Letztendlich tritt das “Diffusion of Responsibility”-Phänomen [7] ein, dass sich irgendwann dafür keiner mehr so richtig verantwortlich fühlt und Entwickler:innen teilweise den Durchblick verlieren, weil viele der Mit-Entwickler:innen den Code mitverändert haben.
Mittels der DETANGLE Analyse Methoden lässt sich zusätzlich der Committer-Friction-Index (CFI) dafür messen. Wir haben das Diagramm mit den Committer-Friction-Werten und der Anzahl an Entwicklern für Q4/2020 in Abb. 10 aufgetragen:
Abb. 10: CFI-Werte der Risk- und Exposure-Submission-Verzeichnisse; x-Achse: CFI, y-Achse: Anzahl Entwickler:innen
Die Betrachtung der Werte in Abb. 10 lässt folgende Beobachtungen zu:
Diese Quellcode-Bereiche lassen sich wie Knowledge Islands und Balances als Knowledge Tangles (wie in Tabelle 1 im ersten Teil des Artikels ausgeführt) visuell in den unteren Netzwerkdiagrammen sichtbar machen.
Abb. 12 zeigt zum einen Knowledge Islands/Balances der iOS-App in Q4/2020 in Verbindung mit Bugs als rote Dreiecke. Einige wenige Quelldateien sind von drei oder zwei Bugs betroffen, mehrere von einem Fehler, aber der überwiegende Teil (ca. 95 Prozent) ist fehlerfrei.
Abb. 12: Knowledge Tangles der iOS-App Q4/2020, Risk– und Exposure Submission-Dateien umrandet
Demgegenüber zeigt Abb. 12 für die iOS-App einen großen Knowledge Tangle auf, der im Vergleich zu Knowledge Islands und Balances sehr verstärkt von Fehlern betroffen ist. In beiden Diagrammen wurden Quelldateien aus den Risk– und Exposure Submission-Verzeichnissen schwarz umrandet, so dass erkennbar wird, dass diese, wie bereits durch die Werte aus Abb. 10 vermutet werden konnte, in großem Umfang in dem besagten Knowledge Tangle vertreten sind. Dabei stammen wiederum ca. 85 Prozent dieser Quellcodedateien aus den drei oben erwähnten und in Abb. 11 rechts angesiedelten Quellcodeverzeichnissen mit einem hohen Committer-Friction-Index.
In vorliegenden Artikel haben die Autoren anhand einer Analyse der Entwicklung der Corona-Warn-App im Zeitraum von Q2 bis Q4 2020, Mittel und Wege vorgestellt, wie Teams und Projektverantwortliche den Zusammenhang zwischen Entwicklungsaufwänden und der Effektivität der Wissensverteilung messen und monitoren können. Mit den Befunden können Projekt- und Produktrisiken frühzeitig erkannt und entsprechende Gegenmaßnahmen zeitnah eingeleitet werden.
Im Einzelnen konnte durch die Analyse der Codehistorie festgestellt werden, dass Wissens- und Teamstrukturen nicht oder kaum explizit analysiert worden sein können. Die außerordentlich inhomogene Wissenverteilung (Knowledge Islands) in den Teams der beiden Teilprojekte iOS-App und Android-App wurde mit der Software Analyse Suite DETANGLE nachgewiesen und visualisiert. Man scheint sich auf das Prinzip der Selbstorganisation von Teams mit seinen Reviews und gegenseitigen Feedbacks verlassen zu haben. Dass das nicht die erhoffte Wirkung hatte, zeigt die ebenfalls sehr inhomogene Verteilung der Entwicklungslast innerhalb der beiden Teams.
Bei der iOS-App 50 Prozent von zwei Entwickler:innen und das bei einer Teamgröße von bis zu 28 Entwickler:innen. Eine solche ineffektive Wissens- und inhomogene Aufwandsverteilung führt zu generellen Ineffizienzen im Entwicklungsprozess und zusätzlich auch noch zu unerwünschten Abhängigkeiten von einzelnen Entwickler:innen. Ein Ausfall einer/s dieser Entwickler:innen kann die Qualität, den Launchtermin oder den gesamten Projekterfolg nachhaltig gefährden.
Neben dem leicht erfassbaren Muster der Knowledge Islands, wurden als weitere Muster die Knowledge Balances und Knowledge Coordinators eingeführt, die per Netzwerkdiagramme visualisiert und bis auf Ebene der Quellcodeverzeichnisse quantifiziert werden können. Dadurch weiß man, wo und wann Knowledge Islands und einzelne Koordinator:innen ein Risiko darstellen und wie sie mittels einer Verstärkung der Knowledge Balances ausgeglichen werden können.
Bugfixing ist stets Blindleistung. Um eine nachhaltige Wertschöpfung in der Featureentwicklung zu gewährleisten, empfehlen die Autoren die Durchführung dieser Analysen begleitend über die Iterationen der Entwicklung hinweg. Die Ergebnisse wären ein wesentlicher Input für Team-Reviews, um Verbesserungsmaßnahmen zu initiieren oder zum Zwecke der Transparenz für Projektverantwortliche, Auftraggeber und Nutzer.
Unsere Diagnose, dass die Wissensverteilung und die Verteilung der Entwicklungsaufwände in den Entwicklungsteams der Corona-Warn-App problematisch ist, könnte durch die Realität bestätigt worden sein, denn beim Launch neuer Features traten wiederholt Verzögerungen und funktionale Einschränkungen, bis hin zum Ausfall der App auf [8].
Anmerkung: Die vorgestellten Ergebnisse und Erkenntnisse sind nur ein kleiner Teil dessen, was an relevanten Informationen hätte erzielt werden können, falls die Autoren einen offenen Zugang zu den Entwicklerteams und zu den von dem Projektteams verwendeten, aber nicht-öffentlichen SAP JIRA-Projekten erhalten hätten.
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 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 [3] zu finden.
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.
[1] Agile Alliance, Collective Code Ownership
https://www.agilealliance.org/glossary/collective-ownership
[2] heise developer, “Collective Code Ownership: Ein Anti-Pattern?”
https://www.heise.de/developer/artikel/Collective-Code-Ownership-Ein-Anti-Pattern-3909449.html
[3] Blog Cape of Good Code, Details zum Vorgehens bei der Analyse ("Zum Vorgehen")
https://capeofgoodcode.com/de/wissen/corona-warn-app-auf-dem-weg-zu-kritischen-technischen-schulden/
[4] JCON 2020, “Feature and Time-Based Software Analysis”,
Measuring Development Effort: https://youtu.be/aD4OQScGILo?t=790
5 Minuten: 13:10 – 18:27
[5] Blog Cape of Good Code, “Kooperation und Knowledge Sharing für Agile Remote Entwicklung”
https://capeofgoodcode.com/de/wissen/kooperation-und-knowledge-sharing-fuer-agile-remote-entwicklung/
[6] Blog Cape of Good Code, “Corona Warn App – Auf dem Weg zu kritischen Technischen Schulden?”
https://capeofgoodcode.com/de/wissen/corona-warn-app-auf-dem-weg-zu-kritischen-technischen-schulden/
[7] Diffusion of Responsibility
https://web.archive.org/web/20100227092905/http://greatergood.berkeley.edu/greatergood/archive/2006fallwinter/keltnermarsh.html
[8] Handelsblatt, “Die Fehler der Corona-App offenbaren eine gefährliche Schweigsamkeit der Firmen”
https://www.handelsblatt.com/meinung/kommentare/kommentar-die-fehler-der-corona-app-offenbaren-eine-gefaehrliche-schweigsamkeit-der-firmen/26038162.html