Masterarbeit "Entscheidungsfindung in der Paarprogrammierung"

Was ist Paarprogrammierung?

Paarprogrammierung (PP) ist ein Arbeitsmodus, in dem zwei Programmierer_innen gemeinsam an einem Rechner in enger Zusammenarbeit und ständiger Kommunikation eine Aufgabe der Softwareentwicklung bearbeiten. Die Arbeitsweise ist eine wertvolle Ergänzung jeder Art von Softwareentwicklungsprozess. Eine PP-Sitzung dauert meist zwischen wenigen Minuten und ca. 3 Stunden.

Was ist der Forschungsstand?

Die Arbeitsgruppe Software Engineering erforscht die Paarprogrammierung seit 2004. Sie hat anfangs die Grundelemente des Prozesses ermittelt, genannt [[OurPublications#baseconbook][Basiskonzepte] und sich dann auf einen von zwei Hauptaspekten des Prozesses konzentriert: Den Wissenstransfer.

Wir haben Dutzende von Aufzeichnunen kompletter PP-Sitzungen in zahlreichen verschiedenen Firmen gesammelt, auf denen die beiden Ingenieur_innen ihre jeweils gerade anstehende echte Arbeitsaufgabe bearbeiten. Diese Daten analysieren wir qualitativ mit der Grounded Theory Methodology (GTM).

Damit haben wir vieles über den Wissenstransfer herausgefunden (die beste Quelle für all diese Ergebnisse ist die Dissertaton von Franz Zieris, ppknowtransdiss:

• Wissenstransfer hat eine Episodenstruktur. Diese Episoden laufen in unterschiedlichen Modi ab: Push, Pull, Co-Produce oder Pioneering.
• Die PP insgesamt kann in drei verschiedenen Stufen von Flüssigkeit

  ablaufen

  normal, fast und breakdown.

• Der Gesamtverlauf einer Sitzung beginnt immer mit dem Abgleich der Wissensstände (closing the primary gap) und dann dem gemeinsamen Aufbau des Wissens, das zum Lösen der aktuellen Aufgabe fehlt (closing the secondary gap). Beides betrifft nur systemspezifisches Wissen (S-Wissen, d.h. Wissen über die Codebasis). Beim zweiten Schritt wird unterwegs manchmal auch allgemeines Programmierwissen (G-Wissen, generic) übertragen, das nicht von der Codebasis abhängt.
• Es gibt so etwas wie PP-Können, das weitgehend unabhängig vom Programmierkönnen ist. Gute Paare sorgen dafür, dass ihre mentalen Zustände immer eng beeinander bleiben (hohe Togetherness) und balancieren kurz- und mittelfristige Ziele sinnvoll miteinander.

Arbeitsthema

Nun steht an, auch den zweiten Hauptaspekt der PP zu untersuchen: Das *Entscheiden*. Auch das lässt sich mit den vorhandenen Daten und der GTM analysieren. Als Forschungsfragen und ungefähre Erwartungen sind z.B. folgende denkbar (die Schwerpunktsetzung ist aber völlig offen):

• Welche Gegenstände für Entscheidungen kommen vor? (Eine einfache Unterscheidung ist aus den Basiskonzepten schon bekannt: nächster Schritt, Vorgehensplan, Entwurfsentscheidung)
• Was ist eine Entscheidungsepisode? Was macht ihren Anfang und ihr Ende aus?
• Wie können Entscheidungsepisoden ausgehen? (Zum Beispiel vielleicht: entschieden, Fakten geschaffen, vertagt, versackt.)
• Welche Arten von Schritten kommen im Innern von Entscheidungepisoden vor? (Zum Beispiel vielleicht: Wissen beschaffen, Vorschlag machen, Vorschlag bewerten, Vorschlag untersuchen; auch hier halten die Basiskonzepte schon diverse Fälle bereit)

Schwierigkeitsgrad: Für wen geeignet?

GTM ist schwierig, man hat es im Studium nicht gelernt und es ist zudem eine Talentsache: hohe Intelligenz ist keine hinreichende Bedingung dafür, dass man das gut hinbekommt. Diese Arbeit ist insofern als schwierig anzusehen. Gut geeignet sind tendenziell Menschen, die sehr assoziativ denken und hinter Geschehnissen schnell plausible Muster und Mechanismen am Werk sehen, auch wenn sie diese zuvor nicht kennen.

Es gibt in der Vorlesung "Empirische Methoden im Software Engineering" inzwischen mit den Einheiten 4 und 5 einen Kurs zur GTM, mit dem man nicht nur die Grundzüge der GTM gut lernen, sondern dabei auch eine Idee davon bekommen kann, ob eine solche Abschlussarbeit wohl Erfolg verspricht.

Bei Interesse bitte Kontakt aufnehmen mit Lutz Prechelt.