Code Ownership und Bus-Faktor

Bild: Pexels / Andrea Piacquadio - Lizenz

Um es mit den Worten eines befreundeten Scrum Masters zu sagen: "Wenn man nicht ab und zu über Code spricht sollte man auch nicht über Scrum sprechen." In diesem Sinn - sprechen wir über Code, in diesem Fall konkret über Code Ownership. Was das ist, was es sein kann und was es nicht sein sollte.

Code Ownership bedeutet, dass ein Entwickler "Besitzansprüche" auf einen Teil des Quelltextes erhebt. Dieses allerdings nicht in dem Sinn, dass er der Eigentümer ist, sondern eher dahingehend, dass er der Einzige ist, der diesen Abschnitt bearbeiten darf. Gründe dafür gibt es verschiedene: den Glauben alleine schneller oder besser zu sein, den Unwillen mit anderen zusammenzuarbeiten, den Wunsch unersetzbar zu sein oder den Versuch fehlerhafte Arbeit vor anderen zu verbergen. Aber lassen wir die negativen Deutungen weg und gehen wir vom besten Fall aus - da ist jemand der wirklich so viel besser ist als die anderen, dass er Code schreibt, der so genial ist, dass nur er ihn versteht.¹ Ist Code Ownership in diesem Fall eine gute Idee? Nein, auch dann nicht.

Selbst wenn es (scheinbar) eine gute Idee ist, dass bestimmte Code-Abschnitte nur von einer bestimmten Person bearbeitet werden dürfen, geht jedes Projekt und jede Firma die sich darauf einlässt ein unkalkulierbares Risiko ein. Denn wenn diese eine Person ausfällt hat die gesamte Organisation ein Problem, schließlich ist dann niemand in der Lage ihre Aufgaben zu übernehmen. Man spricht in diesem Zusammenhang vom so genannten Bus-Faktor, der definiert wie viele Mitarbeiter ausfallen (von einem Bus angefahren werden) müssen um alle Arbeit zum Stillstand zu bringen. Im Fall von angewandter Code Ownership liegt dieser Faktor bei 1: wenn ein einziger Code Owner ausfällt blockiert das im Zweifel alle anderen. Arbeitsfortschritte gibt es nicht mehr, Agilität schon gar nicht.

Um dieses Risiko zu beseitigen bleibt letztendlich nur eine Möglichkeit: Code Ownership darf es nicht geben, bzw. nur in Form ihres Gegenteils, der "shared Code Ownership": Jeder Entwickler darf jeden Teil des Codes bearbeiten, und nicht nur das - jeder sollte sich irgendwann einmal mit jedem Teil des Codes beschäftigt haben. Nur dann hält sich das Ausfallrisiko in Grenzen. Der in diesem Fall ideale Bus-Faktor ist genau so hoch wie die Teamgröße. Erst wenn jeder einzelne von einem Bus angefahren wurde (was sehr unwahrscheinlich ist) kann die Arbeit nicht mehr weitergehen.

In Scrum, Extreme Programming und ähnlichen Methoden ist es aus diesem Grund best Practice, dass gemeinsam an Programmieraufgaben gearbeitet wird. Für die konkrete Umsetzung gibt es dabei mehrere Möglichkeiten: Pair Programming, Code Reviews oder die Verteilung der Unteraufgaben einer User Story auf mehrere Personen sind die üblichsten. Die Teams mit derartigen Ideen bekannt zu machen sollte Bestandteil jeder Einführung agiler Entwicklungsmethoden sein.


¹Natürlich ist das ein schlechtes Beispiel, denn unverständlicher Code ist nur selten genial