Gemeinsame Verantwortlichkeit

Häufig ist die Arbeitsaufteilung in traditionellen Softwareprojekten dergestalt, daß jedem Subsystem (auch Modul oder Komponente) ein Ingenieur zugeordnet ist. Dieser Ingenieur ist verantwortlich für das Detaildesign, die Implementierung sowie die Wartung dieses Subsystems zuständig. Mit anderen Worten, dieser Ingenieur ist "Eigentümer" des Codes mit allem was dazugehört.

Auf den ersten Blick macht dies sehr viel Sinn, denn im Normalfall ist es so, daß die Fähigkeiten und das Wissen nicht gleichmäßig im Team verteilt sind. So gibt es Experten für Datenbanken, für Benutzeroberflächen, für bestimmte Algorithmen. Oder es gibt Ingenieure, die besonders begabt sind, ein ausgefeiltes Design für ein Subsystem zu erstellen.

Aber wenn man genauer hinschaut, kann man aber auch erhebliche Nachteile erkennen. Da gibt es den sogenannten "Truck"-Faktor. Damit bezeichnet man die Überlegung, was passiert, wenn ein bestimmtes Teammitglied vom Laster überfahren wird. Wenn nur ein Ingenieur einem Subsystem zugeordnet wird, dann ist der "Truck"-Faktor für diesen Bereich 1: Der Ausfall beträgt 100%, wenn diese Person, aus welchen Gründen auch immer, ausfällt.

Nun wird in der Regel natürlich nicht gleich ein Unglück passieren, aber es genügt manchmal, wenn jemand im Urlaub ist, eine Weiterbildungsmaßnahme besucht, oder aber krank wird. Wer kümmert sich dann um das Subsystem dieses Ingenieurs?

Eine traditionelle Lösung: Backup-Ingenieur

Eine in der Praxis vorkommende Lösung zu dem Problem ist es, nicht nur einen Ingenieur sondern zusätzlich einen weiteren Ingenieur dem Subsystem zugeordnet. Ziel ist, daß sich nicht nur eine Person in diesem Bereich auskennt, sondern mindestens eine weitere, die als Stellvertreter agieren kann.

Überzeugend auf den ersten Blick, jedoch wie sieht es in der Praxis aus? Normalerweise wird nicht paarweise programmiert. Das bedeutet, daß der Hauptverantwortlich sich 100% seiner Zeit um das Subsystem kümmert, und sich damit auch am besten auskennt. Der Stellvertreter ist aber wiederum der Hauptverantwortliche für ein anderes Subsystem. In der Realität wird damit der Stellvertreter sich nicht oder aber nur selten mit dem Subsystem, dessen Backup er ist, beschäftigen. Damit kann er aber bei weitem eben nicht Experte in diesem Subsystem sein!

Die XP Antwort

Wissen und Programmierfähigkeiten im Projektteam zu verteilen, sind die beste Möglichkeit, den "Truck"-Faktor zu reduzieren. XP geht hier einen pragmatischen Weg: Alle Mitglieder des Projektteams sind gemeinsam für sämtliche Arbeitsergebnisse verantwortlich.

Umgesetzt wird das zum Beispiel mit paarweisem Programmieren. Das allein reicht aber nicht aus, sondern es muß hinzukommen, daß beim paarweisem Programmieren in kurzen Abständen der Programmierpartner gewechselt wird, am besten mehr als einmal am Tag.

Das führt dann zwar nicht dazu, daß ein Anfänger SQL-Experte wird. Aber es ist zumindest eine hinreichende Maßnahme, um eben diesem Anfänger zumindest soviel SQL-Wissen beizubringen, daß er im Notfall die Arbeit mit nur geringen Beeinträchtigungen weiterführen kann. Das natürlich wiederum nicht alleine, sondern im Paar.

Da nun die Paare sich immer wieder neu finden, ergibt sich über einen relativ kurzen Zeitraum eine sehr gute Verteilung von Wissen und Fähigkeiten im Team.

Es gibt weitere XP Arbeitsmethoden, in denen sich die gemeinsame Verantwortlichkeit widerspiegelt. Das Planungsspiel wird im Team gespielt. Tägliche Standup-Meetings dienen dem Abgleich innerhalb des Teams.

Aus Sicht der Programmierer ergibt sich der Vorteil, eben nicht immer am "ungeliebten" Subsystem arbeiten zu müssen. Statt dessen ergibt sich eine Abwechslung, in dem immer wieder in unterschiedlichen Bereichen gearbeitet werden kann. Dies führt in der Regel auch zu einer Marktwertsteigerung, weil die Basis aus Wissen und Fähigkeiten kontinuierlich verbreitert wird.

Tipps

• Regelmäßig den Partner beim paarweisen Programmieren wechseln, am besten mehrmals am Tag.
• Täglich mindestens ein Standup-Meeting machen.
• Tritt ein Fehler in einem, eventuell bereits ausgelieferten, System auf, so ist das gesamte Team verantwortlich für die Lösung. Deshalb den Fehler zuallererst im Team besprechen.