Der Tod des Navigators

Wir machen auf der Arbeit regelmäßig ein Coding-Dojo: vier Leute, drei Monate, zwei mal in der Woche anderhalb Stunden, eine Aufgabe, rotierendes Pairprogramming am Beamer. Die Frage nach der Rolle des Navigators, des Beifahrers, beim Pair Programming hat uns dabei schon öfter beschäftigt. Wir rotieren alle 5 Minuten (btw: Minuteur ist ein wuenderbares Tools um das auf dem Mac zu steuern). In der Literatur, in Vorträgen findet sich ein gängiges Muster: Der Fahrer sei zuständig für die taktischen Fragen, der Navigator für die Strategie. Den Fahrer kümmere die Syntax, den Navigator der große Plan, die Route. Obwohl diese Beschreibung sich durchgängig findet, hat das Beschriebene bei uns einfach nicht funktioniert. Das mag  verschiedene Gründe haben: falsch angewendet, unerfahren, unqualifiziert, zu wenig Disziplin, eine falsche Vorstellung davon wie es auszusehen hat.

Und nun sind wir auf zwei Studien gestoßen: Pair Programming an the Mysterious Role of the Navigator und The Social Dynamics of Pair Programming. Beide untersuchen die Frage der Kommunikation beim Pair Programming empirisch. Und beide Studien kommen zu dem Ergebnis, dass es die Rollenaufteilung in Navigator und Fahrer nicht gibt. Die Anteile beider Rollen an verschiedenen Ebenen der Betrachtung des Programms sind gleichverteilt. Es gibt keinen Unterschied in dem, was ich betrachte - und dann auch verbalisiere -, der sich aus meiner Rolle ableiten läßt. Und dass obwohl die Beteiligten selber ihre Rollen vor dem Experiment als Fahrer und Navigator beschrieben und der Meinung waren, so funktioniere ihr Pairing. Wenn die Rolle des Navigators als permanentem Code Reviewer oder als Steuermann eine Chimäre ist, was kennzeichnet denn dann das Gespräch zwischen den beiden? Die Rollen seien zumindest nicht sehr unterschiedlich, sehe man einmal vom trivialen Umstand ab, dass der eine die Tastatur hat und der andere nicht. Das Gespräch spiele sich eher auf einer Ebene von 'abstract chunks of code' ab. Damit seien Fragen von Namensstandards, Fragen allgemeiner Programmierstrategien, Umsetzungen von Programmstrategien im konkreten Programm gemeint. Der Bereich - so die eine Studie - der 'abstract chunks of code' sei der Vermittlungsbereich zwischen der Diskussion über konkrete Methode, Variablen und Syntax auf der einen und Fachdomänen bzw. der Übersetzung von Fachdomänenfragen ins Programm auf der anderen Seite. Pair Programming sei am effektivsten, wenn beide Teilnehmer ständig beide Rollen ausfüllten.

Einen wirklichen Unterschied sieht die eine Studie, wenn erfahrene mit unerfahreneren Programmierern pairen. Bei einem grossen Unterschied werde der unerfahrene Programmierer passiv. Diese Passivität führe dazu, dass er nicht mehr wirklich handle, sondern mehr zuschaue, und nicht mehr viel lerne. Pair Programming eigne sich nicht für den Wissenstransfer bei grossen Unterschieden in der Erfahrung oder Qualifikation. Die eine Studie schliesst eine Beobachtung an, die sie nicht mehr verifiziert, weil sie beendet wurde. Neu ins Team gekommene Programmierer, hätten nicht so viele Probleme die Erfahrenen zu unterbrechen, sie würden nicht so schnell passiv werden, das könne ein Indiz sein, dass bei ihnen der Transfer auch bei einem grossen Wissensunterschied noch funktioniere.

Die Lektüre der zwei Studien wirkte sich befreiend aus. Vorher hatte ich das Gefühl, unsere Betrachtungen müssten in die Richtung eigener Unzulänglichkeiten gehen, warum machen wir das noch nicht richtig. Danach würde ich sagen, die Frage, wie Pair Programming zu lehren uns zu kultivieren sei ist wieder offen oder aber schon beantwortet, weil man sich eben so verständigt, wie man sich verständigt: auf der mittleren Ebene und gleichberechtigt.

Ich freue mich über Kommentare an: self(ät)jenshimmelreich.de

Kommentare