Diplomarbeit Evaluation von DPP mit XPairtiseals Diplomarbeit vorgelegt von Dominik Kröger Starenweg 4 48308 Senden (Matrikel-Nr. 5556457) angefertigt am Lehrgebiet Kooperative Systeme

FERNUNIVERSITÄT in Hagen

FACHBEREICH INFORMATIK

Evaluation von

Distributed Pair Programming

mit XPairtise

als Diplomarbeit

vorgelegt von

Dominik Kröger

Starenweg 4

48308 Senden

(Matrikel-Nr. 5556457)

angefertigt am Lehrgebiet

Kooperative Systeme – Praktische Informatik VI

der FernUniversität in Hagen

Betreuer:

Dr. Till Schümmer

– 15. Juli 2008 –

Evaluation von Distributed Pair Programming mit XPairtise II

Danksagung

Ich danke meinen Eltern und meinen beiden Schwestern, die mich in den Jahren mei-

nes Studiums immer unterstützt haben. Ihnen widme ich diese Arbeit.

Ich versichere, dass ich die vorliegende Diplomarbeit selbstständig und nur unter Ver-

wendung der angegebenen Quellen und Hilfsmittel angefertigt und die den benutzten

Quellen wörtlich oder inhaltlich entnommenen Stellen als solche kenntlich gemacht

habe. Die Arbeit hat in gleicher oder ähnlicher Form noch keiner anderen Prüfungsbe-

hörde vorgelegen.

Datum Unterschrift

Evaluation von Distributed Pair Programming mit XPairtise III

I N H A L T S V E R Z E I C H N I S

INHALTSVERZEICHNIS .............................................................................................................. III

TABELLENVERZEICHNIS ............................................................................................................ V

ABBILDUNGSVERZEICHNIS ....................................................................................................... V

1 EINFÜHRUNG ....................................................................................................................... 1

2 UNTERSTÜTZUNG FÜR DISTRIBUTED PAIR PROGRAMMING....................................... 4

2.1 Pair- und Distributed Pair Programming - Begriffsbestimmung ..................................... 4

2.2 Historie des Pair- und Distributed Pair Programmings .................................................. 6

2.3 Software für Distributed Pair Programming ................................................................... 9

2.4 Entstehungsgeschichte und Funktionen von XPairtise................................................ 12

2.5 Architektur von XPairtise .............................................................................................. 14

3 FORSCHUNGSFRAGEN .................................................................................................... 15

3.1 Effektivität von Pair- und Distributed Pair Programming .............................................. 15

3.2 Hypothesen und Forschungsmethoden ....................................................................... 17

4 EVALUATIONSDESIGN ...................................................................................................... 23

4.1 Testkontext/Setting ...................................................................................................... 23

4.2 Angewendete Evaluationsmethoden ........................................................................... 25

4.2.1 Protokollierung von Logfiles bei der Nutzung von XPairtise ............................... 25

4.2.1.1 Erzeugung Logfiles.................................................................................. 26

4.2.1.2 Auswertung Logfiles ................................................................................ 28

4.2.2 Audio-Aufzeichnungen einzelner Sessions ........................................................ 29

4.2.3 CVS-System ........................................................................................................ 30

4.2.4 Selbst- und Fremdeinschätzungsbefragungen ................................................... 31

4.2.5 Interviews ............................................................................................................ 31

5 EVALUATIONSERGEBNISSE ............................................................................................ 32

5.1 Organisation der Gruppen ........................................................................................... 32

5.1.1 Bearbeitungsverhalten bei den Planungskarten ................................................. 32

5.1.2 Verhalten der Gruppenleiter ................................................................................ 34

5.2 XPairtise - Ergebnisse der Benutzung ......................................................................... 35

5.2.1 Nutzung der Features von XPairtise ................................................................... 40

5.2.1.1 Kommunikation in einer XPairtise-Session ............................................. 41

5.2.1.2 Rollenwechsel ......................................................................................... 41

5.2.1.3 Benutzung des Whiteboards ................................................................... 44

5.2.1.4 Texteingaben ........................................................................................... 44

5.2.2 Verhältnis Driver - Navigator ............................................................................... 45

5.2.3 Anzahl der Gäste ................................................................................................ 48

5.2.4 Pausen während XPairtise-Sessions .................................................................. 48

Evaluation von Distributed Pair Programming mit XPairtise IV

5.2.5 Pair Rotationen ................................................................................................... 49

5.2.5.1 Untersuchung Pair Rotationen -Gruppe 1- ............................................. 50

5.2.5.2 Untersuchung Pair Rotationen -Gruppe 2- ............................................. 54

5.3 Audioaufnahmen .......................................................................................................... 55

5.4 CVS-Auswertungen...................................................................................................... 58

5.4.1 CVS-Ergebnisse der ersten Gruppe ................................................................... 59

5.4.2 CVS-Ergebnisse der zweiten Gruppe ................................................................. 65

5.4.3 CVS-Ergebnisse - Vergleich beider Gruppen ..................................................... 68

5.5 Ergebnisse Selbst- und Fremdeinschätzungsbefragungen ......................................... 71

5.5.1 Zeitlicher Aufwand der Studenten ....................................................................... 71

5.5.2 Verhältnis Solo Programming - Pair Programming ............................................. 72

5.5.3 Vergleich Selbst- und Fremdeinschätzungen ..................................................... 73

5.6 Interviewergebnisse ..................................................................................................... 77

6 DISKUSSION DER ERGEBNISSE ..................................................................................... 84

6.1 Vergleiche mit Studien zum Pair Programming ........................................................... 86

6.1.1 Zufriedenheit ....................................................................................................... 86

6.1.2 Vertrauen in das Ergebnis .................................................................................. 87

6.1.3 Paarzusammensetzung ...................................................................................... 88

6.1.4 Rollenwechsel ..................................................................................................... 90

6.1.5 Anfertigung von Tests ......................................................................................... 92

6.2 Vergleiche mit Studien zum Distributed Pair Programming ......................................... 93

6.2.1 Arbeiten mit Distributed Pair Programming ........................................................ 93

6.2.2 Whiteboard .......................................................................................................... 95

7 FAZIT UND AUSBLICK ....................................................................................................... 97

LITERATURVERZEICHNIS ......................................................................................................... VI

ANHANG ....................................................................................................................................... X

A 1: Interviewfragen ....................................................................................................................... X

A 2: Selbst- und Fremdeinschätzungsfragen .............................................................................. XII

A 3: Muster der Einverständniserklärung ................................................................................... XIII

A 4: CD ...................................................................................................................................... XIV

Evaluation von Distributed Pair Programming mit XPairtise V

T A B E L L E N V E R Z E I C H N I S

Tabelle 1: Übersicht Audio-Transkription -Gruppe 1- .................................................................. 56

Tabelle 2: CVS-Check-Ins in Korrelation zu XPairtise-Sessions pro Student ............................. 62

Tabelle 3: Abweichungen der Selbst- gegenüber den Fremdeinschätzungen ........................... 76

Tabelle 4: Übersicht Zufriedenheit Kooperation/Kommunikation ................................................ 81

Tabelle 5: Zusammenfassung Hypothesenanalyse .................................................................... 85

A B B I L D U N G S V E R Z E I C H N I S

Abbildung 1: XP-Praktiken ............................................................................................................ 5

Abbildung 2: XPairtise-Perspektive in Eclipse ............................................................................ 12

Abbildung 3: Bildschirm Logauswertungsprogramm ................................................................... 28

Abbildung 4: Ergebnis aus dem Logauswertungsprogramm ...................................................... 29

Abbildung 5: Nutzung von XPairtise im Praktikumsverlauf (Zeit in Minuten) .............................. 36

Abbildung 6: Nutzung von XPairtise im Praktikumsverlauf (Sessions pro Woche) .................... 36

Abbildung 7: Minuten pro XPairtise-Session im Praktikumsverlauf ............................................ 39

Abbildung 8: Benutzung der Funktionen in XPairtise .................................................................. 40

Abbildung 9: Rollenwechsel ........................................................................................................ 42

Abbildung 10: Verhältnis Driver/Navigator .................................................................................. 45

Abbildung 11: Editormarkierungen vom Navigator ...................................................................... 46

Abbildung 12: Verhältnis Editormarkierungen Driver/Navigator .................................................. 47

Abbildung 13: Soziogramm der Paarzusammensetzungsvariationen -Gruppe 1- ...................... 50

Abbildung 14: Zeitleiste Paarzusammensetzungen der Sessions -Gruppe 1- ............................ 51

Abbildung 15: Zusammenarbeit der Studenten untereinander ................................................... 52

Abbildung 16: Soziogramm der Paarzusammensetzungsvariationen -Gruppe 2- ...................... 54

Abbildung 17: Gesprächsanteile Driver/Navigator in Prozent ..................................................... 57

Abbildung 18: Beispiel CVS-Check-In ......................................................................................... 58

Abbildung 19: CVS-Check-Ins -Gruppe 1- .................................................................................. 59

Abbildung 20: Check-Ins pro Student -Gruppe 1- ....................................................................... 60

Abbildung 21: Autoren pro Java-Klasse -Gruppe 1- ................................................................... 64

Abbildung 22: CVS-Check-Ins -Gruppe 2- .................................................................................. 65

Abbildung 23: Check-Ins pro Student -Gruppe 2- ....................................................................... 66

Abbildung 24: Autoren pro Java-Klasse -Gruppe 2- ................................................................... 67

Abbildung 25: CVS-Check-Ins beider Gruppenprojekte im Vergleich ......................................... 69

Abbildung 26: CVS-Daten beider Gruppenprojekte .................................................................... 70

Abbildung 27: Zeitlicher Aufwand der Studenten ........................................................................ 71

Abbildung 28: Verhältnis zwischen Solo- und Distributed Pair Programming ............................. 72

Abbildung 29: Darstellungen der Selbst- und Fremdeinschätzungen ......................................... 75

Abbildung 30: Vertrauen in das entwickelte Produkt ................................................................... 81

Kapitel 1 ● Einführung 1

1 EINFÜHRUNG

In Zeiten einer immer weiter fortschreitenden Globalisierung, in deren Zusammenhang

Verlagerungen und Verflechtungen von Unternehmen in alle Teile der Welt stattfinden,

steigt der Kommunikations- und Informationsfluss stetig an. Diese Entwicklung geht

auch am Softwaresektor nicht vorbei. Viele Softwareentwicklungseinheiten werden

aufgrund des zunehmenden Kostendrucks von Amerika oder Europa in Billiglohnländer

im asiatischen Raum mit qualifizierten Entwicklern verlagert. Hier nehmen z. B. Indien

oder China einen großen Stellenwert ein, wobei aber die Hauptsitze und die Organisa-

tionsabteilungen überwiegend in den Stammländern ansässig bleiben. Aufgrund dieser

zunehmenden Anzahl an Outsourcing- und Offshoring-Projekten (z. B. bei IBM oder

SAP beginnend in den Jahren 2003/2004 [HB04] [Pöß04]) sollen jährliche Kosten in

Millionenhöhe eingespart werden. Diese Verlagerungen in Billiglohnländer führen oft-

mals gerade bei Unternehmen mit eng verflochtenen Unternehmensstrukturen ohne

autonome Aufgabenaufteilungen zu einer immer bedeutsameren und engeren Zusam-

menarbeit der einzelnen Unternehmensbereiche untereinander über große Entfernun-

gen hinweg und erfordern damit ein funktionierendes Netzwerk mit einer guten Organi-

sation und einer unkomplizierten Kommunikation zu den Stammsitzen. Des Weiteren

liegen gerade in mittelständischen Unternehmen Home-Offices bzw. Telearbeit im

Trend. So ist der Anteil der Unternehmen nach Angaben des Instituts der Deutschen

Wirtschaft, bei denen Telearbeit zum Einsatz kam, von 7,8 Prozent im Jahre 2003 auf

18,5 Prozent im Jahre 2006 gestiegen [RZ07]. Von der Softwareindustrie werden im-

mer mehr Kommunikationsmöglichkeiten entwickelt, um den weltweit zunehmenden

Kommunikationsaustausch sowohl zu gewährleisten als auch zu verbessern, da der

Bedarf an derartigen technischen Unterstützungsprogrammen stetig steigt [BS08].

Vielfach geht die Verlagerung von Unternehmensbereichen einher mit einer erforderli-

chen Zusammenarbeit in Form von Teams zwischen den verschiedenen Unterneh-

mensstandorten über größere Entfernungen hinweg. Aber auch davon unabhängig

spielt Teamarbeit in Unternehmen eine immer bedeutsamere Rolle. Es existieren viele

Studien zur Erforschung der Effektivität der Arbeit in (virtuellen) Teams (vgl. [PPI04]).

Für Teamarbeit sprechen zahlreiche Vorteile, aber ggf. kann Teamarbeit bei Projekten

auch nachteilig sein. Generell muss im Ausgangsstadium unter Beachtung der Rah-

menbedingungen genau analysiert werden, ob Teamarbeit für spezielle Projekte in

Frage kommt, also förderlich ist oder nicht.

In beiden angesprochenen Bereichen, der Verlagerung von Unternehmensbereichen

an andere Standorte sowie der Arbeit in Teams, greift das Distributed Pair Program-

ming bei der Bewältigung von größeren Softwareprojekten. Das Pair- oder Distributed

Pair Programming ist eine mittlerweile immer weiter verbreitete Methode, um mittels


eines agilen Softwareprozesses schnell auf wechselnde Produktanforderungen reagie-

ren zu können. Es kann ferner dazu beitragen, dass zwei oder auch mehr Programmie-

rer aus den unterschiedlichsten Teilen der Erde zeitgleich, zielorientiert und effektiv

Programmiercode zusammen entwickeln. Damit entfallen zeitaufwendige und kostenin-

tensive Reisewege für gemeinsame Besprechungen oder Softwareprojektentwicklun-

gen vor Ort, was damit auch der Umwelt zugute kommt. Von diesen Programmierern

werden neben der Arbeit mit häufig bestehendem generellen Zeitdruck und neben sehr

guten Programmierkenntnissen darüber hinaus noch hohe soziale Kompetenzen im

Rahmen der gemeinschaftlichen Zusammenarbeit in Teams erwartet. Hier gilt es, diese

Zusammenarbeit mit optimalen Tools zu unterstützen, um letztlich neben der Steige-

rung der Produktivität zusätzlich eine Verbesserung der Qualität zu erreichen.

Der Nachweis der generellen Effektivität von Pair- und Distributed Pair Programming

ist ein schwer zu untersuchendes und zu beweisendes Unterfangen. Zur Untersuchung

der Effektivität gibt es zahlreiche Studien, die die möglichen Vorteile des Pair Pro-

grammings aufzeigen und aussagen, dass Paare bessere Software entwickeln als Solo

Programmierer [Nos98] [Wil00] [WKCJ00]. In dem in der Literatur weit beachteten Arti-

kel von Alistair Cockburn und Laurie Williams „The Costs and Benefits of Pair Pro-

gramming“ [CW00] illustrieren die Autoren eindrucksvoll anhand von verschiedenen

Aspekten und Untersuchungen, dass Pair Programming eine sehr wirksame und sinn-

volle Softwareentwicklungsmethode sein kann. Ein interessantes Zitat von dem be-

kannten Softwareentwickler Ron Jeffries zu seinen ersten Erfahrungen zum Pair Pro-

gramming lautet: “I’m not entirely stupid. I noticed very quickly that this most junior of

programmers was actually helping me! Me! Can you believe it? Me! That has been my

experience every time thereafter, in pair-programming. Having a partner makes me a

better programmer.“ [WKCJ00]

Schwerpunktmäßig erfolgt in dieser Diplomarbeit die Untersuchung von Distributed

Pair Programming in der Praxis im Rahmen der Evaluation eines Fachpraktikums, das

von elf Studenten der FernUniversität in Hagen im Wintersemester 2007/2008 absol-

viert wurde. Im besagten Fachpraktikum wurden die Studenten in zwei Gruppen aufge-

teilt, denen die Aufgabe oblag, unter Einsatz des Eclipse-Plugins XPairtise, das Distri-

buted Pair Programming unterstützt, eine größere Programmieraufgabe zu bewältigen.

Dabei sollen durch diese Evaluation die Vor- und Nachteile beim Umgang von Paaren

mit Distributed Pair Programming und das Gruppenverhalten herausgearbeitet werden,

um auch Empfehlungen an Programmanforderungen an Systeme des Distributed Pair

Programmings und an Verhaltensweisen in Gruppenarbeiten stellen zu können. Diese

Evaluation hat ferner den Sinn und Zweck konkret zu durchleuchten, wie von den Be-


nutzern mit den zur Verfügung stehenden „Werkzeugen“ umgegangen wird und wie

häufig bzw. wozu diese angewendet werden, um ggf. Verbesserungsmöglichkeiten

aufzuzeigen und um das Verhalten der einzelnen Benutzer zu erforschen. Dabei ka-

men bei dieser Evaluation mehrere Evaluationsmethoden (wie Logfileprotokollierun-

gen, Audiomitschnitte, Selbst- und Fremdeinschätzungsbefragungen, Interviewbefra-

gungen) zum Einsatz. Es sollte ein möglichst guter Überblick und Eindruck gewonnen

werden, um Rückschlüsse ziehen zu können und Erfahrungen bei der aktiven Anwen-

dung des Distributed Pair Programmings im Rahmen von Teamarbeit zu bekommen.

Die vorliegende Arbeit ist wie folgt gegliedert:

Kapitel 1 (Einführung) liefert die Motivation für die Problemstellung. Kapitel 2 (Unter-

stützung für Distributed Pair Programming) führt mit einer Begriffsbestimmung und der

historischen Entwicklung des (Distributed) Pair Programmings in das Thema ein. Dabei

werden ausgewählte Programme, die das Distributed Pair Programming unterstützen,

vorgestellt. Erläutert wird in dem Zusammenhang auch das Programm XPairtise, das

einen Schwerpunkt dieser Evaluation bildet. In Kapitel 3 (Forschungsfragen) werden

einige Aussagen aus der Literatur über die Effektivität des Pair Programmings und die

damit evtl. verbundenen Vor- und Nachteile getroffen, aus denen sich die in dem Kapi-

tel ebenfalls vorgestellten Hypothesen dieser Evaluation entwickelt haben. Ferner wer-

den die detaillierten Beweggründe zu den Hypothesenherleitungen und die angewen-

deten Evaluationsmethoden zur Untersuchung der jeweiligen Hypothesen aufgeführt.

Kapitel 4 (Evaluationsdesign) erläutert den organisatorischen Ablauf und die zugrunde

liegende Aufgabe des zu evaluierenden Fachpraktikums und stellt die angewendeten

Evaluationsmethoden im Detail vor. Die einzelnen Ergebnisse dazu werden in Kapitel 5

(Evaluationsergebnisse) ausführlich erörtert und schließlich in Kapitel 6 (Diskussion der

Ergebnisse) mit Resultaten und Erkenntnissen aus anderen wissenschaftlichen Stu-

dien, auch in Bezug auf die aufgestellten Hypothesen, verglichen und diskutiert. Mit

Kapitel 7 (Fazit und Ausblick) werden die Kernergebnisse dieser Arbeit zum Distributed

Pair Programming abschließend eingeschätzt.

Kapitel 2 ● Unterstützung für Distributed Pair Programming 4

2 UNTERSTÜTZUNG FÜR DISTRIBUTED PAIR PROGRAMMING

In diesem Kapitel wird das (Distributed) Pair Programming vorgestellt und die histori-

sche Entwicklung aufgezeigt. Ferner werden ausgewählte Beispielprogramme, die

Distributed Pair Programming unterstützen, kurz erörtert, bevor das Eclipse-Plugin

XPairtise im Detail erläutert wird.

2.1 Pair- und Distributed Pair Programming - Begriffsbestimmung

Im Folgenden wird ausgeführt, worum es sich beim Pair Programming (PP) und Distri-

buted Pair Programming (DPP) genau handelt und welcher Zusammenhang zum Ex-

treme Programming (XP) besteht. Die Vorgehensweise beim PP (vgl. [WKCJ00]) ist

die, dass sich zwei Programmierer zu einem Team zusammenschließen, um gemein-

sam Seite an Seite Programmcode zu entwickeln, wobei sie der folgenden Rollenauf-

teilung unterliegen: Ein Programmierer ist der sogenannte Driver und der zweite Pro-

grammierer ist der Navigator1. Die Rollen können und sollten aber flexibel von Zeit zu

Zeit während einer Programmiersession getauscht werden. Der Driver hat in einer ge-

meinsamen Session die aktive Kontrolle über die vorliegenden Arbeitswerkzeuge wie

z. B. Maus oder Tastatur. Der Navigator besitzt eine beobachtende Rolle. Er beobach-

tet und kontrolliert fortdauernd jegliche Schritte und Tätigkeiten des Drivers. Die Idee

dabei ist, dass der Navigator sowohl Fehler vom Driver erkennen als auch Anregungen

und Verbesserungsvorschläge machen kann. In einem gemeinsamen Projekt fungieren

beide Programmierer, unabhängig von der aktuellen Rollenaufteilung, als Team und

damit als gleichberechtigte und verantwortliche Partner für das Projekt.

Unter DPP versteht man eine spezielle Form des PP, bei der die Entwickler räumlich

verteilt zusammenarbeiten. Die räumliche Trennung stellt einige Schwierigkeiten im

Umgang und in der Kommunikation untereinander dar. Grundsätzlich ist immer mit

Schwierigkeiten bei gemeinschaftlichen, aber räumlich getrennt stattfindenden Arbeiten

zu rechnen [OO00]. Im Vergleich zum PP haben einzelne Programmierer oder auch

Gruppen beim DPP grundsätzlich gesehen drei Nachteile: Die Kommunikation unter-

einander ist schwieriger und aufwändiger, die Gruppenmitglieder lernen sich langsamer

kennen bzw. nehmen sich weniger bewusst wahr und der gemeinsame Zugang zu

physischen Objekten und Orten (wie ein Drucker oder der Cafeteria) ist schwieriger

[SS01]. Die Frage ist, inwieweit diese Hindernisse mittels einer guten Softwareunter-

stützung aus dem Weg geräumt werden können.

Arbeiten Programmierer in Teams oder Gruppen räumlich getrennt zusammen, werden

diese auch als virtuelle Teams bezeichnet. Ein virtuelles Team kann wie folgt definiert

werden: „Unlike conventional teams, a virtual team works across time, distance, culture

1 In der Literatur zum Pair Programming oft auch als „Observer“ bezeichnet.


and organizational boundaries, thereby creating an “anyone/anytime/anyplace” con-

cept.” [GMW02]

Generell ist PP eine Praktik des Extreme Programming (XP). Unter XP versteht man

eine „leichtgewichtige“-Softwareentwicklungsmethode, d. h. es werden die Produktan-

forderungen nicht alle nach einem vorher genau festgelegten Plan durchgeführt und

entwickelt, sondern Teilaspekte können auf Wunsch des Kunden im Projektverlauf ver-

nachlässigt oder auch ganz weggelassen werden, wenn sie keinen Nutzen mehr für

das Projekt bringen oder sich die Anforderungen im Projektverlauf an das Produkt än-

dern. Gedacht ist XP für kleine bis mittelgroße Teams von Programmierern. Als Erfin-

der und erste Entwickler des XP werden häufig die drei Softwareentwicklungsexperten

Kent Beck, Ron Jeffries und Ward Cunningham genannt. Diese haben im Laufe der

Entwicklung des XP zahlreiche Untersuchungen vorgenommen und ihre gewonnenen

Erkenntnisse in diversen Publikationen (wie z. B. [Bec99], [Cun92] oder [Jef08]), die im

weiteren Verlauf dieser Diplomarbeit auch noch teilweise angeführt werden, veröffent-

licht. Wichtig ist es in diesem Zusammenhang noch kurz zu erwähnen, dass PP zwar

ein Verfahren des XP ist, allerdings schon eigenständig lange vor der Entwicklung des

XP im Bereich der kollaborativen Softwareentwicklung eingesetzt wurde [Con95]

[DL87].

Die folgende Abbildung (vgl. [Jef08]) skizziert die vorkommenden, möglichen Praktiken

des XP-Entwicklungsparadigmas und liefert einen guten Überblick sowie eine Einord-

nung des PP in den Gesamtkontext:

Abbildung 1: XP-Praktiken


Grundidee und Kernkonzept des XP ist es, schneller mit der Implementierung des Pro-

duktes beginnen zu können als mit den klassischen Softwareentwicklungsmethoden.

Im XP existieren grundsätzlich drei verschiedene Rollenfunktionen: Der Projektleiter,

der Kunde und der Entwickler. Das dieser Diplomarbeit zugrunde liegende Fachprakti-

kum zweier Gruppen bestehend aus Studenten, das ausführlich noch in den folgenden

Kapiteln dargestellt wird, sollte nach den Regeln des XP durchgeführt werden, wobei

die Betreuer in der Rolle der Kunden agierten. Dabei wurde den Studenten empfohlen,

die XP-Praktiken aktiv anzuwenden.

Eine Praktik des XP, das in der Abbildung Nr. 1 rot unterlegte Pair Programming, ist

der Schwerpunkt der Evaluation im Rahmen dieser Diplomarbeit. Allgemein stehen die

XP-Praktiken im Zusammenhang zum PP, wobei bei einer konsequenten Softwareent-

wicklung, organisatorisch strukturiert nach dem XP-Ansatz, alle dargestellten Praktiken

zum Einsatz kommen. Es besteht teilweise ein ganz direkter und teilweise ein indirek-

ter Zusammenhang der Praktiken untereinander. In der Abbildung Nr. 1 sind die XP-

Praktiken farblich gelb hervorgehoben, die im Rahmen des zu evaluierenden Fach-

praktikums im Zusammenhang mit dem Pair Programming eine Rolle gespielt haben

und bei den beiden Gruppen zum Einsatz kamen. Bis auf die beiden in der Abbildung

nicht farblich unterlegten Praktiken „Kundentests“ (es wurden keine direkten Tests von

der Kundenseite (Betreuer) angefertigt) und die „40-Stunden-Woche“ (da es sich um

überwiegend noch berufstätige Fernstudenten handelte, kam es zu einer flexiblen Zeit-

einteilung) sind die XP-Praktiken bei den Gruppen zum Einsatz gekommen. Es wird im

Laufe dieser Arbeit noch teilweise darauf eingegangen, inwieweit einzelne dieser Prak-

tiken von beiden Gruppen konsequent angewandt wurden (z. B. testgetriebene Ent-

wicklung).

2.2 Historie des Pair- und Distributed Pair Programmings

Die Entstehungsgeschichte des PP bzw. DPP lässt sich historisch betrachtet schwierig

an einem bestimmten Ereignis festmachen oder auf ein bestimmtes Jahr datieren. PP

bzw. DPP sind aus einer Entwicklung heraus entstanden. In dem 1995 erschienenen

Buch “Constantine on Peopleware” [Con95] hat Larry L. Constantine über die Beo-

bachtung von „Dynamic Duos“ berichtet, welche er schon in den späten 1970er Jahren

beobachtet und dabei festgestellt hat, dass diese Quelltext schnell erzeugen können

und dieser gemeinschaftlich entwickelte Code nur wenige Fehler enthält. Darüber hin-

aus bestehen in der Literatur aber auch noch weitere frühe Untersuchungen, wie bei-

spielsweise von Tom de Marco und Timothy Lister beschrieben in ihrem Buch „Peo-

pleware: Productive Projects and Teams“ von 1987 [DL87]. Darin kommen die Autoren

zu der Erkenntnis, dass Ergebnisse von Teams besser sind als die Ergebnisse der


gleichen Personen, wenn diese allein arbeiten. Außerdem besteht bei Teamarbeit ein

höherer Spaßfaktor.

Das erste Beispiel eines technischen Computersystems zur Unterstützung gemein-

schaftlicher Arbeit von verschiedenen Orten aus ist das „NLS“-System [EE68], das

unter Führung von Douglas Engelbart entwickelt und 1968 in San Francisco auf der

Joint Computer Conference live vorgestellt wurde. Dieses System erlaubte es zwei

Nutzern kooperativ in Echtzeit am gleichen Text von verschiedenen Orten und Compu-

tersystemen aus zu arbeiten. Neben den beiden von den Vorführern benutzten und

angezeigten Mauszeigern war sogar schon ein Whiteboard implementiert. Bei der Vor-

führung dieses Systems benutzte Engelbart zur Verständigung eine parallele Telefon-

konferenz mit Videoübertragung. Die damalige sehr interessante Demonstration ist

auch im Internet als Videoaufzeichnung verfügbar2.

1991 hat Ward Cunningham XP in einem kommerziellen in Smalltalk entwickelten Pro-

jekt namens „The WyCash Portfolio Management System“ schon diverse XP-Praktiken,

allerdings noch nicht unter dieser Bezeichnung, praktisch angewandt [Cun92]. Dabei

kam auch PP in dem kleinen Entwicklerteam zum Einsatz, wodurch sichergestellt wer-

den sollte, dass sich mehrere Programmierer sehr gut im gesamten Quellcode aus-

kennen. Cunningham verwendete diese Vorgehensweise, weil es ihm in dem Projekt

wichtig war, in dem Prozessablauf schnell auf wechselnde aktuelle Marktanforderun-

gen (Kundenwünsche) reagieren zu können, die notwendige Programmanpassungen

erfordern, um die Kunden auch optimal zufrieden stellen zu können. Das ist auch heute

noch einer der großen Vorteile des XP im Vergleich zum eher starren Wasserfallmo-

dell. 1995 veröffentlichte Jim Coplien das organisatorische Pattern in dem Buch „Pat-

tern Languages of Program Design” [Cop95], in dem er u. a. auch herausstellte, dass

PP positive Effekte besitzt.

Der eigentlich praktische Start in einem größeren Unternehmen von XP, mit Elementen

des PP, begann 1996 mit dem Chrysler-Projekt „Chrysler Comprehensive Compensa-

tion System“, häufig in der Literatur auch als „C3“ bezeichnet. Für das Projekt, in dem

aus diversen Systemen ein einheitliches Lohnabrechnungssystem entwickelt werden

sollte, wurden die Softwareengineering-Experten Beck, Jeffries und Fowler angestellt,

nachdem es ein Jahr vorher gestartet wurde und es im Vorfeld große Probleme in der

Entwicklung gab [Fow05]. Das Projekt erfolgte teils in Einzel- und teils in Paararbeit.

PP kam dahingehend zum Einsatz, dass in den Büros im C3-Entwicklerteam die

Schreibtische zu einem großen viereckigen Tisch zusammengestellt wurden und zwei

benachbarte Programmierer sich direkt sehen konnten. Dabei konnten sie ebenfalls die

Monitore ihrer Nachbarn einsehen und so schnell und direkt miteinander kommunizie-

2 siehe http://sloan.stanford.edu/mousesite/1968Demo.html (Stand 30.06.2008)


ren. Bei dem Projekt wurde festgestellt, dass die meisten Fehler, die in den ersten fünf

Monaten bekannt wurden, überwiegend aus Einzelarbeit stammten [Bec00].

1998 hat Professor Nosek über seine durchgeführte Studie berichtet, in der 15 erfahre-

ne Programmierer eines Softwareunternehmens in 45 Minuten ein Problem lösen

mussten. Die Programmierer wurden dazu in zwei Gruppen eingeteilt. In der einen

Gruppe arbeiteten die Programmierer in Paaren vor einem PC zusammen, während in

der anderen Kontrollgruppe die Programmierer alleine arbeiteten. Die Programmierer

beider Gruppen arbeiteten in ihrer gewohnten Arbeitsumgebung und mit ihrer eigenen

Ausstattung. Als Ergebnis stellte Nosek dabei fest, dass PP die Performance verbes-

sert und sowohl das Vertrauen in den Code als auch das Arbeitsgefühl der Program-

mierer gesteigert wird [Nos98].

Die ersten Softwareentwicklungen zur Unterstützung von DPP begannen im letzten

Jahrzehnt vor der Jahrtausendwende. 1993 wurde das von Dewan und Riedl entwi-

ckelte Programm FLECSE (Flexible Environment for Collaborative Software-

Engineering) vorgestellt, welches das Ziel hatte, kooperative Softwareentwicklung zu

unterstützen, wobei schon beispielsweise das verteilte Editieren und Codieren möglich

war [DR93]. Auch wegen der immer weiteren Verbreitung der Breitbandverbindungs-

möglichkeiten und der generellen Bedeutsamkeit solcher Programme wurden immer

mehr kommerzielle und nicht kommerzielle Programme zur kollaborativen Zusammen-

arbeit entwickelt. Ferner haben mehrere Studien, gerade an amerikanischen Universi-

täten, zur Untersuchung der Effektivität des PP und dem Umgang mit dem DPP statt-

gefunden [FNP+04] [Han05]. Nach der Studie von Nosek hat vor allem die Professorin

Williams in den folgenden Jahren diverse Studien mit Studenten durchgeführt (vgl.

[BWG+02] [SWN+03]).


2.3 Software für Distributed Pair Programming

Zur Unterstützung des DPP sind neben weiteren Programmen die im Folgenden kurz

vorgestellten Programme/Eclipse-Plugins3 entwickelt worden. Diese Programme wer-

den hier beispielhaft aufgeführt, da sie zum Einen in der Literatur zum DPP häufig an-

geführt werden und zum Anderen in der Branche recht bekannt sind. Darüber hinaus

stellen diese Programme einen guten Querschnitt der DPP-Programme dar und bein-

halten teilweise Elemente und Funktionen, die auch in dem dieser Evaluation zugrunde

liegenden Eclipse-Plugin XPairtise vorhanden sind:

TUKAN: TUKAN, 1999 entwickelt im Rahmen ei-ner Diplomarbeit von Till Schümmer, ist ein Sys-tem, das DPP durch synchrone Kooperationsme-chanismen unterstützt. Es stehen neben einem „cooperative class browser“, der DPP ermöglicht (siehe Abb.), zahlreiche Funktionen wie z. B. ein Text- oder Audiochat zur Kommunikation oder Te-lecursor zur anschaulichen Unterstützung zur Ver-fügung. Ferner können weitere Programmierer innerhalb der Umgebung aus einer Benutzerliste ausgewählt und zu einer DPP-Session eingeladen werden [SS01].

„cooperative class browser“ und Textchat in TUKAN

Sangam: Sangam ist ein Eclipse-Plugin zur Unter-stützung von DPP. Die Anfänge von Sangam ge-hen auf das Jahr 2002 zurück, wo die Softwareun-terstützung für das DPP noch sehr selten war. Be-gonnen wurde das Projekt von Somik Raha. Da-nach haben sich an dem Open-Source Projekt mehrere Entwickler und sonstige Unterstützer (u. a. Williams) zu einer Community zusammenge-schlossen. In Sangam wird ein zentraler Server benutzt und es stehen den Usern zahlreiche Funk-tionen zur Unterstützung des DPP zur Verfügung, wie ein synchronisierter Editor, eine Rollenwech-selfunktion zwischen Driver und Navigator und die Möglichkeit, gemeinsam JUnitTests auszuführen. Über Sangam wird in „Sangam - A Distributed Pair Programming Plug-in for Eclipse“ berichtet [HRGW04].

Editor und Textchat in Sangam4

3 Eclipse ist die Bezeichnung für ein umfangreiches und beliebtes Open-Source-Rahmenwerk, das

besonders für die Java-Entwicklung viele Features bietet. Eclipse ist ferner die Basis für die Integrati-on von zahlreichen Erweiterungsmöglichkeiten in Form von Modulen, die als Plugins bezeichnet wer-den. Die Plattform Eclipse kann durch diese Plugins um zahlreiche Funktionen und Tools erweitert werden.

4 http://sangam.sourceforge.net/ (Stand 30.06.2008)


Milos: Milos wurde von Maurer und Martel entwi-ckelt. DPP unterstützt das Tool dahingehend, dass über Microsoft NetMeeting mit den synchronen Funktionen des Application Sharings und den Au-dio- u. Videofunktionen zusammen programmiert werden kann. Schwerpunkt des Projektes bei Milos war es, eine Plattform zur Projektkoordination für verteilt arbeitende Teams zu erzeugen, die gute Funktionalitäten (z. B. Anfertigung von Story Cards) zur Bewältigung eines größeren Software-projektes, z. B. für ein Praktikum (wie das zu eva-luierende Fachpraktikum) liefert, um Teams sinn-voll und organisatorisch zu unterstützen und um die Zusammenarbeit damit zu erleichtern [Mau02].

Anlegung einer Story Card in Milos

COPPER: COPPER (Collaborative Pair Program-ming EditoR) ist ebenfalls ein Tool, welches dem DPP dient. Es stehen neben diversen Funktionen ein kollaborativer Editor und ein Dokumentenver-waltungssystem zur Verfügung. Über in der Sym-bolleiste integrierte Schaltflächen können Rollen-wechsel zwischen Programmierern angefordert werden. Ferner können mittels eines Radar Views, der die aktuellen Betätigungsstellen eines Pro-grammierers im Quelltext anzeigt, die Tätigkeiten des Programmierers verfolgt werden. Copper wur-de auch als Programmierplattform in der Studie “Empirical Evaluation of Collaborative Support for Distributed Pair Programming” [FNP+04] eingesetzt und untersucht, auf die noch in Kapitel 6 zurückge-kommen wird [NFM+03].

Ansicht von COPPER mit Editor

Moomba: Reeves und Zhu entwickelten Moomba als ein Tool für das DPP. Mit Moomba kann über „shared editors“ gemeinsam an einer Datei gear-beitet werden. Weiterhin ist in Moomba neben di-versen anderen Funktionalitäten eine Versions-verwaltung und ein „Pair-Programming Partner Finder“ implementiert. Damit kann über ein Web-portal mit Hilfe eingestellter Userprofile nach ge-eigneten Partnern für ein Projekt gesucht werden [RZ04].

Editor mit Textchat in Moomba


Saros: Saros ist ein Eclipse-Plugin zur Unterstüt-zung des DPP. Es ist ein Open-Source Projekt, das im Rahmen einer Diplomarbeit der „Software Engineering AG“ an der Freien Universität Berlin entstanden ist. In Saros agieren ein Driver und ein Observer miteinander und es findet eine Echtzeit-Synchronisation statt. Daneben stehen Features wie eine User-List oder die Möglichkeit Text-Markierungen vorzunehmen zur Verfügung [Dje06].

Sicht des Navigators in Saros5

PEP: PEP - Pair Eclipse Programming ist ebenfalls ein von zwei Programmierern in der Programmier-sprache Java entwickeltes Open-Source Eclipse-Plugin, das die Code Synchronisation unterstützt. Hierbei obliegt den Entwicklern die Möglichkeit, auf diverse Funktionen wie z. B. einen Chat zurückzu-greifen. Die Besonderheit bei PEP ist, dass im Ge-gensatz zu vielen DPP-Programmen (z. B. Saros) kein Server benötigt wird [PM06].

PEP-Perspektive

JBuilder: Der JBuilder 20076 ist ein kommerzielles und mächtiges Plugin für Eclipse der Firma Code-Gear (früher Borland), das die Zusammenarbeit und Kommunikation von verteilt agierenden Ent-wicklerteams über Netzwerke unterstützt. Dafür stehen den Programmierern mit der integrierten „TeamInsight-Collaboration-Funktion“ Unterstüt-zungstools wie z. B. ein verteilter Code-Editor, ge-meinsames Refactoring oder Debugging zur Ver-fügung. Damit ist der JBuilder ein sehr umfangrei-ches Produkt, das sehr viele Funktionen in einer Plattform vereinigt und damit z. Zt. Teamarbeit kompakter und einfacher unterstützt als viele Open-Source Produkte, die die Vielzahl an Funkti-onen auf einer Plattform bzw. vereinigt in einem Programm nicht bieten.

Perspektive im JBuilder

Darüber hinaus existieren noch die klassischen reinen Application Sharing und Kom-

munikationsprogramme der großen Softwareanbieter, wie das frühere Microsoft Net-

Meeting (welches mittlerweile von Microsoft durch andere Programme wie z. B. Win-

dows Meeting Space7 ersetzt wurde) oder die Weiterentwicklung RealVNC8, der sehr

5 http://dpp.sourceforge.net/screenshots.php (Stand 30.06.2008) 6 http://www.borland.com/de/products/jbuilder/ (Stand 30.06.2008) 7 http://www.microsoft.com/germany/windows/products/windowsvista/features/details/meetingspace

mspx (Stand 30.06.2008) 8 http://www.realvnc.com/ (Stand 30.06.2008)


bekannten Open-Source Plattform Virtual Network Computing (VNC). Diese Program-

me bieten aber über dem Application Sharing hinaus keine weiteren interaktiven und

kooperativen Elemente an, so dass diese für eine gute und intensive kollaborative Zu-

sammenarbeit für das DPP nicht ausreichend sind.

2.4 Entstehungsgeschichte und Funktionen von XPairtise

In diesem Kapitel wird das Eclipse-Plugin XPairtise, welches ebenfalls DPP unterstützt,

vorgestellt. XPairtise ist im Wintersemester 2006/2007 vom XPairtise Team [XPT07] im

Rahmen des Fachpraktikums „CSCW - Entwicklung einer kooperativen Anwendung“

an der FernUniversität in Hagen entwickelt worden. Die relativ hohe Anzahl der Down-

loads des Plugins (1 971 Downloads - von der Veröffentlichung am 26.03.2007 bis zum

30.06.2008) auf der XPairtise-Internetseite9 bei Sourceforge zeigt, wie groß das Inte-

resse nach einem derartigen Programm ist.

Das Programm XPairtise, auf das und dessen Funktionen nun im Folgenden näher

eingegangen wird, bildet die zentrale Grundlage für die Evaluation im Rahmen dieser

Diplomarbeit:

Abbildung 2: XPairtise-Perspektive in Eclipse

Als Hauptfunktionen und teilweise perspektivisch sofort erkennbar sind diverse Kern-

funktionalitäten in XPairtise implementiert, die nachfolgend kurz vorgestellt werden:

9 http://sourceforge.net/projects/xpairtise/ (Stand 30.06.2008)

1

3

2 4


Editor: In XPairtise ist ein Texteditor (siehe Abb. 2 Ziffer 1) implementiert. Alle Code-

änderungen vom Driver oder Markierungen vom Driver und vom Navigator werden bei

allen angemeldeten Nutzern inkl. Spectators (Gäste) sichtbar.

User Gallery: In der User Gallery (siehe Abb. 2 Ziffer 2) sind alle registrierten Nutzer

des Plugins namentlich und ggf. mit einem kleinem Bild erkennbar. Ferner wird dort

auch deutlich, welchen Status (online bzw. offline) die User aktuell besitzen. Darüber

hinaus erfolgt die Darstellung des Sessionnamens, wenn sich ein User in einer aktiven

Session befindet.

Session Gallery: In der Session Gallery sind namentlich alle bisher erzeugten

Sessions aufgelistet. Als User kann man ggf. einer bestehenden Session beitreten

oder ansonsten auch neue Sessions anlegen.

Whiteboard: In XPairtise steht den Nutzern ein Whiteboard als zusätzliche Funktion

(siehe Abb. 2 Ziffer 3) zur Verfügung. Hierüber können schnell eigene Gedanken und

Ideen in Form von gemalten Skizzen zwischen Driver und Navigator ausgetauscht

werden. Diese Zeichnungen können ferner zur späteren Verwendung abgespeichert

werden.

Global Chat: In XPairtise steht ein Textchat (siehe Abb. 2 Ziffer 4) für alle registrierten

User zur Verfügung. Sämtliche Texteinträge werden für alle User sichtbar dargestellt.

Session Chat: Um neben einer evtl. parallel stattfindenen Audiokommunikation eine

direkte Kommunikation zwischen Driver und Navigator zu ermöglichen, ist in XPairtise

neben dem Global Chat ein spezieller Session Chat implementiert, über den in einer

aktiven Session ausschließlich der Driver, der Navigator und ggf. Gäste Texteinträge

austauschen können.

Rollenwechsel: Gerade beim PP ist es sinnvoll, dass die Nutzer die Rollen

(Driver/Navigator) von Zeit zu Zeit tauschen. Dafür steht in XPairtise eine Rollenwech-

selfunktion zur Verfügung. In einer Session kann sowohl der Driver als auch der Navi-

gator einen Rollenwechsel anfordern. Der jeweils andere Nutzer bekommt eine Mittei-

lung, dass ein Rollenwechsel angefordert wurde und kann diesen nun bestätigen oder

auch ablehnen. Er kann demzufolge nicht zu einem Rollenwechsel gezwungen wer-

den. Nach der Zustimmung werden die Rollen sofort gewechselt und die Nutzer agie-

ren fortan in getauschten Rollen.


2.5 Architektur von XPairtise

Der folgende Abschnitt befasst sich mit der Softwarearchitektur von XPairtise. XPairtise

ist in der Programmiersprache Java programmiert und nach dem flexiblen und einfach

erweiterbaren MVC10 (Model-View-Controller) Architekturmuster entwickelt worden.

Über dieses Modell werden alle User-Aktivitäten gesteuert und neue Features können

über Schnittstellen vorhandene Implementierungsdetails erweitern bzw. ggf. auch er-

setzen.

Der Datenaustausch erfolgt nach dem Client-Server-Modell, d. h. dass die Anfragen

der verschiedenen User an den Server gestellt werden und von dort bearbeitet und

wiederum an alle anderen User bereit gestellt werden. In XPairtise wird JMS (Java

Messaging Service) als der dieser Kommunikation zugrunde liegender Transaktionen-

mechanismus eingesetzt. Als Provider, der die Verwaltung dieser Transaktionen vor-

nimmt, wurde ActiveMQ gewählt.

Um DPP überhaupt erst zu ermöglichen, ist die Synchronisation eines Editors zwin-

gende Voraussetzung. In XPairtise wird dazu der Quellcode, nachdem der Driver den

Quellcode einer Datei geöffnet hat, im Plugin bei dem Navigator reproduziert. Alle Än-

derungen, die der Driver durchführt, werden gleichfalls beim Navigator angezeigt. Än-

derungen vom Navigator werden dahingehend allerdings bei einer gemeinsamen Ses-

sion ignoriert. Neben der reinen Textanzeige werden außerdem vorgenommene Text-

markierungen sowohl vom Driver als auch vom Navigator jeweils beim anderen Partner

durch farbliche Markierungen hervorgehoben.

Das Plugin XPairtise bietet verschiedene Funktionen und Möglichkeiten zur Unterstüt-

zung der Programmierung in Paaren an. Nach erfolgter Installation von XPairtise und

Start von Eclipse und des XPairtise-Servers hat der Benutzer die Möglichkeit, die

Standard-Perspektive von XPairtise zu wählen. Um XPairtise dann aktiv nutzen zu

können, muss der Nutzer sich einmalig registrieren und sich ein Profil anlegen. In die-

sem Schritt wird auch der Server ausgewählt, über den später die Daten mit den ande-

ren Benutzern ausgetauscht und synchronisiert werden. Nach der Anmeldung steht

dem Anwender nun die Vielfalt des Plugins zur Verfügung. Programmierer können in

XPairtise verschiedene Rollen einnehmen. Generell steht dem Anwender die Rolle

eines Drivers oder eines Navigators bei einer gemeinsamen Session zur Verfügung. Es

ist in XPairtise aber darüber hinaus möglich, dass neben den beiden Hauptakteuren

noch weitere Zuschauer als Gäste bei einer Session teilnehmen. Diese können dann

im Hintergrund den Verlauf einer Session in der Rolle eines „Spectators“ beobachten.

10 Vgl. http://java.sun.com/blueprints/patterns/MVC.html (Stand 30.06.2008)

Kapitel 3 ● Forschungsfragen 15

3 FORSCHUNGSFRAGEN

In diesem Kapitel werden erste Aussagen aus Studien zur Effektivität des PP angege-

ben. In diesem Zusammenhang werden im Anschluss die im Vorfeld aufgestellten Hy-

pothesen dieser Evaluation vorgestellt und die genauen Herleitungsgründe dazu im

Zusammenhang mit den Evaluationsmethoden erläutert.

3.1 Effektivität von Pair- und Distributed Pair Programming

Eine spannende Frage in der Forschung ist die Frage nach der Effektivität von PP bzw.

DPP. Wie schon in der Einleitung beschrieben, ist es schwer, die Effektivität von PP

und DPP eindeutig zu belegen. Wie bei jeder Softwareentwicklungsmethode gibt es

auch beim PP Vor- und Nachteile, die gegeneinander abzuwägen sind. Laurie Williams

kam beispielsweise in einer Studie zu dem Ergebnis, dass Paare beim Pair Program-

ming zwar ca. 15 % mehr Zeit als Solo Programmierer (SP) benötigen, aber erstere

eine höhere Qualität erreichen [Wil00]. In einer anderen Studie kam Brian Hanks zu

dem Ergebnis, dass Studenten bei Praktizierung des PP im Durchschnitt bei der Ab-

solvierung von Praktika nur 0,67 Probleme pro Praktikum bekamen, während Solo

Programmierer durchschnittlich 1,62 Probleme pro Praktikum hatten und externe Hilfe

von Dritten benötigten, was damit eine seiner im Vorfeld aufgestellten Hypothese un-

terstützt, dass Paare generell in weniger Fällen Unterstützung benötigen als Solo Pro-

grammierer [Han07].

In dem Artikel “Virtual Teaming: Experiments and Experiences with Distributed Pair

Programming“ [SWN+03] stellen sich die Autoren die Frage, ob sich die vorhandenen

Untersuchungen zum PP mit der Hypothese, dass Programmieren in Paaren effektiver

ist als Solo Programming, auch auf örtlich verteilt agierende Paare übertragen lassen.

Dabei kommen die Autoren aufgrund von durchgeführten Studien, bei denen auch die

Qualität der Arbeit und der Zeitbedarf von Studenten bei der Anwendung von DPP un-

tersucht wurden, zu dem Ergebnis, dass DPP durchaus praktikabel ist.

Bei einer Studentenbefragung zu den Vor- und Nachteilen zum PP an der Universität

von Washington gaben Studenten, nachdem diese einen Programmierkurs per PP

praktiziert hatten, mit 30,0 % als größten Vorteil von PP an, dass sie durch die Arbeit

mit dem Partner viel lernen konnten. Danach folgte als Angabe mit 29,4 %, dass durch

das Wissen mehrerer beteiligter Personen das Lösen von Problemen und Debugging

generell einfacher sind. Diese beiden Angaben mit insgesamt fast 60 % zeigen die

bedeutsamsten Vorteile des PP aus Studentensicht auf. Die aufwendige Zeitplanung

und Abstimmung für die gemeinsamen Treffen wurden dagegen mit 47,8 % als größter

Nachteil angesehen. Danach folgten mit 25,6 % mögliche persönliche Differenzen mit

dem Partner und mit 22,9 % abweichende Kenntnisse beim Partner. Alle weiteren an-

gegebenen Nachteile lagen demnach im einstelligen Prozentbereich [Van04].


Generell muss die Überlegung, ein Projekt per SP, per PP oder per DPP durchzufüh-

ren, im Vorfeld genau auf Vor- und Nachteile untersucht und bewertet werden. Als

durchweg positiv ist beim PP bzw. DPP anzusehen, dass bei der Zusammenarbeit

Synergien dahingehend entstehen, dass sich immer zwei Programmierer nach ge-

meinsamen Sessions im Quellcode auskennen, zusammen schneller Fehler erkennen,

generell damit eine bessere Qualität des Codes erreicht wird und ein Wissenstransfer

untereinander stattfindet. Diese vermuteten Vorteile müssen beim PP und DPP mit

dem großen Nachteil der doppelten zeitlichen Ressourcenbeanspruchung und der

Problematik bezüglich der Teamarbeit aufgrund unterschiedlicher sozialer Charaktere

und Kenntnisstände der Teammitglieder abgewogen werden.

Im Zusammenhang mit der Effektivität ist der Kostenaspekt bei der Entwicklung von

Software ein wesentlicher, wenn nicht sogar der wichtigste Faktor. Da beim PP bzw.

DPP zwar immer zwei Programmierer zeitlich beteiligt sind und damit erst einmal sub-

jektiv doppelter personeller Zeitaufwand entsteht, muss aber überdies untersucht wer-

den, ob durch das Prinzip „Vier Augen sehen mehr als zwei“ diese Zeitressourcen nicht

durch einen besseren fehlerreduzierten Code mehr als kompensiert werden. Gerade

spätere Fehlerbereinigungen bei (größeren) Softwareprojekten sind ein nicht zu unter-

schätzender Kosten- und damit auch Zeitfaktor. In dem Artikel „Strengthening the Case

for Pair-Programming“ erläutern die Autoren Williams, Kessler, Cunningham und Jeff-

ries, dass sie bei einem Versuch und Vergleich zwischen solo- und gemeinschaftlich

arbeitenden Teams festgestellt haben, dass die Fehlerquote im programmierten Quell-

code bei den gemeinschaftlichen Teams ca. 15 % geringer war als bei den Solo Pro-

grammierern [WKCJ00]. Arbeitgeber sehen beim PP erfahrungsgemäß jedoch vorran-

gig den doppelt notwendigen Personalaufwand und vernachlässigen dabei die vorhan-

denen Vorteile [CW00].

Um effektiv DPP praktizieren zu können ist eine optimal funktionierende technische

Unterstützung eine der wesentlichen Grundvoraussetzungen. Besonders gute Kom-

munikationsmöglichkeiten sind existenziell für erfolgreiches DPP. Es wäre optimal,

wenn eine Plattform alle Funktionen, die beim DPP benötigt werden, unterstützen wür-

de. In der aktuellen Praxis sieht es z. Zt. so aus, dass verschiedene Softwarewerkzeu-

ge und Programme beim DPP eingesetzt werden. Für verteilt arbeitende Gruppen

müssen sowohl synchrone (wie z. B. Audio- und/oder Textchat) als auch asynchrone

Kommunikationsmittel (E-Mails, virtuelle Gruppenräume) in Verbindung mit einer Pro-

grammieroberfläche (wie z. B. Eclipse) zur Verfügung stehen. Ein guter Ansatz ist es,

die Plattform Eclipse zu nutzen, wofür jetzt schon zahlreiche Open-Source Plugins, wie

auch XPairtise, frei zur Verfügung stehen und weitere Plugins entwickelt werden.

Gerade beim DPP besteht in Gegenüberstellung zum PP die große Gefahr, dass zu-

sätzliche Probleme und Konflikte durch Mängel in der technischen Unterstützung (wie


z. B. Leitungsprobleme oder Abstürze von Softwareprogrammen, die für die aktive An-

wendung des DPP genutzt werden) entstehen können. Haben Programmierer deswe-

gen zusätzlichen (zeitlichen) Aufwand, können auf diese Weise ganze Projekte gefähr-

det werden, weil bei den Programmierern ein Frustfaktor entstehen könnte.

3.2 Hypothesen und Forschungsmethoden

In dieser Diplomarbeit soll anhand der Benutzung von XPairtise evaluiert werden, wie

sich Mitglieder in Gruppen beim DPP verhalten. Aus den im vorherigen Kapitel 3.1 vor-

gestellten Aspekten zum PP bzw. DPP und aufgrund stattgefundener Literaturrecher-

chen wurden im Vorfeld zu dieser Evaluation von Distributed Pair Programming mit

XPairtise zehn Kernhypothesen im Zusammenhang mit der aktiven Anwendung von

DPP in einem Team aufgestellt, die es zu untersuchen und damit zu belegen oder zu

widerlegen galt. Wenn sich alle aufgestellten Hypothesen im Rahmen dieser Evaluati-

on bestätigen, würde dies von einer sehr konsequenten und effizienten aktiven An-

wendung des DPP seitens der Teilnehmer zeugen und vorherige Studien zum DPP

bekräftigen.

Generell existieren zur Untersuchung der aufgestellten Hypothesen verschiedene mög-

liche Evaluationsmethoden. Im Rahmen dieser Diplomarbeit ist der Schwerpunkt auf

die Untersuchung der Anwendung von DPP mit dem in Kapitel 2.4 vorgestellten Eclip-

se-Plugin XPairtise gelegt worden. Daneben wurden aber noch weitere Aspekte bezüg-

lich der Arbeit in Gruppen mit verschiedenen Evaluationsmethoden untersucht, um

möglichst ein gutes Gesamtbild des Verhaltens einer Gruppe bei der Bewältigung einer

größeren Programmieraufgabe zu bekommen. Es kamen für die Evaluation des Fach-

praktikums insgesamt fünf Evaluationsmethoden zum Einsatz, um qualitative und

quantitative Aussagen im Umgang mit DPP zu erhalten:

• Protokollierung von Logfiles während der Programmierung mit XPairtise,

• Audio-Aufzeichnungen von einzelnen Programmiersitzungen,

• CVS-Daten-Auswertungen,

• Monatliche Selbst- bzw. Fremdeinschätzungsbefragungen,

• Interviews mit den einzelnen Gruppenmitgliedern.

Weitere mögliche Evaluationsmethoden wie z. B. Videobeobachtungen, Befragungen

per Fragebögen oder Leistungstests kamen nicht zum Einsatz, weil diese nicht weiter

zweckdienlich gewesen wären. Da die Gruppenmitglieder an verschiedenen Wohnor-

ten jeweils einzeln vor einem PC saßen, würden Videos mit Mimiken oder Gestiken

keine relevanten Aufschlüsse liefern. Aufgrund der geringen Anzahl der Studenten

(insgesamt elf) sind auch Fragebögen, die überwiegend bei anonymen Befragungen

mit einem großen Teilnehmerkreis sinnvoll sind, um an statistisch bedeutsame Ergeb-

nisse zu gelangen, nicht genutzt worden. Auch auf Leistungstests wurde verzichtet, um


die Studenten nicht unnötig unter Druck zu setzen, da die Evaluation freiwillig in dem

Fachpraktikum angesetzt war und auch keinen Einfluss auf das Bestehen des Prakti-

kums hatte. Die Interaktionsprotokollierung per Logdaten belegt alle wichtigen Funkti-

onsbenutzungen und Verhaltensweisen in XPairtise, die im Rahmen dieser Evaluation

eine Rolle spielen. Im direkten Zusammenhang mit Audioaufzeichnungen können diese

bedeutsame Aufschlüsse zu Verhaltensweisen liefern und zu interessanten Erkennt-

nissen über die Kommunikation zwischen den Nutzern in einer XPairtise-Session füh-

ren. Ausgewertete CVS-Daten (das CVS-System wird in Kapitel 4.2.3 erläutert) bele-

gen den Aktivitätsgrad der Studenten im Praktikumsverlauf. Weiterhin können anhand

einer Korrelation der CVS-Daten mit den Logdaten der XPairtise-Sessions Aufschlüsse

über den Grad des Verhältnisses zwischen SP und DPP gezogen werden. Die monatli-

chen Selbst- bzw. Fremdeinschätzungsbefragungen dienen dazu, Erkenntnisse über

das Sachwissen der Studenten zu erfahren und weitere Aufschlüsse über die gegen-

seitigen Wahrnehmungen und Einschätzungen der Studenten untereinander in Bezug

auf Aspekte zum DPP zu erhalten. Das Interview erfolgte mit jedem Studenten separat

in einer persönlichen Atmosphäre im Rahmen eines ermittelnden, standardisierten In-

terviews, bei dem jedem Studenten die gleichen Fragen gestellt wurden, um von die-

sen vergleichbare Aussagen relevanter Sachverhalte zu Auswertungs- und Gegen-

überstellungszwecken zu erhalten.

Diese Methoden und deren spezifischen Anwendungen im Rahmen der Evaluation

dieser Diplomarbeit werden in Kapitel 4 „Evaluationsdesign“ detailliert erläutert.

Im Folgenden werden nun zehn Hypothesen zum DPP mit Angaben der Herleitungen

aus der Literatur, insbesondere aus früheren Studien, erörtert. Daneben werden zu den

jeweiligen Hypothesen auch direkt die dazu im Vorfeld geplanten Evaluationsmethoden

dargestellt. Die Hypothesen berücksichtigen generell verschiedene Aspekte und Berei-

che der breiten Thematik des DPP und der räumlich verteilten Zusammenarbeit in ei-

nem Team. Die Untersuchung der Hypothesen soll damit aufschlussreiche und wis-

senschaftlich relevante Erkenntnisse für zukünftige Projekte liefern. Generell bleibt

anzumerken, dass sich rein faktisch gesehen einzelne Aspekte nicht eindeutig durch

messbare Indikatoren untersuchen lassen, sondern teilweise auf die subjektiven Ein-

drücke der Studenten (z. B. in den Interviewbefragungen) zurückgeführt werden. Diese

können jedoch interessante qualitative Aspekte berücksichtigen und Aufschlüsse lie-

fern, die quantitativ nicht messbar oder belegbar und daher von hoher Wichtigkeit sind:


Hypothese 1 – Nutzerverhalten

Die Paare, die von Anfang an annäherungsweise gleiche Programmiervor-kenntnisse mitbringen und damit die gleichen Grundvoraussetzungen besit-zen, werden direkt das Plugin XPairtise nutzen. Bei Nutzern mit ungefähr glei-chen Kenntnisständen und Fähigkeiten wird eine ausgewogene Distributed Pair Programmierung während einer Session stattfinden. Dieses erkennt man z. B. an regelmäßigen Rollenwechseln. Gleich starke Programmierer lernen und profitieren von einem guten Austausch voneinander. Herleitung: Diese Hypothese wurde basierend auf den Erkenntnissen einer Studie [KWW+04], in welcher unterschiedliche Kennt-nisstände der Programmierer einen Schwerpunkt bildeten, aufgestellt. Daneben lieferten auch die Aussagen von Stu-denten aus einer Befragung zu deren Erfahrungen mit dem PP und speziell zu persönlichen Eigenschaften von mögli-chen Partnern [MM02] interessante Anhaltspunkte. Eine andere Studie [TRR03] kam zu dem Ergebnis, dass gerade die Paare mit ungefähr den gleichen Kenntnisständen am besten zusammenarbeiten und gute Ergebnisse erzielen.

Evaluationsmethoden: Anhand der Logfiles und der Audioaufnahmen lässt sich feststellen, ob und welche Studenten DPP mit XPairtise nutzen. Im Zusammenhang mit den Selbst- und Fremdein-schätzungsbefragungen und den Interviews kann ferner der Lernfaktor (zumindest der subjektive Eindruck der Stu-denten) herausgearbeitet wer-den.

Hypothese 2 – Anfängerverhalten

Nutzer mit geringeren Programmierkenntnissen werden sich während einer Session eher passiv verhalten, d. h. sie werden überwiegend die Rolle des Na-vigators einnehmen und wenige qualitative und quantitative Chat-, Whiteboard- und Audioanteile haben. Herleitung: Diese Hypothese stützt sich wie die erste auf Studiener-gebnisse ([KWW+04] und [MM02]), nach denen Anfänger zunächst geringere Programmieranteile haben.

Evaluationsmethoden: Untersuchung anhand der Logfiles, der Audioaufnah-men sowie der Interviews.

Hypothese 3 – Wissenstransfer

Durch (Distributed) Pair Programming und der Nutzung von XPairtise findet ein Wissensaustausch untereinander statt. Demgemäß lernen gerade die Anfänger Fachwissen und generelle Methodiken gut und schnell von den Experten. Die Experten können sich dabei darin üben, ihr Fachwissen auf verständliche Wei-se an die Anfänger weiterzuvermitteln. Unter den Nutzern kann einmal gebilde-tes Know-How auch auf andere Bereiche transferiert werden. Außerdem trägt der bei einem guten Austausch untereinander stattfindende Wissensfluss dazu bei, dass sich jeder einzelne Programmierer im Gesamtprojekt gut auskennt. Herleitung: In einem Artikel von Thomas, Ratcliffe und Robertson [TRR03] wird erläutert, dass in einer Studie Studenten mit eher geringeren Programmierkenntnissen und weniger Selbstvertrauen sehr gerne PP praktiziert haben. In einer anderen Studie von VanDeGrift [Van04] gaben Studenten als größten Vorteil des PP an, dass sie viel lernen konnten. Da PP sehr kommunikativ sein kann und Programmierer die Möglichkeit der Wissensvermittlung haben, werden diese positiven Effekte auch für diese Evaluation erwartet.

Evaluationsmethoden: Untersuchung anhand der Interviewbefragungen. Zu-dem können auch die Logfiles Aufschlüsse liefern, inwiefern Pair Rotationen stattgefunden haben, durch die auch ein Wissenstransfer auf Dritte ermöglicht wird.


Hypothese 4 – Pair Rotation

In Bezug auf die Paarbildung wird die Hypothese aufgestellt, dass einmal ge-bildete Paare mit ungefähr den gleichen Kenntnisständen, welche erste Aufga-ben gut und effizient bewältigt haben und sich überdies ansonsten auch aus sozialen Gesichtspunkten gut verstehen, während des Praktikums (überwie-gend) beibehalten werden. Das kann in Einzelfällen positiv sein, aber man muss bedenken, dass häufigere Pair Rotationen mit verschiedenen Paarungen bzgl. des Wissenstransfers (siehe Hypothese 3) effektiver sein könnten. Sessi-ons mit ungleichen Paarungen bzgl. der Programmierkenntnisse werden nicht so häufig vorkommen, es sei denn, der versiertere Programmierer ist gewillt, bewusst eine Mentorrolle einzunehmen. Herleitung: In einem Artikel von Ferzli, Wiebe und Williams [FWW02] wird berichtet, dass der Erfolg beim PP nach Aussagen von Studenten von einer geeigneten Partnerwahl abhängig ist. Pair Rotationen tragen dazu bei, verschiedene Program-mierer aus sozialen und erfahrungstechnischen Aspekten kennen zu lernen und zu beurteilen. Daneben kann durch verschiedene Paarwechsel auch Wissen an Dritte weiter-gegeben werden. Die Ergebnisse aus einer Studentenbe-fragung zu den Vor- und Nachteilen von Pair Rotationen wird auch in einem Artikel von Srikanth, Williams, Wiebe, Miller und Balik [SWW+04] angeführt, in dem die Autoren gleichfalls die Vermutung aufstellen, dass einmal gefunde-ne und gut funktionierende Paarungen überwiegend beibe-halten werden.

Evaluationsmethoden: Untersuchung anhand der Logfiles, Audioaufnahmen, Interviews und Selbst- bzw. Fremdeinschätzungsbefra-gungen.

Hypothese 5 – Nutzung der Features in XPairtise

Das Hauptkommunikationsmedium zwischen zwei Programmierern in einer DPP-Session wird der begleitende Audiochat z. B. über Skype sein. Der Text-chat wird eine untergeordnete Bedeutung haben. Daneben wird auch die Mög-lichkeit, dem Driver seitens des Navigators durch Markierungen Hinweise zu geben, häufiger genutzt werden. Dieses Feature ersetzt zusammen mit dem für anschauliche Zwecke wichtigen Whiteboard die Gestik, die ansonsten in einer PP-Session direkt stattfinden könnte. Herleitung: Zahlreiche in der Literatur existierende Studien ([BRB06], [Dje06], [SWN+03], [SSG04]) beschäftigen sich mit der Un-tersuchung der notwendigen und sinnvollen Funktionen für das DPP. Sie kommen zu dem Ergebnis, dass eine Audio-kommunikation sehr sinnvoll ist. Viele Nutzer, die schon einmal aktiv DPP praktiziert haben, hielten darüber hinaus beispielsweise ein Whiteboard für gut bzw. wünschten sich eines, wenn keines vorlag. Deswegen wurde die Hypothese aufgestellt, dass die in XPairtise implementierten Unterstüt-zungstools auch von den Nutzern aktiv benutzt werden. Ferner wird vermutet, dass ein alleiniger Textchat zur Kommunikation nicht ausreicht und begleitende Audiochats benutzt werden.

Evaluationsmethoden: Untersuchung anhand der Logfiles (Häufigkeit von Fea-turenutzungen), Audioauf-nahmen (wie die Kommunika-tion untereinander erfolgt) und Interviews.


Hypothese 6 – Rollenwechsel

Die Rollenwechselfunktion wird häufig - gerade bei Paaren mit ungefähr glei-chen Fähigkeiten - genutzt werden. Dabei wird vermutet, dass der Wunsch nach einem Rollenwechsel überwiegend vom Driver ausgeht. Herleitung: Zur Thematik Rollenwechsel und zum praktischen Umgang mit Rollenwechseln und den Erfahrungen damit gibt es in der Literatur sowohl positive als auch kritische Auffassun-gen ([Bec99], [DZ02], [WYW+02], [FWW02], [Han05]). Rol-lenwechsel werden ein sehr spannendes Thema für diese Evaluation sein, weil zwar bei vielen Forschern Einigkeit darüber besteht, dass regelmäßige Rollenwechsel sinnvoll sind, aber es keine einheitliche Meinung beim praktischen Umgang mit Rollenwechseln in der Forschung gibt.

Evaluationsmethode: Rollenwechsel werden in den Logdaten protokolliert und können damit eindeutig belegt und ausgewertet werden.

Hypothese 7 – Effekte beim DPP

Entgegen kritischen Meinungen ist beim DPP die Konzentration des Drivers und des Navigators relativ konstant, obwohl sich anders als beim PP kein Na-vigator in direkter räumlicher Nähe befindet. Während einer DPP-Session wird konzentriert mit wenig Abwechslungspotential programmiert. Private Angele-genheiten werden vor bzw. nach einem Hauptprogrammierzeitraum unterein-ander besprochen. Herleitung: In einem Artikel von Williams und Kessler [WiKe00] werden verschiedene positive Effekte, die bei der Beobachtung von PP festgestellt wurden, erläutert. Ein wichtiger Gesichts-punkt dabei ist „Pair-Pressure“, was bedeutet, dass durch die Anwesenheit eines Partners die Konzentration auf die Aufgabe fokussiert und damit die Gefahr verringert wird, von einem Thema abzukommen. Die Effektivität von PP und Aspekte des DPP werden auch in weiteren Publikatio-nen in der Literatur beschrieben [CW00] [HRGW04].

Evaluationsmethoden: Untersuchung anhand der Logfiles (gibt es große Unter-brechungen?) in Verbindung mit den Audioaufnahmen (Verhalten der Studenten un-tereinander) und eine Frage direkt zu der Thematik im In-terview.

Hypothese 8 – Pausen

Kleinere Pausen werden beim (D)PP zur kurzen Entspannung ausdrücklich empfohlen und in dieser Evaluation auch erwartet. Es werden in einer DPP-Session aber auch direkte Programmierpausen erfolgen, in denen die Pro-grammierer zu aufgetretenen Problemen und Fragen in der Fachliteratur nach-schlagen müssen, in denen untereinander diskutiert wird oder auch mal die Session zur Klärung der offenen Fragen komplett beendet werden muss. Herleitung: In einem Artikel von Williams und Kessler [WK00] empfeh-len die Autoren ausdrücklich, Pausen zur Entspannung während PP-Sessions zu machen. In einem weiteren Artikel [Bel05] zieht der Autor Belshee folgenden Schluss aus sei-nen Beobachtungen: Die Produktivität beim PP ist am höchsten, wenn eine Paarung nach 90 Minuten eine Pause macht und danach möglichst eine Pair Rotation stattfindet.

Evaluationsmethoden: Die Länge und Häufigkeit von Pausen erhält man direkt aus den Logdaten. Um Aussagen über die genauen Hintergrün-de zu erfolgten Pausen zu bekommen, existiert dazu eine Frage im Interview.


Hypothese 9 – Eigenschaften des DPP

Die Gruppenmitglieder werden gerne DPP mit XPairtise praktizieren. Negative Faktoren (wie z. B. Abneigungen gegenüber disziplinierter Kommunikation und Teamarbeit) werden keine bedeutende Rolle spielen. Ferner werden die einzel-nen Gruppenmitglieder ein hohes Vertrauen in ihr gemeinschaftlich entwickel-tes Produkt herstellen. Herleitung: In einem Artikel [TRR03] machen die Autoren Thomas, Ratcliffe und Robertson die Feststellung, dass Studenten in einer Studie generell dem PP positiv gegenübergestanden haben. Diese Verhaltensweise wird auch an anderer Stelle in einem Artikel von Cockburn und Williams [CW00] bestä-tigt. Der Artikel „Distributed Pair Programming: Empirical Studies and Supporting Environments“ [BWG+02] kommt u. a. zu der Schlussfolgerung, dass DPP Teamwork in einer verteilt arbeitenden Gruppe fördert. Dieses wird auch für die Evaluation bei der Einhaltung wichtiger Verhaltensweisen, die Williams und Kessler [WK00] erörterten, mit XPairtise erwartet. Damit einhergehend wird auch ein großes Ver-trauen der Studenten in ihr Produkt vermutet, wie es schon frühere Studien ([Nos98], [Wil00], [Han05], [MWBF06]) zum PP bzw. DPP aufgezeigt haben. Dieses soll in der vorlie-genden Evaluation bestätigt werden.

Evaluationsmethoden: Zu dieser Thematik sind spe-zielle Fragen in der Interview-befragung enthalten. Die Logdaten liefern dazu Auf-schlüsse über die Anzahl und Regelmäßigkeit der XPairtise-Sessions. Die CVS-Daten belegen die Check-Ins, um auch einen Eindruck über die Aktivitäten der einzelnen Gruppenmitglieder im Prakti-kumsverlauf zu bekommen.

Hypothese 10 – Gruppenverhalten

Gruppen oder Teams, unabhängig von der Nutzung von DPP, die räumlich ver-teilt in Projekten zusammenarbeiten, sind dann am effektivsten und funktionie-ren am besten, wenn diese untereinander dahingehend gut organisiert sind, dass die Mitglieder viel miteinander kommunizieren, eng zusammenarbeiten und die vorhandenen Unterstützungsmedien für die Teamarbeit zielgerichtet und regelmäßig einsetzen. Herleitung: In dem Artikel „The Costs and Benefits of Pair Program-ming“ [CW00] führen die Autoren Cockburn und Williams aus, dass Nutzer von bzw. mit DPP lernen zu diskutieren und zusammenzuarbeiten. Eine gute Kommunikation inner-halb einer Gruppe ist dabei sehr bedeutsam. Eine weitere Voraussetzung dafür und für die generelle Zufriedenheit in einem verteilt arbeitenden Team ist die organisatorische Zufriedenheit mit der Methode, die in dem Artikel „Analyzing Pair-Programmer’s Satisfaction with the Method, the Result, and the Partner“ erörtert wird [PSSH04]. Ein Team muss für jedes Mitglied erkennbar organisiert sein und es sollte ein zentraler Ansprechpartner oder Gruppenleiter für evtl. auf-tretende Probleme benannt sein. Dann sind die Grundstei-ne für ein erfolgreiches Gelingen eines Projektes, wie in dieser zehnten Hypothese angesprochen, gegeben. Ohne eine regelmäßige Kommunikation untereinander, ohne en-ge Zusammenarbeit und regelmäßige Zwischenabstim-mungen in der Gruppe kann ein Team nicht effektiv an ei-nem Projekt zusammenarbeiten. Da das zu evaluierende Fachpraktikum auch ein größeres Projekt darstellt und über einen längeren Zeitraum angelegt ist, werden diese Eigen-schaften auch für die Gruppen des Praktikums wichtig sein.

Evaluationsmethoden: Zum Gruppenverhalten gibt sowohl die Interviewbefra-gung Aufschlüsse als auch der Gesamteindruck der Grup-pen bei der Benutzung der einzelnen Tools und Medien im Rahmen des Fachprakti-kums (u. a. auch die CVS-Daten).

Kapitel 4 ● Evaluationsdesign 23

4 EVALUATIONSDESIGN

In diesem Kapitel wird der organisatorische Ablauf und die zugrunde liegende Aufgabe

des zu evaluierenden Fachpraktikums erläutert. Im Anschluss daran werden die ange-

wendeten Evaluationsmethoden im Detail aufgezeigt.

4.1 Testkontext/Setting

Im Rahmen dieser Evaluation wurden zwei Gruppen, bestehend aus elf Studenten der

FernUniversität in Hagen, im Rahmen des Fachpraktikums „CSCW - Entwicklung einer

kooperativen Anwendung“ im Wintersemester 2007/2008 schwerpunktmäßig dahinge-

hend untersucht, wie diese das Plugin XPairtise genutzt haben. Daneben wurden zu-

sätzlich noch weitere Aspekte des Gruppenverhaltens während des Praktikums be-

trachtet. Die Aufgabe11 der Gruppenmitglieder für beide Gruppen bestand darin, dass

diese im Rahmen des Fachpraktikums ein Eclipse-Plugin entwickeln sollten, das die

synchrone und kooperative Bearbeitung von beliebigen Diagrammen (UML-

Klassendiagramme, UML-Zustandsdiagramme, OWL-Diagramme und Workflow-

Diagramme) ermöglicht. Dazu sollte ein Diagrammeditor entstehen, welcher für unter-

schiedliche Diagrammtypen leicht konfiguriert und erweitert werden kann. Für das

Praktikum wurden die beiden Gruppen bezüglich der Diagrammtypen mit einer leicht

unterschiedlichen Aufgabenstellung beauftragt. Der ersten Gruppe oblag dabei die

Aufgabe, ihren Editor für OWL-Diagramme zu konfigurieren, während die zweite Grup-

pe ihren Editor für UML-Diagramme entwickeln sollte.

Der eigentliche Start des Fachpraktikums begann für die Teilnehmer mit einer viertägi-

gen Präsenzphase an der FernUniversität in Hagen. Dort lernten sich die Praktikums-

mitglieder zum ersten Mal kennen und dort wurden diese in zwei Gruppen eingeteilt

und jeweils ein Gruppen- und damit Projektleiter für jede Gruppe festgelegt. Das Ziel

dieser Präsenzveranstaltung war es, neben der Gruppeneinteilung und dem Kennen-

lernen untereinander die Planung des Projekts mit funktionierenden Gruppenstrukturen

vorzunehmen. Gerade zu Anfang eines Projektes ist es wichtig, die Organisation in-

nerhalb eines Teams zu besprechen und feste Konventionen (z. B. zu Verhaltenswei-

sen) festzulegen. Dabei spielt auch die Qualifikation und die Erfahrung eines Gruppen-

leiters eine bedeutende Rolle, weil dieser erster Ansprechpartner für den Kunden ist. In

Konfliktsituationen ist es die Aufgabe eines Gruppenleiters, vermittelnd tätig zu sein.

Auf diese Weise können viele Folgeprobleme vermieden werden. Es wurde ferner ein

konkreter Fahrplan mit fest terminierten Meilensteinen vereinbart. Innerhalb der Grup-

pen wurde die weitere Vorgehensweise abgeklärt und zu erledigende Aufgaben wur- 11 Vgl. Aufgabenstellung gemäß Info-Heft Nr. 17 vom 29.05.2007 der FernUniversität in Hagen


den, gemäß XP, in einzelne Tasks zerlegt und auf Planungskarten definiert. Generell

ist den Gruppenmitgliedern von den Betreuern zur Umsetzung ihrer Programmierauf-

gabe nahegelegt worden, ihr Projekt nach XP durchzuführen und dafür das Eclipse-

Plugin XPairtise aktiv zu nutzen. Die Betreuer fungierten während des Praktikums da-

bei gemäß der XP-Aufteilung in der XP-Rolle eines Kunden.

An einem Tag der Präsenzphase wurde den Studenten von den beiden Betreuern DPP

in einer ca. zweistündigen Livevorstellung präsentiert, indem von den Betreuern unter

Nutzung von XPairtise eine Beispielanwendung programmiert wurde. Während dieser

Demonstration wurde sowohl der Kerngedanke des Extreme Programming (XP) erklärt

als auch intensiv das Eclipse-Plugin XPairtise vorgestellt. In diesem Zusammenhang

wurden alle Funktionen und Features (wie z. B. Rollenwechsel, Benutzung von Text-

chat und Whiteboard etc.) von XPairtise erklärt und aktiv benutzt. Später bekamen bei-

de Gruppen Zeit, XPairtise aktiv auszuprobieren.

Im Rahmen des Fachpraktikums wurde für beide Gruppen jeweils ein eigener Raum in

CURE12 angelegt und für die jeweiligen Mitglieder freigeschaltet. CURE (Collaborative

Universal Remote Education) ist eine webbasierte Plattform, welche an der FernUni-

versität in Hagen zur Unterstützung von Arbeit in Gruppen, die aus einzelnen Studen-

ten oder auch Betreuern bestehen können, entwickelt wurde. Dort können Studenten

im Rahmen ihres Fernstudiums, die trotz verschiedener Wohnorte in einer Gruppe oder

einem Team z. B. für ein Seminar oder Praktikum zusammen agieren, über virtuelle

Seiten und Räume in CURE kommunizieren oder Inhalte austauschen. Abgesehen von

der Möglichkeit dort Dateien abzulegen besteht neben vielen zahlreichen weiteren

Funktionen in CURE ansonsten die Kommunikationsmöglichkeit über Gruppenmails.

Die Betreuer haben den beiden Gruppen nahegelegt, CURE zu organisatorischen

Zwecken intensiv zu nutzen, da gemäß durchgeführter Studien sowie Fachartikel (z. B.

[SS01]) eine alleinige Kommunikation über Mails innerhalb einer verteilt agierenden

Gruppe nicht das effektivste Kommunikationsmedium ist. Auch auf die spezielle Mög-

lichkeit in CURE, Planungskarten in Form von vorgefertigten Vorlagen, auch Templates

genannt, anzulegen, wiesen die Betreuer explizit hin. Die während der Präsenzphase

erstellten und auch die zukünftigen Planungskarten sollten als weiteres Organisati-

onsmedium in CURE angelegt und regelmäßig jeweils aktuell gepflegt werden. Noch

während der Präsenzphase wurden den ersten Planungskarten feste Bearbeiter zuge-

ordnet. Im weiteren Verlauf des Projektes war es dann möglich, entweder den Pla-

nungskarten feste Bearbeiter in Gruppenbesprechungen zuzuteilen oder die Möglich-

keit zu nutzen, dass sich Gruppenmitglieder nach Erledigung von Aufgaben neue Pla-

12 CURE – siehe http://www.pi6.fernuni-hagen.de/CURE/ (Stand 30.06.2008)


nungskarten selbstständig nehmen und sich selber als Bearbeiter darauf eintragen. Die

Planungskarten sehen vom Aufbau her jeweils zwei Bearbeiter (Driver/Navigator) vor.

Ferner stehen auf den Planungskarten neben einer ID und einer Namensbezeichnung

mit dem Stichwort der Aufgabe ein freies Beschreibungs- und Kommentarfeld für

Kommentare oder Aufgabenbeschreibungen zur Verfügung. Außerdem kann und sollte

der aktuelle Bearbeitungsstatus der Karte wie z. B. „in Bearbeitung“ oder „fertig“ erfasst

werden. Daneben sind noch die Angabe eines Zeitaufwandes und die spätere tatsäch-

liche Realaufwandszeit erfassbar.

Generell bleibt anzumerken, dass alle von den Betreuern empfohlenen Unterstützungs-

tools für das DPP wie XPairtise oder andere Organisationsmedien und Werkzeuge für

verteilte Teamarbeit wie z. B. CURE als freiwillige Angebote an die Studenten gerichtet

waren und diese nicht zwingend von den Studenten bei der Absolvierung ihres Fach-

praktikums eingesetzt werden mussten. Auch die Teilnahme an dieser Evaluation war

freiwillig und keine verpflichtende Bedingung im Rahmen ihres Fachpraktikums.

Nach einer gewissen im Selbststudium erfolgten Einarbeitungszeit nach der Präsenz-

phase, in der überwiegend alle notwendigen Programme installiert wurden und ein Ein-

lesen in die Fachliteratur zu der Problematik der zu bewältigenden Praktikumsaufgabe

stattfand, fingen die Studenten mit der eigentlichen Programmierung ihrer Aufgabe an.

4.2 Angewendete Evaluationsmethoden

Wie schon in Kapitel 3.2 erwähnt, kamen bei dieser Evaluation insgesamt fünf Evalua-

tionsmethoden zum Einsatz, welche mitsamt ihrer Anwendungen in den folgenden Ka-

piteln vorgestellt werden.

4.2.1 Protokollierung von Logfiles bei der Nutzung von XPairtise

In XPairtise wurden im Vorfeld serverseitig diverse Log-Statements in den Open-

Source-Quellcode eingearbeitet, damit qualifizierte und umfangreiche Logdateien er-

zeugt werden konnten. Diese bilden die zentrale Grundlage dieser Evaluation und die-

nen zur Untersuchung der aufgestellten Hypothesen. Dadurch lassen sich alle erzeug-

ten Sessions der Studenten nachvollziehen und belegen. Es wurde von der FernUni-

versität ein zentraler Server für die gesamte Praktikumsphase bereitgestellt, auf dem

das Eclipse-Plugin XPairtise installiert und auf dem ebenso die Logdaten hinterlegt

wurden.


4.2.1.1 Erzeugung Logfiles

Zur Erzeugung von Logfiles wurden alle Daten bei der aktiven Benutzung von XPairtise

protokolliert, bei denen Aktionen vom Benutzer vorgenommen wurden. Neben An- und

Abmeldungsprozessen mit Protokollierung des Benutzernamens und der eingenom-

menen Rolle (Driver/Navigator) wurden Aktionen wie Editoreingaben, Editormarkierun-

gen, Rollenwechselanforderungen und Rollenwechsel, Whiteboard und Textchateinträ-

ge mit Zeitstempeln (Timestamps) versehen und in einem Logfile protokolliert.

Um diese Logfiles erzeugen zu können, musste der Quellcode von XPairtise modifiziert

werden. In XPairtise ist das Logging-Framework Apache log4j 2.013 integriert, das auch

für die Erzeugung der Logdaten für diese Evaluation benutzt wurde. Prinzipiell gibt es

in XPairtise drei Hauptkommunikationskanäle. Erstens die Kommunikation von den

Clients zum Server. Diese wird von der Klasse de.fuh.xpairtise.common.

network.imp.activemq.internal.ActiveMQServerCommandReceiver auf

der Server-Seite verarbeitet. Zweitens die Kommunikation vom Server an einen Client.

Diese wird von der Klasse de.fuh.xpairtise.common.network.imp.

activemq.ActiveMQClientCommandInterface verwendet. Und zuletzt die

Kommunikation vom Server an alle verbundenen Clients. Diese wird von der Klasse

de.fuh.xpairtise.common.network.imp.activemq.ActiveMQMasterList

verarbeitet. Die beiden Klassen ActiveMQServerCommandReceiver und Acti-

veMQClient-CommandInterface im Package de.fuh.xpairtise.common.

network.imp.activemq.internal wurden zur Protokollierung erweitert. Für jede

vorkommende ActiveMQ-Message im Quellcode in XPairtise wurde ein Logeintrag für

die Evaluation ergänzt. Diese Evaluationslogeinträge wurden nach Nachrichtenarten

durchnummeriert, um sie später eindeutig zu identifizieren und wieder einfacher ausle-

sen zu können.

Ein Logeintrag beispielsweise für eine Rollenwechselanforderung (Wechsel zwischen

Driver und Navigator) wird in XPairtise durch den folgenden Eintrag (hier Nachrichten-

art Nr. 198: Rollenwechselanforderung) im Quellcode erzeugt:

case IRemoteCommands.SEND_NEW_ROLE_CHANGE_REQUEST_STATE:

{

StreamMessage sm = (StreamMessage) m;

String sessionToken = sm.readString();

boolean state = sm.readBoolean();

listener.onNewRoleChangeRequestState(sessionToken, state);

XPLog.getLog().info("Evaluation Log 198 -

SEND_NEW_ROLE_CHANGE_REQUEST_STATE: userName: "

+userName.get(userSessionToken) +" xpSessionIdEvaluation: "

+xpSessionIdEvaluation.get(userSessionToken)

+" userSessionToken: " +userSessionToken

+" sessionToken: " +sessionToken

13 http://logging.apache.org/log4j/ (Stand 30.06.2008)


+" state: " +state);

break;

}

Im Workspace von XPairtise “\XPairtise\conf\log4j.properties” muss ferner der Parame-

ter log4j.logger.de.fuh.xpairtise für die Logprotokollierung auf “INFO” ge-

setzt werden. Das angepasste XPairtise-Server Executable-Jar-File „de.fuh.xpairtise_

server_evaluation_1.1“ liegt dieser Diplomarbeit auf der beigefügten CD (siehe Anhang

A 4) bei.

Der folgende Auszug zeigt einen Beispielextrakt aus einem erzeugten Logfile:

2008-01-23 17:19:39,438 INFO [MQ Session Task] server - Evaluation

Log 132 - SEND_XPSESSION_CREATE_MESSAGE_ID: userName: Dominik xp

SessionIdEvaluation: 8ee6ae4f0aa1816d userSessionToken:

6a41de4367e57a60 xpSessionTopic: Editorprogrammierung sharedProject:

de.fuh.test.editor


Log 135 - SEND_XPSESSION_JOIN_MESSAGE_ID: userName: Dominik role: 1

xpSessionIdEvaluation: 8ee6ae4f0aa1816d userSessionToken: 6a41de4367

e57a60 xpSessionId: 6b2d1354e3c7e92b


Log 135 - SEND_XPSESSION_JOIN_MESSAGE_ID: userName: Jule role: 2

xpSessionIdEvaluation: 8ee6ae4f0aa1816d userSessionToken: 5b67de2005

e02a50 xpSessionId: 6b2d1354e3c7e92b


Log 108 - SEND_EDITOR_OPEN_MESSAGE_ID: userName: Dominik xpSession

IdEvaluation: 6b2d1354e3c7e92b userSessionToken: 6a41de4367e57a60

editorId: 9de4808345e3231c xpSessionId: 6b2d1354e3c7e92b inputPath:

src/de/ fuh/test/editor/TestEditor.java inputChecksum: 7b2a692f514e5e

editorType: org.eclipse.jdt.ui.CompilationUnitEditor


Log 198 - SEND_NEW_ROLE_CHANGE_REQUEST_STATE: userName: Dominik

xpSessionIdEvaluation: 6b2d1354e3c7e92b userSessionToken:

6a41de4367e57a60 sessionToken: 9b9d18b73809ad4c state: true

Dargestellt ist hier ein Start einer neuen Session in XPairtise. Der erste Eintrag belegt,

dass der User „Dominik“ eine neue Session mit der Bezeichnung „Editor Programmie-

rung“ angelegt hat. Der zweite Logeintrag bedeutet, dass der User „Dominik“ als Driver

(role: 1) der Session beigetreten ist. Der dritte Eintrag dokumentiert, dass die Benutze-

rin „Jule“ der Session als Navigator (role: 2) beigetreten ist. Der letzte Eintrag zeigt, wie

die Rollenwechselanforderung (Nr. 198) im Log dargestellt wird. In diesem Fall forderte

der Benutzer „Dominik“ einen Rollenwechsel an.


4.2.1.2 Auswertung Logfiles

Um die in Kapitel 4.2.1.1 beschriebenen erzeugten Logdaten zur Belegung und Unter-

suchung der Hypothesen (z. B. zum Nutzerverhalten, Nutzung der Features etc.) die-

ser Evaluation automatisch auswerten zu können, wurde speziell für diese Diplomar-

beit ein Java-Programm „LogFilter – Analyser XPairtise“ entwickelt. So liefert das Pro-

gramm beispielsweise pro Session Gesamtsummen bezüglich der von den Nutzern

getätigten Editoreinträge oder Markierungen. Ferner ermittelt das Programm die An-

zahl der durchgeführten Rollenwechsel, die Anzahl von stattgefundenen Pausen oder

die Benutzung diverser Funktionen in XPairtise wie z. B. die Benutzung des Whitebo-

ards oder der Textchats.

Im Programm muss als erstes eine erzeugte Logdatei geladen werden, die dann auf

dem Bildschirm ausgegeben wird:

Abbildung 3: Bildschirm Logauswertungsprogramm

Auf dieser Abbildung ist ein Screenshot aus dem Logauswertungsprogramm darge-

stellt, nachdem eine Logdatei über den Menüpunkt „Logfile“ geöffnet wurde. Zu erken-

nen sind die einzelnen mit Timestamps protokollierten Logeinträge. Nach Eingabe ei-

nes gewünschten Auswertungszeitraumes über den Menüpunkt „XPairtiseLogResult-

Dialog“ liefert das Programm über entsprechende programmierte Algorithmen die an-

gesprochenen Gesamtsummen und die Summen der getätigten Aktionen pro aktivem

Benutzer:


Abbildung 4: Ergebnis aus dem Logauswertungsprogramm

Daneben bietet das Programm noch zwei zusätzliche Funktionen an. Es besteht ein-

mal die Möglichkeit, sich alle User einer ausgewählten Logdatei ggf. mit Eingrenzung

eines Auswertungszeitraumes anzeigen zu lassen und ferner gibt es die Funktion, sich

nur die Daten bestimmter Nutzer ggf. mit Eingrenzung eines bestimmten Auswertungs-

zeitraumes und unter vorheriger Eingabe des Nutzernamens auswerten zu lassen.

Das Programm „LogFilter – Analyser XPairtise“ sowie eine Kurzbeschreibung und

Anleitung liegen dieser Diplomarbeit bei (siehe Anhang A 4).

4.2.2 Audio-Aufzeichnungen einzelner Sessions

Neben den Logfiles sind zusätzlich einige Audioaufzeichnungen bei der aktiven Benut-

zung von XPairtise mitgeschnitten worden, die vor allem für die Belegung der Hypothe-

sen wichtig sind. Neben der Erlangung eines guten Gesamteindrucks dienen sie ferner

dazu, die Interaktionen und Verhaltensweisen der Programmierer während einer Ses-

sion zu beobachten. Die Audiobeobachtungen verdeutlichen, wie die Paare beim DPP

agieren und wie die Konversation untereinander abläuft.

Da die Audiokommunikation der Gruppenmitglieder bei beiden Gruppen untereinander

per Skype14 stattfand, wurden Audiomitschnitte mittels eines Audioaufnahmetools von

den Skype-Telefonaten gemacht. Skype ist eine VoIP-Software, mit der über das Inter-

14 Skype Technologies S.A. - siehe http://www.skype.com (Stand 30.06.2008)


net telefoniert werden kann. Dabei erlaubt Skype Audiokonferenzen mit mehreren Teil-

nehmern, womit es ein gutes Kommunikationsmedium für die Praktikumsgruppen dar-

stellt. Weiterhin stehen in Skype neben weiteren Funktionen auch eine Textchatfunkti-

on zur Verfügung und es können Daten und Dateien direkt aus Skype heraus unterein-

ander versendet werden.

4.2.3 CVS-System

Um einen Überblick über die Aktivitäten der Studenten bei Java-Klassenänderungen

während des Fachpraktikums zu bekommen, wurden die Daten der CVS-Check-Ins im

Rahmen dieser Evaluation untersucht. Dazu wurde den beiden Gruppen von der Fern-

Universität in Hagen jeweils ein eigenes CVS-Repository auf einem zentralen Server

der Universität zur Verfügung gestellt. CVS15 (Concurrent Versions System) ist ein Sys-

tem zur Versionsverwaltung von Dateien, das überwiegend für Programmcode benutzt

wird. Es bewerkstelligt kontrollierte Änderungen von Programmcode an einem Projekt,

wobei diese auch während der Entwicklung von verschiedenen Programmierern paral-

lel vorgenommen werden können. Mittels des CVS-Systems lässt sich jeder Check-In

der einzelnen Java-Klassen im Quellcode feststellen und belegen. Die Verfahrenswei-

se ist dergestalt, dass CVS-Nutzer den Quellcode lokal im eigenen System ändern und

diesen dann später aktualisiert per Check-Ins in das CVS-System übertragen können,

wobei ein automatisierter Konfliktabgleich seitens des CVS-Systems erfolgt. Dabei

können ggf. eigene erklärende Kommentierungen für die übrigen Gruppenmitglieder

über die vorgenommenen Eingriffe in den Quellcode ergänzt werden. Nach erfolgtem

und fehlerfreiem Check-In ist der Code mit allen Veränderungen für alle anderen Teil-

nehmer einsehbar und kann von diesen zur Weiterentwicklung wieder per Check-Outs

auf ihre eigenen Systeme übertragen werden.

Diese Daten der CVS-Check-Ins zeigen die Anzahl der Aktivitäten der Studenten und

der Gruppen im Praktikumsverlauf auf und erlauben ferner durch eine Korrelation zu

den Logdaten der XPairtise-Sessions einen Eindruck über das Verhältnis des SP zum

DPP bei den Studenten und in den Gruppen. Erfolgen die Check-Ins vom Timing her

(Zeitpunkt des Check-Ins) korrespondierend mit einer XPairtise-Session, zeigt dies,

dass der Code gemeinschaftlich entwickelt wurde. Zur Auswertung wurden die Daten

aus der CVS-Historie exportiert und mit dem BASE-Datenbanksystem16 von OpenOffi-

ce.org zusammengefasst und ausgewertet. Dabei wurden für verschiedene Auswer-

tungen hauptsächlich Zusammenfassungen und Gruppierungen vorgenommen, um z.

B. Aussagen über die Anzahl der Check-Ins im Fachpraktikumsverlauf pro Gruppe zu

erhalten oder beispielsweise Erkenntnisse über die Anzahl der Klassen-Check-Ins pro 15 http://www.nongnu.org/cvs/ (Stand 30.06.2008) 16 http://de.openoffice.org/product/base.html (Stand 30.06.2008)


Student zu bekommen oder wie viele Klassen von wie vielen Studenten bearbeitet

wurden.

4.2.4 Selbst- und Fremdeinschätzungsbefragungen

Während des Fachpraktikums wurden die Studenten gebeten, monatlich (insgesamt

fünfmal) eine Selbst- und eine Fremdeinschätzung gegenüber den Gruppenmitgliedern

abzugeben. Die vorgenommenen Selbst- und Fremdeinschätzungen wurden unterein-

ander zwischen den Gruppenmitgliedern nicht ausgetauscht oder kommuniziert. Für

die Befragung wurde den Studenten jeweils eine eigene Seite in dem CURE-System

(CURE- siehe Kapitel 4.1) zur Verfügung gestellt. Diese Seite war außer für den jewei-

ligen Studenten und dem Evaluator für niemanden einsehbar. Auf speziellen Wunsch

wurden den Studenten der ersten Gruppe die monatlichen Einschätzungen per Mail zur

Verfügung gestellt, die nach Ausfüllung von diesen wieder zurückgesendet wurden.

Es gab Fragen zur Einschätzung von Expertenwissen, um einen Überblick über die

Programmierkenntnisse zu bekommen, aber es sollten überdies Fragen zum persönli-

chen zeitlichen Aufwand für das Praktikum beantwortet werden. Darüber hinaus sollte

eine Angabe über den Anteil des Solo- bzw. Pair Programmings im jeweiligen Monat

gemacht werden.

Ein Ziel dieser Befragung war die Untersuchung, wie gerne und wie häufig die Grup-

penmitglieder während des Praktikums zusammenarbeiten und wie viel Arbeit dagegen

in Einzelarbeit erledigt wird. Somit dienen die Befragungen auch dazu, Erkenntnisse für

die erste Hypothese über die Zusammensetzung der Paare zu bekommen und heraus-

zufinden, ob es, wie es die vierte Hypothese erläutert, zu Pair Rotationen kommt. Zu-

dem kann dadurch auch das eigene Empfinden zu Spezialwissen und Programmierer-

fahrungen untersucht werden, um auch Erkenntnisse zur dritten Hypothese zu erhal-

ten. Alle Fragen werden im Anhang unter A 2 aufgeführt.

4.2.5 Interviews

Es war geplant, ungefähr einen Monat vor Beendigung des Praktikums mit jedem Stu-

denten ein Interview über Skype zu führen. Dafür wurden Fragen rund ums DPP und

den Erfahrungen damit vorbereitet. Durch gezielte Interviewfragen sollten Rückschlüs-

se zu den Hypothesen (siehe im Detail Kapitel 3.2) gezogen werden. Die gesamte Auf-

listung der gestellten Interviewfragen können dem Anhang A 1 entnommen werden.

Kapitel 5 ● Evaluationsergebnisse 32

5 EVALUATIONSERGEBNISSE

In diesem Kapitel werden detailliert die Ergebnisse dieser Evaluation aus der Anwen-

dung der in Kapitel 4 angeführten Evaluationsmethoden vorgestellt.

5.1 Organisation der Gruppen

Eine gute Organisation innerhalb eines Teams ist, wie es die zehnte Hypothese be-

hauptet, eine bedeutende Voraussetzung für die erfolgreiche Bewältigung eines größe-

ren Gruppenprojektes. Bei der Beobachtung der beiden Gruppen lassen sich schon

relativ früh Unterschiede in der Organisation für das Projekt feststellen.

Bei der ersten Gruppe erfolgte ein Großteil der E-Mail-Kommunikation und die Ablage

von Dateien zum Projekt über den Gruppenraum in CURE. Diverse Anleitungen, ge-

fundene Literatur, Gruppenregeln, vereinbarte Zeitpläne, Dokumentation der vereinbar-

ten Programmierstandards (siehe Abbildung Nr. 1) und Protokolle der wöchentlichen

Gruppentreffen wurden dort für jedes Gruppenmitglied zugreifbar eingestellt und damit

gleichzeitig archiviert. Auf diese Weise konnten die Betreuer, die in der Rolle des XP-

Kunden fungierten, den wichtigsten Mailverkehr verfolgen und auch die Protokolle und

den Fortschritt des Projektes beobachten. Insgesamt wurden 27 Besprechungsproto-

kolle der wöchentlichen Gruppenbesprechungen in CURE eingestellt.

Im Gegensatz zur ersten Gruppe hat die zweite Gruppe in den ersten Wochen von

ihrem CURE-Raum wenig Gebrauch gemacht. Der E-Mail-Verkehr erfolgte größtenteils

in Rundmails untereinander und damit auch für die Betreuer nicht einsehbar. Ein ge-

meinsames Ablagesystem wurde nicht genutzt. Erst ab Mitte Dezember (d. h. nach der

neunten Woche im Praktikumsverlauf) wurden nach einer Besprechung und Aufforde-

rung seitens des Betreuers Protokolle in CURE eingestellt und eine E-Mail-

Kommunikation über CURE angefangen, die allerdings nie so intensiv und konsequent

erfolgte wie bei der ersten Gruppe. Insgesamt stellte die zweite Gruppe lediglich fünf

Besprechungsprotokolle in CURE ein.

5.1.1 Bearbeitungsverhalten bei den Planungskarten

Wie in Kapitel 4.1 erläutert, empfahlen die Betreuer, Planungskarten in CURE einzu-

stellen und zu pflegen. Von der ersten Gruppe wurde diese Vorgehensweise anfangs

regelmäßig befolgt. Die Karten wurden angelegt und nach den zeitlich festgelegten

Meilensteinen eingeteilt, sortiert und regelmäßig gepflegt, d. h. wenn z. B. eine Karte

mit einer Aufgabe erledigt wurde, wurde diese Karte auch als erledigt gekennzeichnet.

Insgesamt hat die erste Gruppe während des Fachpraktikums 188 Planungskarten

angelegt. Die Disziplin der Kartenpflege wurde allerdings gegen Ende des Praktikums

bei dieser Gruppe immer mehr vernachlässigt. So standen am Ende die Karten zwar

weitgehend auf dem Bearbeitungsstatus „erledigt“, allerdings wurden 60 Karten (= ca.


31,9 %) nicht gepflegt. Dieses zeigte sich in der Tatsache, dass die Karten keinem

festen Bearbeiter zugeordnet waren, auch wenn die dazugehörige Aufgabe erfasst

wurde. Bei den 128 nach Bearbeiter und Status gepflegten Karten wurden in rund 10 %

der Fälle noch weitere Kommentare erfasst. Von der Möglichkeit, die im Vorfeld ge-

schätzten Zeitaufwände für die Aufgaben mit den realen Bearbeitungszeiten in Bezie-

hung zu setzen, wurde in 79 Fällen Gebrauch gemacht. Bei diesen Karten war sowohl

eine geschätzte als auch die reale Aufwandszeit vermerkt. Dabei war zu 49 % der rea-

le Zeitverbrauch geringer als der im Vorfeld geschätzte Zeitaufwand, zu 43 % war der

reale Aufwand (teilweise deutlich) höher als der geschätzte und in 8 % der Fälle war

der Zeitverbrauch gleich dem geschätzten Zeitaufwand.

Bei der zweiten Gruppe wurden ebenfalls Planungskarten bei der Präsenzphase ange-

legt. Wie schon erwähnt, erfolgte erst nach einer Aufforderung seitens des Betreuers

eine Pflege der Karten in den letzten Wochen. In solch einer Situation ist es gerade

auch in der Anfangsphase eines Projektes die Aufgabe des Gruppenleiters darauf zu

achten, dass eine regelmäßige Pflege vorgenommen wird, um einen Überblick über

den Projektfortschritt zu behalten und unnötigen Ärger mit dem Kunden (Betreuer) zu

vermeiden. Insgesamt wurden bei der zweiten Gruppe 69 Karten angelegt (und damit

119 Karten weniger als bei der ersten Gruppe). Von den 69 Karten waren am Ende des

Praktikums 60 als erledigt gekennzeichnet und neun Karten hatten den Status „ge-

plant“. Das bedeutet, dass noch neun weitere Aufgaben vorgesehen waren, aber nicht

mehr abgearbeitet wurden. Bei diesen Aufgaben handelte es sich aber nicht um essen-

tielle Aufgaben. Unerledigte oder anderweitig noch offene Karten waren nicht mehr

vorhanden, so dass die zweite Gruppe zum Ende hin alle ihre Planungskarten über-

prüft und organisiert hatte. Bei den 69 Karten wurden keine weiteren Kommentare er-

fasst. Von der Möglichkeit, die im Vorfeld geschätzten Zeitaufwände für die Aufgaben

mit den realen Bearbeitungszeiten in Beziehung zu setzen, ist bei der zweiten Gruppe

in 36 Fällen Gebrauch gemacht worden. Dabei war in 16 % der Fälle der reale Auf-

wand geringer als der im Vorfeld geschätzte Aufwand, in 68 % war der reale Zeit-

verbrauch höher als der geschätzte und in 16 % der Fälle war der Aufwand gleich der

geschätzten Zeiterfordernis. Die Ergebnisse der beiden Gruppen zu den Zeiteinschät-

zungen belegen, dass es schwierig ist, den exakten Zeitaufwand im Vorfeld präzise

abzuschätzen.

Der Umgang beider Gruppen mit den Planungskarten zeigt, dass dieses Organisati-

onssystem, das sowohl den Gruppenmitgliedern als darüber hinaus auch außenste-

henden Personen, wie z. B. den Betreuern, einen guten Überblick über den aktuellen

Stand des Projekts liefert, nicht konsequent genutzt wurde. Die Gründe dafür können

unterschiedliche Ursachen haben. Bei der Anlegung von Planungskarten ist der Sinn


und Umfang der Karte in Bezug auf die Aufgabe genau zu überlegen und festzulegen.

Die hohe Anzahl der 188 Karten der ersten Gruppe ist evtl. für das Projekt eine etwas

zu hohe Anzahl gewesen, weil dort selbst kleinere und sehr spezielle Aufgaben detail-

liert aufgenommen wurden. Besser wären Karten mit den Hauptaufgaben gewesen,

ohne diese in ganz feine Details auf weiteren Planungskarten zu untergliedern. Realis-

tisch wäre es, wenn man den XP-Ansatz ernst nimmt, bei einem Team bestehend aus

6 Personen, die Aufgaben auf ca. 114 Karten einzuteilen (Bearbeitungszeit für eine

Planungskarte im Team: 10 Stunden; pro Woche wären es dann per DPP insgesamt 6

Karten bei 20 Std./pro Woche; die Gesamtpraktikumsphase dauerte insgesamt 19 Wo-

chen = 114 Karten; vgl. auch „Extreme Programming: A gentle introduction“17). Durch

die hohe Anzahl wurde es unübersichtlicher und damit fühlten sich Gruppenmitglieder

für Detailaufgaben nicht zuständig, weil sich diese Detailaufgaben überwiegend auch

nur im Zusammenhang mit größeren Aufgaben und Hauptkonstruktionselementen ei-

ner Programmierung bewältigen lassen.

Betreuer oder auch evtl. Kunden von Projekten, die in Teamarbeit erfolgen und mittels

Planungskarten definiert werden, sollten schon im eigenen Interesse darauf achten,

dass diese sinnvoll eingeteilt und regelmäßig bearbeitet und gepflegt werden, um Risi-

ken zu vermeiden und Probleme bei der Einhaltung von festen Zeitplänen rechtzeitig

zu erkennen bzw. ggf. früh genug zu beheben. Bei Problemen sollten sich die Kunden

zeitnah mit den Gruppenleitern in Verbindung setzen.

5.1.2 Verhalten der Gruppenleiter

Die beiden Gruppenleiter haben in diesem zu evaluierenden Fachpraktikum unter-

schiedlich agiert. Insgesamt ließen dazu die Interviews, der Gesamteindruck und die

Verhaltensweisen der Gruppen Rückschlüsse zu. Die erste Gruppe hat mit einem

Gruppenleiter, der sowohl innerhalb der Gruppe zentraler Ansprechpartner war als

auch im stetigen Kontakt zum Betreuer stand, deutlich stressfreier und strukturierter ihr

Ziel erreicht. Wichtig für eine erfolgreiche Absolvierung eines größeren Softwareprojek-

tes nach dem XP-Ansatz mit mehreren beteiligten Personen im Rahmen von Gruppen-

arbeit ist es, dass die Entwickler bzw. ein Gruppenleiter im engen Kontakt zu den Kun-

den (Betreuern) stehen und regelmäßige Zwischengespräche, wie z. B. bei Erreichung

eines Meilensteines, stattfinden. Kristallisieren sich Probleme heraus oder wird sich

nicht an Absprachen oder vorgegebene Zeitpläne gehalten, sollten die Kunden direkt

und damit zeitnah tätig werden, klärende Gespräche einfordern und dadurch auch ggf.

etwas notwendigen Druck auf die Gruppe ausüben.

17 http://www.extremeprogramming.org/ (Stand 30.06.2008)


Bei der zweiten Gruppe traten im Projektverlauf Probleme auf, wobei die Gründe dafür

nicht beurteilt werden können. Die Meilensteine wurden nicht eingehalten und es er-

folgten auch keine Bestrebungen von der Gruppe oder gerade von dem Gruppenleiter

dahingehend, dieses mit dem Betreuer zu besprechen und die Probleme der Nichtein-

haltung zu erläutern. So kam es schnell zu einem gestörten Verhältnis zwischen dem

Betreuer (in der Rolle des Kunden) und der Gruppe, was vermutlich durch klärende

Gespräche mit Erläuterung der Probleme vermeidbar gewesen wäre.

Ein möglicher Verbesserungsvorschlag besteht deswegen dahingehend an die Kunden

(Betreuer) eines Projektes, dass sie explizit den Gruppenleitern in Vorbesprechungen

vorschlagen sollten, dass diese während eines Projektes neben dem wichtigen Kun-

denkontakt in engem Kontakt zu jedem einzelnen Programmierer stehen sollten und

auch mit jedem separat regelmäßige Zwischengespräche führen bzw. Feedbacks ein-

fordern sollten. Für solche organisatorisch sinnvollen Zusatzaufgaben müsste den

Gruppenleitern seitens der Kunden genügend Zeit zur Verfügung gestellt werden. So

können Unstimmigkeiten zeitnah geklärt und Probleme früher gelöst werden. Ein

Gruppenleiter könnte in regelmäßigen Abständen, außerhalb der Gruppenkonferenzen,

die Programmierer zu ihrer generellen Zufriedenheit in Bezug auf Paarzusammenset-

zungen, Pair Rotationen, den Verlauf des Projektes, dem persönlichen Timing und

dergleichen mehr befragen. Darüber hinaus sollten sie sich auch nach möglichen Ver-

besserungsvorschlägen erkundigen. Das hat neben einer höheren allgemeinen Zufrie-

denheit der Teilnehmer den Vorteil, dass ein Gruppenleiter auch den notwendigen

Überblick über das Gesamtprojekt behält. Generell sollte der Gruppenleiter auf die

Einhaltung der festgelegten Konventionen innerhalb der Gruppe kontinuierlich achten

und auch hier bei Bedarf zeitnah eingreifen.

5.2 XPairtise - Ergebnisse der Benutzung

Der eigentliche Start der Gruppen mit den Anfängen der Programmierung der Prakti-

kumsaufgabe begann leicht zeitversetzt. Bei der ersten Gruppe sind nach 22 Tagen die

ersten Programmieraktionen und Javaklassen-Check-Ins in das CVS-System vorge-

nommen worden. Bei der zweiten Gruppe sind schon nach sechs Tagen die ersten

Javaklassen entstanden. Das Plugin XPairtise kam nach der Präsenzphase bei der

ersten Gruppe nach 16 Tagen und bei der zweiten Gruppe nach 10 Tagen zum ersten

Mal zum Einsatz. Dabei handelte es sich bei beiden Gruppen um erste Schritte, um

sich mit dem Plugin vertraut zu machen. In der ersten Session der ersten Gruppe, die

aus zwei Studenten18 bestand und insgesamt knapp zwei Stunden dauerte, wurde

schon testweise (ohne Programmierung an dem eigentlichen Projekt) programmiert 18 Um die Anonymität der weiblichen Studentinnen zu wahren, erfasst im Rahmen dieser Diplomarbeit

der Begriff „Student“ sowohl die weiblichen als auch die männlichen Gruppenmitglieder.


Zeit in Minuten

und infolgedessen direkt Quellcode erzeugt. Bei dieser ersten Session handelte es sich

bei den Studenten um einen schon kundigeren Programmierer und einem Anfänger.

Die besonderen Funktionen von XPairtise wurden dabei nicht mehr ausprobiert und

auch nicht benutzt. Bei der zweiten Gruppe dauerte die erste Testsession, bei der fünf

der sechs Gruppenmitglieder anwesend waren, insgesamt ca. eineinhalb Stunden,

wobei alle Funktionen und Features ausprobiert wurden. Programmierungen im Quell-

code wurden dabei nicht vorgenommen.

Eine vollständige Übersicht über die Nutzung der beiden Gruppen von XPairtise im

Praktikumsverlauf liefern die beiden folgenden Abbildungen:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18Gruppe 10

100

200

300

400

500

600

700

800

900

1.000

1.100

1.200

Gruppe 1 Gruppe 2

Abbildung 5: Nutzung von XPairtise im Praktikumsverlauf (Zeit in Minuten)

0

1

2

3

4

5

6

7

8

9

10

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

Gruppe 1 Gruppe 2

Abbildung 6: Nutzung von XPairtise im Praktikumsverlauf (Sessions pro Woche)

Sessions pro

Woche

Wochenverlauf

Wochenverlauf


Die Abbildung 5 zeigt den Einsatz des Plugins XPairtise im wochenzeitlichen Prakti-

kumsverlauf. Es ist direkt zu erkennen, dass die erste Gruppe während der gesamten

Praktikumsphase deutlich häufiger das Plugin XPairtise benutzte und damit häufiger in

Paaren direkt am Quellcode arbeitete als die zweite Gruppe. Es lassen sich über den

gesamten Zeitraum deutliche Schwankungen feststellen. Insgesamt kam XPairtise bis

zur 18. Woche im Praktikumsverlauf der Gruppen zum Einsatz. Das bedeutet, dass es

in den letzten drei Wochen der Praktikumsphase bei der ersten Gruppe und aufgrund

der unterschiedlichen Abgabetermine bei der zweiten Gruppe (die zweite Gruppe hat

eine Praktikumsverlängerung gegenüber der ersten Gruppe von drei Wochen erhalten)

in den letzten sechs Wochen keine Nutzung von XPairtise mehr gab. Generell lässt

sich aus der Abbildung ablesen, dass XPairtise nach einem verhaltenen Start, der

durch die Einarbeitungszeit zu begründen ist, am intensivsten in der siebten bis neun-

ten Woche von beiden Gruppen im Praktikumsverlauf benutzt wurde.

Insgesamt wurden im Rahmen dieser Evaluation 52 Sessions zum DPP untersucht und

zwar 41 Sessions von der ersten Gruppe und 11 von der zweiten Gruppe, dargestellt in

Abbildung 6. Insgesamt haben die Gruppen 55 Sessions in XPairtise getätigt. Drei

Sessions waren anfangs allerdings nur Sessions zur Eingewöhnung und zum Testen

der Funktionen von XPairtise. Gegen Ende des Praktikums wurde XPairtise immer

weniger eingesetzt. Das hatte mehrere Gründe. Bei der ersten Gruppe wurde gegen

Ende des Praktikums immer weniger zusammen programmiert, weil das Grundgerüst

stand und gegen Ende eher kleine Verfeinerungen und Anpassungen programmiert

wurden, die überwiegend in Einzelarbeit erledigt wurden. Weiterhin haben die Fehler-

suche - aufgrund technischer Defizite beim Debugging in XPairtise - und kleinere Pro-

grammverbesserungen mit Optimierungen ohne die Nutzung von XPairtise stattgefun-

den. XPairtise wurde im Praktikumsverlauf überwiegend dazu benutzt, um gemeinsam

reinen Quellcode mit neuen Elementen zu entwickeln. Der Einsatzzweck zeigt, dass in

XPairtise eine Unterstützung für gemeinsames Debugging wünschenswert gewesen

wäre. Eine konkrete Aussage eines Studenten lautete im Rahmen der Interviewbefra-

gung dazu:

„Würde das (Anmerkung: Debugging) durch XPairtise stabil unterstützt, wäre

das sicherlich eine hervorragende Sache, weil du dabei auf jeden Fall etwas

lernst und du auch merkst, wenn der andere mitliest, liest der Fehler mit, die

du einfach überliest, weil du was anderes liest, was da steht. Weil im Kopf da

hast du eine Vorstellung, das müsste da stehen, aber das steht da gar nicht.

Dem anderen, dem ist das klar, oh was schreibt der denn da für einen Mist hin,

also besonders bei solchen Sachen ist es sicherlich interessant und auch

sehr effektiver, dieses mit zwei Mann zu machen.“


Die zweite Gruppe hat XPairtise - und generell DPP - viel weniger benutzt. Der Großteil

der Programmierung wurde per SP vorgenommen, so dass XPairtise gerade auch ge-

gen Ende des Praktikums nur noch sporadisch zum Einsatz kam.

Generell bleibt noch ausdrücklich anzumerken, dass es auch teilweise technische

Probleme bei der aktiven Benutzung von XPairtise gegeben hat. So gaben gerade die

Studenten der ersten Gruppe z. B. am Rande der Interviews oder der Audiomitschnitte

explizit an, dass XPairtise bei der Ausführung größerer Programme oder beim Refacto-

ring Probleme bereitet und es auch zu Programmabstürzen aufgrund von Problemen

mit der Verbindung zum Server kam. Ohne diese Mängel und mit einer funktionieren-

den Debugging-Funktion wäre XPairtise wahrscheinlich häufiger bei den Gruppen zum

Einsatz gekommen. Diese Mängel waren auch ein Grund mit dafür, dass XPairtise ge-

gen Ende des Praktikums immer weniger benutzt wurde. Deswegen ist es wichtig, wie

schon erwähnt, bei einer möglichen Weiterentwicklung von XPairtise darauf zu achten,

dass diese Mängel behoben werden und auch eine Debugging-Funktion integriert wird.

Ein stabiles Programm zur Unterstützung von DPP ist auch dahingehend wichtig, dass

DPP effektiv angewendet werden kann, von den Nutzern gerne angenommen wird und

die Nutzer sich nicht um technische Randprobleme kümmern müssen, die mit dem

eigentlichen Prozess des DPP nicht in Verbindung stehen.

Es lässt sich bei der ersten Gruppe erkennen, dass XPairtise jeweils in den Tagen vor

den Meilensteinen deutlich häufiger benutzt wurde. Die erste Gruppe hatte in der 9.,

17. und 20. Woche ihre Meilensteine definiert. Gerade bei den ersten Meilensteinen

wurde XPairtise damit überproportional häufig benutzt, was zeigt, dass die Mitglieder

vor den Meilensteinen viel gemeinsam programmiert haben und sich daneben auch

viel ausgetauscht haben, um jeweils auf dem gleichen Kenntnisstand im Projektverlauf

zu sein und die Meilensteine erfolgreich einzuhalten. Da die zweite Gruppe XPairtise

nicht konsequent eingesetzt hat, lassen sich diesbezüglich keine generellen Ableitun-

gen bei dieser Gruppe vornehmen.

Neben einem festen Zeitplan mit klar definierten Aufgaben hatten die vereinbarten Mei-

lensteine überdies die Funktion, den Betreuern bei Erreichung eines Meilensteines ein

Zwischenfeedback zu liefern. Es war vorgesehen, dass nach Erreichung eines Meilen-

steines von beiden Gruppen telefonische Zwischengespräche mit dem jeweiligen Be-

treuer geführt werden sollten. Diese Zwischengespräche wurden bei der ersten Gruppe

auch geführt, während es bei der zweiten Gruppe die erwähnten Probleme gab.

Im Allgemeinen hat die zweite Gruppe laut einer expliziten Nachfrage seitens des Eva-

luators an den Gruppenleiter maximal in festen Zweierteams während des Fachprakti-


kums zusammengearbeitet, ohne dass es einen großen Austausch zwischen den

Teams oder gar Pair Rotationen gab. Ferner haben die Zweierteams, was die XPairti-

se-Nutzung bestätigt, kaum DPP-Sessions abgehalten, sondern es dominierte damit

generell in der Gruppe SP. Während bei der ersten Gruppe außer XPairtise und Skype

keine weiteren kollaborativen Tools eingesetzt wurden, hat die zweite Gruppe nach

eigenen Aussagen neben XPairtise und Skype ferner noch vereinzelt VNC oder das

Webkonferenzdienstprogramm Yugma19 genutzt. Yugma ermöglicht es, gemeinsam

mit mehreren Nutzern zu kommunizieren. In Yugma ist überdies eine Application Sha-

ring Funktion integriert, so dass sich der Bildschirm eines Nutzers an alle Konferenz-

teilnehmer duplizieren lässt. Bezogen auf die aufgestellten Hypothesen kann man an

dieser Stelle schon erkennen, dass man offensichtlich zwischen den beiden Gruppen

differenzieren muss, weil diese sich abweichend verhalten haben. Anhand der unter-

schiedlich intensiven Nutzung von XPairtise und des generell höheren Anteils am DPP

kann man durchaus feststellen, dass die neunte Hypothese bzgl. der Teamarbeit nur

von der ersten Gruppe erfüllt wird. Bei der zweiten Gruppe gab es schon Abneigungen

in Hinsicht auf eine disziplinierte Kommunikation und Teamarbeit, was daneben noch

an anderen Stellen dieser Arbeit deutlich wird. Damit zeigen die beiden Gruppen au-

ßerdem heterogene Ansätze bei der Nutzung von Unterstützungstools für die Teamar-

beit.

Die folgende Abbildung zeigt die Dauer aller im Praktikumsverlauf stattgefundenen

Sessions beider Gruppen in Minuten, wobei die Sessions der ersten Gruppe in den

roten Säulen und die Sessions der zweiten Gruppe in den blauen Säulen dargestellt

werden:

0

50

100

150

200

250

Nut

zung

in M

inut

en

Sessions -Gruppe 1- Sessions -Gruppe 2-

Abbildung 7: Minuten pro XPairtise-Session im Praktikumsverlauf

19 Yugma – siehe http://www.yugma.com/ (Stand 30.06.2008)

Stattgefundene Sessions


Wie man anhand der Abbildung erkennen kann, haben durchaus Sessions mit einer

Dauer von drei bis vier Stunden stattgefunden. Der Durchschnitt liegt bei ca. 93 Minu-

ten pro Session. Dabei gab es bei der durchschnittlichen Dauer einer Session nur klei-

nere Unterschiede bei beiden Gruppen (Gruppe 1: ca. 98 Minuten - Gruppe 2: ca. 73

Minuten). Aufgrund der Standardabweichung führen diese Durchschnittswerte aller-

dings zu keiner signifikanten Aussage. Natürlich kam es auch zu kleineren Pausen bei

der Nutzung von XPairtise während einer Session. Diese sind detailliert in Kapitel 5.2.4

dargestellt.

5.2.1 Nutzung der Features von XPairtise

Das folgende Diagramm zeigt die Anzahl der Sessions beider Gruppen, bei denen von

der Benutzung der einzelnen DPP-Funktionen, unabhängig von der Häufigkeit, in

XPairtise Gebrauch gemacht wurde (Grundlage waren 52 Sessions):

0

10

20

30

40

50

Session Chat Global Chat Rollen-wechsel

Whiteboard Text-eingaben

Markierungenvom

Navigator

Markierungenvom Driver

Anz

ahl B

enut

zung

in X

Ses

sion

s

Abbildung 8: Benutzung der Funktionen in XPairtise

Aus der Abbildung kann man direkt entnehmen, dass die vorhandenen Funktionen wie

die Textchats oder das Whiteboard in XPairtise aus diversen Gründen, die in den nun

folgenden Abschnitten ausgeführt werden, eher selten und nicht regelmäßig genutzt

wurden. Auf die genaue Verteilung der Features, die Anzahl und die durchschnittlichen

Nutzungen wird in den folgenden Detailbetrachtungen näher eingegangen. Eine detail-

lierte Übersicht über alle stattgefundenen Sessions und die Anzahl der Benutzungen

der verschiedenen Funktionen in XPairtise ist auch der dieser Diplomarbeit beiliegen-

den CD zu entnehmen. (Übersichten zur Logauswertung - siehe auch Anhang A 4).


5.2.1.1 Kommunikation in einer XPairtise-Session

Die Audiokommunikation der Gruppenmitglieder fand bei beiden Gruppen in Skype

statt. Skype wurde sowohl bei den Gruppenkonferenzen als auch als Hauptverständi-

gungsmittel der Paare bei der Arbeit mit XPairtise benutzt. Man kann sagen, dass DPP

ohne eine Audiokommunikation schwer vorzustellen ist und wahrscheinlich ohne eine

parallel stattfindende intensive Audioverständigung nicht genutzt werden würde. Das

ist offenbar auch der Grund, warum die beiden in XPairtise implementierten Textchats

in aktiven Sessions de facto keine Rollen spielten und zur Kommunikation untereinan-

der nicht verwendet wurden. Gerade mal in zehn Sessions kam mindestens einer der

beiden Chats zum Einsatz und dabei auch nur sporadisch. Die maximale Anzahl der

vorkommenden Textchateinträge waren bei einer Session sechs Einträge. Ansonsten

gab es, wenn der Textchat bei einer Session genutzt wurde, anzahlmäßig nie mehr als

ein bis zwei Textchateinträge. Durch die Audioverständigung über Skype, welches im-

mer parallel bei jeder Session lief, war eine Kommunikation über die Textchats damit in

den Hintergrund getreten. Weiterhin muss an dieser Stelle erwähnt werden, dass das

Programm Skype über Textchatfunktionen verfügt, infolgedessen darüber auch Texte

und Daten ausgetauscht werden können. Hiervon wurde auch von den Studenten ver-

einzelnd Gebrauch gemacht, was die Audioaufnahmen bestätigen, aber ansonsten

nicht weiter erhoben wurde.

5.2.1.2 Rollenwechsel

Die Auswertung der Logdaten hat ergeben, dass die Möglichkeit, die Rollen Driver und

Navigator zu tauschen, in 21 der 52 ausgewerteten Sessions Verwendung gefunden

hat. Da in 5 der 52 Sessions keine Editoreinträge vorgenommen wurden und somit

kein Quellcode weiterentwickelt wurde und in diesen Sessions ausschließlich die Mar-

kierungsfunktion oder das Whiteboard benutzt wurde (Detailergebnisse dazu werden

noch in den folgenden Kapiteln erörtert), wozu keine Rollenwechsel nötig waren, die-

nen damit 47 Sessions als Grundlage. In vier Sessions sind allerdings nach erfolgten

Rollenwechseln keinerlei Aktionen vom zweiten Partner vorgenommen worden. Es

handelte sich bei diesen Sessions folglich nur um Testwechsel o. ä., so dass de facto

in 47 Programmiersessions 17 Rollenwechsel (= 36,2 %) stattgefunden haben, bei de-

nen der zweite Partner selber auch aktiv in die Rolle des Drivers gewechselt ist und

gleichfalls aktiv programmiert hat. Bei 63,8 % aller Sessions hat damit überhaupt kein

Rollentausch stattgefunden. Insgesamt gab es 12 Sessions mit Rollenwechseln bei der

ersten Gruppe und 5 bei der zweiten Gruppe.


Die folgende Abbildung zeigt für beide Gruppen getrennt die stattgefundenen Sessions

mit Rollenwechseln. Neben der Anzahl der Rollenwechsel werden auch die Abstände

in Minuten zwischen den einzelnen Rollenwechseln während den jeweiligen Sessions

dargestellt:

0

50

100

150

200

250

1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5

Zei

t in

Min

uten

1. Programmierer in der Rolle als Driver 2. Programmierer in der Rolle als Driver

Abbildung 9: Rollenwechsel

Generell sind keine signifikanten Unterschiede zwischen den beiden Gruppen feststell-

bar, allerdings ist die Anzahl der Sessions mit Rollenwechseln auch sehr gering, so

dass sich daraus keine statistisch relevanten Schlüsse ziehen lassen. Aus der Abbil-

dung kann man ferner entnehmen, dass - beide Gruppen betrachtet - in sieben Fällen

nur einmal zwischen dem Driver und dem Navigator gewechselt wurde. In den anderen

zehn Fällen (= 58,8 %) gab es mindestens zwei Wechsel mit mehreren Interaktionen

untereinander. Rollenwechsel kamen nicht ausschließlich durch die Rollenwechsel-

funktion in XPairtise zustande, sondern darüber hinaus auch dadurch, dass eine Ses-

sion vorübergehend beendet wurde, um z. B. programmierten Code ohne Einsatz von

XPairtise zu testen. Wenn dann nach den Tests die Sessions wieder in XPairtise fort-

gesetzt wurden, sind die Programmierer in einigen Fällen mit absichtlich vertauschten

Rollen wieder zu XPairtise zurückgewechselt. So kam es auch durch diese Vorgänge

zu abgesprochenen Rollenwechseln.

Die relativ geringe Anzahl der Rollenwechsel bei allen Sessions weist darauf hin, dass

es in den Sessions bei dieser Evaluation generell immer einen Hauptprogrammierer

gab, was ebenso die Auswertung der vorgenommenen Editoreinträge (siehe Verhältnis

Driver - Navigator, Kapitel 5.2.2) bestätigt. Ferner zeigt es, dass mehrere regelmäßige

Wechsel innerhalb einer Session eher selten vorkamen.

- Sessions Gruppe 1 - - Sessions Gruppe 2 -


Diese Evaluation gibt somit Rückschluss darauf, dass der Navigator mehr als Beob-

achter fungiert hat. Allerdings ist das auch ganz deutlich vom Kenntnisstand her ab-

hängig gewesen. Waren der Driver und der Navigator programmiertechnisch auf glei-

cher Augenhöhe wie z. B. in der obigen Abbildung bei Session Nr. 2 der ersten Grup-

pe, dann gab es mehr Rollenwechsel und qualifiziertere Aktivitäten seitens des Naviga-

tors. Bei den hier vorliegenden Sessions mit mehreren Rollenwechseln (z. B. Session

Nr. 2 -Gruppe 1-) handelt es sich um zwei Programmierer mit schon mehrjähriger Pro-

grammiererfahrung, was damit die erste Hypothese dieser Diplomarbeit erhärtet, dass

Nutzer mit gleichen Kenntnisständen ausgewogenes DPP absolvieren und Rollen-

wechseln gegenüber nicht abgeneigt sind. Die Paarung der ersten Gruppe der 2. Ses-

sion hat auch in der 10. Session zusammengearbeitet. Dabei kam es aber im Gegen-

satz zur 2. Session lediglich zu zwei Rollenwechseln. Die geringe Anzahl generell und

die weitere Auswertung der Rollenwechsel zeigt ferner, dass Anfänger dagegen selte-

ner bis gar nicht in die Rolle des Drivers wechseln, wodurch wiederum die zweite

Hypothese erhärtet wird.

Neben der Anzahl der Rollenwechsel ist die Frage nach den zeitlichen Abständen zwi-

schen den Rollenwechseln ein spannendes Thema. So schreibt Brian Hanks bei-

spielsweise, dass ein typisches Intervall für Rollenwechsel 20 Minuten beträgt [Han04].

Die Detailuntersuchung der Daten dieser Evaluation zeigt, dass zwar bei den Sessions

mit Rollenwechseln durchschnittlich die Rollen nach ca. 26 Minuten während einer

Session getauscht wurden, berücksichtigt man allerdings, dass es in vielen Sessions

überhaupt keinen Rollenwechsel gegeben hat und es bei den Sessions mit Rollen-

wechseln in 41,2 % der Fälle nur maximal einen Rollenwechsel innerhalb einer Sessi-

on gegeben hat, dann sind damit generell keine Rollenwechselaktivitäten mit festen

Intervallen feststellbar.

In 62,8 % aller Fälle ging die Rollenwechselanfrage vom Driver aus, in 37,2 % folglich

vom Navigator. Das Ergebnis korreliert mit der sechsten Hypothese, bei der die Vermu-

tung aufgestellt wurde, dass der Wunsch nach einem Rollenwechsel überwiegend vom

Driver ausgeht. Während einer Programmiersession hat ein Driver häufiger das Be-

dürfnis, einen Navigator aktiv zu Rate zu ziehen oder sich evtl. eine kleine Auszeit zu

nehmen, wodurch in diesen Fällen die Aufforderung zu einem Rollenwechsel vom

Driver ausgeht. Ein Rollenwechsel ausgehend vom Navigator könnte aber evtl. auch

vom Driver dahingehend interpretiert werden, dass Ersterer dem Driver seine Schreib-

rechte entziehen möchte. Da jedoch vor einem Rollenwechsel i. d. R. Audiokommuni-

kation untereinander stattfindet, sprechen sich Driver und Navigator ab und es werden

nicht einfach Rollen „zwangsweise“ angefordert. Dieses wird durch die Auswertung der

Audioaufnahmen bestätigt. Ein Beispieldialog, der während einer aufgezeichneten

Session zwischen zwei eher erfahreneren Programmierern erfolgte, ist der Folgende,


bei dem, nachdem eine größere Thematik während einer Session bearbeitet und erle-

digt wurde, nun mit einer neuen Thematik begonnen werden sollte: Der Driver erläutert

die Problematik und stellt im Anschluss die direkte Frage an den Navigator: „Willst

du?“ – Antwort Navigator: „Von mir aus“. Danach wurden die Rollen getauscht und

der Navigator wechselte damit in die Rolle des Drivers und begann mit der Program-

mierung, während der vorherige Driver in die Rolle des Navigators wechselte. In der

Literatur gibt es einige Studien (z. B. [WYW+02] oder [FWW02]), die das Verhalten des

Drivers und des Navigators und daneben ebenso die Rollenwechsel untersuchen. Da-

bei kommen diese Studien auch teilweise zu dem Ergebnis, dass regelmäßige Rollen-

wechsel nicht immer konsequent in der Praxis erfolgen. Ein Vergleich dieser Evaluati-

onsergebnisse mit diesen Studien wird in Kapitel 6.1.4 vorgenommen.

5.2.1.3 Benutzung des Whiteboards

Das Feature Whiteboard in XPairtise ist lediglich in vier der 52 untersuchten Sessions

benutzt worden. Alle vier Sessions wurden von der ersten Gruppe absolviert, damit hat

folglich die zweite Gruppe das Whiteboard nicht ein einziges Mal bei einer Session

eingesetzt. Weiterhin ist zu konstatieren, dass unter den vier Sessions nur eine einzige

war, bei der auch Quellcode programmiert oder Markierungen vorgenommen wurden.

Bei dieser anscheinend sehr abwechslungsreichen Session erfolgte auch ein Rollen-

wechsel (siehe Abb. Nr. 9 Rollenwechsel: -Gruppe 1- Session Nr. 12). Die restlichen

drei Sessions waren XPairtise-Sessions, die ausschließlich dazu dienten, per White-

board als eine Art „Unterstützungsmedium“ Zeichnungen vorzunehmen, um dem Part-

ner etwas zu zeigen bzw. zu verdeutlichen. Das ist ein bemerkenswertes und nicht

erwartetes Ergebnis, welches damit der fünften aufgestellten Hypothese widerspricht.

Das Whiteboard wurde folglich lediglich in einer einzigen Programmiersession genutzt,

um dem Partner etwas visuell zu verdeutlichen. Es wurde davon ausgegangen, dass

das Whiteboard durchaus häufiger und spontaner in Sessions eingesetzt wird, um kur-

ze skizzenhafte Erläuterungen vorzunehmen.

5.2.1.4 Texteingaben

In insgesamt 47 der 52 ausgewerteten Sessions kam es zu Editoreinträgen und somit

zur (Weiter-)Entwicklung von Programmcode. Lediglich in fünf Sessions erfolgten keine

Texteinträge. Drei dieser fünf Sessions wurden von den Nutzern nur dazu benutzt, mit

dem Whiteboard zu Diskussionszwecken von Problematiken und zur Veranschauli-

chung für weitere Teammitglieder Zeichnungen anzufertigen. In zwei Sessions ohne

jegliche Texteingaben kam es nur zu Erläuterungen des Quellcodes (teilweise per

Markierungsfunktionen), ohne dass dabei das Programm weiterentwickelt wurde.


5.2.2 Verhältnis Driver - Navigator

Direkt aus den Resultaten der stattgefundenen Rollenwechsel lässt sich weiterhin das

Verhältnis zwischen Driver und Navigator ableiten. Die Rollenwechselauswertung zeig-

te schon, dass die Möglichkeit, Rollenwechsel durchzuführen, eher seltener zur An-

wendung kam. Das spiegelt sich überdies in dem Verhältnis zwischen Driver und Navi-

gator wider. Die Logauswertungen haben ergeben, dass in insgesamt 63,8 % aller

XPairtise-Sessions mit Quellcodeweiterentwicklung kein Rollenwechsel stattgefunden

hat. Damit hat der Driver zu 100 % den Code während der Session alleine geschrie-

ben, während der Navigator bei der Entwicklung ggf. lediglich mündlich etwas beige-

tragen hat.

Die folgende Abbildung bildet das Verhältnis der einzelnen Sessions beider Gruppen

zwischen zwei Teilnehmern in den Rollen als Driver und Navigator ab. Es zeigt, wie

sich das prozentuale Verhältnis anhand der vorgenommenen und protokollierten Edi-

toreinträgen zwischen den beiden Partnern in den XPairtise-Sessions verhält. Bei den

fünf in Kapitel 5.2.1.4 erwähnten Sessions, bei denen keine Editoreingaben erfolgten,

wurden ersatzweise die Anzahl der Aktionen dieser Funktionen (White-

board/Markierungsfunktion) jeweils im Verhältnis Driver/Navigator gesetzt:

0

10

20

30

40

50

60

70

80

90

100

0 5 10 15 20 25 30 35 40 45 50


Ver

hältn

is in

%

1. Teilnehmer 2. Teilnehmer

Abbildung 10: Verhältnis Driver/Navigator

Die Abbildung zeigt, dass in 32 von 52 Fällen ein Programmierer während einer ge-

meinsamen Session mit einem Partner alleine Code programmiert bzw. alleine aktiv

die Funktionen benutzt hat. Eine Erklärung für dieses Verhalten ist, dass in vielen der

Sessions eher unerfahrenere Programmierer mit erfahreneren zusammengearbeitet

haben und die Navigatoren in den Sessions eher in der Rolle eines Spectators agier-

ten, obwohl diese als Navigatoren in XPairtise angemeldet waren. Vielfach haben sich


die Navigatoren damit bei dieser Evaluation sehr passiv verhalten. Eine Detailauswer-

tung der Sessions, in denen ein ausgewogeneres Verhältnis zwischen Driver und Na-

vigator besteht, ergibt deutlich, dass es sich dabei um Studenten handelt, die einen

ungefähr gleichen Kenntnisstand bzgl. der Programmiererfahrungen besitzen.

Daneben bestätigen auch die Auswertungen der vorgenommenen Editormarkierungen

vom Navigator dieses Bild. Die folgende Abbildung zeigt die Benutzung der Editormar-

kierungen ausgehend vom Navigator in einer XPairtise-Session, auch im Verhältnis zur

zeitlichen Dauer der Sessions. Ausgewertet wurden alle vorgenommenen Editormar-

kierungen. Dabei wurden jeweils übersichtshalber alle Editormarkierungen, die inner-

halb von zehn Sekunden vorgenommen wurden, als ein Eintrag gezählt. Dargestellt

werden alle Editormarkierungen vom Navigator während der einzelnen Sessions (ins-

gesamt 49 Sessions). Ausgenommen sind die drei Session, in denen ausschließlich

(sowohl vom Driver als auch vom Navigator) das Whiteboard zum Einsatz kam:

0

50

100

150

200

250


Dau

er in

Min

uten

/Anz

ahl M

arki

erun

gen

Dauer in Minuten Anzahl Markierungen vom Navigator

Abbildung 11: Editormarkierungen vom Navigator

Editormarkierungen vom Navigator können dazu dienen, dem Driver Hinweise im

Quellcode zu geben oder auch dem Driver bei Fragen bestimmte Stellen im Code zu

zeigen. Diese Auswertung bestätigt, dass sich die Navigatoren bzgl. der Editormarkie-

rungen in neun Sessions (= 18,4 %) völlig passiv verhalten haben und noch nicht ein-

mal eine einzige Markierung im Editor vorgenommen haben. Leider existieren von die-

sen neun Sessions keine Audioaufnahmen, die weitere Rückschlüsse auf das genaue

Verhalten der Navigatoren liefern könnten. Allerdings hat eine Detailanalyse dieser

Sessions ergeben, dass in vier dieser neun Sessions ein absoluter Anfänger (immer

der gleiche Student) mit einem Experten zusammengearbeitet hat. So bleibt zu vermu-

ten, dass dieser Anfänger dem Experten „nur über die Schulter“ geschaut hat, was

auch die Audiomitschnitte anderer Sessions mit diesem Studenten gezeigt haben, der

sich darin bzgl. der aktiven (Mit-)Programmierung ebenfalls sehr passiv verhalten hat.


Diese Ergebnisse widersprechen im Allgemeinen, ähnlich wie schon die Ergebnisse

der Whiteboardauswertung, der fünften Hypothese. Die zweite Hypothese stellt zwar in

diesem Zusammenhang die Behauptung auf, dass sich Programmieranfänger anfangs

eher passiv verhalten werden, allerdings haben sich generell die Navigatoren - unab-

hängig vom Kenntnisstand - deutlich passiver verhalten als es im Vorfeld erwartet wur-

de.

Die folgende Abbildung zeigt das prozentuale Verhältnis der Editormarkierungen zwi-

schen Driver und Navigator (ausgenommen sind wieder die drei Whiteboardsessions -

Grundlage sind damit 49 Sessions):

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%


Ver

hältn

is in

%

Driver Navigator

Abbildung 12: Verhältnis Editormarkierungen Driver/Navigator

Es muss ergänzend darauf hingewiesen werden, dass der Driver auch Markierungen

beispielsweise für Kopiervorgänge getätigt haben kann. Die Logdaten und deren auto-

matische Auswertung lassen leider hierauf keine Rückschlüsse zu. Bei einer zukünfti-

gen Analyse von Logdaten wäre es interessant, noch weitere Unterscheidungen vor-

nehmen zu können. Die Grafik zeigt, dass der prozentuale Anteil der vorgenommenen

Markierungen während einer Session immer, und allgemein mit weit über 50 %, beim

Driver liegt. Durchschnittlich beträgt das Verhältnis der Markierungen 91,8 % zu 8,2 %.

Die Driver waren wesentlich aktiver als die Navigatoren. Das deutet darauf hin, dass

die Driver, abgesehen von Kopiervorgängen, vielfach den Navigatoren per Markierun-

gen Stellen im Quellcode gezeigt haben und weniger die Navigatoren den Drivern.

Vielfach wurden gerade auf diese Weise den eher unroutinierteren Navigatoren Stellen

im Quellcode gezeigt und zudem erklärt, was ferner auch die Audioaufnahmen bestä-

tigt haben. Eine Detailbetrachtung der insgesamt fünf stattgefundenen Sessions mit

einem Markieranteil über 30 % seitens des Navigators hat ergeben, dass in drei dieser

fünf Sessions auch Rollenwechsel stattgefunden haben, was verdeutlicht, dass es sich

bei diesen Teilnehmern um erfahrenere Studenten handelte. Generell kann man aber


konstatieren, dass von der Funktion, Markierungen im Quellcode vorzunehmen und

damit dem Partner Stellen im Quellcode zu zeigen, durchaus Gebrauch gemacht wur-

de. In dieser Hinsicht wird die fünfte Hypothese zur Nutzung der Features in XPairtise

bestätigt, da durch die räumliche Trennung der Programmierer beim DPP keine Stellen

beispielsweise direkt auf einem Monitor gezeigt werden können.

5.2.3 Anzahl der Gäste

In 32,7 % aller Sessions (insgesamt 17 Sessions) waren, zumindest zeitweise, Gäste

in der Rolle eines Spectators anwesend. In 12 Fällen handelte es sich dabei nur um

einen einzelnen Gast. Es gab aber Gruppensitzungen, bei denen alle Studenten der

Gruppe teilnahmen. Dabei waren zwei Studenten jeweils in der Rolle des Drivers bzw.

Navigators und die restlichen Gruppenmitglieder als Spectators in XPairtise angemel-

det. Die Evaluation zeigt, dass damit relativ häufig ein weiterer Gast bei den gemein-

samen Sessions anwesend war. Das deutet darauf hin, dass XPairtise vielfach gut

genutzt werden konnte, um weitere Gruppenmitglieder über Quellcodeänderungen zu

informieren und diese außerdem allen zu zeigen und zu erklären. Eine Detailbetrach-

tung der vorgenommenen Markierungen seitens der Gäste in den Logdaten hat erge-

ben, dass sich diese bzgl. getätigter Markierungen und sonstiger aktiver Benutzung

von Funktionen in einer Session auch sehr zurückhielten. Damit unterscheidet sich ihr

Verhalten auch nicht von dem der Navigatoren in den gemeinsamen Sessions, in de-

nen sich auch die Navigatoren eher passiv verhielten.

5.2.4 Pausen während XPairtise-Sessions

Die Anzahl der Pausen, bei denen keine Aktionen in XPairtise stattgefunden haben, ist

(erwartungsgemäß) gering ausgefallen. Dieses Resultat erhärtet die siebte und achte

Hypothese. Wenn man gemeinsam als Paar z. B. mit XPairtise arbeitet, wird i. d. R.

sehr konzentriert und ergebnisorientiert programmiert. Das haben zudem die Grup-

penmitglieder der ersten Gruppe in der Interviewbefragung bestätigt.

Bei den vorliegenden 52 Sessions waren zwar in 30 Fällen (= 57,7 %) eine oder meh-

rere Pausen mit einer Länge von mehr als fünf Minuten festzustellen, Pausen mit einer

Länge von mehr als 15 Minuten haben aber dagegen nur in fünf Fällen (= 9,6 %) aller

Sessions stattgefunden. Die Audiomitschnitte dazu haben ergeben, dass auch in den

XPairtise-Pausen weitergearbeitet wurde. Das bestätigten auch die Studenten der ers-

ten Gruppe in der Interviewbefragung bei einer gezielt gestellten Frage zu Anzahl und

Gründen von Pausen. Sie gaben dabei an, dass sie in den Pausen im Internet oder in

der Fachliteratur nach Lösungen zu akuten Problemen gesucht oder Fehlermeldungen

nachgeschlagen haben. Generell waren die Sessions aber lt. Aussage der Studenten

größtenteils abgesprochen, geplant und wurden konzentriert durchgeführt. Probleme


oder auch andere Aspekte kamen ansonsten in den Gruppenbesprechungen zur Spra-

che. Das erhärtet wiederum die siebte Hypothese. Darüber hinaus stellte sich in den

Interviewbefragungen auch heraus, dass Situationen zustande kamen, in denen man

auf Probleme gestoßen ist und in denen der Navigator nach Lösungen suchte, wäh-

rend der Driver parallel weiter programmierte. Eine Aussage aus dem Interview von

einem Studenten lautete beispielsweise dazu:

„…das waren dann Pausen in dem Sinne, dass der Driver was gemacht hat

und dem Navigator gesagt hat, guck doch gerade mal wie ich das aufrufen

kann, guck mal gerade bei Google, ruf mal gerade die Seite auf, also es lief

eher parallel, es war keine richtige Pause.“

In den vorhandenen Pausen der bis zu vierstündigen Sessions, in denen XPairtise

nicht zum Einsatz kam, wurde darüber hinaus der programmierte Code ausprobiert und

ausgiebig getestet. Letzteres erfolgte aufgrund einer festgestellten Instabilität von

XPairtise bei der Ausführung komplexer Anwendungen und Tests in den Gruppen ohne

den Einsatz von XPairtise. Nach den vorgenommenen Tests vollzog sich dann aber

zwecks Fehlerbehebung bzw. Fortführung der Programmierung häufig wieder ein

Wechsel zu XPairtise. Da DPP durchaus Anstrengung sowie eine konstante hohe Kon-

zentration der Programmierer erfordert, ist es wichtig, ab und an gezielt kleinere Erho-

lungspausen zur Vermeidung von Stress und Unkonzentriertheit einzulegen. In wie

vielen Fällen derartige Pausen erfolgten, lässt sich durch die gesammelten Daten nicht

belegen. Allerdings war das Bewusstsein für Erholungspausen oder ein sinnvolles En-

de einer Session bei den Studenten vorhanden und wurde auch unter den Studenten

diskutiert, wie das folgende Zitat aus einem Audiomitschnitt einer XPairtise-Session

belegt:

„…wir sollten eine kreative Pause machen…(…)…wir gucken, ob wir das jetzt

hinkriegen und danach hören wir dann auf, dann können wir uns das Ganze

durch den Kopf gehen lassen…“.

5.2.5 Pair Rotationen

Im Rahmen des Praktikums war es den Mitgliedern frei gestellt, ob und mit wem sie

zusammenarbeiten. Feste Regeln oder festgelegte Zwangsrotationen zwischen den

Mitgliedern waren nicht vorgeschrieben. Diesbezüglich wurde in der vierten Hypothese

behauptet, dass einmal gefundene und funktionierende Paarungen beibehalten wer-

den. Die Ergebnisse der Untersuchung, ob und wie viele Pair Rotationen bei den

Gruppen stattgefunden haben, werden im Folgenden erläutert.


5.2.5.1 Untersuchung Pair Rotationen -Gruppe 1-

Die Auswertung der Logdaten hat, inklusiv der stattgefundenen Gruppensessions, bei

der ersten Gruppe die folgende Verteilung der gemeinsamen Sessions ergeben, die

mittels eines Soziogrammes dargestellt wird:

Abbildung 13: Soziogramm der Paarzusammensetzungsvariationen -Gruppe 1-

Das Soziogramm ist folgendermaßen zu erläutern: Die Kreise symbolisieren die fünf

Studenten der ersten Gruppe. Die unterschiedliche rötliche Färbung verdeutlicht den

Expertenstatus der Studenten, der aus den Selbst- und Fremdeinschätzungsbefragun-

gen erlangt wurde. Dabei bedeutet ein kräftigeres Rot gute Programmierkenntnisse,

während ein schwächeres Rot bzw. ein Gelb geringere Programmierkenntnisse ver-

deutlicht (also die Studenten mit den Nummern eins und zwei gelten als erfahrene

Programmierer, während der Student mit der Nummer drei ein Anfänger ist). Die

Strichstärke der Verbindungslinien verdeutlicht die Anzahl der gemeinsamen Sessions

untereinander. D. h. je dicker die Linie ist, desto mehr Sessions wurden gemeinsam

absolviert. Dabei wurden auch zwei Gruppensessions in XPairtise eingerechnet, bei

denen alle Studenten anwesend waren.

Insgesamt hat diese Gruppe 41 Sessions in XPairtise absolviert. Dabei hat jeder Grup-

penteilnehmer, unabhängig von den beiden Gruppensessions, zumindest einmal mit

jedem anderen im Verlauf des Praktikums zusammen eine Session in XPairtise vorge-

nommen. Das Resultat unterstreicht zum einen das gute Verständnis in der Gruppe

und zum anderen die Tatsache, dass die Gruppenmitglieder versucht haben, mit jedem

anderen Teilnehmer zusammenzuarbeiten, auch um festzustellen, ob und wie gut man

mit dem anderen Partner auskommt und programmieren kann. Die Ergebnisse zeigen

ferner, dass sich durchaus gut funktionierende Paarungen gebildet haben, die häu-

fig(er) zusammen in XPairtise gearbeitet haben (z. B. Paarungen 3 und 4 oder auch 1

und 3), was damit die vierte Hypothese stützt. Dabei ist dem Soziogramm zu entneh-

2

4

1

5

3


men, dass es sich bei diesen Paarungen jeweils um einen qualifizierten Studenten mit

einem eher ungeübteren Studenten handelt. Der dritte Student hatte von allen Studen-

ten die häufigsten XPairtise-Sessions und war von den 41 Sessions in insgesamt 27

Sessions vertreten. Das ist wiederum ein Indiz für die vierte Hypothese, dass gerade

Anfänger sehr gerne und häufig XPairtise mit anderen schon erfahreneren Program-

mierern nutzten. Es zeigt aber auch, dass sich der erste und vierte Student Zeit nah-

men, dem unerfahreneren dritten Studenten einiges zu zeigen und zu erklären.

Auch ist es bei den Paarungen, abgesehen von den beiden Gruppensessions, nur zu

einer Paarung gekommen, die lediglich ein einziges Mal zusammengearbeitet hat. An-

sonsten hat jede Paarkombination mindestens zwei gemeinsame Sessions im Prakti-

kumsverlauf abgehalten. Diese Tatsache zeigt, dass die Studenten dieser Gruppe

durchaus Pair Rotationen durchgeführt und verschiedene Paarungen ausprobiert ha-

ben.

Die folgende Grafik veranschaulicht in einer Zeitleiste die Paarungen der 41 Sessions

im Zeitverlauf (in der konkreten Reihenfolge der stattgefundenen Sessions). Auf diese

Weise wird aufgezeigt, in welchen Intervallen die Paarungen die Sessions absolviert

haben. Beim Betrachten können auch mögliche Rückschlüsse auf einen möglichen

Wissenstransfer gezogen werden. Da die erste Gruppe aus insgesamt fünf Teilneh-

mern besteht, gab es damit insgesamt zehn Variationen von Paarzusammensetzun-

gen, wenn man die meist passiven Gäste unbeachtet lässt. Diese zehn Paarungskom-

binationsmöglichkeiten mit den Studentenbezeichnungen (Nummern) aus dem Sozio-

gramm und den Gruppensessions sind in der folgenden Abbildung dargestellt:

Nr. 1 und Nr. 3 Nr. 1 und Nr. 5 Nr. 3 und Nr. 4 Nr. 4 und Nr. 5 Nr. 1 und Nr. 2 Gruppensession

Nr. 1 und Nr. 4 Nr. 2 und Nr. 3 Nr. 3 und Nr. 5 Nr. 2 und Nr. 4 Nr. 2 und Nr. 5

Abbildung 14: Zeitleiste Paarzusammensetzungen der Sessions -Gruppe 1-

Die bunte Verteilung in der Zeitleiste zeigt, dass nicht immer nur die gleichen Paarun-

gen in direkt aufeinander folgenden Sessions zusammengearbeitet haben. Durch diese

Verteilung kann es zu einem Wissensaustausch untereinander gekommen sein und es

kann auch zu einem Wissenstransfer an Dritte geführt haben. Leider lassen sich diese

Optionen anhand harter Fakten nicht belegen. Diese Thematik wurde aber auch in den

Interviewbefragungen angesprochen (siehe Kapitel 5.6), wobei die Studenten bestäti-

gen, dass sie viel gelernt haben und es durchaus zu einem Wissenstransfer gekom-

men ist.

Session Nr. 10 Session Nr. 20 Session Nr. 30 Session Nr. 40


Die Ergebnisse aus den Selbst- und Fremdeinschätzungen entsprechen ebenfalls er-

wartungsgemäß der vierten Hypothese, da es zu Pair Rotationen innerhalb der ersten

Gruppe gekommen ist. Im Folgenden wird die Auswertung der Mitgliederangaben aus

der ersten Gruppe zur Frage „Mit wem hast du zusammengearbeitet? - unabhängig der

XPairtise - Nutzung“ aus den Selbst- und Fremdeinschätzungsbefragungen angege-

ben. Letztere werden im nächsten Kapitel noch näher vorgestellt, liefern aber thema-

tisch schon hier zur Pair Rotation Aufschlüsse:

Student 1: Student 2:

0% 20% 40% 60% 80% 100%

1. Monat

2. Monat

3. Monat

4. Monat

5. Monat

2. Student 3. Student 4. Student 5. Student

0% 20% 40% 60% 80% 100%

1. Monat

2. Monat

3. Monat

4. Monat

5. Monat


Student 3: Student 4:

0% 20% 40% 60% 80% 100%

1. Monat

2. Monat

3. Monat

4. Monat

5. Monat

1. Student 2. Student

4. Student 5. Student

0% 20% 40% 60% 80% 100%

1. Monat

2. Monat

3. Monat

4. Monat

5. Monat


Student 5:

0% 20% 40% 60% 80% 100%

1. Monat

2. Monat

3. Monat

4. Monat

5. Monat


Abbildung 15: Zusammenarbeit der Studenten untereinander


Die Grafiken zeigen, dass es sehr wohl Unterschiede bei den einzelnen Studenten

gab. Bei der Betrachtung des ersten Studenten fällt dessen Angabe, im ersten Monat

nur alleine gearbeitet zu haben, direkt ins Auge. Ferner erkennt man, dass dieser Stu-

dent scheinbar Präferenzen zu bestimmten Gruppenmitgliedern hatte. Laut vorliegen-

der Einschätzung hat er z. B. ausschließlich im zweiten Monat mit dem dritten Studen-

ten zusammengearbeitet. Darüber hinaus fanden gemeinschaftliche Sitzungen mit dem

vierten Studenten überaus häufig vor allem im zweitletzten und komplett im letzten

Monat statt. Bei der Grafik des vierten Studenten kann man dagegen erkennen, dass

dieser durchaus regelmäßig über das gesamte Fachpraktikum hinweg mit allen Stu-

denten der Gruppe zusammengearbeitet hat.

Da es ferner Sessions mit drei oder auch mehreren Mitgliedern gab, existierte in der

ersten Gruppe nach dieser Selbsteinschätzungsbefragung bei Betrachtung des gesam-

ten Zeitraumes keine nicht vorgekommene Paarung. Dieses wird auch durch die Log-

datenanalyse von XPairtise unterstrichen. Allerdings lassen sich durchaus Schwer-

punkte in Form von häufiger vorkommenden Paarungen feststellen.

Eine Interviewfrage zu dieser Thematik „Hattest du bei dem bisherigen Verlauf bei den

gemeinsamen Sessions überwiegend mit bestimmten und immer denselben Gruppen-

mitgliedern zusammengearbeitet oder war es mit allen mehr oder weniger gleichmäßig

verteilt?“ wurde von allen fünf Mitgliedern der ersten Gruppe überwiegend mit „gleich-

mäßig“ beantwortet. Das liegt daran, dass auch Gruppensitzungen oder Sessions mit

mehr als zwei Programmierern stattfanden. Allerdings gaben die Studenten daneben

auch an, dass sich im Laufe der Zeit bevorzugte Paarungen herauskristallisiert haben.

Ein Zitat bei dieser Frage von einem Studenten lautete:

„Also am Anfang war es sehr gemischt, da würde ich sagen war es recht

gleich verteilt so die ersten zwei Monate. Und jetzt, gebe ich zu, habe ich

schon so meine Lieblinge, also jetzt ist es eher so bei drei Leuten, mit denen

ich noch zusammenarbeite.“

Neben dem Aspekt des sozialen Verständnisses füreinander, wodurch es auch zu be-

gründen ist, warum es zu bevorzugten Paarungen innerhalb eines Teams kommen

kann, lag es aber zudem an dem Zeitfaktor. Da ein Gruppenmitglied der Gruppe in

China lebt, war es teilweise für die Studenten schwierig, gemeinsame Termine zwecks

gemeinsamer Programmierungen abzustimmen, da ein Zeitzonenunterschied von

mehreren Stunden bestand. Da es sich ferner um Fernstudenten handelte, die teilwei-

se oder auch voll berufstätig waren, gab es auch hier Probleme mit zeitlichen Abstim-

mungen, so dass sich Paarungen herausbildeten, die entweder tagsüber zusammen-

arbeiten konnten oder eben nur abends bzw. am Wochenende.


5.2.5.2 Untersuchung Pair Rotationen -Gruppe 2-

Leider gab es bei der zweiten Gruppe, die aus sechs Mitgliedern bestand, nicht sehr

viele XPairtise-Sessions (insgesamt elf) und damit sind die Aussagen bei dieser unter-

suchten Gruppe eher eingeschränkter zu sehen. Die Auswertung der Logdaten hat,

inklusiv einer stattgefundenen Gruppensession, bei der zweiten Gruppe die folgende

Verteilung von gemeinsamen Sessions ergeben:

Abbildung 16: Soziogramm der Paarzusammensetzungsvariationen -Gruppe 2-

Das Soziogramm ist wie bei der ersten Gruppe aufgebaut. Allerdings fehlen die Fär-

bungen für die Programmierkenntnisse, weil die Mitglieder der zweiten Gruppe nicht

konsequent die Selbst- und Fremdeinschätzungsbefragungen durchgeführt haben und

damit keine eindeutigen Einschätzungen der Mitglieder zur Expertise möglich sind. In

dem Soziogramm besteht jeweils mindestens eine Verbindung untereinander, weil es

eine Gruppensession gab, in der alle Studenten der Gruppe anwesend waren. Ferner

kann man dem Soziogramm entnehmen, dass es eigentlich nur bei den Paarungen Nr.

3/Nr. 6 und Nr. 2/Nr. 4 zu mindestens zwei gemeinsamen Sessions gekommen ist. In

der Gruppe gab es durch die sechs Teilnehmer insgesamt 15 Variationen von Paarzu-

sammensetzungen. Leider hat es aber nur sieben Paarungen, unberücksichtigt der

Gruppensitzung, bei dieser Gruppe gegeben, die eine gemeinsame Session in XPairti-

se praktiziert haben. Das zeigt die vorgenommene getrennte Arbeitsaufteilung inner-

halb der Gruppe, weil generell nur in festen Zweierteams gearbeitet wurde und dabei

XPairtise kaum zum Einsatz kam.

Pair Rotationen sind gerade auch bezüglich eines Wissenstransfers, gemäß der dritten

und vierten Hypothese, innerhalb des Gesamtprojektes wichtig. Paarprogrammierer

und Gruppenmitglieder, die sich häufig untereinander austauschen und auch die Paa-

rungen wechseln, lernen sehr viel über das Gesamtprojekt kennen. Als Fazit bleibt

festzuhalten, dass bei der ersten Gruppe, auch aufgrund der höheren Anzahl von ge-

meinsamen XPairtise-Sessions, deutlich mehr Pair Rotationen stattgefunden haben als

1

4

2

6

5

3


bei der zweiten Gruppe. Generell bestätigt die erste Gruppe damit die vierte Hypothe-

se. Die Erkenntnisse aus dem Verhalten der zweiten Gruppe stehen im Gegensatz zu

denen der ersten Gruppe. Da mangels Beteiligung bei der zweiten Gruppe keine quali-

fizierten Ergebnisse aus den Selbst- und Fremdeinschätzungen vorliegen und es nur

eine geringe Anzahl von XPairtise-Sessions gab, können zu dieser Gruppe keine wei-

teren Aussagen bzgl. Pair Rotationen gezogen werden. Da allerdings in der zweiten

Gruppe die Studenten nach eigenen Aussagen - unabhängig von der Nutzung von

XPairtise - in festen Zweierteams zusammengearbeitet haben, bestätigt dieses Verhal-

ten zusammen mit den Ergebnissen der ersten Gruppe und den Interviewbefragungen

sowie den Selbst- und Fremdeinschätzungsbefragungen, dass einmal gebildete Paa-

rungen, welche erste Aufgaben gut und effizient bewältigt haben und sich auch an-

sonsten aus sozialen Gesichtspunkten gut verstehen, durchaus während des Prakti-

kums (überwiegend) Bestand hatten.

5.3 Audioaufnahmen

Für die Evaluation wurde bei insgesamt neun Besprechungen der ersten Gruppe die

Audiokommunikation vom Evaluator, der bei diesen Sessions anwesend war, mitge-

schnitten, um möglichst einen umfangreichen Eindruck und Überblick bei der prakti-

schen Anwendung von DPP zu gewinnen. Leider beschränken sich diese nur auf die

erste Gruppe, weil bei der zweiten Gruppe keine Bereitschaft dazu bestand, Audioauf-

nahmen durchführen zu können. Nicht in allen aufgenommenen Sessions kam das

Plugin XPairtise zum Einsatz.

Es wurde während der Evaluation festgestellt, dass die Studenten aufgrund der er-

wähnten teilweise aufgetretenen technischen Probleme mit XPairtise auch eine Art von

DPP-Sessions absolvierten, bei denen weder XPairtise noch andere Unterstützungs-

tools zum DPP zum Einsatz kamen. Insgesamt liefen zwei der neun aufgenommenen

Audiosessions auf diese Art und Weise ab. Es wurde dabei per Skype kommuniziert.

Die Studenten betrachteten Programmiercode teilweise parallel auf den jeweiligen Mo-

nitoren und diskutierten Probleme bzw. Anmerkungen. Dabei wurde immer wieder zwi-

schendurch, zeitweise ohne weitere Kommunikation untereinander, alleine an ver-

schiedenen Stellen weiterprogrammiert, ohne allerdings ganz auf sich allein gestellt zu

sein, weil man bei evtl. Problemen bei dem Partner nachfragen konnte. Von Zeit zu

Zeit wurde dann über die Änderungen kommuniziert. Bei großen Veränderungen kam

es zwischenzeitlich zu einer Übertragung in das CVS-System, so dass sich der zweite

Partner per CVS-Check-Out die Neuerungen anschauen konnte. Auch gemeinsames

Debugging erfolgte auf diese Art in der ersten Gruppe. Die Gründe für dieses Verhalten

sind neben den aufgetretenen technischen Problemen darin zu sehen, dass dieses

keine Sessions waren, bei denen eng miteinander programmiert wurde. Diese Sessi-


ons sind in dieser Evaluation nicht nachvollziehbar oder belegbar, weil im Vorfeld da-

von ausgegangen wurde, dass bei den gemeinsamen DPP-Sessions immer XPairtise

zum Einsatz kommen würde. Generell ist es ein interessanter Aspekt, dass sich Pro-

grammierer auch mal gerne - unabhängig von konkreten und konsequenten DPP-

Sessions - austauschen und auch kleine Probleme, die sich in einer SP-Session erge-

ben können, in der Gruppe oder mit einem anderen Partner diskutieren.

Von den sieben Sessions, bei denen XPairtise genutzt wurde, wurde eine Audio-

Transkription vorgenommen, die allerdings aufgrund der geringen Anzahl keine signifi-

kant statistischen Ergebnisse liefert. Bei der Transkription wurden die jeweiligen zeitli-

chen Gesprächsanteile der Studenten ausgewertet. Eigentlich wurde im Vorfeld ge-

plant, noch mehr Audiosessions aufzuzeichnen, aber dieses war von der Bereitschaft

und der Kooperation der Studenten abhängig. Letztere sahen es in ihrem Fachprakti-

kum als vorrangiges Ziel an, ihre Fachpraktikumsaufgabe zu lösen und setzten hier

ihre Prioritäten.

Die folgende Tabelle zeigt die Gesprächsanteile der Driver, Navigatoren und ggf. Gäs-

te untereinander in einer Session. Ferner wurde herausgestellt, wie sich die Fragen

und Antworten von Driver und Navigator prozentual gesehen verteilen:

Nr. Anzahl Fragen Anzahl Antworten/ Erklärungen/

Erläuterungen

Gesprächsanteile (Min. = Minuten)

Driver Naviga-tor/Gast

Driver Naviga-tor/Gast

Driver Naviga-tor

Gast

An-zahl

in % An-zahl

in % An-zahl

in % An-zahl

in % Min. in % Min. in % Min. in %

1 13 48,1 14 51,9 32 62,7 19 37,3 31 77,1 7 16,7 2 6,2

2 26 52,0 24 48,0 57 52,3 52 47,7 26 57,8 19 42,2 -- --

3 15 53,6 13 46,4 33 46,5 38 53,5 16 69,1 6 27,0 1 3,9

4 3 18,7 13 81,3 23 79,3 6 20,7 16 82,4 3 17,6 -- --

5 5 45,5 6 54,5 17 77,3 5 22,7 20 92,4 2 7,6 -- --

6 16 41,0 23 59,0 48 78,7 13 21,3 44 69,6 19 30,4 -- --

7 9 40,9 13 59,1 21 67,7 10 32,3 23 86,1 4 13,9 -- --

Tabelle 1: Übersicht Audio-Transkription -Gruppe 1-

Zu den Programmiererfahrungen der Teilnehmer bei diesen Audiosessions muss Fol-

gendes angemerkt werden: Bei der zweiten und dritten dargestellten Session handelte

es sich bei den Studenten um zwei Experten, während bei den anderen Sessions ein

Experte mit einem Anfänger zusammengearbeitet hat. Ferner sind bei den Gesprächs-

anteilen nur die Zeiträume betrachtet worden, bei denen XPairtise direkt oder unmittel-

bar zum Einsatz kam. Vor- bzw. Nachbesprechungen oder auch teilweise vorhandene

Pausen, die nicht unmittelbar mit dem DPP im Zusammenhang standen, wurden nicht


weiter ausgewertet, so dass die Sessions damit insgesamt auch zeitlich länger gedau-

ert haben als die dargestellten Gesprächsanteile es zeigen. Es sind zudem nicht alle

Sessions in voller Länge mitgeschnitten worden, weil sich die Studenten teilweise nicht

unmittelbar zu Beginn bei dem Evaluator, der zu den jeweiligen Sessions per Skype

hinzukam, gemeldet haben. Aufgrund dieser Tatsache konnte dann nur noch die restli-

che Sessiondauer aufgezeichnet werden. Darüber hinaus sind Pausen bei der Nutzung

von XPairtise (Testphasen) oder allgemeine Besprechungen losgelöst von der eigentli-

chen Programmierung mit XPairtise in den Gesprächsanteilen nicht enthalten. Diese

Anteile belegen damit die Nettogesprächsanteile der Programmierer.

Die prozentualen Gesprächsanteile wurden anhand der jeweiligen Gesprächsdauer der

Teilnehmer ermittelt. Grafisch dargestellt ergeben die Resultate der Gesprächsanteile

die folgende prozentuale Verteilung:

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

Session 1 Session 2 Session 3 Session 4 Session 5 Session 6 Session 7

Gast

Navigator

Driver

Abbildung 17: Gesprächsanteile Driver/Navigator in Prozent

Diese Grafik verdeutlicht die Ergebnisse der Auswertung der aufgenommenen Audio-

sessions und zeigt die Gesprächsanteile der Programmierer in den Rollen Driver, Na-

vigator und ggf. Gast untereinander. Man erkennt, dass das Verhältnis nicht ausgewo-

gen ist. Die Driver hatten einen deutlich höheren Gesprächsanteil. Zwar fand während

der Sessions eine angeregte Kommunikation untereinander statt, allerdings hat viel-

fach der Driver beim aktiven Programmieren einen höheren Gesprächsanteil, weil er

parallel dem Navigator erklärt, was er gerade programmiert und warum er es auf eine

bestimmte Art und Weise macht. Diese Verteilung ist in den aufgenommenen Sessions

allerdings darauf zurückzuführen, dass in fünf der sieben ausgewerteten Sessions ein

eher routinierterer Programmierer mit einem eher unerfahreneren Navigator zusam-

mengearbeitet hat. Damit wird die zweite Hypothese unterstützt, dass Navigatoren mit

geringen Programmiererfahrungen auch geringere Audioanteile während einer Session

haben. Bei der zweiten und dritten ausgewerteten Audiosession arbeiteten dagegen

Studenten mit mehrjähriger Programmiererfahrung zusammen. Wie aus der obigen


Tabelle und der Abbildung zu erkennen ist, ist dabei der Gesprächsanteil des Naviga-

tors auch deutlich höher als bei den übrigen fünf untersuchten Sessions. Größtenteils

stellte der Navigator, besonders dann wenn es sich bei diesem um einen eher unerfah-

renen Programmierer handelte, Fragen zum Verständnis. In den Sessions mit zwei

Experten waren die Fragen auf beiden Seiten (Driver/Navigator) gleich qualitativ und

konstruktiv.

Die Audiobetrachtungen haben ferner ergeben, dass bei Problemen der Navigator pa-

rallel, teilweise sogar selbstständig und ohne Aufforderung seitens des Drivers, z. B. im

Internet nach konkreten Lösungen recherchierte. Ein Beispieldialog dafür ist der fol-

gende, wobei der Driver dabei war, eine „Sleep-Funktion“ zu implementieren, aber

nicht auf Anhieb wusste, wie es genau geht und durch Ausprobieren versuchte, eine

fehlerfreie Sleep-Funktion zu integrieren. Dabei entstand im Gespräch zwischen Driver

und Navigator der folgende Dialog:

Driver:„…es gibt eine Sleep-Funktion…meine Güte...“ -> Navigator: „Mal gu-

cken woran es liegt und im Internet suchen…(kurze Pause – Navigator sucht nach einer Lösung im Internet, während der Driver parallel vergeblich durch Versu-che im Quellcode probiert, eine Funktion zu implementieren)…nee, es gibt kei-

ne…(kurze Pause – Navigator sucht weiter)…ich weiß wie es geht:

Thread.Sleep…“. Dank dieses Hinweises seitens des Navigators ist das Problem dann gelöst worden.

5.4 CVS-Auswertungen

In den folgenden Abschnitten wird eine Detailbetrachtung der CVS-Check-Ins beider

Gruppen vorgenommen, wobei im Anschluss die Ergebnisse einander gegenüberge-

stellt werden. Bei der ersten Gruppe sind nach 22 Tagen die ersten Programmieraktio-

nen in Form von Check-Ins von Javaklassen in das CVS-System vorgenommen wor-

den. Bei der zweiten Gruppe sind schon nach sechs Tagen die ersten Javaklassen

entwickelt worden. Eine Belegung der Check-Ins liegt ebenfalls anonymisiert als Datei

„CVS-Daten-Belegung der Gruppen“ auf der CD dieser Arbeit bei - siehe Anhang A 4.

Ein Beispiel für einen erfolgten Check-In liefert der folgende Screenshot aus der Histo-

rie des Gruppenprojektes der ersten Gruppe aus Eclipse:

Abbildung 18: Beispiel CVS-Check-In


Das Feld „Revision“ zeigt in diesem Beispiel mit „1.2“ an, dass es der zweite CVS-

Check-In der Java-Klasse „LeaveSessionAction.java“ ist, die durch diesen Check-In

modifiziert wurde. Ferner wird bei einem Check-In das Datum und die Uhrzeit protokol-

liert. Das Feld „Author“ gibt an, welcher User den Check-In vorgenommen hat (in die-

sem Beispiel wurde es aus Anonymisierungsgründen geschwärzt). Im Feld „Comment“

hat der User, der den Check-In vornimmt, die Möglichkeit, einen individuellen Kom-

mentar zum Verständnis zu dem Check-In zu ergänzen.

5.4.1 CVS-Ergebnisse der ersten Gruppe

Die folgende Abbildung zeigt die Anzahl der CVS-Check-Ins pro Tag im Fachprakti-

kumsverlauf der ersten Gruppe:

30.10.2007 30.11.2007 31.12.2007 31.01.2008 02.03.20080

20

40

60

80

100

120

140

Anzahl

CVS-Eincheckungen -bereinigt- CVS-Eincheckungen -gesamt-

Abbildung 19: CVS-Check-Ins -Gruppe 1-

Insgesamt gab es bei der ersten Gruppe 2 910 Check-Ins von Javaklassen in das CVS-

Repository. Hierbei wurde in der Abbildung eine Differenzierung zwischen Check-Ins

aufgrund von klassischen Quellcodeänderungen, bereinigt um Sondereinflüsse, vorge-

nommen. Sondereinflüsse waren z. B. Namensänderungen von Klassen oder ganzen

Packages sowie generelle Überarbeitungsaktionen, ohne dass am eigentlichen Java-

Quellcode etwas verändert wurde. Aber auch Dokumentationen und Javadoc-

Ergänzungen, die gerade in der letzten Woche vor Abgabe vorgenommen wurden, sind

bei den bereinigten CVS-Check-Ins heraus gerechnet worden. Da diese CVS-Check-

Ins bzgl. der Evaluation von DPP keine relevanten Erkenntnisse liefern und auch gene-

rell keine große Bedeutungen hatten (weil z. B. eine Umbenennung eines Packages

gleich zahlreiche Check-Ins verursacht, ohne dass am Quellcode der Klassen etwas

geändert wurde), werden diese in dieser Evaluation nicht weiter untersucht oder aufge-

Termine Meilensteine


schlüsselt. Bereinigt gab es demgemäß am 02.03.2008 beispielsweise 241 allgemeine

Check-Ins aufgrund von Codedokumentationen, die damit in die bereinigten Daten

nicht mit aufgenommen wurden. Bereinigt um diese Sondereinflüsse gab es bei der

ersten Gruppe insgesamt 2 380 Check-Ins.

Deutlich wird, ähnlich wie die Nutzung des XPairtise-Plugins es schon in Kapitel 5.2

gezeigt hat, dass die Aktivitäten vor den Meilensteinen zunehmen. Die Meilensteine

waren bei der ersten Gruppe am 09.12., 03.02., 24.02. sowie Abgabe am 10.03.2008

und sind in der Abbildung durch die schwarzen Pfeile kenntlich gemacht worden. Grö-

ßere Unterbrechungen oder längere Zeitintervalle, in denen von der ersten Gruppe an

mehreren aufeinander folgenden Tagen nicht programmiert bzw. keine CVS-Check-Ins

vorgenommen wurden, sind - mit Ausnahme der Weihnachtsfeiertage, an denen die

Gruppe gemeinschaftlich beschlossen hatte, eine kleine Pause einzulegen - nicht zu

verzeichnen. Insgesamt wurde von der Gruppe stetig und konsequent an ihrem Projekt

gearbeitet. An den letzten Tagen vor der direkten Abgabe haben überwiegend nur

noch Quellcodekommentierungen und sonstige generelle Überarbeitungsaktionen

stattgefunden. Das zu programmierende Plugin wurde fristgerecht mit Dokumentation

fertiggestellt und abgegeben.

Die folgenden Kreisdiagramme verdeutlichen die Aufgliederung der Check-Ins auf die

einzelnen Studenten:

CVS-Check-Ins: CVS-Check-Ins inkl. der CVS-Check-Ins als Navigator:

280 =12 %

14 = 1 %

482 = 20 %

1074 = 45 %

530 = 22 %

407 =14 %

325 = 11 %

484 = 17 %

1090 = 37 %607 =

21 %

Abbildung 20: Check-Ins pro Student -Gruppe 1-

Das erste Diagramm enthält die um die oben beschriebenen Sondereinflüsse bereinig-

ten 2 380 Check-Ins aufgeteilt pro Student. Beim zweiten Diagramm ist eine Korrelation

der CVS-Daten zu den stattgefundenen XPairtise-Sessions aus den Logdaten herge-

stellt worden. Dabei sind die vom Timing her (Zeitpunkt des Check-Ins) korrespondie-

renden Check-Ins mit den stattgefundenen DPP-XPairtise-Sessions in direkte Verbin-

dung gebracht worden. Hier hat die Detailanalyse ergeben, dass insgesamt 533


Check-Ins in Verbindung mit einer gemeinsamen XPairtise-Session erfolgten. Diese

sind damit auch den bei diesen Sessions als Navigator fungierenden Studenten zuzu-

rechnen, weil auch die Navigatoren zu der Entwicklung beigetragen haben. Nach oder

während einer Session hat meistens der Driver den veränderten Code in das CVS-

System übertragen, was technisch jeweils auch nur ein Teilnehmer machen kann. Da-

mit liegen dem zweiten Diagramm aufgrund dieser Doppelzählungen zugunsten der

Navigatoren insgesamt 2 913 Check-Ins (2 380 Check-Ins pro Student zuzüglich der

533 Check-Ins der beteiligten Navigatoren) zugrunde.

Das erste Kreisdiagramm verdeutlicht, dass es in der ersten Gruppe einen teils deutli-

chen Unterschied in der Anzahl der CVS-Check-Ins pro Student gab. Die geringe An-

zahl der Check-Ins bei dem dritten Studenten ist dadurch zu begründen, dass dieser

ein Programmieranfänger war und der Gruppe bzgl. der Hauptprogrammierung nur

geringe Unterstützung bieten konnte. Leider ist es trotz des Einsatzes von DPP nicht

gelungen, dass dieser Student gegen Ende des Praktikums eigenständig Java-Code

für das Fachpraktikum entwickelt hat. Gerade dieser Student war in vielen XPairtise-

Sessions als Navigator oder Spectator anwesend. Allerdings kommt es zudem immer

individuell auf die Personen an, inwiefern diese genügend Selbstvertrauen haben,

selbstständig kleinere Funktionalitäten einfach mal anzufangen, auszuprobieren und

diese umzusetzen. Der Schwerpunkt war bei diesem Student die Dokumentation.

Das zweite Kreisdiagramm zeigt auf, dass sich das Verhältnis der Check-Ins pro Stu-

dent deutlich ändert, wenn man die CVS-Check-Ins detailliert und differenziert betrach-

tet, die per DPP entstanden sind und die auch den Navigatoren zugerechnet werden

können. So wird damit belegt, dass der dritte Student - wie schon erläutert - bei vielen

Sessions als Navigator agierte und damit auch Anteil bei Entstehung des gemeinsa-

men Quellcodes hatte. So hat sich die Anzahl der ihm zuzurechenbaren Check-Ins von

14 auf 325 erhöht, was bedeutet, dass 311 Check-Ins mittelbar bei Entwicklung mit

einem Partner entstanden sind. Bei dem ersten Studenten sind dagegen nur 16 mittel-

bare Check-Ins in der Rolle des Navigators festgestellt worden. Das bedeutet aber

nicht, dass dieser keine XPairtise-Sessions absolviert hat, sondern im Gegenteil, dass

er in den stattgefundenen gemeinsamen Sessions fast immer als Driver aktiv war und

danach auch den modifizierten Code ins CVS-System übertragen hat.

Die Anzahl der Check-Ins sagen natürlich nichts über die Qualität des programmierten

Codes aus, allerdings sind diese ein guter Indikator dafür, wie innerhalb der Gruppe

gearbeitet wurde. Interessant ist dabei, dass bei der ersten Gruppe ein Student mit ca.

37 % (inkl. der Check-Ins als Navigator) den Großteil der CVS-Check-Ins vorgenom-

men hat, was ferner darauf hindeutet, dass dieser ein Leistungsträger der Gruppe war

und über Programmiererfahrung schon vor Beginn des Praktikums verfügte. Daneben


haben aber auch die übrigen Studenten wesentlich innerhalb der Gruppe mitgearbeitet

und ihren Anteil zum Erfolg und zur Fertigstellung des Produktes beigetragen.

Die folgende Tabelle verdeutlicht detailliert das Verhältnis zwischen SP und DPP der

einzelnen Studenten anhand der CVS-Daten in Korrelation zu den XPairtise-Sessions:

Stu-dent Nr.

Bereinig-te Check-

Ins pro Student

-Gesamt-

Check-Ins per

SP

Check-Ins i. V. m DPP-Sessions

Summe Check-Ins per

DPP

Summe korrelier-te Check-

Ins pro Student

(vgl. Abb. 20)

Verhältnis Solo- bzw. Dis-

tributed Pair Programming

als

Driver als Na-vigator

SP

in % DPP in %

1 1 074 789 285 16 301 1 090 72,4 27,6

2 482 359 123 2 125 484 74,2 25,8

3 14 14 0 311 311 325 4,3 95,7

4 530 418 112 77 189 607 68,9 31,1

5 280 267 13 127 140 407 65,6 34,4

Sum-men: 2 380 1 847 533 533 1 066 2 913 63,4 36,6

Tabelle 2: CVS-Check-Ins in Korrelation zu XPairtise-Sessions pro Student

In dieser Tabelle ist wiederum die Korrelation der bereinigten CVS-Daten mit den

XPairtise-Sessions dargestellt. Grundlage für die Berechnung des Verhältnisses zwi-

schen SP und DPP sind damit pro Student jeweils die Check-Ins, die jeder Student per

SP vornahm und die Summe der Check-Ins, die bei dem jeweiligen Studenten im Zu-

sammenhang mit einer XPairtise-Session erfolgten.

Ausschließlich gemessen an den absoluten Check-Ins, ohne Beachtung der mittelba-

ren Check-Ins, die auch dem jeweiligen Navigator zuzurechnen sind, ergibt sich in die-

ser ersten Gruppe ein Gesamtverhältnis der Check-Ins von 77,6 % SP zu 22,4 % DPP.

Grundlage bilden dabei die 2 380 bereinigten Check-Ins im Verhältnis zu den 1 847

erfolgten Check-Ins per SP bzw. 533 Check-Ins per DPP. Dieses Verhältnis ist aber

nicht aussagekräftig, weil zur Beurteilung die detaillierten Verhältnisse pro Student un-

ter Beachtung der korrelierten Check-Ins der Navigatoren betrachtet werden müssen.

So erfolgten beispielsweise beim ersten Studenten 789 Check-Ins per SP und 301

Check-Ins im Rahmen von DPP. Als Ergebnis bleibt zu konstatieren, dass der erste

Student damit 27,6 % der Check-Ins im Rahmen von DPP vornahm.

Wenn man im Detail die Gesamtverhältnisse unter Berücksichtigung der Beteiligung

der Navigatoren betrachtet, ergibt sich durchschnittlich aus den Werten der Tabelle

(Summe korrelierte Check-Ins pro Student = 2 913 im Verhältnis zur Summe Check-Ins

per SP = 1 847 und zur Summe Check-Ins per DPP = 1 066) ein Verhältnis gemessen

an dieser Korrelation von 63,4 % SP zu 36,6 % DPP. Diese zuletzt genannten Werte

und besonders die dargestellten Verhältnisse bei den einzelnen Studenten zeigen da-


mit faktisch, dass DPP einen wichtigen Stellenwert bei der ersten Gruppe im Praktikum

hatte und diese gemäß der neunten Hypothese gerne DPP praktiziert haben

Anhand der Tabelle Nr. 2 kann man weiterhin erkennen, wie sich die Verhältnisse

Driver/Navigator bei den Studenten darstellen. So agierte beispielsweise der dritte Stu-

dent bei den Sessions, die später ins CVS-System übertragen wurden, immer in der

Rolle des Navigators. Insgesamt ist sein DPP-Anteil anhand dieser Daten im Praktikum

mit 95,7 % sehr hoch. Die Daten verstärken damit wiederholt den Eindruck, dass die-

ser Student sehr gerne und fast ausschließlich DPP zur Entwicklung von Quellcode

benutzt hat bzw. alleine keine großen Programmierungen vorgenommen hat. Offen-

sichtlich wird, dass der dritte Student ein Programmieranfänger war, was auch noch an

anderen Stellen dieser Evaluation deutlich wird. Insgesamt beweisen diese Zahlen

ferner, dass alle Studenten der ersten Gruppe DPP aktiv praktiziert haben und es kei-

nen gab, der sich dem DPP verweigert hat. Gerade der erste, der zweite und der vierte

Student waren in den Sessions die erfahreneren Studenten und agierten häufig in den

Rollen des Drivers. Diese drei Studenten hatten auch - unabhängig von den gemein-

samen Sessions - den größten Anteil der CVS-Check-Ins, was auch darauf hindeutet,

dass sie den größten Anteil der Programmierleistung übernommen haben. Der fünfte

Student hat zwar in den gemeinsamen Sessions überwiegend als Navigator agiert, hat

aber auch allein Quellcode entwickelt bzw. Check-Ins vorgenommen.

Bei diesen in diesem Kapitel erörterten Daten und aufgeführten Verhältnissen muss

man generell bedenken, wie schon in Kapitel 5.3 (Audioaufnahmen) erläutert, dass

über die protokollierten XPairtise-Sessions hinaus noch gemeinschaftlich zusammen-

gearbeitet wurde, was sich allerdings nicht belegen lässt. Auch haben teilweise XPair-

tise-Sessions stattgefunden, bei denen die CVS-Check-Ins nicht unmittelbar erfolgten,

sondern erst u. U. später, weil diese nach einer gemeinsamen Sessions per SP weiter-

bearbeitet wurden und damit für diese Korrelation nicht in Verbindung gebracht werden

konnten, so dass der Gesamtanteil der Zusammenarbeit der Studenten noch höher

ausfällt.


Ein weiteres interessantes Ergebnis der Untersuchung der CVS-Daten wird durch die

folgenden Kreisdiagramme dargestellt, wobei das erste deutlich macht, wie viele Klas-

sen (inkl. später wieder gelöschter Javaklassen) von wie vielen Autoren (Programmie-

rern) gemäß der CVS-Check-Ins - bereinigt um die Sondereinflüsse - geändert wurden.

Beim zweiten Diagramm ist wiederum wie bei Abbildung 20 eine Korrelation der CVS-

Daten mit den stattgefundenen XPairtise-Sessions vorgenommen worden:

1. Anzahl Autoren pro Klasse: 2. Anzahl Autoren pro Klasse (unter Berück- sichtigung der Check-Ins als Navigator):

97 = 36 %

66 = 25 %

47 =17 %

11 =4%48 =

18 %

61 = 23 %

54 = 20 %

37 = 14 %

46 =17 %

71 = 26 %

Abbildung 21: Autoren pro Java-Klasse -Gruppe 1-

Insgesamt wurden im Fachpraktikumsverlauf von der ersten Gruppe 269 Javaklassen

angelegt sowie bearbeitet (und teilweise später auch wieder entfernt). Darunter waren

von den 269 Javaklassen insgesamt 52 Java-Testklassen (z. B. auch JUnit-Klassen).

Die Diagramme zeigen wieder, dass sich unter Berücksichtigung der Korrelation der

CVS-Daten mit den XPairtise-Sessions ein deutlich verändertes Bild ergibt. Das zweite

Diagramm verdeutlicht, dass bei ca. 66 % der Klassen diese von mindestens drei oder

auch mehr Programmierern bearbeitet wurden. Das ist ein Indiz dafür, dass es keinen

expliziten Klassen-Owner gab. Dass mehrere Studenten an einer Klasse Codeände-

rungen vorgenommen haben, ist wiederum ein Beleg dafür, dass innerhalb der Gruppe

ein guter Austausch untereinander stattgefunden hat und sich die Studenten daneben

auch gut innerhalb des gesamten Java-Projektes auskannten sowie die Abhängigkei-

ten und Verflechtungen der Methoden und Klassen kannten. Aber immerhin wurden

noch ca. 34 % der Klassen nur von einem oder höchstens zwei Programmierern vor-

genommen.


5.4.2 CVS-Ergebnisse der zweiten Gruppe

Die folgende Abbildung zeigt die Anzahl der CVS-Check-Ins pro Tag im Fachprakti-

kumsverlauf der zweiten Gruppe:

0

20

40

60

80

100

120

140

Anzahl

CVS-Eincheckungen -bereinigt- CVS-Eincheckungen -gesamt-

Abbildung 22: CVS-Check-Ins -Gruppe 2-

Insgesamt gab es bei der zweiten Gruppe bis zur Fachpraktikumsabgabe 3 851 Check-

Ins von Javaklassen in das CVS-Repository. Hierbei wurde in der Abbildung, wie auch

bei der ersten Gruppe, eine Differenzierung zwischen CVS-Check-Ins aufgrund von

klassischen Quellcodeänderungen, bereinigt um Sondereinflüsse, vorgenommen. So

gab es beispielsweise eine Zusammenführung (Merge) des Gruppenprojektes in ein

anderes Projekt im CVS-System mit 272 Check-Ins am 16.02.08, die damit heraus

gerechnet wurden. Bereinigt um diese Sondereinflüsse nahm die zweite Gruppe insge-

samt 3 134 Check-Ins vor.

Insgesamt ist bei der Betrachtung der Abbildung zu konstatieren, dass die Aktivitäten

bezogen auf die CVS-Check-Ins im Zeitverlauf des Praktikums ansteigen. Eine deutli-

che Steigerung der Aktivitäten vor den Meilensteinen kann man, abgesehen vom vier-

ten Meilenstein und dem Praktikumsende, nicht eindeutig erkennen. Die Meilensteine

waren bei der zweiten Gruppe am 20.11., 17.12., 28.01., 25.02. und offizielle Abgabe

am 31.03.2008 und sind in der Abbildung wiederum durch schwarze Pfeile kenntlich

gemacht. Allerdings wurden diese, wie in Kapitel 5.1.2 beschrieben, nicht eingehalten.

Insgesamt arbeitete auch die zweite Gruppe stetig und ohne große Unterbrechungen

an ihrem Produkt. Wie man anhand des offiziellen Abgabetermins erkennen kann,

wurden praktisch, im Gegensatz zur ersten Gruppe, bis zur letzten Minute noch Quell-

codeentwicklungen- und änderungen vorgenommen. Selbst über das offizielle Ende

07.10.2007 31.10.2007 30.11.2007 31.12.2007 31.01.2008 29.02.2008 31.03.2008

Termine Meilensteine


hinaus sind noch Codeüberarbeitungen (überwiegend Kommentare und

Dokumentationen) vorgenommen worden, was zeigt, dass das Produkt bis zum letzten

Tag noch nicht vollständig entwickelt war und die Gruppe diese Zeit benötigte.

Bereinigt um die beschriebenen Sondereinflüsse gab es bei den sechs Studenten die

folgende Aufteilung der CVS-Check-Ins pro Student, wobei beim zweiten Diagramm

wieder eine Korrelation der CVS-Daten mit den stattgefundenen XPairtise-Sessions

aus den Logdaten vorgenommen wurde:

CVS-Check-Ins: CVS-Check-Ins inkl. der CVS-Check-Ins als Navigator:

749 =24 %

181 = 6 %

542 =17 %

681 =22 %

591 =19 %

390 =12 %

390 =12 %

684 =22 %

749 =23 % 195 =

6 %

559 =18 %

599 =19 %

Abbildung 23: Check-Ins pro Student -Gruppe 2-

Diese Kreisdiagramme verdeutlichen, dass es in der zweiten Gruppe bezogen auf die

Anzahl der CVS-Check-Ins, abgesehen vom dritten Studenten, eine recht gleichmäßi-

ge Verteilung der Anzahl der CVS-Check-Ins gab, was ein deutlicher Hinweis auf eine

gute Verteilung der Arbeit innerhalb der Gruppe ist. Einen offensichtlichen Ausreißer,

wie bei der ersten Gruppe festgestellt, ist bei der zweiten Gruppe nicht erkennbar. Kein

Student hat mehr als 25 % aller CVS-Check-Ins vorgenommen.

Es wird aus den Diagrammen ersichtlich, dass die Unterschiede der Check-Ins mit den

korrelierten Check-Ins in Verbindung mit den XPairtise-Sessions sehr gering sind. Das

kommt daher, weil diese Gruppe nur sehr wenige gemeinsame XPairtise-Sessions

absolviert hat und auch im direkten (zeitlichen) Zusammenhang mit den gemeinsamen

Sessions keine CVS-Check-Ins vorgenommen wurden. Warum es insgesamt nur so

wenige gab oder ob diese Check-Ins später und damit völlig losgelöst von den gemein-

samen Sessions erfolgten, lässt sich nicht belegen. Insgesamt sind die Unterschiede

so marginal, dass diese nicht - wie bei der ersten Gruppe - weiter kommentiert oder

ausgewertet werden müssten.


Die folgenden Kreisdiagramme verdeutlichen, wie viele Klassen (inkl. später wieder

gelöschter Javaklassen) von wie vielen Autoren (Programmierern) - bereinigt um die

Sondereinflüsse - bei der zweiten Gruppe geändert wurden:

1. Anzahl Autoren pro Klasse: 2. Anzahl Autoren pro Klasse (unter Berück- sichtigung der Check-Ins als Navigator):

31 = 6 %

133 = 27 %

63 = 13 %

48 = 10 %

6 =1 %

217 =43 %

63 = 13 %

49 = 10 %

33 =7%

7 = 1 %

132 = 27 %

214 =42 %

Abbildung 24: Autoren pro Java-Klasse -Gruppe 2-

Insgesamt wurden von der zweiten Gruppe 498 Javaklassen angelegt sowie bearbeitet

(und teilweise später auch wieder entfernt). Weil die zweite Gruppe während des Prak-

tikumsverlaufes zwischenzeitlich einmal das Hauptprojekt im CVS-System gewechselt

hat, aber später wieder darauf zurückgekommen ist, war es für diesen Vergleich not-

wendig, die Javaklassennamen nach ihrer eindeutigen Namensbezeichnung zu identi-

fizieren und diese für diese Darstellung korrekt zusammenzufassen.

Von den 498 Java-Klassen waren insgesamt 45 Java-Testklassen (z. B. auch JUnit-

Klassen). Das zweite Diagramm verdeutlicht, dass 31 % der Klassen (zum Vergleich:

66 % bei der ersten Gruppe) von mindestens drei oder auch mehr Programmierern

bearbeitet wurden. Damit wurden 69 % der Klassen nur von einem bzw. höchstens

zwei Studenten bearbeitet. Das bestätigt die Aussage der zweiten Gruppe dahinge-

hend, dass diese überwiegend getrennt und in Zweierteams gearbeitet haben. Die di-

versen Aufgaben wurden untereinander (in den Zweierteams) aufgeteilt und der Quell-

code wurde überwiegend getrennt mit wenigen Verflechtungen entwickelt. Die CVS-

Daten deuten damit darauf hin, dass es bei der zweiten Gruppe eindeutigere Klassen-

Owner gab als dies bei der ersten Gruppe der Fall war.


5.4.3 CVS-Ergebnisse - Vergleich beider Gruppen

Die Anzahl und Regelmäßigkeit der vorgenommenen CVS-Check-Ins zeigt, dass teil-

weise auch mehrmals am Tag Code ins Gesamtsystem integriert wurde. Somit haben

beide Gruppen die XP-Praktik „Fortlaufende Integration“ (siehe Abbildung Nr. 1) aktiv

praktiziert. Wie die CVS-Auswertungen beider Gruppen ferner gezeigt haben, sind aber

durchaus Unterschiede zwischen den beiden Gruppen festzustellen. Das betrifft die

quantitativen Aspekte wie die Anzahl der Check-Ins, die Anzahl der angelegten Java-

klassen, den Zeitverlauf der vorgenommenen Check-Ins, die Verteilung der Check-Ins

auf die Gruppenmitglieder und die Anzahl der Programmierer pro Javaklasse. Qualita-

tive Aussagen können anhand der vorliegenden Daten nicht getroffen werden, aller-

dings ist noch ein weiterer Unterschied zwischen den Gruppen bezüglich der Kommen-

tierung der Check-Ins feststellbar: Das CVS-System war dahingehend justiert worden,

dass bei jedem Check-In von Quellcode automatisch generierte Mails an alle Gruppen-

teilnehmer versendet wurden. Dieses hatte den Hintergrund, dass jeder Teilnehmer

sehen konnte, wann welche Klasse(n) verändert wurde(n). Dabei hatten die Gruppen-

mitglieder jeweils die ihnen im Vorfeld empfohlene Möglichkeit, vorgenommene Verän-

derungen per Kommentar kurz zu erläutern, damit die übrigen Teammitglieder auf dem

aktuellsten Stand sind. Die eingestellten Kommentare können bei Bedarf daneben spä-

ter in der Klassenhistorienentwicklung des CVS-Systems recherchiert werden, wenn

die Nutzer evtl. ältere Veränderungen noch nachvollziehen möchten. Das erfolgte bei

der ersten Gruppe weitestgehend konsequent. Neben einem Kommentar, der nur aus

einem kurzen Satz oder ggf. auch aus einer erweiterten Erläuterung bestehen konnte,

wurde der Bearbeiter bzw. das Bearbeiterkürzel desjenigen, der die Check-Ins vor-

nahm, mit angegeben. Dieses Verhalten war bei der zweiten Gruppe anfangs gar nicht,

später im Verlauf nur sporadisch bei einigen Mitgliedern festzustellen. Dementspre-

chend erfolgten vielfach Check-Ins von verändertem und auch neuem Quellcode ohne

jeglichen Kommentar.

Die folgende Abbildung zeigt im direkten Vergleich die Anzahl der vorgenommenen

Check-Ins der beiden Gruppen im Fachpraktikumsverlauf auf. Aus Gründen der Über-

sichtlichkeit werden die Check-Ins in der Abbildung entgegen der tageweisen Einzel-

darstellung der CVS-Check-Ins pro Gruppe in den letzten beiden Abschnitten wochen-

weise dargestellt. Es handelt sich dabei wieder jeweils um die bereinigten CVS-Daten:


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 260

50

100

150

200

250

300

350

400

450

5001. Gruppe 2. Gruppe

Abbildung 25: CVS-Check-Ins beider Gruppenprojekte im Vergleich

Wie man aus der Abbildung entnehmen kann hat die zweite Gruppe zwar geringfügig

früher mit der Quellcodeentwicklung angefangen und damit haben früher CVS-Check-

Ins stattgefunden, allerdings hat die erste Gruppe in den ersten Wochen (besonders in

der achten und neunten Woche) viele CVS-Check-Ins vorgenommen und damit folglich

viel Quellcode erzeugt. Der Einbruch in der 12. Woche ist durch die kleine Pause in der

Weihnachtszeit begründet. Generell lässt sich bei beiden Gruppen eine Steigerung der

CVS-Check-Ins in der Wochenverlaufsbetrachtung feststellen, wenn man die Ausreißer

der ersten Gruppe in der achten und neunten Woche außer Acht lässt. Das unter-

schiedliche Ende ist damit zu begründen, dass die erste Gruppe in der dargestellten

23. Woche ihre Abgabefrist hatte und die zweite Gruppe eine Verlängerung bekommen

hatte. In den letzten Wochen des Fachpraktikums erfolgten die meisten CVS-Check-

Ins. Allerdings hatte die erste Gruppe die meisten CVS-Check-Ins in der neunten Wo-

che, während die zweite Gruppe die meisten CVS-Check-Ins erst in der 25. und damit

vorletzten Woche vor dem bei dieser Gruppe verlängerten Abgabetermin hatte.

Zwar steigen bei beiden Gruppen gegen Ende des Praktikums die Anzahl der Check-

Ins an, allerdings sind bei der zweiten Gruppe deutlich mehr CVS-Check-Ins zu ver-

zeichnen als bei der ersten. Dieses Faktum ist ein Indiz dafür, dass die zweite Gruppe

gegen Ende der Abgabefrist noch viel Quellcode entwickeln musste. Während bei der

ersten Gruppe zum Ende der Abgabefrist hin neben kleineren Anpassungen überwie-

gend nur noch allgemeine Überarbeitungen mit Ergänzung von Kommentaren oder

Ähnliches stattgefunden haben, ist bei der zweiten Gruppe praktisch bis zum letzten

Tag der Abgabe programmiert worden und es kam folglich bis zum Schluss zu CVS-

Check-Ins. Dieser Vergleich zeigt, dass die erste Gruppe planungstechnisch und damit

Wochen im Praktikumsverlauf

Anzahl

CVS-

Check-Ins


organisatorisch besser strukturiert war und die vereinbarte Abgabefrist damit stress-

freier und fristgerecht eingehalten hat.

Die folgende Abbildung zeigt den Vergleich der beiden Gruppen bezüglich der Anzahl

der programmierten Javaklassen und der bereinigten CVS-Check-Ins in den jeweiligen

Projekten während des Fachpraktikums:

2.380

269

3.134

498

0

500

1.000

1.500

2.000

2.500

3.000

3.500

Anzahl Klassen Anzahl CVS-Eincheckungen

Anz

ahl

Gruppe 1

Gruppe 2

Abbildung 26: CVS-Daten beider Gruppenprojekte

Die zweite Gruppe hat insgesamt deutlich mehr CVS-Check-Ins vorgenommen und

dabei darüber hinaus mehr Javaklassen im Praktikumsverlauf angelegt. Demzufolge

hat die zweite Gruppe rund 85 % mehr Klassen in ihrem Projekt angelegt als die erste

Gruppe. Auch die Anzahl der bereinigten CVS-Check-Ins ist bei der zweiten Gruppe

mit ca. 32 % höher als bei der ersten Gruppe. Dieses ist natürlich einmal dadurch be-

dingt, dass die zweite Gruppe drei Wochen länger programmiert hat, zeigt allerdings

auch, dass diese Fristverlängerung zur erfolgreichen Absolvierung des Fachpraktikums

notwendig war, was ferner auch die hohe Anzahl der CVS-Check-Ins bei der zweiten

Gruppe in der 23. bis zur 25. Woche verdeutlicht.

Dieses könnte darauf hindeuten, was ebenfalls schon von anderen Studien (vgl.

[Wil00]) bestätigt wurde, dass Gruppen und Paare, die sich besser und häufiger aus-

tauschen und miteinander intensiv kommunizieren, die Quelldateien und Abhängigkei-

ten besser kennen und u. U. dadurch produktiver und schneller arbeiten können, wo-

durch wiederum weniger Quellcode notwendig wird. Die geringere Anzahl der CVS-

Check-Ins und die geringere Anzahl der programmierten Klassen bei der ersten Grup-

pe könnte ein Indiz zur Belegung dieser Thesen sein, denn bei der ersten Gruppe be-

stand während des gesamten Praktikums ein besserer Austausch und eine bessere

Kommunikation untereinander. Dahingehend unterstützen diese Resultate die zehnte

aufgestellte Hypothese. Teams, die in enger Abstimmung zusammenarbeiten, sind

effektiver, arbeiten stressfreier zusammen und die Mitglieder haben überdies mehr

Spaß an der Gruppenarbeit.


5.5 Ergebnisse Selbst- und Fremdeinschätzungsbefragungen

Die Ergebnisse der Selbst- und Fremdeinschätzungsbefragungen zeigen einige inte-

ressante Aspekte der einzelnen Gruppenmitglieder im Zeitverlauf des Praktikums auf.

Leider hat nur die erste Gruppe konsequent die Einschätzungen monatsweise vorge-

nommen, so dass sich die folgenden Ergebnisse jeweils nur auf die erste Gruppe be-

ziehen.

5.5.1 Zeitlicher Aufwand der Studenten

Die folgende Abbildung zeigt den zeitlichen Aufwand in Stunden pro Woche:

12

23

19

22

18

33

10

15

2625

1615

18 18

1818

19

18

19

25

30

1010

2019

5

10

15

20

25

30

35

1. Monat 2. Monat 3. Monat 4. Monat 5. Monat

Dur

chsc

hnitt

liche

Stu

nden

pro

Woc

he

1. Student 2. Student 3. Student 4. Student 5. Student

Abbildung 27: Zeitlicher Aufwand der Studenten

Man kann erkennen, dass der angegebene stündliche Aufwand pro Woche in einem

Korridor zwischen mindestens 10 und höchstens 33 Stunden lag. Dabei muss man

erwähnen, dass es sich bei den Studenten um Fernstudenten handelte, die ihr Studium

in Teilzeit absolvieren. Der Rückgang im dritten Monat ist dadurch zu begründen, dass

es sich um die kleine Unterbrechung in der Weihnachtszeit handelt. Betrachtet man

alle angegebenen Zeiten der Studenten über den gesamten Praktikumsverlauf, lag der

durchschnittliche wöchentliche Zeitaufwand bei 19,0 Stunden. Deutlich wird weiterhin

der Anstieg der Zeiten im letzten Monat. Da lag der zeitliche Aufwand bei vier der fünf

Studenten über dem Durchschnitt von ca. 19 Stunden pro Woche. Die teilweise aufge-

tretenen Schwankungen der Studenten sind daneben auch durch individuelle berufli-

che oder private Gründe zu erklären.

Vor Praktikumsbeginn wurden die Studenten seitens der Betreuer gebeten, sogenann-

te „Steckbriefe“ auszufüllen, auf denen sich die Studenten kurz vorstellen konnten und

daneben ferner ihr Spezialwissen (ähnlich den Fragen der Selbst- und Fremdeinschät-

zungen) abgefragt wurde. Eine Frage lautete dazu, wie viel Zeit sie wöchentlich für das


Praktikum aufwenden können und wollen. Dabei gaben vier der Studenten aus der

ersten Gruppe an, 10 Stunden pro Woche investieren zu können und ein Student 15

Stunden. Die Ergebnisse zeigen damit, dass die durchschnittlich absolvierten wöchent-

lichen Stunden nach Angaben der Studenten, die sich nicht weiter faktisch z. B. durch

die Logdaten (da nicht ausschließlich XPairtise benutzt wurde) belegen lassen, teilwei-

se deutlich über den selbst gesteckten Zeitangaben lagen bzw. auch aufgebracht wer-

den mussten. Die Ergebnisse zeigen zudem aber auch, was die Studenten auch in den

Interviews bestätigt haben, dass sie teilweise gerne diese Zeit investiert haben, weil es

ihnen selber Spaß gemacht hat, zusammen dieses Projekt durchzuführen. Das unter-

stützt die neunte Hypothese, dass zumindest die erste Gruppe positive Erfahrungen

mit der Bewältigung einer größeren Programmierungsaufgabe im Rahmen von Team-

arbeit gemacht hat. Insgesamt liegen die Angaben der aufgewendeten Zeit damit im

Rahmen von anderen Studien zum zeitlichen Aufwand von Studenten an anderen Uni-

versitäten. Studenten wenden durchschnittlich 10 - 15 Stunden für Projekte auf, die ein

vergleichbares Ausmaß wie dieses Praktikum haben [SJ03].

5.5.2 Verhältnis Solo Programming - Pair Programming

Aus den Selbsteinschätzungsbefragungen, worin monatsweise bei jedem Teilnehmer

nach dem eigenen prozentualen Anteil der Eigenarbeit bzw. der Arbeit mit einem Part-

ner gefragt wurde, hat die erste Gruppe folgendes Ergebnis geliefert, wobei hier der

prozentuale Anteil des DPP dargestellt wird:

0

10

0

2520

10

20

0

45

70

80 80

60

10

909090

10

66

50

75

132020

100

0

10

20

30

40

50

60

70

80

90

100

1. Monat 2. Monat 3. Monat 4. Monat 5. Monat

Pro

zent

ante

il A

rbei

t m

it ei

nem

Par

tner


Abbildung 28: Verhältnis zwischen Solo- und Distributed Pair Programming

Die Zeitangaben der Studenten zeigen hierbei, dass es im ersten Monat viel Einzelar-

beit gegeben hat, weil erst von den Studenten ein Selbststudium der neuen Medien

und der Literatur zur Aufgabenbewältigung stattgefunden hat. Aber schon im zweiten

Monat nahm der Anteil der Zusammenarbeit deutlich zu. Im vierten Monat wurde - pro-


zentual betrachtet - am häufigsten zusammengearbeitet. Im letzten Monat geht der

Anteil des PP dann wieder deutlich zurück. Das liegt vor allem daran, dass gegen Ende

des Praktikums das Grundgerüst des zu programmierenden Plugins fertig war und nur

noch kleinere Anpassungen und Verbesserungen im Quellcode vorgenommen wurden,

ohne dass neue und umfangreiche Bausteine implementiert wurden. Neben diesen

konkreten zeitlichen Angaben zum Vergleich PP und SP gab es natürlich bei den Stu-

denten noch weitere Phasen, in denen sie gemeinschaftlich an ihrem Projekt gearbeitet

haben. Zu erwähnen sind dabei die regelmäßig stattgefundenen Gruppenkonferenzsit-

zungen über Skype und diverse Besprechungen (z. B. zum Design etc.) untereinander,

die im Rahmen dieser Evaluation allerdings nicht weiter untersucht wurden, weil sich

diese nur schwer belegen lassen.

Anhand der vorliegenden Fakten ist zu erkennen, dass ein Großteil der Programmier-

leistung von den Praktikumsmitgliedern der ersten Gruppe, teilweise auch unabhängig

von der Nutzung von XPairtise, mittels DPP erfolgte. Das belegen zudem auch die

Logfiles und die Interviewresultate. Durch den prozentual hohen DPP-Anteil bestand

für die Studenten die Möglichkeit viel zu lernen. Allerdings sind auch viele Aufgaben

mittels SP erledigt worden. Die Ursachen dafür sind vielschichtig und unterschiedlich.

Neben zeitlichen Problemen zwecks virtueller Treffen für gemeinsame Sessions spie-

len natürlich ferner die persönlichen Präferenzen zum DPP und die generellen Pro-

grammierfähigkeiten der Studenten eine große Rolle. Einige Studenten gaben in den

Interviews (auf die noch in Kapitel 5.6 näher eingegangen wird) an, einige spezielle

Tätigkeiten lieber in Einzelarbeit verrichtet zu haben.

Generell lässt sich anhand dieser Angaben als Fazit festhalten, dass die Studenten der

ersten Gruppe gerne und relativ häufig Arbeiten in Paaren absolviert haben und inso-

fern der Arbeit in Paaren oder Gruppen positiv gegenüber gestanden haben, weil an-

sonsten nicht ein dementsprechend hoher Prozentanteil an DPP oder Teamarbeit ge-

nerell zustande gekommen wäre. Dieses Ergebnis stützt damit die neunte Hypothese.

5.5.3 Vergleich Selbst- und Fremdeinschätzungen

Im Folgenden werden die Selbsteinschätzungen der Studenten der ersten Gruppe im

ersten Monat im Vergleich zu den Selbsteinschätzungen im letzten Monat pro Student

und Frage (Thematik) gegenübergestellt. Ferner wird als dritte Säule die durchschnittli-

che Einschätzung der Gruppenmitglieder mit dargestellt. Ein Vergleich zwischen den

Selbst- und Fremdeinschätzungen in den ersten Monaten macht keinen großen Sinn,

da sich die Mitglieder noch nicht richtig kennengelernt hatten und damit eine Fremd-

einschätzung schwierig war, weshalb vielfach auch keine Einschätzung von den Stu-

denten vorgenommen wurde. Waren nicht alle Angaben von allen Gruppenmitgliedern

bei den Fremdeinschätzungen vollständig (Angabe k.E. = keine Einschätzung mög-


lich), wurden für die Werte bei der Fremdeinschätzung die Durchschnittswerte aus den

vorhandenen Mitgliedereinschätzungen gebildet. Dazu wurden für die Durchschnittsbe-

rechnung und Darstellung nur dann Werte dargestellt, wenn mindestens zwei Fremd-

einschätzungen vorlagen. Lagen zu einem Themengebiet weniger als zwei Fremdein-

schätzungen vor, sind diese mit dem Wert „null“ (= k.E.) in der Abbildung dargestellt.

Als Orientierung galt für die Studenten die folgende Bewertungsskala:

* * * * * = Exzellente Kenntnisse = 5 * * * * = Gute Kenntnisse = 4 * * * = Kenntnisse vorhanden = 3 * * = Erste Grundkenntnisse vorhanden = 2 * = Sehr wenige bis keine Vorkenntnisse vorhanden = 1 k.E. = Keine Einschätzung möglich -

Die verschiedenen Themengebiete lauteten jeweils: GUI-Entwicklung Plugin-Expertise Dokumentation Netzwerkprogrammierung Thread-Programmierung Analyse Objektorientiertes Design Datenhaltung/Persistenz Planning Games Testerfahrung eXtreme Programming

In der folgenden Abbildung sind graphisch die jeweiligen Einzeleinschätzungen pro

Student dargestellt worden:

= Selbsteinschätzung 1. Monat = Selbsteinschätzung 5. Monat = Fremdeinschätzung 5. Monat

Student 1: Ergebnis Selbst- und Fremdeinschätzung

GUI Netz-werk

Objekt-orientiertes

Design

Test-erfahrung

Plugin-Expertise

Thread-Program-mierung

Daten-haltung/

Persistenz

eXtremeProgram-

ming

Doku-mentation

Analyse PlanningGames

0

1

2

3

4

5

Ein

schä

tzun

g


GUI Netz-werk-

Objekt-orientiertes

Design

Test-erfahung

Plugin-Expertise


Daten-haltung/

Persistenz

eXtremeProgram-

ming

Doku-mentation


0

1

2

3

4

5

Ein

schä

tzun

g



GUI Netz-werk

Objekt-orientiertes

Design

Test-erfahrung

Plugin-Expertise


Daten-haltung/

Persistenz

eXtremeProgram-

ming

Doku-mentation


0

1

2

3

4

5

Ein

schä

tzun

g


GUI Netz-werk

Objekt-orientiertes

Design

Test-erfahrung

Plugin-Expertise


Daten-haltung/

Persistenz

eXtremeProgram-

ming

Doku-mentation


0

1

2

3

4

5

Ein

schä

tzun

g


GUI Netz-werk

Objekt-orientiertes

Design

Test-erfahrung

Plugin-Expertise


Daten-haltung/

Persistenz

eXtremeProgram-

ming

Doku-mentation


0

1

2

3

4

5

Ein

schä

tzun

g

Abbildung 29: Darstellungen der Selbst- und Fremdeinschätzungen

Diese Auswertung zeigt, dass sich alle Studenten am Ende des Praktikums erwar-

tungsgemäß (teilweise deutlich) bei den verschiedenen Themengebieten besser ein-

schätzten als es zu Beginn der Fall war, weil sie gemäß der ersten Hypothese viel ler-

nen und daneben auch bei den einzelnen Themengebieten Erfahrungen sammeln

konnten. Generell ist ebenfalls zu erkennen, dass die Selbsteinschätzungen durch-

schnittlich etwas unter den Benotungen der Fremdeinschätzungen liegen. Die folgende

Tabelle verdeutlicht diese Abweichungen:


Abweichungen Studenten Durchschnitt

Abweichung Nr. 1 Nr. 2 Nr. 3 Nr. 4 Nr. 5 GUI-Entwicklung 1,0 0,0 k.E. 0,3 0,0 0,3 Netzwerkprogrammierung 0,5 0,3 1,0 1,3 0,0 0,6 Objektorientiertes Design 0,3 0,3 k.E. 0,3 0,3 0,3 Testerfahrung 1,3 -0,3 k.E. -0,3 1,0 0,4 Plugin-Expertise 0,0 -0,7 0,0 0,0 0,3 -0,1 Thread-Programmierung 0,3 -0,3 0,0 0,7 k.E. 0,2 Datenhaltung/Persistenz 1,0 0,3 0,5 k.E. 0,3 0,5 eXtreme Programming 1,7 -0,5 0,7 -0,3 -0,5 0,2 Dokumentation 1,5 1,0 0,3 -1,3 1,3 0,6 Analyse 1,5 1,5 1,0 -0,3 -0,5 0,6 Planning Games 1,0 1,5 1,0 2,7 k.E. 1,5

Durchschnitt Abweichung

0,9

0,3

0,6

0,3

0,3 0,48 0,46

Tabelle 3: Abweichungen der Selbst- gegenüber den Fremdeinschätzungen

Anhand der Daten lässt sich belegen, dass die durchschnittliche Abweichung aller Ein-

schätzungen sämtlicher Studenten 0,46 Notenpunkte beträgt. Das bedeutet, dass die

Studenten sich durchschnittlich 0,46 Punkte schlechter eingeschätzt haben als sie sel-

ber von den anderen Gruppenmitgliedern eingeschätzt wurden. Besondere Auffälligkei-

ten sind dabei nicht weiter festzustellen. Der Student Nr. 1 hat sich durchschnittlich fast

eine ganze Note (0,9) schlechter eingeschätzt als er selber eingeschätzt wurde. Bei

den anderen Studenten liegt diese Quote zwischen 0,3 und 0,6 Notenpunkten.

Die Durchschnittsabweichung beträgt bei der Bewertung der Themengebiete 0,48 No-

tenpunkte. Betrachtet man die unterschiedlichen Themengebiete im Detail, lässt sich

feststellen, dass dabei zwei Auffälligkeiten existieren: Bei der Plugin-Expertise schätzte

sich ein Student um 0,7 Punkte besser ein als er selber eingeschätzt wurde, so dass

im Durchschnitt bei diesem Themengebiet ein Wert von -0,1 Notenpunkte als durch-

schnittliche Notenvergabe vorgenommen wurde. Als ein Ausreißer nach oben lässt

sich das Themengebiet Planning Game feststellen. Hier beträgt die durchschnittliche

Abweichung +1,5 Notenpunkte, was aus der Notenvergabe (2,7 Punkte) beim 4. Stu-

denten zu begründen ist. Das ist ein Indiz dafür, dass von den Studenten die Thematik

Planning Game und die damit verbundenen Beziehungen zwischen Kunde und Ent-

wicklern nicht umfassend erfasst wurden.

Aufgrund der relativ geringen Durchschnittsabweichungen der Notenpunkte der

Selbsteinschätzungen der Studenten im Verhältnis zu den Fremdeinschätzungen von

ihren Gruppenmitgliedern ist als Fazit festzuhalten, dass alle Einschätzungen doch

ziemlich realistisch vorgenommen wurden und sich die Mitglieder in ihrer Gruppe durch

die erfolgte intensive Zusammenarbeit gut kennengelernt und einzuschätzen gelernt

haben.


5.6 Interviewergebnisse

Im Folgenden werden die Ergebnisse der Interviewbefragungen erläutert. Die Antwor-

ten der Studenten sind teilweise schon an diversen Stellen in dieser Diplomarbeit ver-

arbeitet, aber auf einige ausgewählte Aspekte mit relevanten Sachverhalten zum PP

und DPP soll in diesem Kapitel explizit eingegangen werden. Leider war nur die erste

Gruppe zu einer Interviewbefragung bereit, so dass diese Ergebnisse sich immer auf

Aussagen der Studenten der ersten Gruppe beziehen:

Die Frage „Konntest du mit dem Plugin XPairtise direkt starten und gemeinsam mit

einem weiteren Pair effektiv loslegen zu programmieren, oder war erst - auch wegen

den vorhandenen Programmier(vor)kenntnissen - eine Eingewöhnung notwendig?“

wurde von drei der fünf befragten Studenten damit beantwortet, dass ein direkter und

problemloser Start ohne Eingewöhnung möglich war. Zwei Studenten antworteten da-

gegen, dass eine gewisse kurze Eingewöhnungsphase von ein paar Tagen nötig war

um herauszufinden, was mit dem Plugin XPairtise alles möglich ist bzw. nicht möglich

ist. An evtl. fehlenden Programmierkenntnissen lag diese Eingewöhnungsphase bei

den zwei Studenten allerdings nicht. Es trifft damit die erste Hypothese zu, dass die

Studenten direkt mit dem Plugin XPairtise starten konnten.

Eine Frage im Interview zur Untersuchung der vorhandenen Features in XPairtise zur

Kommunikation und Koordination lautete: „Was ist für dich das beste und meistgenutz-

te Feature in XPairtise gewesen, um neben dem Audiochat mit dem Pair zu kommuni-

zieren, gestikulieren und programmieren?

a) Textchat b) Whiteboard

c) Markierungen d) Rollenwechsel“

Wie schon in Kapitel 5.2.1.1 beschrieben, hat der Textchat keine Rolle bei der Kom-

munikation untereinander gespielt, da parallel immer ein Audiochat zur Kommunikation

bereit stand und auch genutzt wurde. Die Beantwortung dieser Frage war sehr unter-

schiedlich. Zwei Studenten nannten Antwort c) „Markierungen“, zwei weitere gaben b)

„Whiteboard“ an und einer meinte d) „Rollenwechsel“. Diese unterschiedlichen Antwor-

ten verdeutlichen die unterschiedliche Nutzung von XPairtise einzelner Studenten.

Routiniertere Studenten haben z. B. zur Koordination mehr Gebrauch von Rollenwech-

seln gemacht, während eher ungeübte Programmierer großen Nutzen von gezeigten

Stellen im Code mittels Markierungen durch kundige Studenten ziehen konnten. Die

Bedeutung einer Rollenwechselfunktion belegt auch das Zitat desjenigen Studenten,

der bei dieser Frage Rollenwechsel angab und dies folgendermaßen begründete:

„Wenn der andere eine Idee hatte, dass der sofort umschalten konnte und

dann die Idee auch umsetzen konnte und dass man nicht irgendwie kompli-


ziert ein- und aussteigen musste oder dass der versucht hatte, das einem zu

erklären, sondern man einfach hingehen konnte, mach du jetzt Driver, ich

schaue mir an, was du da vorhast“.

Die Angabe des Whiteboards durch die Studenten entstand dadurch, dass gegen Ende

des Praktikums das Whiteboard dazu genutzt wurde, um Verständnisbilder (z. B. zum

Programmdesign oder zu Prozessabläufen) anzufertigen. Während der ersten Phase

des Fachpraktikums und bei reinen Quellcodeprogrammierungen wurde dagegen das

Whiteboard, wie schon in Kapitel 5.2.1.3 angesprochen, praktisch nur in einer XPairti-

se-Session genutzt. Die Sessions mit Whiteboardbenutzung erfolgten überwiegend

komplett ohne Programmierung von Code im Editor, sondern nur zur Anfertigung von

Entwürfen und Zeichnungen für bildliche Verdeutlichungen und Erklärungen.

Insgesamt unterstützen diese Aussagen der Studenten bedingt die fünfte Hypothese

über die Nutzung der Features in XPairtise. Denn wenn auch nicht unbedingt in jeder

Session oder innerhalb fester Intervalle wurden sehr wohl die Funktionen in XPairtise

genutzt, wenn auch nicht so häufig wie im Vorfeld vermutet. Ohne diese Features ist

eine gute Zusammenarbeit und Kommunikation in einer DPP-Session deutlich um-

ständlicher.

Zur Untersuchung, ob DPP zu einem Wissenstransfer beitragen konnte, wie es in der

dritten Hypothese behauptet wird, diente die folgende Frage im Interview, weil es an-

sonsten ein schwierig zu untersuchender und zu belegender Aspekt ist: „Wie beurteilst

du persönlich den Wissensfluss in eurer Gruppe? Hat ein Wissensfluss untereinander

stattgefunden und hast du durch den Austausch mit den Pairs und dem Einsatz von

XPairtise gut und viel lernen können?“

Sowohl die Logdaten als auch die Eindrücke aus den Audioaufzeichnungen haben

bisher ergeben, dass es vielfach XPairtise-Sessions gegeben hat, bei denen der selber

in Eigenarbeit programmierte Code einfach nur anderen Mitgliedern gezeigt und zudem

erklärt wurde. Damit wurde zusätzlich sichergestellt, dass sich mindestens zwei Mit-

glieder in dem vorhandenen Quellcode für spezielle Teilbereiche auskennen. Das da-

mit und auch während der gemeinsamen Sessions erlernte Wissen wurde durch diese

Sessions untereinander weitergegeben. Inwieweit es dann an anderen Stellen einge-

setzt wurde, lässt sich schwer belegen. Die konkreten Interviewergebnisse zu dieser

Frage haben ergeben, dass alle fünf Studenten mit Nachdruck bestätigt haben, dass

sie durch die Nutzung von XPairtise und generell durch Anwendung von DPP viel ge-

lernt haben und es durchaus einen Wissensfluss untereinander gegeben hat. Es ist

nicht verwunderlich, dass gerade Programmieranfänger dieses ausdrücklich bestäti-

gen. Das ging sogar so weit, dass ein Student im Interview zu dieser Frage zum The-

ma Lernen und Wissensfluss mit XPairtise sagte: „Es war sehr gut, mir wird was


fehlen, wenn das Praktikum zu Ende ist“. Weiterhin gab ein Student konkret an,

gerade durch die gemeinsame Programmierung erst so richtig die MVC-Aufteilung ver-

standen und verinnerlicht zu haben. Ein anderer erwähnte, dass er von den anderen

Mitgliedern einiges zu JUnits gelernt hat. Aber auch schon erfahrenere Programmierer

bestätigen einen Lernerfolg. Ein nicht unerfahrener Programmierer erklärte beispiels-

weise, dass er noch Einiges von einem Partner gelernt hat. Konkret hat ihm dieser bei-

spielsweise die Funktionen einer Hashtabelle in Java erklärt, welche er vorher nicht

kannte und nie eingesetzt hatte. Später hat dieser Student an mehreren Stellen im

Quellcode und für verschiedene Funktionalitäten Hashtabellen implementiert und das

per DPP erworbene Wissen somit später wieder sinnvoll eingesetzt. Nach Aussage

eines anderen routinierten Studenten hat ein Wissensfluss besonders dahingehend

stattgefunden, dass er etwas bei Spezialthemen lernen konnte, wo ein anderes Grup-

penmitglied sich schon in die Thematik (z. B. Graphical Editing Framework (GEF) oder

Plugin-Entwicklung) eingelesen hatte und die Informationen und das angelesene Wis-

sen weitergeben konnte. Damit musste sich nicht jedes Mitglied in allen Spezialthemen

auskennen, woraus sich auch für jeden einzelnen eine Zeitersparnis ergab. Diese Wis-

senssammlungen zu den Thematiken oder auch hilfreiche Links wurden ebenfalls in

dem CURE-Raum der Gruppe für alle Mitglieder zur Verfügung eingestellt.

Insgesamt haben die Antworten der Studenten zu dieser Frage ergeben, dass sie er-

wartungsgemäß der dritten Hypothese Nutzen aus den gemeinsamen XPairtise-

Sessions gezogen haben und einmal gelerntes Wissen auch auf andere Bereiche

transferiert und an anderen Stellen wieder zweckmäßig eingesetzt haben. Dabei lernen

Programmieranfänger allgemein die Vorgehensweise bei Programmierungen, während

sich erfahrenere Programmierer eher Detail- und Spezialwissen bei gemeinsamen

Sessions aneignen. Gerade auch neben der konkreten Programmierung in einer Ses-

sion kommt es durch Diskussionen und der grundsätzlichen Zusammenarbeit zu einem

regen Wissensaustausch untereinander. Neben dem persönlichen Wissenstransfer ist

es beim PP auch wichtig, dass ein Wissenstransfer bezüglich des Gesamtprojektes

stattfindet. Dieses gelingt besonders dann gut, wenn es zu regelmäßigen Pair Rotatio-

nen kommt, die auch in der ersten Gruppe stattfanden (siehe Soziogramm Abbildung

Nr. 13 und Zeitleiste Paarzusammensetzungen Abbildung Nr. 14). Im Zusammenhang

zum Wissensfluss erwähnte ein Student auch einen weiteren Vorteil des (D)PP:

„Wenn du zusammen gesessen hast und du hast einen echt bösen Fehler und

du suchst zusammen und du kämpfst zusammen und am Ende hast du es

dann hingekriegt, dann ist es wichtig, dass jedes Gruppenmitglied so ein

bisschen den Anteil daran hatte, weil dann sind alle stolz und alle haben auch

kapiert, warum es so lange gedauert hat. Wenn du das einfach nur erzählst,

dann weiß der andere gar nicht, wie viel Arbeit das war und dann sagt er –

aha, schön, jetzt geht’s. Aber es ist ja dann im Grunde nur so ein winziges


Bisschen, was die Software jetzt mehr kann, aber es hat ja vielleicht viel ge-

kostet und wenn das halt so im gemeinsamen Entwickeln läuft, ist das einfach

für die Gruppe viel besser.“ Somit wird durch (D)PP auch der Gruppenzusammenhalt und das Verständnis unter-

einander gefördert.

Eine weitere Frage lautete: „Wofür wurde XPairtise deiner Meinung/Einschätzung nach

am häufigsten eingesetzt und verwendet:

a) Schwieriger Code b) Einfacher Code

c) Debugging d) Tests

e) Entwürfe f) GEF

g) Plugin h) Um anderen z. B. in Gruppen- oder auch Ein-zelgesprächen programmierten Code zur Veran-schaulichung zu zeigen und zu erklären

i) Sonstiges“

Diese Frage ist angelehnt an eine vorgenommene Befragung von Riad Djemili im

Rahmen seiner Diplomarbeit aus dem Jahre 2006. Darin antworten als größte Gruppe

23 % der Befragten, dass sie für schweren Code DPP verwenden würden. Auf Platz

zwei folgte mit 18 % Debugging. Einfacher Code wurde dagegen nur von 12 % der

Befragten angegeben [Dje06].

Im Rahmen dieser Diplomarbeit ergab die Befragung folgendes Ergebnis: Genannt

wurde einmal a) „Schwieriger Code“, einmal f) „GEF“ und insgesamt dreimal h) „Veran-

schaulichung von Code“. Es waren aber dazu auch - nach Priorität festzulegen - Mehr-

fachnennungen möglich. Die aufgeführten Antworteten waren dabei für die Studenten

die Wichtigsten. Es zeigt sich damit, dass Programme oder Plugins wie XPairtise sehr

nützlich sind, um Informationen und Wissen durch Erklärungen im Quellcode anderen

zu zeigen und zu vermitteln, womit die erste und dritte Hypothese untermauert wird.

Die Frage nach der Bearbeitung von eher schwierigen oder eher einfachen Code wur-

de unterschiedlich beantwortet. Es gab dazu Studentenaussagen dahingehend, dass

sie gerade bei schwerem Code gerne zusammen arbeiten (überwiegend Studenten mit

geringerer Programmiererfahrung), während die routinierten Programmierer angaben,

eher XPairtise bei einfacherem Code benutzt zu haben, da sie schweren Code lieber

alleine bearbeiten, weil sie dafür mehr Zeit und daneben Ruhe benötigen. Tests und

Debugging wurden deshalb nicht angegeben, weil XPairtise hier technische Probleme

bereitete und nicht benutzt werden konnte.

Bei der Interviewbefragung wurden weiterhin Fragen zur Zufriedenheit der Kooperation

und Kommunikation innerhalb der Gruppe gestellt. Alle Studenten der ersten Gruppe

äußerten sich sehr positiv über ihre Gruppenmitglieder und den Umgang miteinander.


Die vorgenommenen Benotungen können der folgenden Übersicht entnommen wer-

den:

Tabelle 4: Übersicht Zufriedenheit Kooperation/Kommunikation

Diese Benotungen zeigen die gute Kommunikation und das gute Verständnis innerhalb

dieser Gruppe. Alle Meinungen zu Thematiken oder Problemen konnten von den Stu-

denten in der Gruppe frei angesprochen werden und vereinzelt aufgetretene Konflikte

wurden fair in der gesamten Gruppe diskutiert und auf diese Art und Weise versucht

auszuräumen, was auch immer gelang. Dadurch wird die neunte und zehnte Hypothe-

se bestätigt, dass DPP den Programmierern auch Spaß macht, wenn die sozialen Ein-

stellungen der Mitglieder in einer Gruppe gut untereinander harmonieren. Würde dies

nicht der Fall sein, besteht die Gefahr, dass es aufgrund von persönlichen Differenzen

zu Problemen in der Gruppe kommen könnte und damit die Arbeit an einem gemein-

samen Projekt erschwert werden würde.

Einen ganz interessanten Aspekt stellt die Frage nach dem Vertrauen in das Produkt

dar. Die konkrete Frage dazu lautete: Wie zufrieden bist du bzw. wie viel Vertrauen

hast du (Skala 0 bis 100 –> 0 = überhaupt nicht zufrieden, 100 = sehr zufrieden) mit/zu

eurem programmierten Produkt/Plugin? Die folgende Grafik zeigt die Ergebnisse:

75 % 75 %

99,9 %

30 %

90 %

0

10

20

30

40

50

60

70

80

90

100


Pro

zent

anga

be

Abbildung 30: Vertrauen in das entwickelte Produkt

Wie man der Abbildung entnehmen kann, liegt in 80 % der Antworten das Vertrauen in

einem Bereich größer oder gleich 75 % (im Durchschnitt bei 74,0 %). Die beiden „Aus-

reißer“ bei dieser Befragung sind durch die folgenden Aussagen der Studenten be-

gründet worden: Der Student Nr. 4 gab deshalb nur 30 % als Vertrauensangabe in das

Produkt an, weil seiner Meinung nach der Problemfaktor Zeit eine große Rolle in der

Kooperation in der Gruppe Kommunikation in der Gruppe Student 1 Gut Gut Student 2 Sehr gut Sehr gut Student 3 Sehr gut Sehr gut Student 4 Sehr gut Sehr gut Student 5 Sehr gut Sehr gut


Entwicklung des Plugins spielte. Demgemäß herrschten in der Gruppe Defizite bei der

Plugin-Entwicklung, vor allem in Zusammenhang mit GEF, so dass vieles aufgrund

Zeitmangels manuell und schnell und damit handwerklich nicht exakt sauber program-

miert werden musste. Da die Abgabefrist fest vorgegeben war, war es aufgrund des

Zeitdrucks nicht möglich, weitere Verbesserungen vorzunehmen. Allerdings machte

der Student aber auch deutlich, dass das Plugin seiner Meinung nach alles leistet, was

es leisten muss. Der dritte Student begründete seine Angabe in das Plugin mit 99,9 %

damit, dass er vollstes Vertrauen in die Gruppenmitglieder und in die gute Arbeit der

gesamten Gruppe hat. Insgesamt bestätigen diese Resultate die neunte Hypothese.

Alle Studenten gaben durchaus an, dass sie viele positive Faktoren bei der Anwen-

dung von DPP und bei der generellen Gruppenarbeit empfunden haben und bestätig-

ten die Hypothese weiter dahingehend, dass sie mehrheitlich angaben, ein recht hohes

Vertrauen in ihr entwickeltes Produkt zu besitzen. Dadurch, dass andere Projektteil-

nehmer an dem gleichen Projekt mitarbeiten und dieses ebenfalls kennen und testen,

fühlten sich die einzelnen Programmierer, auch auf die von ihnen zu verantwortenen

und entwickelten Produktbereiche, sicherer. Das folgende Zitat eines Studenten (1.

Student - Abbildung 30) bestätigt diese Aussagen, indem der Student darauf hinweist,

dass er zu einem von ihm entwickelten Programm, das er in seinem Grundstudium

alleine programmieren musste, nicht ein so hohes Vertrauen hatte wie jetzt in das ge-

meinschaftlich entwickelte Programm der Gruppe:

„Bei meinem Grundpraktikum, da mussten wir ja alleine arbeiten, da hatte ich

auch nicht so viel Vertrauen gehabt wie jetzt.“

Die zweitletzte Frage bezog sich auf die generelle Einstellung und Haltung der Studen-

ten gegenüber dem DPP. Es wurde bei den Antworten über die individuellen Erfahrun-

gen mit dem DPP berichtet. Dabei kristallisierten sich teilweise etwas unterschiedliche

Meinungen zwischen Studenten mit mehrjähriger Programmiererfahrung und den pro-

grammiertechnisch eher ungeübteren Studenten heraus. Zwei beispielhafte Zitate wer-

den dazu an dieser Stelle kurz angeben. Ein erfahrener Student erläuterte im Zusam-

menhang zur Effektivität von PP Folgendes:

„Es ist umso effektiver, umso besser die beiden auf dem gleichen Level sind,

denn dann klappt dieses Mitlesen und Fehlererkennen oder dies und jenes

und unterstützen ganz gut. Umso größer der Abstand der Sachen in dem Be-

reich ist, umso mehr ist es eigentlich eine Schulungsveranstaltung für den,

der es nicht so gut kann, als für den anderen eine gewinnbringende Einrich-

tung…(…)...das hast du bei uns ja auch gemerkt, bei bestimmten Leuten hast

du beim PP auch die Rollenwechsel gemacht, bei anderen Leuten, ach nee,

mach du mal und dann fragen die, das habe ich noch nicht ganz verstanden

und dann ging es so hin und her…“.

Die Antwort eines eher unerfahreneren Studenten lautete zu der gleichen Frage:


„Ich konnte viel lernen, weil ich ja live sehen konnte, wie Experten (wir hatten

Experten in unserer Gruppe), wie die Probleme programmiertechnisch umset-

zen, somit hat es mir sehr, sehr geholfen“.

Diese Aussagen bestätigen damit ganz konkret die erste, dritte und ebenso die neunte

Hypothese. Klassisches PP ist nur bei ungefähr gleich bewanderten Programmierern

möglich, weil diese ansonsten damit beschäftigt sind, anderen etwas zu zeigen oder

beizubringen. Allerdings machen die Aussagen auch deutlich, dass man viel voneinan-

der lernen kann, wenn sich beide Partner darauf einstellen und der erfahrenere Pro-

grammierer überdies gewillt und teilweise auch geduldig ist, dem unerfahreneren Part-

ner etwas beizubringen. Gerade durch PP oder DPP kann man viel voneinander profi-

tieren, da die Pairs durch Beobachtung der Verhaltensweisen bei der aktiven Pro-

grammierung und durch besondere angewandte Tricks und Kniffe, die in keinem Buch

stehen, viel voneinander lernen können. Es wurde von den Studenten aber auch er-

wähnt, dass die Gruppe und das Miteinander in der Gruppe eine große Rolle spielt. So

erläuterte ein Student:

„Ich glaube, wenn das Team nicht zusammen läuft, kannst du es (Anmerkung: DPP) vergessen, dann kannst du besser alleine programmieren. Ich glaube,

wenn das Team gut kommuniziert und zusammen läuft, dann ist die Gruppen-

arbeit besser. Dann wird das Produkt auch besser.“

Die letzte Frage im Interview lautete: „Wenn du wieder eine größere Programmierauf-

gabe bewältigen müsstest (z.B. im Rahmen des Studiums oder beruflich) und du dir

aussuchen könntest, ob du es im Rahmen von SP oder PP machen kannst, was wür-

dest du konkret wählen:

a) Pair Programming b) Solo Programming c) Weiß nicht“

Vier der fünf Studenten antworteten auf diese Frage, dass sie sich erneut für das PP

entscheiden würden, womit die positive Grundhaltung der Studenten der ersten Grup-

pegegenüber dem PP deutlich und damit wiederholt die neunte und zehnte Hypothese

bestätigt wird. Allerdings wurde ferner erwähnt, dass Einiges auf die Voraussetzungen

ankommt und es auch auf die Gruppe und das Verständnis untereinander ankommt.

Ein Student gab als Antwort „weiß nicht“ an. Als Begründung dafür nannte dieser das

Problem der zeitlichen Abstimmung mit dem Partner. Ferner erläuterte dieser Student,

dass er PP je nach Aufgabenstellung schon für sinnvoll ansieht, allerdings müssen

dazu die Rahmenbedingungen passen und im Vorfeld bekannt sein. Damit machen die

Studenten deutlich, dass es einige Risikofaktoren bezüglich der Team- oder Partnerzu-

sammensetzung beim PP oder DPP gibt, die die Effektivität und das erfolgreiche Ge-

lingen eines Projektes mittels PP beeinflussen können.

Kapitel 6 ● Diskussion der Ergebnisse 84

6 DISKUSSION DER ERGEBNISSE

In diesem Kapitel werden die Ergebnisse dieser Evaluation bzgl. der aufgestellten

Hypothesen zusammengefasst und im Anschluss mit anderen wissenschaftlichen Pub-

likationen verglichen.

Die im Rahmen dieser Diplomarbeit vorgenommene Evaluation ist eine Mischung aus

sowohl einer quantitativen als auch einer qualitativen Untersuchung einer Gruppenar-

beit bei der Bewältigung einer größeren Programmieraufgabe. Neben den quantitativen

Ergebnissen der protokollierten Logdaten und der Erhebung der CVS-Daten wurden

qualitative Aussagen aus den Interviewbefragungen, den Audioaufzeichnungen und

den Angaben der Selbst- bzw. Fremdeinschätzungsbefragungen gezogen. Es lassen

sich aus dieser Evaluation die folgenden Schlüsse zu den in Kapitel 3.2 aufgestellten

Hypothesen ziehen, die in der folgenden Übersicht dargestellt werden:

Hypo-thesen

Auswertungsergebnis Unter-

sucht in Kapitel

Bewer-tung

1. Hypo- these: Nutzer-verhalten

• Bei Sessions mit gleich erfahrenen Partnern kam es zu häufigeren Rollenwechseln und Aktivitäten untereinan-der als bei ungleichen Paarungen.

• Die Mitglieder der ersten Gruppe gaben an, viel wäh-rend der gemeinsamen Sessions gelernt zu haben.

5.2.1.2 5.5.3 5.6

Bestä-tigt

2. Hypo-these:

Anfänger-verhalten

• Speziell die Detailbetrachtungen der ersten Gruppe haben ergeben, dass sich gerade Programmieranfänger sehr passiv in den gemeinsamen Sessions verhalten haben und selten die Rollen gewechselt haben.

5.2.1.2 5.2.2 5.3

Bestä-tigt

3. Hypo-these: Wissens-transfer

• Die Studenten der ersten Gruppe gaben an, dass sie viel gelernt haben und auch erlerntes Wissens wieder aktiv an anderen Stellen einsetzen konnten.

• Die verschiedenen Paarungen und deren Verteilung in den stattgefundenen Sessions im Verlauf deuten darauf hin, dass durchaus ein Wissenstransfer auf Dritte mög-lich war, was sich allerdings faktisch nicht belegen lässt.

5.2.5.1 5.6

Bestä-tigt

4. Hypo-these: Pair Rotation

• Bestätigt werden kann die Hypothese dahingehend, dass es Paarungen gab, die häufiger als andere zu-sammengearbeitet haben.

• Bei vielen in XPairtise stattgefundenen Sessions kam es bei der ersten Gruppe zu Paarungen von einem Exper-ten mit einem Anfänger. Dabei fanden diese auch wie-derholt mit exakt der gleichen Paarung statt. Das zeigt, dass der erfahrenere Programmierer durchaus gewillt und geduldig war, dem Anfänger Wissen beizubringen und sich über die Schulter schauen zu lassen.

• Pair Rotationen haben nachweislich zumindest bei der ersten Gruppe stattgefunden.

5.2.5 5.2.5.1

5.5

Bestä-tigt

5. Hypo-these: Nutzung der Fea-tures in XPairtise

• Das Whiteboard wurde lediglich sehr selektiv und prak-tisch nur ein einzigstes Mal während einer klassischen Session genutzt, womit es bei den Studenten eine un-tergeordnete Rolle besaß.

• Aufgrund der häufig konstatierten Passivität der Naviga-toren ist die Markierfunktion von diesen seltener als vermutet zum Einsatz gekommen

• Der Textchat hatte gar keine Relevanz. • Bestätigt wurde die Hypothese dahingehend, dass die

Kommunikation per Audio stattfand.

5.2.1.3 5.2.2 5.6

Wider-legt


Hypo-thesen

Auswertungsergebnis Unter-

sucht in Kapitel

Bewer-tung

6. Hypo-these: Rollen-wechsel

• Allgemein hat die Evaluation ergeben, dass deutlich weniger Rollenwechsel als erwartet stattgefunden ha-ben.

• Bestätigt werden kann die Hypothese allerdings dahin-gehend, dass es besonders dann Rollenwechsel gab, wenn Programmierer mit dem gleichen Kenntnislevel zusammengearbeitet haben.

• 62,8 % aller Rollenwechselanfragen gingen vom Driver aus. Das Faktum ist allerdings kein signifikant nachhal-tiger Beweis für die Bestätigung der Teilhypothese da-hingehend, dass ein Rollenwechsel überwiegend vom Driver ausgeht.

5.2.1.2

Wider-legt

7. Hypo-these: Effekte beim DPP

• Wie die Interviewbefragungen ergaben, haben zumin-dest die Mitglieder der ersten Gruppe gerne DPP prakti-ziert. Dabei gaben sie an, dass es zu einer guten und konzentrierten Zusammenarbeit während der gemein-samen XPairtise-Sessions gekommen ist, die überwie-gend geplant waren und konsequent durchgezogen wurden.

• Größere Pausen oder unstrukturiertes Handeln sind nicht festzustellen gewesen.

5.2.4 5.6

Bestä-tigt

8. Hypo-these: Pausen

• Pausen haben wie im vermuteten Maße stattgefunden, wodurch die Hypothese bestätigt wird.

• Ein Bewusstsein für Pausen zur Erholung war bei den Studenten vorhanden.

• Teilweise wurde auch parallel ohne Pause(n) vom Navi-gator nach Problemlösungen recherchiert, während der Driver weiterprogrammierte.

5.2.4

Bestä-tigt

9. Hypo-these: Eigen-schaften des DPP

• Diese Hypothese kann durch diese Evaluation aufgrund des unterschiedlichen Agierens der zwei Gruppen nicht generell bestätigt werden: Die erste Gruppe hat diese Hypothese zwar weitgehend bestätigt, aber die zweite Gruppe zeigte Divergenzen im Gesamtprojektverlauf auf, die auf Abneigungen bzgl. einer geregelten Team-arbeit hindeuten. Während die erste Gruppe deutlich häufiger und auch überwiegend sehr gerne und zufrie-den DPP angewendet hat, hat das Verhalten der zwei-ten Gruppe ein anderes Bild aufgezeigt. Hier gab es Probleme in der Gruppe und es wurde im direkten Ver-gleich mit der ersten Gruppe weit weniger aktiv DPP praktiziert.

• Bzgl. des Teilaspekts nach der Frage des Vertrauens in ihre Arbeit hat sich diese Hypothese bei der ersten Gruppe jedoch bestätigt.

5.4.1 5.5.1 5.5.2 5.6

Wider-legt

10. Hypo-these: Gruppen-verhalten

• Die erste Gruppe, die organisatorisch disziplinierter strukturiert war als die zweite Gruppe, hat das Projekt, auch in Beziehung zu den Betreuern (Kunden), z. B. bei der Einhaltung der Meilensteine, konsequenter und stressfreier absolviert.

5.1 5.2

5.4.3 5.6

Bestä-tigt

Tabelle 5: Zusammenfassung Hypothesenanalyse


6.1 Vergleiche mit Studien zum Pair Programming

Viele Studien, vor allem im nordamerikanischen Raum und an amerikanischen Univer-

sitäten, handeln vom Vergleich zwischen PP bzw. DPP und SP. Auf einige Studien mit

diversen interessanten Aspekten wird in diesem Kapitel eingegangen, zudem werden

sie mit den Ergebnissen dieser Evaluation verglichen und diskutiert.

6.1.1 Zufriedenheit

Generell gibt es verschiedene Arten der Zufriedenheit beim PP, die Voraussetzung

dafür ist, dass die Programmierer gerne PP praktizieren. Die Autoren in dem Artikel

„Analyzing Pair-Programmer’s Satisfaction with the Method, the Result, and the Part-

ner“ unterscheiden dabei zwischen drei verschiedenen Arten. Einmal die organisatori-

sche Zufriedenheit mit der angewendeten Methode, zweitens die Zufriedenheit bezüg-

lich des Ergebnisses und der dazugehörigen Motivation und schließlich die soziale

Zufriedenheit mit dem Partner [PSSH04]. Gerade diese letzte angesprochene Zufrie-

denheit bezüglich des Partners ist einer der wichtigsten Aspekte beim PP, was auch

die Studenten dieser Evaluation in den Interviewbefragungen erörterten. Sind die Pro-

grammierer mit der Partnerzusammenstellung unzufrieden, können dadurch keine zu-

friedenstellenden und qualitativ hochwertigen Resultate in einem Projekt erzielt wer-

den. Die Interviewbefragung bei dieser Evaluation hat ergeben, dass vier der fünf Stu-

denten der ersten Gruppe sich wieder für das DPP entscheiden würden, wenn diese

sich zwischen SP und DPP entscheiden müssten. Lediglich ein Student gab die Ant-

wort „weiß nicht“ an, weil er es von den Rahmenbedingungen abhängig machen wür-

de. Die Antworten gleichen damit den Ergebnissen vorheriger Studien und Befragun-

gen zum PP. In einem Experiment von Brian Hanks [Han05] ging es um die Beantwor-

tung von vier Fragen, die sich auf das PP beziehen und eine Notenvergabe von 1 bis 7

ermöglichten. Hierbei gaben 50 % bis 66 % der Studenten die beiden bestmöglichen

Bewertungen (6 und 7) an. Infolgedessen kam Hanks zu dem Ergebnis, dass die Ein-

stellung der Studenten dem PP gegenüber eindeutig als positiv anzusehen ist.

Daneben bestätigt eine Studie, die an der Universität von Auckland (Neuseeland) mit

Studenten zum PP stattgefunden hat, diese Erkenntnisse. Für diese Studie konnten

Studenten im Rahmen eines Kurses zur Absolvierung von Aufgaben an der Universität

wählen, ob sie lieber alleine oder lieber in Paaren arbeiten. Die Studenten, die dabei im

Rahmen von PP zusammengearbeitet haben, zeigten eine positive Grundeinstellung

gegenüber dem PP. Ferner kommen die Autoren zu dem Ergebnis, dass die Studen-

ten, die PP genutzt haben, bessere Ergebnisse bei der Bewältigung der Aufgaben ge-

liefert haben. Weiterhin stellen sie fest, dass tendenziell eher schwächere Studenten

lieber in Paaren arbeiten als stärkere Studenten. Das liegt vermutlich daran, dass diese

hoffen, viel zu lernen und mehr Nutzen von kundigeren Studenten zu erhalten [NP03].


Daher ist es auch auffällig, dass die Studenten dieser Evaluation bei der Interviewbe-

fragung zur Einstellung zum DPP angegeben haben, dass es vielfach auf den genauen

Aufgabenbereich und auf die Rahmenbedingungen ankommt, ob sie lieber alleine oder

mit einem Partner programmieren. Ein Zitat von einem schon routinierten Studenten

dazu lautet beispielsweise:

„Es kam bei mir auf den Aufgabenbereich an, bei einer bestimmten Aufgabe

(Feature), was wir programmieren sollten, habe ich super gerne mit dem Part-

ner zusammengearbeitet. Da habe ich auch viel gelernt, das war auch sehr ef-

fektiv und bei anderen Funktionalitäten, da haben wir auch konkret zu Anfang

gesagt, dass mache ich alleine, das geht schneller und effektiver, das macht

mir dann auch mehr Spaß und dann bin ich auch schneller damit durch, des-

wegen kann ich generell nicht sagen, alleine ist besser oder im Pair ist es

besser“.

Als Fazit - auch in Bezug auf die aufgestellte neunte Hypothese - zeigt diese Evaluati-

on, dass DPP durchaus in der Praxis funktioniert. Allerdings weisen die unterschiedli-

chen Verhaltensweisen der beiden Gruppen darauf hin, dass DPP kein „Selbstläufer“

ist. Stimmen die Grundvoraussetzungen nicht mit den Vorstellungen der Anwender

überein oder existieren organisatorische oder daneben soziale Probleme untereinan-

der, sind PP-Projekte gefährdet oder u. U. auch nicht effektiv. Wichtig ist es, dass sich

die Teammitglieder, wie in der zehnten Hypothese angesprochen, gegenseitig vertrau-

en und sich am besten auch schon im Vorfeld näher kennen oder sich zudem bezüg-

lich ihrer vorhandenen Programmierkenntnisse näher kennen gelernt haben, damit

keine unerwarteten Überraschungen auftreten.

6.1.2 Vertrauen in das Ergebnis

Die Interviewbefragung zur Frage zum Vertrauen in das Ergebnis ihrer Arbeit hat bei

dieser Evaluation durchschnittlich ein hohes Maß an Vertrauen der Studenten in ihr

Produkt ergeben (siehe Kapitel 5.6). Dieses Resultat bestätigt damit Studien (wie

[Wil00] oder [Nos98]) zum PP, die zu dem Ergebnis kommen, dass Mitglieder aus

Gruppenarbeiten ein hohes Vertrauen (z. B. >= 75 % [Wil00]) in ihr Produkt haben, was

tendenziell höher ist als bei Programmierern, die vornehmlich alleine ein Produkt ent-

wickeln. Das liegt überwiegend an dem Aspekt, dass sich Pair Programmierer in ihrer

Arbeit sicherer und bestätigter fühlen. So kommt Laurie Williams zu dem Ergebnis,

dass 95 % der Programmierer angaben, mehr Vertrauen in ihre Entwicklungen zu ha-

ben, wenn sie mit Partnern zusammenarbeiten [Wil00]. Ferner bestätigt eine weitere

Studie zum Vergleich zwischen SP und PP, durchgeführt an der University of Califor-

nia-Santa Cruz, dieses Ergebnis. Es wurde eine Befragung bei Studenten zu dem Ver-

trauen in ihre Arbeit vorgenommen, bei dem eine Skala (wie bei dieser Evaluation) von

0 (= überhaupt kein Vertrauen) bis 100 (= sehr großes Vertrauen) zugrunde lag. Dabei


gaben die Studenten, die in Paaren zusammengearbeitet haben, ihr Vertrauen in ihre

Arbeit mit durchschnittlich 89,4 % an, während die Vergleichsgruppe der Studenten,

die alleine gearbeitet hat, ein Vertrauen in ihre Arbeitsergebnisse mit durchschnittlich

71,2 % angab [MWBF06]. Auch Brian F. Hanks nahm in einer Studie, beschrieben in

seiner Dissertation, eine Befragung mit der gleichen Einteilungsskala zu dem Vertrau-

en der Studenten in ihre Arbeit vor, die mit PP gearbeitet haben. Das Ergebnis von

durchschnittlich 87,4 % spricht für sich [Han05].

Der große Vorteil bei gemeinsamer Teamentwicklung eines Produktes ist, dass u. U.

mehrere kundige Programmierer durch eine aktive Mitarbeit an der Entwicklung des

Produktes beteiligt sind, diese obendrein permanent testen und infolgedessen direkt

Fehler feststellen und beheben können. Außerdem bekommt der einzelne Program-

mierer von den anderen Gruppenmitgliedern eine bessere und direktere Rückmeldung

über seine Arbeit und fühlt sich auf diese Weise sicherer. Damit hat sich bei dieser

Evaluation bei der ersten Gruppe die neunte Hypothese in Bezug auf das mehrheitlich

hohe vorhandene Vertrauen in ihr gemeinschaftlich entwickeltes Produkt bestätigt.

6.1.3 Paarzusammensetzung

Ein interessanter und überaus bedeutender Faktor ist die Zusammensetzung der Paa-

re beim PP. Soziale und zudem erfahrungstechnische Aspekte, wie z. B. Pro-

grammiererfahrung, Teamfähigkeit etc., müssen dabei berücksichtigt werden. Diese

Thematik wird in verschiedenen Studien zum PP behandelt. Einige Wissenschaftler

sind dabei der Meinung, dass besonders die Paare effektiv zusammenarbeiten, die

einen unterschiedlichen Programmierkenntnisstand besitzen. Demgemäß kommt z. B.

Jensen in dem Artikel „A Pair Programming Experience“ [Jen03] bei einem Versuch

zum PP zu dem Ergebnis, dass die meisten Probleme bei den Teams entstanden sind,

die einen ungefähr gleichen Kenntnisstand besaßen. Er stellte fest, dass bei den Paa-

ren, bei denen ein Programmierer etwas bessere Vorkenntnisse als der zweite besaß,

die Zusammenarbeit besser funktionierte. Andere Studien und auch die Resultate die-

ser Diplomarbeit deuten dagegen an, dass der Kenntnisabstand auch nicht zu groß

sein darf. Bei einem zu großen Expertenvorsprung wird der zweite Programmierer

schnell in die Rolle eines Navigators mit absoluter Passivität, d. h. in die Rolle eines

Zuschauers, gedrängt, der dem Driver nur noch über die Schulter (zu)schaut. Das ha-

ben auch die sehr geringe Anzahl von Rollenwechsel in dieser Evaluation gezeigt, vor

allem wenn ein Experte mit einem eher unerfahrenen Programmierer zusammengear-

beitet hat (siehe Kapitel 5.2.1.2). Es kommt dann zu keinem klassischen PP mit aktiven

Rollenwechseln etc., sondern eher, wie es auch ein Student in dieser Evaluation bei

der Interviewbefragung ausdrückte, zu einer „Schulungsveranstaltung“ für den Naviga-

tor. Dieses sind Belege zur Bestätigung der ersten und zweiten Hypothese. Daneben


geht auch ein Artikel [MM02], der sich mit einer Befragung von Studenten zu dieser

Thematik befasst, in diese Richtung. Es wird darin von den Studenten zum PP negativ

angemerkt, dass es bei Paarungen mit ungleichen Kenntnisständen zu einem höheren

Zeitaufwand kommt, weil der stärkere Partner viel Zeit mit zusätzlichen Erklärungen für

den schwächeren Partner aufbringen muss, was damit nicht sehr produktiv ist und ge-

rade bei knappen Zeitplänen Probleme verursacht. Außerdem wird die dadurch statt-

findende ungleiche Beteiligung beim Programmieren als ein Nachteil des PP angese-

hen. Das ist auch das Hauptergebnis, zu dem die Autoren in der Studie “On Un-

derstanding Compatibility of Student Pair Programmers” [KWW+04] kommen, nämlich

dass Studenten es bevorzugen, mit Partnern gleicher „technischer Kompetenz“ zu-

sammenzuarbeiten.

Eine weitere interessante Studie zum PP ist in dem Artikel „Code Warriors and Code-a-

Phobes: A Study in Attitude and Pair Programming“ [TRR03] beschrieben. Es handelt

sich dabei um Experimente mit Studenten zum PP. Studenten wurden dabei aufgrund

einer Vorabselbsteinschätzung über ihre Programmierkenntnisse in drei verschiedene

Gruppen (gute, mittelmäßige und eher unerfahrene Programmierer) eingeteilt. Dann

wurden Programmierexperimente mit diesen absolviert. Einmal wurden die Studenten

aufgrund der vorherigen Selbsteinschätzung in Paare mit ungefähr den gleichen

Kenntnisständen eingeteilt und ein anderes Mal in andere Paarungen mit unterschied-

lichen Programmierkenntnissen. Die Autoren sind dabei zu interessanten Erkenntnis-

sen gekommen. Zunächst stellten sie fest, dass die Studenten generell dem PP positiv

gegenüberstehen. Zudem bevorzugen die Studenten mit den geringeren Programmier-

kenntnissen PP am meisten und haben dieses als gutes Mittel bewertet. Ein weiteres

Ergebnis war, dass Paarungen am besten zusammenpassen bzw. die besten Resulta-

te erzielen, wenn diese ungefähr den gleichen Kenntnisstand besitzen. Dementspre-

chend zeigen die Untersuchungen daneben noch bei mehreren diversen Studien zum

PP (vgl. FWW02), dass der Erfolg von PP maßgeblich von der erfolgreichen Partner-

wahl abhängt. Verstehen sich die Partner zudem auch aus sozialen Gesichtspunkten,

dann wird PP gerne und häufig sehr erfolgreich eingesetzt.

Das zeigt sich auch in dieser Studie mit XPairtise, wo ein Mitglied der ersten Gruppe

ohne große Programmiererfahrung den größten Anteil an den XPairtise-Sitzungen hat-

te. Gerade dieser Student war sehr begeistert vom DPP, weil er viel lernen konnte,

indem die anderen Studenten es ihm ermöglichten, ihnen über die virtuelle Schulter zu

schauen und ihm dadurch viel zu erklären. Aus den Interviews wurde ferner deutlich,

dass die erfahreneren Programmierer angaben, dass sie häufig dann effektive DPP-

Sessions hatten, wenn sie mit gleich starken Partnern zusammengearbeitet haben.

Es bleibt noch anzumerken, dass nicht alle Studien von Williams ausschließlich posi-

tive Schlussfolgerungen zum PP geliefert haben. Wird sich nicht an abgesprochene


und abgestimmte Grundsätze mit festen Regeln untereinander gehalten, funktioniert

das PP gerade auch in Hinblick auf eine gute Kommunikation nicht problemlos. Eine

Sammlung von Verhaltenskonventionen wie z. B. „Share everthing“, „Play fair“ etc. für

das erfolgreiche Durchführen von PP haben Williams und Kessler in dem Artikel „All I

Really Need to Know about Pair-Programming I Learned in Kindergarten“ [WK00] zu-

sammengefasst.

Neben der generellen Partnerwahl sind auch Pair Rotationen ein wichtiger Faktor beim

PP. In dem Artikel “On Pair Rotation in the Computer Science Course” haben die Auto-

ren Diskussionsergebnisse einer Befragung von Studenten zusammengefasst. Stu-

denten von der North Carolina State University wurden nach der Absolvierung eines

Kurses, in welchem diese auch PP angewendet hatten, über die Vor- und Nachteile

von Pair Rotationen befragt. Die Studenten sahen es als deutlichen Vorteil des PP an,

dass sie viel von den wechselnden Partnern bei Pair Rotationen lernen konnten. Fer-

ner wurde es als positiv empfunden, dass man Partner wechseln kann, wenn man mit

diesen nicht klar kommt. Als Nachteil wurde dagegen dargestellt, dass Pair Rotationen

auch ineffektiv sein können, wenn man sich immer wieder auf neue Partner einstellen

muss. Außerdem kann man durch Pair Rotationen auch gute Partner verlieren, mit

denen man förderlich zusammengearbeitet hat, und schließlich dann evtl. wieder

schlechtere Partner bekommen [SWW+04].

Im Rahmen des Fachpraktikums war es den Studenten frei gestellt, mit wem und ob

sie zusammen arbeiten oder nicht. Es wurde ihnen aber von den Betreuern empfohlen,

möglichst viel Quellcode mittels DPP zu entwickeln, wovon zumindest die erste Gruppe

Gebrauch gemacht hat, genauso wie von häufigeren Partnerwechsel. Es ist aber

durchaus, wie es auch in der vierten Hypothese behauptet wurde, zu bevorzugten Paa-

rungen gekommen. Generell waren die Gruppenmitglieder damit sehr zufrieden.

6.1.4 Rollenwechsel

Die Rollenverteilung und der Rollenwechsel ist in der Fachliteratur zum PP ein weit

verbreitetes Diskussionsthema. Es wird häufig darüber diskutiert, inwieweit die klassi-

schen Rollenverteilungen mit Driver und Navigator in der Praxis umgesetzt werden.

Zum Thema Rollenwechsel schreibt Kent Beck beispielsweise: “Just watching some-

one program is about as interesting as watching grass die in a desert. Pair program-

ming is a dialog between two people trying to simultaneously program (and analyze

and design and test) and understand together how to program better.” [Bec99]. Er ist

der Ansicht, dass Rollen in regelmäßigen Intervallen gewechselt werden sollen, auch

wenn ein Partner programmiertechnisch eher ungeübter ist als der andere. In dem Arti-

kel „Paired Programming & Personality Traits“ [DZ02] berichten die beiden Autoren

über ihre Erfahrungen mit PP. In einem Versuch beobachteten sie Teams aus erfahre-


nen (mehr als zwei Jahre Entwicklungserfahrung) und unerfahreneren Entwicklern. Ein

Problem, welches sie bei der Beobachtung festgestellt haben, ist, dass ein dynami-

scher Wechsel zwischen Driver und Navigator in der Praxis nicht stattfand. Das spie-

geln in Ansätzen ebenfalls die Ergebnisse dieser Diplomarbeit wider und bestätigen

damit nicht die sechste aufgestellte Hypothese dahingehend, dass in regelmäßigen

Intervallen die Rollen gewechselt werden. Im Artikel “Pair Programming in an Introduc-

tory Computer Science Course: Initial Results and Recommendations”, der ein Experi-

ment zum PP an der North Carolina State University beschreibt, stellen die Autoren

fest, dass mit wenigen Ausnahmen Rollenwechsel sehr selten und ungern durchgeführt

wurden. Einige Studenten blieben daher teilweise immer in der gleichen Rolle während

einer gesamten Session [WYW+02]. In dem Artikel „Paired Programming Project: Fo-

cus Groups with Teaching Assistants and Students”, welcher Ergebnisse zu Studen-

tenbefragungen zusammenfasst, stellen mehrere Studenten fest, dass ein Rollen-

wechsel ca. alle 20 Minuten nicht unbedingt praktikabel und sinnvoll ist und damit des-

wegen in der Praxis nicht unbedingt stattgefunden hat [FWW02].

Über die eigentliche Aufgabe und Funktion des Navigators kommen die Autoren des

Artikels „Pair Programming and the Mysterious Role of the Navigator” [BRB07], der

vorgenommene Experimente in verschiedenen Unternehmen zur Paar- und Rollenver-

teilung beschreibt, u. a. zu dem Fazit, dass sich der Navigator auf der gleichen Ab-

straktionsebene wie der Driver befindet und beide zusammen die direkten Probleme

besprechen, z. B. aktuelle Fehlerbehandlung bzw. den Code. Nach ihren Erkenntnis-

sen besitzt der Navigator nicht, wie es andere Studien behaupten, die Rolle eines Art

Vordenkers, der strategisch vorausdenkt. Die Autoren untersuchten zwei mögliche Rol-

len bzw. Aufgaben eines Navigators. Dabei unterscheiden sie zum Einen zwischen

einem „navigator as reviewer“, also einem Navigator, der überwiegend den aktuellen

Code des Drivers überprüft und ggf. auf Fehler hinweist, und zum Anderen einem „na-

vigator as foreman“, also einem Navigator, der mehr als Vordenker und Stratege agiert.

Allgemein hat diese Evaluation ergeben, dass wiederholte dynamische Rollenwechsel

aufgrund verschiedener Ursachen nicht stattgefunden haben. Ein Grund ist, dass bei

dieser Evaluation häufig eher unerfahrenere Programmierer in der eingenommenen

Rolle eines Navigators mit sehr routinierten Programmierern zusammengearbeitet ha-

ben, die in vielen Sessions permanent als Driver tätig waren. Dabei waren die Naviga-

toren in einer sehr passiven „Zuschauerrolle“ und konnten den Drivern auch keine gro-

ßen Tipps oder Hinweise für die direkte Programmierung geben. Allerdings gab es ge-

rade besonders dann Rollenwechsel, wenn Programmierer mit dem gleichen Kenntnis-

level zusammengearbeitet haben. Hier zeigte es sich, dass gerade auch die bewander-

ten Programmierer voneinander profitieren konnten und diese gemeinsamen Sessions

ihnen viel Spaß gemacht haben. Damit wird die sechste Hypothese nicht fühlbar bestä-


tigt, weil es auf die Programmiererfahrungen der Programmierer bei dieser Evaluation

ankam.

6.1.5 Anfertigung von Tests

Wie schon die Abbildung Nr. 1 in Kapitel 2.1 deutlich macht, spielen Tests eine wichti-

ge Rolle bei klassischem XP. Da das klassische XP im Vorfeld keine ausführliche Pro-

duktspezifikation vorsieht, sollten die gewünschten Funktionen des Programmes in

Testfällen untergliedert und dokumentiert sein und der Kunde sollte einzelne Testfälle

auswählen, die von den Programmierern umgesetzt werden sollten. Sowohl die CVS-

Check-Ins beider Gruppen als auch die mit den Studenten der ersten Gruppe durchge-

führten Interviews belegen, dass der Test-First-Ansatz beim PP im Rahmen des Prak-

tikums nicht konsequent eingehalten wurde, obwohl dazu explizit in der Aufgabenstel-

lung hingewiesen wurde und ferner die Betreuer es empfohlen haben, Testcases zu

verfassen. Eine Konsequenz, die daraus gezogen werden könnte, ist, Test-Cases ver-

pflichtend in einem Fachpraktikum von Betreuerseite her zu verlangen und die Einhal-

tung auch regelmäßig zu überprüfen, wenn der XP-Ansatz konsequent angewendet

werden soll. Bei der ersten Gruppe wurden anfangs noch einige Tests geschrieben,

allerdings später gegen Ende des Praktikums praktisch gar keine mehr. Die CVS-

Auswertung der ersten Gruppe hat ergeben, dass insgesamt immerhin 52 Java-

Testklassen (z. B. auch JUnit-Klassen) angelegt wurden. Bei der zweiten Gruppe wa-

ren es gemäß der CVS-Auswertung 45 Testklassen. Damit ist kein großer Unterschied

zwischen beiden Gruppen feststellbar. Ein Zitat von einem Student zum Thema Tests

während des Interviews lautete:

„Am Anfang haben wir viel mehr Tests geschrieben, aber so mehr wir zum

Ende kommen und sehen, dass wir uns damit beschäftigen müssen, Funktio-

nalitäten zu haben anstatt Tests, ist es eher weniger geworden.“

Andere Studien bestätigen dieses Phänomen ebenfalls. Beispielsweise kamen die Au-

toren Melnik und Maurer in einer Studentenbefragung [MM02] zu dem gleichen Resul-

tat, dass unter großem Zeitmangel bzw. Zeitdruck im Hinblick auf einen Abgabetermin

die Tests praktisch eingestellt wurden. Da von den Betreuern in der Rolle des XP-

Kundens während dieses Praktikums kein Druck auf die konkrete Einhaltung des XP-

Ansatzes auf die Gruppen ausgeübt wurde und die Betreuer auch nicht explizit Testfäl-

le aufgestellt oder angefordert haben, sahen die Studenten keinen eindeutigen Mehr-

wert bei der konsequenten Anfertigung von Tests und diese wurden damit nicht stetig,

sondern nur vereinzelt vorgenommen.


6.2 Vergleiche mit Studien zum Distributed Pair Programming

Gerade bei Untersuchungen zum DPP steht insbesondere ein Hauptaugenmerk auf

der technischen Unterstützung und der diversen möglichen Werkzeuge im Fokus, um

möglichst keine großen Nachteile zum PP aufgrund der mit der räumlichen Trennung

verbundenen schwierigeren Zusammenarbeit und Kommunikation entstehen zu lassen.

In dem folgenden Abschnitt werden Erfahrungen aus Studien zum DPP vorgestellt und

auch mit den Ergebnissen dieser Evaluation verglichen.

6.2.1 Arbeiten mit Distributed Pair Programming

In dem im Jahre 2002 erschienenen Artikel „Distributed Pair Programming: Empirical

Studies and Supporting Enviroments“ [BWG+02] beschreiben die Autoren einen Ver-

such zum DPP. Das Hauptaugenmerk dieser Untersuchung lag auf der Verdeutlichung,

dass Programmierer, die gemeinsam, aber räumlich getrennt an einem Projekt arbei-

ten, bessere Erfolge erzielen, wenn diese synchron zusammenarbeiten. Unter ande-

rem lautete eine für den Versuch formulierte Hypothese, dass Teams, die synchron

zusammenarbeiten, eine bessere Verständigung haben und dadurch ein besseres

Teamwork zustande kommt als bei den Teams, die nicht synchron zusammenarbeiten.

Für den Versuch wurden im Herbst 2001 an der North Carolina State University in ei-

nem fünfwöchigen Projekt 132 Studenten in Gruppen aufgeteilt. Es gab neun Gruppen,

die gemeinschaftlich an einem Projekt arbeiteten, wobei aber die Arbeit auf die einzel-

nen Mitglieder aufgeteilt, von diesen eigenständig erledigt und am Ende in einer ge-

meinschaftlichen Phase zusammengefügt wurde. Dann gab es 16 Gruppen, bei denen

die Aufgaben auf Paare in den Gruppen verteilt wurden, wobei auch PP zum Einsatz

kam. Weiterhin gab es acht Gruppen, bei denen die Mitglieder ohne Paarbildung von

verschiedenen Orten aus alleine arbeiteten und am Ende die verschiedenen Ergebnis-

se in einer gemeinschaftlichen Phase zusammengefügt wurden. Schließlich gab es

fünf weitere Gruppen, die zusammen in Paaren über das Internet mit Benutzung von

Application Sharing Programmen zusammenarbeiteten. Eine Erkenntnis, zu der die

Autoren dabei gekommen sind, ist, dass die verteilt arbeiteten Teams verglichen mit

den Teams, die gemeinschaftlich an einem Ort arbeiteten, eine etwas bessere Produk-

tivität aufwiesen. Weiterhin waren fünf von sechs Studenten aus den DPP-Teams der

Meinung, dass die technischen Mittel kein großes Hindernis für gemeinschaftliche Pro-

grammierung waren. In den Schlussfolgerungen kommen die Autoren des Artikels zu

der Feststellung, dass Softwareentwicklung mit DPP im Hinblick auf Produktivität und

Qualität vergleichbar mit PP zu sein scheint. Außerdem zeige das Feedback von den

Studenten, dass DPP die Teamarbeit und Kommunikation innerhalb einer örtlich ge-

trennt arbeitenden Gruppe fördert.


Die Untersuchung der beiden Gruppen im Rahmen dieser Diplomarbeit gibt dahinge-

hend Indizien, dass die Gruppe, die von Anfang an mehr DPP-Phasen hatte und unter-

einander kommunikationstechnisch strukturierter organisiert war, bessere Erfolge im

Hinblick auf die Erreichung der Meilensteine und der Einhaltung des Abgabetermins

erzielt hat als die zweite Gruppe, bei denen die Aufgaben im größeren Rahmen mittels

SP erledigt wurden. Das ist damit eine Bestätigung der zehnten Hypothese.

In 2003 wurde an der University of California ein Experiment mit Studenten zum DPP

vorgenommen. Die Ergebnisse daraus wurden von Hanks in dem Artikel „Distributed

Pair Programming: An Empirical Study“ [Han04] veröffentlicht. Bei dem Versuch wur-

den 76 Studenten in verschiedene Gruppen eingeteilt, wobei diese abermals unterteilt

wurden. Zum Einen gab es Gruppen, die mit einem Tool arbeiten sollten, das DPP un-

terstützt, und zum Anderen existierten Vergleichsgruppen, die mit klassischem PP ar-

beiteten, ohne dass eine räumliche Trennung vorlag. In einer Umfrage wurden diese

Studenten nach ihrem eigenen Vertrauen in die programmierten Aufgaben befragt. Als

Ergebnis stellte Hanks fest, dass sowohl die Studenten, welche in den Gruppen mit

dem DPP eingeteilt waren und das Unterstützungstool benutzt haben als auch die üb-

rigen Studenten das ungefähr gleiche Vertrauen in die programmierte Aufgabe hatten

[Han04]. Dieses zeigt, dass DPP in Hinsicht zum Vertrauen mit dem PP durchaus ver-

gleichbar ist und das Vertrauen generell, wie bei den Studenten dieser Evaluation,

recht hoch ist.

Der Artikel “Virtual Teaming: Experiments and Experiences with Distributed Pair Pro-

gramming“ [SWN+03] beschreibt zwei Experimente an Universitäten zum DPP. Die

Autoren kommen darin zu der Schlussfolgerung, dass sich DPP anbietet, Software zu

entwickeln. Das zeigte ebenfalls die Evaluation im Rahmen dieser Diplomarbeit. Trotz

(teilweise technischer) Hindernisse wurde Quellcode im Rahmen von DPP-Sessions

erstellt. Die Autoren kommen ferner zu dem Ergebnis, dass kooperative Softwareent-

wicklung durchaus effektiv mit ein paar einfachen technischen Hilfsmitteln wie Monitor

Sharing und einer internetbasierten Audio-Kommunikation möglich ist. Dazu bleibt im

Rahmen dieser Evaluation aber anzumerken, dass eine gute technische und stabile

Unterstützung noch weiter dazu beiträgt, dass DPP-Sessions effektiver, häufiger und

von den Anwendern lieber vorgenommen werden.

In dem Artikel „How Distribution Affects the Success of Pair Programming“ [CCL+06]

wird von einer Versuchsreihe an der Universität von Sannio in Italien und einer Ver-

gleichsstudie dazu an der Universität von Neapel berichtet. Dort nahmen 16 Studenten,

aufgeteilt in Paaren, an dem Experiment teil. Untersucht und verglichen wurden Paare,

die gemeinschaftlich Aufgaben lösen sollten. Dabei gab es Gruppen, die PP, und Ver-

gleichsgruppen, die DPP praktizierten. Das erste Experiment in dieser Versuchsreihe

deutet darauf hin, dass ohne eine ausreichende Unterstützung in Bezug auf Kommuni-


kation und Zusammenarbeit die Paare zum Scheitern neigen, was ein teurer Risikofak-

tor in PP-Projekten sein kann. Allerdings zeigte es außerdem, dass das beste DPP

Paar ein bisschen weniger Zeit benötigte als das beste PP praktizierende Paar. In den

Schlussfolgerungen kommen die Autoren zu dem Fazit, dass die Voraussetzung einer

optimalen technischen Unterstützung für die Kommunikation für das erfolgreiche Ge-

lingen eines Projektes beim DPP gegeben sein muss. Weiterhin wird konstatiert, dass

es keine empirischen Belege dafür gibt, dass der allgemeine Arbeitsaufwand und Ab-

stimmungsbedarf beim DPP höher als beim PP ist.

In „Empirical Evaluation of Collaborative Support for Distributed Pair Programming“

[FNP+04] wird ein DPP-Experiment mit dem Programm COPPER, welches DPP unter-

stützt, beschrieben (siehe auch Kapitel 2.3). In dem Versuch wurden 12 Studenten,

aufgeteilt in sechs Paarungen, untersucht. Dabei mussten die Paare Aufgaben lösen,

wobei diese sowohl gemeinschaftlich örtlich zusammenarbeiteten als auch räumlich

getrennt mit NetMeeting und mit dem Programm COPPER. Ein Ergebnis der Studie

war es, dass beim DPP genauso viele Fehler erkannt wurden wie beim PP. Eine weite-

re Hypothese des Artikels konnte dagegen nicht bestätigt werden, denn mit dem Pro-

gramm COPPER wird keine bessere generelle Verständlichkeit erzielt als mit einem

normalen Application Sharing Programm wie NetMeeting.

Als Fazit zu diesen Studien zum Vergleich zwischen PP und DPP und den gewonne-

nen Erfahrungen und Erkenntnissen aus der Evaluation von DPP mit XPairtise bleibt

anzumerken, dass DPP praktikabel und zur Entwicklung von Software geeignet ist.

Allerdings müssen möglichst optimal funktionierende technische Unterstützungstools

für das DPP vorhanden sein. Somit lässt sich die neunte aufgestellte Hypothese mit

den Eigenschaften zum DPP nicht für beide Gruppen einheitlich bestätigen oder be-

antworten. Nach den gemachten Erfahrungen mit dem Fachpraktikum sind die positi-

ven Eigenschaften der aufgestellten Hypothesen durchaus bei der ersten Gruppe wie-

der zu finden, während bei der zweiten Gruppe schon deutliche Einschränkungen vor-

handen sind, was anhand des aktiven Einsatzes der Tools und anhand des Verlaufs

des Fachpraktikums feststellbar ist.

6.2.2 Whiteboard

In diesem Abschnitt soll auf ein spezielles Feature, das in XPairtise implementierte

Whiteboard, explizit eingegangen werden. Daneben kommt es zu einem Vergleich mit

anderen Studien. In dem Artikel „Support for Distributed Pair Programming in the

Transparent Video Facetop“ [SSG04] wird ein Experiment zum DPP beschrieben, wel-

ches untersucht, ob DPP ebenso effektiv ist wie PP. Dazu gab es einen Versuchsauf-

bau mit einer video-basierten Benutzeroberfläche namens „Facetop“. Dieses System

erlaubt es, dass sich die Programmierer jeweils über den Monitor transparent im Hin-


tergrund sehen. Die Programmierer haben dann mittels eines Application Sharing Pro-

gramms und eines weiteren Programms zur Sprach- und Textchatverständigung in

dem Versuch zusammen als Paar gearbeitet. Die Autoren kommen bei dem Experi-

ment zu dem Ergebnis, dass die Programmierer mittels dieses eingesetzten Systems

genauso effektiv zusammengearbeitet haben als wenn sie nebeneinander gesessen

hätten. Ein weiteres Ergebnis dieses Versuches war es, dass sich die Programmierer

ein Whiteboard zur besseren Unterstützung des DPP wünschten. In dem Artikel „Virtu-

al Teaming: Experiments and Experiences with Distributed Pair Programming“

[SWN+03] kommen die Autoren u. a. zu der Schlussfolgerung, dass ein Whiteboard bei

der Benutzung von DPP sehr hilfreich ist. Ferner zeigen weitere Studien (z. B.

[BRB06]) die Nützlichkeit eines Whiteboards auf. Frühere Studien und Befragungen

haben ergeben, dass ein Whiteboard gerade zur Veranschaulichung sehr nützlich ist.

Im Rahmen der Diplomarbeit „Entwicklung einer Eclipse-Erweiterung zur Realisierung

und Protokollierung verteilter Paarprogramming“ von Riad Djemili aus dem Jahre 2006

[Dje06] wurde eine Umfrage u. a. bei verschiedenen Internetgemeinschaften vorge-

nommen, bei der 44 Personen teilnahmen. Es wurden verschiedene Fragen im Zu-

sammenhang mit DPP gestellt. Eine Frage lautete, welche Anforderungen die Teil-

nehmer an ein optimales Werkzeug stellen würden. 11 % der Teilnehmer beantworte-

ten die Frage nach der Funktionalität eines Whiteboards mit der Wichtigkeit „Unneces-

sary“, 45 % bewerteten es mit „Nice to have“, 27 % Prozent bewerteten die Funktionali-

tät immerhin mit „Important“ und 9 % sogar mit „Essential“. 7 % der Befragten gaben

dazu keine Angaben an.

Die Evaluation im Rahmen dieser Diplomarbeit hat dagegen ergeben, dass das vor-

handene Whiteboard in XPairtise neben drei Sessions, bei denen ausschließlich das

Whiteboard zum Einsatz kam, praktisch nur in einer Session als zusätzliches Erklä-

rungsmedium benutzt wurde und damit die fünfte aufgestellte Hypothese nicht bestätigt

wurde. Das Whiteboard besaß bei den Studenten eher eine geringere Priorität. Aller-

dings gaben die Studenten der ersten Gruppe bei der Interviewbefragung das White-

board durchaus als gern benutztes Feature mit an. Festzuhalten bleibt die Erkenntnis,

dass ein Whiteboard für bestimmte Aufgaben- und Problemdiskussionen im Rahmen

von DPP-Sitzungen durchaus sinnvoll erscheint und in einem Tool zum DPP nicht feh-

len sollte, um auch die allgemeine Akzeptanz nicht zu schmälern. Es ist wahrscheinlich

im allgemeinen Kontext als ein „Nice to have“-Feature anzusehen.

Kapitel 7 ● Fazit und Ausblick 97

7 FAZIT UND AUSBLICK

Die im Rahmen dieser Diplomarbeit durchgeführte Evaluation hat ergeben, dass sich

die aufgestellten Hypothesen größtenteils bestätigt haben. DPP stellt eine praktikable

und gute Methode zur Softwareentwicklung dar, sofern es richtig eingesetzt wird. Auf

dieser Basis lassen sich unter der Prämisse von stimmigen Rahmenbedingungen viele

Synergie-Effekte erzielen. Da die Grundlage dieser Beobachtungen nur zwei Gruppen

mit insgesamt elf Studenten im Rahmen eines Fachpraktikums umfasste, lassen sich

die gewonnenen Resultate nicht aussagekräftig auf allgemeines Gruppenverhalten

generalisieren. Allerdings sind die erlangten Einzelergebnisse und Verhaltensweisen

der Studenten durchaus interessant und zeigen einige wichtige Erkenntnisse bei der

aktiven Anwendung des DPP auf. Die Ergebnisse decken sich zudem mit Erkenntnis-

sen aus der einschlägigen Literatur.

Die Aussagen der Studenten am Rande der Interviewbefragungen und auch der Au-

diomitschnitte bzgl. der aktiven Benutzung von XPairtise während dieser Evaluation

ergaben, dass noch technische Probleme in XPairtise bzgl. der Zuverlässigkeit existie-

ren und dass XPairtise auch noch in Hinblick auf die Stabilität bei der Ausführung um-

fangreicher Programme verbessert werden kann. Ohne diese Probleme hätten wahr-

scheinlich noch mehr gemeinsame DPP-Sessions stattgefunden. Ferner bestätigten

auch die Studenten in den Interviews, dass Features wie gemeinsames Debugging

sowie Testausführungen wichtig für DPP-Programme sind. Eine dahingehende Unter-

stützung wäre bei einer evtl. Weiterentwicklung von XPairtise eine bedeutungsvolle

Funktionsvariante, da DPP gerade für derartige Einsätze eine optimale und interessan-

te Entwicklungsmethode ist. Daneben wäre ein direkt in XPairtise integrierter Audiochat

sinnvoll, um nicht mehrere Programme parallel nutzen zu müssen. Die Evaluation hat

ergeben, dass der Textchat in XPairtise keine Relevanz hatte und die Kommunikation

in den Sessions per Audiokommunikation erfolgte.

► Fazit: Die Technik (Tools zur Zusammenarbeit und Kommunikation) muss beim

DPP uneingeschränkt zuverlässig funktionieren.

Die sozialen Aspekte sowie eine gute Kommunikation untereinander sind bei Paaren

mindestens genauso konstitutiv wie die Notwendigkeit von guten Vor- bzw. Program-

mierkenntnissen. Diese Aspekte entscheiden über Erfolg oder Misserfolg. Die vorlie-

genden Ergebnisse zeigen, dass bei dem Praktikum im Prinzip alle Studenten gut zu-

sammengearbeitet haben. Allerdings arbeiten routinierte Entwickler lieber mit gleich-

wertig erfahrenen Programmierern zusammen. Bei diesen kongenialen Partnern exis-

tiert ein überaus bedeutungsvoller Lern- aber auch Spaßfaktor. Ansonsten lernen zwar

gerade auch ungeübte Programmierer viel während einer DPP-Session, allerdings ent-


sprechen diese Sessions nicht dem klassischen DPP-Konzept und es besteht die Ge-

fahr, dass die versierteren Programmierer schneller den Spaß am DPP verlieren, weil

ihnen nur über die Schultern geschaut wird und sie keinen eigenen Nutzen für sich aus

dem DPP ziehen können. Aber auf Folgendes sollte man die Experten explizit im Vor-

feld hinweisen: Es ist auch gerade bei langfristig angelegten Projekten aus didaktischer

Sicht wichtig sowie sinnvoll, dass die eher unerfahreneren Programmierer viel von den

Experten lernen. Dadurch werden bei allen Teilnehmern Kompetenzen aufgebaut, da-

mit sich möglichst viele Projektmitglieder im Gesamtkontext des Projektes und in dem

Quellcode des zu entwickelnden Programmes auskennen, wodurch schließlich auch

die Experten mittel- bis langfristig wieder profitieren können. Man muss den Program-

mierern verdeutlichen, dass ein guter Wissenstransfer untereinander nützlich ist, um

sich gegenseitig bei Problemen helfen zu können, sich in Stresssituationen durch Ar-

beitsaufteilungen oder ggf. Neueinteilungen zu entlasten oder auch um evtl. auf

(krankheitsbedingte) Ausfälle vorbereitet zu sein.

► Fazit: Die Weitergabe von Kenntnissen ist sowohl für einzelne Programmierer

sehr bedeutsam als auch für das gesamte Projekt von großem Vorteil. Außer-

dem zählt neben dem persönlichen Lernzuwachs und Erfolg vor allem das Ge-

samtziel.

Wenn bezüglich der Programmierkenntnisse ungleiche Paarungen (D)PP praktizieren,

sollten die Programmiererfahrungen den jeweiligen Partnern im Vorfeld bekannt sein.

Sofern der erfahrenere Programmierer gewillt ist und genügend Geduld besitzt, eine

Mentorrolle einzunehmen, können die unerfahreneren Programmierer in der Rolle des

Navigators sehr schnell äußerst viel lernen. Paarungen mit Programmierneulingen soll-

ten dagegen allerdings vermieden werden. Gewisse Grundkenntnisse sollten bei Pro-

grammierern bei der Anwendung von DPP vorhanden sein und von den Kunden (Be-

treuern) verlangt oder auch ggf. im Vorfeld überprüft werden. Eine Möglichkeit, Pro-

grammieranfänger erfolgreich in erfahrenere Gruppen zu integrieren, ist es, dass diese

anfangs in der Rolle eines Gastes DPP-Sessions mit einem Driver und Navigator bei-

wohnen und so die Gelegenheit haben, von erfahreneren Programmierern zu lernen,

ohne dass diese bei ihrer eigentlichen Arbeit sehr beeinträchtigt werden.

Es ist aber darüber hinaus auch generell von Vorteil, unabhängig vom Wissen der

Kenntnisstände untereinander, wenn sich die Projektmitglieder schon vor dem Start

eines DPP-Projektes kennen gelernt haben und sich damit auch aus sozialen Ge-

sichtspunkten besser beurteilen können. Ein Verbesserungsvorschlag für zukünftige

Fachpraktika oder generelle räumlich verteilt geplante Gruppenarbeiten könnte es sein,

dass den Teilnehmern schon etwas früher vor einer evtl. Präsenzphase die Möglichkeit

gegeben wird, sich etwas besser untereinander kennen zu lernen. Auch hier ist eine


gute Planung und Organisation wichtig. Ein erstes Kennenlernen könnte man bei-

spielsweise durch die Bereitstellung eines Audio-Chatraumes bewerkstelligen, in dem

freiwillig schon erste Probleme oder die Aufgabenstellung untereinander diskutiert wer-

den könnten oder sich einfach nur unterhalten und ausgetauscht werden kann. Mit ei-

ner gewissen Vorlaufzeit und solchen möglichen Audiokonferenzen, die auch in Unter-

nehmen vorstellbar sind, kann der einzelne Teilnehmer schon gut einige Reaktionen

und Verhaltensweisen der anderen Programmierer erkennen und beurteilen, welche(r)

mögliche(n) Partner für gemeinsame Projekte vorstellbar (ist) sind. Verpflichtende An-

weisungen von Seiten der Kunden (Betreuer) zu Paarbildungen oder zu Pair Rotatio-

nen sind dagegen beim DPP zu vermeiden, es sei denn, es kommt zu überhaupt kei-

nen Pair Rotationen, weil das persönliche Empfinden eines Programmierers eine be-

deutende Rolle für seine Motivation und damit für eine effektive Absolvierung der Auf-

gabe spielt.

► Fazit: Aufgrund der Notwendigkeit von hohen sozialen Kompetenzen der Pro-

grammierer wird der Einsatz von DPP nur dann effektiv und reibungslos verlau-

fen, wenn die Paare sich auf sozialer Ebene verstehen sowie sich generell res-

pektieren und vertrauen. Ansonsten könnte es zum Scheitern und Abbruch des

DPP kommen.

► Fazit: Im Vorfeld eines umfangreicheren Projektes, das per DPP durchgeführt

werden soll, ist es ratsam, den Projektmitgliedern die Gelegenheit zu geben,

sich kennen zu lernen.

Die Evaluation hat ferner gezeigt, dass die erste Gruppe intensiver und konsequenter

die verschiedenen zur Verfügung stehenden kollaborativen Tools zur Zusammenarbeit

wie XPairtise oder CURE eingesetzt hat und dass es bei ihr außerdem zu einem bes-

seren Austausch untereinander in der Gruppe, auch durch Pair Rotationen, gekommen

ist. Die erste Gruppe ist somit deutlich schneller und stressfreier zum Ziel gelangt als

die zweite Gruppe, die diese Tools und die Möglichkeiten des Austausches nicht eben-

so konsequent genutzt hat.

► Fazit: Eine kontinuierliche Kommunikation und eine gute Organisation innerhalb

einer Gruppe sind beim DPP sehr wichtig.

Ein weiterer Faktor, der auch in diesem Fachpraktikum eine signifikante Rolle gespielt

hat und der gerade bei der Arbeit in Gruppen substanziell ist, ist die gewissenhafte

Auswahl des Gruppenleiters. Der Gruppenleiter hat eine bedeutungsvolle zentrale

Funktion. Er ist sowohl erster Ansprechpartner gegenüber dem Kunden als auch

zentraler Gruppenorganisator und Konferenzleiter innerhalb der Gruppe.


► Fazit: Der Gruppenleiter ist sorgfältig sowohl in Hinblick auf qualitative als auch

auf soziale Kompetenzen auszuwählen.

Zahlreiche Studien und Befragungen kommen zu dem Resultat, dass (D)PP beliebt ist

und Programmierer gerne diese Softwareentwicklungsmethode anwenden. Allerdings

sollte man sich, wie auch in einigen Studien beschrieben, über die möglichen Nachteile

(Stärke des Partners, aufwändige Kommunikation mit Partnern und Kunden) bewusst

sein. Arbeit in Teams wird - auch in Unternehmen - zukünftig eine immer größere Rolle

spielen und die weitere Entwicklung wird spannend bleiben. Dazu werden gute Unter-

stützungstools, die auch schon heute zur Verfügung stehen und die vor allem der

Kommunikation dienen, benötigt. Durch die weitere Breitbandausbreitung und die zahl-

reichen Outsourcing- und Offshoring-Aktivitäten von Unternehmen in der ganzen Welt

werden kollaborative Softwareprogramme zudem immer häufiger eingesetzt. Das ha-

ben auch die großen Softwarekonzerne erkannt. Aktuell liefern sich z. B. die Konzern-

riesen Microsoft20 und Google21 einen Konkurrenzkampf in Bezug auf Softwarelösun-

gen zur Entwicklung von Webseiten, die in Teams erstellt und verwaltet werden kön-

nen. Der Softwaregigant Microsoft hat in den letzten Jahren viele Programme zur Un-

terstützung von kollaborativer Gruppenzusammenarbeit entwickelt (wie z. B. „Windows

Live Messanger“, „Groove“, „Office Live Communications Server“ oder „Windows-

Teamarbeit“). Diese Aktivitäten zeigen, dass die Softwareentwicklungsunternehmen

die Zeichen der Zeit erkannt haben und immer bessere Programme vermarkten. Aber

diese Unterstützungsmedien werden auch zunehmend verstärkt von den Unternehmen

und Benutzern eingefordert, die diese Programme vermehrt aktiv einsetzen und den

großen Nutzen der Arbeit in kollaborativen Gruppen sehen.

Abschließend bleibt folgendes Gesamtfazit dieser Diplomarbeit zu ziehen: Die

Evaluation von Distributed Pair Programming mit XPairtise hat gezeigt, dass

Distributed Pair Programming eine in der Praxis funktionierende Softwareent-

wicklungsmethode ist, die ähnlich wie das Pair Programming im Vergleich zum

Solo Programming Vorteile bietet, sofern die beschriebenen Prämissen berück-

sichtigt werden.

20 http://www.microsoft.com/de/de/default.aspx (Stand 30.06.2008) 21 http://www.google.com/ (Stand 30.06.2008)

Anhang ● Literaturverzeichnis VI

L I T E R A T U R V E R Z E I C H N I S

Bec99: Kent Beck, Extreme Programming Explained: Embrace Change, erschienen 1999, Ad-dison Wesley.

Bec00: Kent Beck, Extreme Programming: Die revolutionäre Methode für Softwareentwicklung

in kleinen Teams, dt. Ausgabe erschienen 2000, München. Addison Wesley Longman Verlag, ISBN 3-8273-1709-6.

Bel05: Arlo Belshee, Promiscuous Pairing and Beginner’s Mind: Embrace Inexperience, vor-

gestellt auf: Proceedings Agile 2005 Conference, erschienen 2005, Erscheinungsort: http://svn.arlim.org/arlo_papers/Promiscuous%20pairing/Agile%202005/paper.doc, Stand 30.06.2008.

BRB06: Sallyann Bryant, Pablo Romero und Benedict du Boulay, Pair programming and the re-

appropriation of individual tools for collaborative software development IDEAS Labora-tory, University of Sussex, UK, erschienen 2006, Erscheinungsort: http://www.cogs.susx.ac.uk/users/bend/papers/coop2006.pdf, Stand 30.06.2008.

BRB07: Sallyann Bryant, Pablo Romero und Benedict du Boulay, Pair Programming and the

Mysterious Role of the Navigator, IDEAS Laboratory, University of Sussex, UK, er-schienen 2007, Erscheinungsort: http://www.cogs.susx.ac.uk/users/bend/papers/ ijhcs07.pdf, Stand 30.06.2008.

BS08: Berlecon-Studie: Fachbereiche wollen Unified Communications, erschienen 08.05.2008,

Erscheinungsort: http://boersen.manager-magazin.de, Stand 30.06.2008. BWG+02: Prashant Baheti, Laurie Williams, Edward Gehringer, David Stotts und Jason McC.

Smith, Distributed Pair Programming: Empirical Studies and Supporting Environments, erschienen 2002, Erscheinungsort: http://collaboration.csc.ncsu.edu/laurie/Papers/ TR02-010.pdf, Stand 30.06.2008.

CCL+06: Gerardo Canfora, Aniello Cimitile, Giuseppe A. Di Lucca und Corrado Aaron Visaggio,

How Distribution Affects the Success of Pair Programming, International Journal of Software Engineering and Knowledge Engineering, 16 (2), Seiten 293-313, erschienen 2006, Erscheinungsort: http://plone.rcost.unisannio.it/canfora/papers/journal-papers/ IJSEKE-06.pdf, Stand 30.06.2008.

Con95: Larry L. Constantine, Constantine on Peopleware, erschienen 1995, Yourdon Press

Computing Series, Prentice Hall/Yourdon Press. Cop95: James O. Coplien, A Development Process Generative in Pattern Language of Pro-

gram Design, Seiten 183-237, erschienen 1995. ACM Press/Addison-Wesley. Cun92: Ward Cunningham, The WyCash portfolio management system, Conference on Object

Oriented Programming Systems Languages and Applications, Addendum to the pro-ceedings on Object-oriented programming systems, languages, and applications (Ad-dendum), Seiten 29-30, erschienen 1992. ACM Press.

CW00: Alistair Cockburn und Laurie Williams, The Costs and Benefits of Pair Programming,

erschienen 2000, Erscheinungsort: http://collaboration.csc.ncsu.edu/laurie/Papers/ XPSardinia.PDF, Stand 30.06.2008.

Dje06: Riad Djemili: Entwicklung einer Eclipse-Erweiterung zur Realisierung und Protokollie-

rung verteilter Paarprogrammierung, Freie Universität Berlin, Diplomarbeit, erschienen 2006, Erscheinungsort: https://www.inf.fu-berlin.de/w/SE/ThesisDPPI, Stand 30.06.2008.

DL87: Tom DeMarco and Timothy Lister, Peopleware: Productive Projects and Teams, erschie-

nen 1987, New York: Dorset House Publishing Co.

Anhang ● Literaturverzeichnis VII

DR93: Prasun Dewan und John Riedl, Toward Computer Supported Concurrent Software-Engineering, erschienen 1993, Volume 26, Seiten 17-27. IEEE Software.

DZ02: Andrew J. Dick und Bryan Zarnett, Paired Programming & Personality Traits, Third Inter-

national Conference on eXtreme Programming and Agile Processes in Software Engi-neering (XP2002), erschienen 2002, Erscheinungsort: http://agilealliance.com/system/ article/file/916/file.pdf, Stand 30.06.2008.

EE68: Douglas C. Engelbart und William K. English, A research center for augmenting human

intellect, AFIPS Conference Proceedings of the 1968 Fall Joint Computer Conference, San Francisco, CA, December 1968, Vol. 33, pp. 395-410, erschienen 1968, Erschei-nungsort: http://sloan.stanford.edu/mousesite/Archive/ResearchCenter1968/Research Center1968.html, Stand 30.06.2008.

FNP+04: Jesus Favela, Hiroshi Natsu, Cynthia Pérez, Omar Robles, Alberto L. Morán, Raul

Romero, Ana M. Martínez-Enríquez und Dominique Decouchant, Empirical Evaluation of Collaborative Support for Distributed Pair Programming, erschienen 2004, Buchkapi-tel aus Buch: Groupware: Design, Implementation and Use, Volume 3198/2004, Seiten 215-222. Springerlink.

Fow05: Martin Fowler, The New Methodology, martinfowler.com, erschienen 2005, Erschei-

nungsort: http://martinfowler.com/articles/newMethodology.html, Stand 30.06.2008. FWW02: Miriam Ferzli, Eric N. Wiebe und Laurie Williams, Paired Programming Project: Focus

Groups with Teaching Assistants and Students, NCSU Technical Report, TR-2002-16, erschienen 2002, Erscheinungsort: http://collaboration.csc.ncsu.edu/laurie/Papers/ PRLTechReport.pdf, Stand 30.06.2008.

GMW02: Boby George, Mohammad Mansour und Laurie Williams, A Multidisciplinary Virtual

Team, Systemics, Cybernetics and Informatics (SCI), erschienen 2002, Erscheinungs-ort: http://collaboration.csc.ncsu.edu/laurie/Papers/attvteam.pdf, Stand 30.06.2008.

Han04: Brian F. Hanks, Distributed Pair Programming: An Empirical Study, erschienen 2004,

Buchkapitel aus Buch Extreme Programming and Agile Methods - XP / Agile Universe 2004. Springerlink.

Han05: Brian F. Hanks, Empirical Studies of Distributed Pair Programming, Doktorarbeit, Uni-

versity of California, Santa Cruz, erschienen 2005, Erscheinungsort: http://faculty.fortlewis.edu/Hanks_b/publications/dissertation.pdf, Stand 30.06.2008.

Han07: Brian F. Hanks, Problems encountered by novice pair programmers, International Com-

puting Education Research Workshop, Proceedings of the third international workshop on Computing education research, erschienen 2007, Seiten 159-164, New York. ACM Press.

HB04: Handelsblatt: EDV: Indien lockt, erschienen 2004, Erscheinungsort:

http://www.handelsblatt.com/News/Technologie/Geschaeftsfelder/_pv/_p/204966/_t/ft/_b/710027/default.aspx/edv-indien-lockt.html, Stand 30.06.2008.

HRGW04: Chih-Wei Ho, Somik Raha, Edward Gehringer und Laurie Williams: Sangam: a dis-

tributed pair programming plug-in for Eclipse, Proceedings of the 2004 OOPSLA work-shop on eclipse technology eXchange: Seiten 73-77, erschienen 2004, New York. ACM Press.

Jef08: Ron Jeffries, XProgramming.com - an Agile Software Development Resource, Erschei-

nungsort: http://www.xprogramming.com, Stand 30.06.2008. Jen03: R. W. Jensen, A Pair Programming Experience”, CrossTalk, erschienen 2003, Erschei-

nungsort: http://www.stsc.hill.af.mil/crosstalk/2003/03/jensen.html, Stand 30.06.2008.

Anhang ● Literaturverzeichnis VIII

KWW+04: Neha Katira, Laurie Williams, Eric Wiebe, Carol Miller, Suzanne Balik und Ed Ge-hringer, On Understanding Compatibility of Student Pair Programmers, SESSION: Paired programming/collaborative learning, 36(1): Seiten 7-11, New York, erschienen 2004. ACM Press.

Mau02: Frank Maurer, Supporting Distributed Extreme Programming, erschienen 2002, Buch-

kapitel aus Buch: Extreme Programming and Agile Methods – XP / Agile Universe 2002. Springerlink.

MM02: Grigori Melnik und Frank Maurer, Perceptions of Agile Practices: A Student Survey,

erschienen 2002, Buchkapitel aus Buch: Extreme Programming and Agile Methods - XP/Agile Universe 2002. Springerlink.

MWBF06: Charlie McDowell, Linda Werner, Heather E. Bullock und Julian Fernald, Pair pro-

gramming improves student retention, confidence, and program quality, Communica-tions of the ACM, 49 (8): Seiten 90-95, erschienen 2006. ACM Press.

NFM+03: Hiroshi Natsu, Jesus Favela, Alberto L. Morán, Dominique Decouchant und Ana M.

Martinez-Enriquez, Distributed Pair Programming on the Web, erschienen 2003, Fourth Mexican International Conference on Computer Science, Seiten 81-88. IEEE Software.

Nos98: J. T. Nosek, The Case for Collaborative Programming”, Communications of the ACM,

41(3): Seiten 105-108, New York, erschienen 1998. ACM Press. NP03: Radu Nicolescu und Robert Plummer, A Pair Programming Experiment in a Large Com-

puting Course, erschienen 2003, Erscheinungsort: http://citr.auckland.ac.nz/ techreports/2003/CITR-TR-122.pdf, Stand 30.06.2008.

OO00: Gary M. Olson und Judith S. Olson, Distance Matters, Proceedings Human Computer

Interaction, erschienen 2000, Erscheinungsort: http://www.crew.umich.edu/ publications/00-04.pdf, Stand 30.06.2008.

PM06: Leandro Pfleger und Giorgio Merize, PEP - Pair Eclipse Programming, erschienen

2006, Erscheinungsort: http://pep-pp.sourceforge.net/, Stand 30.06.2008. Pöß04: Lutz Pößneck: Programmieren in Indien: IBM will jährlich 168 Millionen sparen, erschie-

nen 19.01.2004, Erscheinungsort: http://www.silicon.de, Stand 30.06.2008. PPI04: Anne Powell, Gabriele Piccoli, Blake Ives, Virtual teams: a review of current literature

and directions for future research, erschienen 2004, New York. ACM Press. PSSH04: Uuno Puus, Asko Seeba, Priit Salumaa und Sven Heiberg, Analyzing Pair-

Programmer’s Satisfaction with the Method, the Result, and the Partner, erschienen 2004, Buchkapitel aus Buch: Extreme Programming and Agile Processes in Software Engineering, Seiten 246-249. Springerlink.

RZ04: Michael Reeves und Jihan Zhu, Moomba – A Collaborative Environment for Supporting

Distributed Extreme Programming in Global Software Development, erschienen 2004, Buchkapitel aus Buch: Extreme Programming and Agile Processes in Software Engi-neering. Springerlink.

RZ07: Rhein-Zeitung, Telearbeit geht nicht ohne Selbstdisziplin, erschienen 30.07.2007, Er-

scheinungsort: http://rhein-zeitung.de/on/07/08/27/service/berufbildung/t/rzo 352841.html, Stand 30.06.2008.

SJ03: Jean-Guy Schneider und Lorraine Johnston, eXtreme Programming at Universities: An

Educational Perspective, erschienen 2003, 25th International Conference on Software Engineering (ICSE'03), Seiten 594-599. IEEE Software.

Anhang ● Literaturverzeichnis IX

SS01: T. Schümmer und J. Schümmer, Support for Distributed Teams in eXtreme Program-ming, erschienen 2001 in: eXtreme Programming Examined. Addison Wesley.

SSG04: David Stotts, Jason McC. Smith und Karl Gyllstrom, Support for Distributed Pair Pro-

gramming in the Transparent Video Facetop, erschienen 2004, Buchkapitel aus Buch: Extreme Programming and Agile Methods - XP / Agile Universe 2004. Springerlink.

SWN+03: David Stotts, Laurie Williams, Nachiappan Nagappan, Prashant Baheti, Dennis Jen

und Anne Jackson, Virtual Teaming: Experiments and Experiences with Distributed Pair Programming, erschienen 2003, Buchkapitel aus Buch: Extreme Programming and Agile Methods - XP/Agile Universe 2003. Springerlink.

SWW+04: Hema Srikanth; Laurie Williams, Eric Wiebe, Carol Miller und Suzanne Balik, On Pair

Rotation in the Computer Science Course, Software Engineering Education and Train-ing, erschienen 2004, Seiten 144-149. IEEE Software.

TRR03: Lynda Thomas, Mark Ratcliffe und Ann Robertson, Code Warriors and Code-a-Phobes:

A Study in Attitude and Pair Programming, Technical Symposium on Computer Science Education, Proceedings of the 34th SIGCSE technical symposium on Computer science education: Seiten 363-367, New York, erschienen 2003. ACM Press.

Van04: Tammy VanDeGrift, Coupling pair programming and writing: learning about students'

perceptions and processes, Technical Symposium on Computer Science Education, Proceedings of the 35th SIGCSE technical symposium on Computer science education, Paired programming/ collaborative learning: Seiten 2-6, erschienen 2004. ACM Press.

Wil00: Laurie Williams, The Collaborative Software Process, University of Utah, Dissertation,

erschienen 2000, Erscheinungsort: http://collaboration.csc.ncsu.edu/laurie/Papers/ dissertation.pdf, Stand 30.06.2008.

WK00: Laurie Williams und Robert R. Kessler, All I Really Need to Know about Pair-

Programming I Learned in Kindergarten, Communications of the ACM, 43(5): Seiten 108-114, New York, erschienen 2000. ACM Press.

WiKe00: Laurie Williams und Robert R. Kessler, The Effects of "Pair-Pressure" and "Pair-

Learning" on Software Engineering Education, erschienen 2000, Proceedings of the 13th Conference on Software Engineering Education & Training, Seite 59. IEEE Soft-ware.

WKCJ00: Laurie Williams, Robert R. Kessler, Ward Cunningham und Ron Jeffries, Strengthen-

ing the Case for Pair-Programming, erschienen 2000, 17(4), Seiten 19-25. IEEE Soft-ware.

WYW+02: Laurie Williams, Kai Yang, Eric Wiebe, Miriam Ferzli und Carol Miller, Pair Program-

ming in an Introductory Computer Science, Course: Initial Results and Recommenda-tions, vorgestellt beim OOPSLA Educator's Symposium, Seattle, Washington, erschie-nen 2002, Erscheinungsort: http://collaboration.csc.ncsu.edu/laurie/Papers/EdSym_ PL_0318.pdf, Stand 30.06.2008.

XPT07: XPairtise Team, XPairtise - Pair Programming for Eclipse, erschienen 2007,

Erscheinungsort: http://sourceforge.net/projects/xpairtise/, Stand 30.06.2008.

Anhang ● Interviewfragen X

A N H A N G

A 1 : Interviewfragen

1) Wenn du einmal an Distributed Pair Programming denkst, was fällt dir spontan

dazu ein?

2) Konntest du mit dem Plugin XPairtise direkt starten und gemeinsam mit einem

weiteren Pair effektiv loslegen zu programmieren, oder war erst – auch wegen

den vorhandenen Programmier(vor)kenntnissen - eine Eingewöhnung notwen-

dig?

3) Wenn du noch einmal deine Programmierkenntnisse (über alles) vor Praktikums-

beginn einschätzen müsstest – wie würdest du dich einschätzen? (Skala von 1

bis 5; 1 = Experte, 5 = Anfänger)

4) Hattest du bei dem bisherigen Verlauf bei den gemeinsamen Sessions überwie-

gend mit bestimmten und immer denselben Gruppenmitgliedern zusammengear-

beitet oder war es mit allen mehr oder weniger gleichmäßig verteilt?

5) Was ist für dich das beste und meistgenutzte Feature in XPairtise gewesen, um

neben dem Audiochat mit dem Pair zu kommunizieren, gestikulieren und pro-

grammieren?

a) Textchat b) Whiteboard

c) Markierungen d) Rollenwechsel

6) Gab es in den bisherigen XPairtise-Sessions häufiger Unterbrechungen bzw. gab

es größere Pausen, um auch mal in Fachliteratur nachzuschauen, im Internet

nach Lösungen zu suchen oder auch mal Privates zu besprechen? Wenn ja, wo-

für genau?

7) Wofür wurde XPairtise deiner Meinung/Einschätzung nach am häufigsten einge-

setzt und verwendet:

a) Schwieriger Code b) Einfacher Code

c) Debugging d) Tests

e) Entwürfe f) GEF

g) Plugin h) Um anderen z.B. in Gruppen- oder auch

Einzelgesprächen programmierten Code zur

Veranschaulichung zu zeigen und zu er-

klären

i) Sonstiges

(Mehrfachnennung möglich – nach Priorität sortieren)

Anhang ● Interviewfragen XI

8) Wie beurteilst du persönlich den Wissensfluss in eurer Gruppe? Hat ein Wissens-

fluss untereinander stattgefunden und hast du durch den Austausch mit den

Pairs und dem Einsatz von XPairtise gut und viel lernen können?

9) Wo lag/liegt dein Schwerpunkt im Praktikum?

a) GUI b) Netzwerkprogrammierung

c) Thread-Programmierung d) Objektorientiertes Design

e) Testabteilung f) GEF

g) Plugin-Entwicklung h) Dokumentation

i) Anderes (bitte angeben)

10) Herrscht(e) in deiner Gruppe eine angenehme und konstruktive Atmosphäre und

konnte man sich dadurch gut zu Themen austauschen und zu Pair-Programming-

Sessions verabreden?

11) Ganz konkret: Wie beurteilst du die Kooperation mit deinen Teammitgliedern?

a) Sehr gut b) Gut

c) Fair d) Schlecht

12) Wie beurteilst du die Kommunikation innerhalb der Gruppe?

a) Sehr gut b) Gut

c) Fair d) Schlecht

13) Wie zufrieden bist du bzw. wie viel Vertrauen hast du (Skala 0 bis 100 –> 0 =

überhaupt nicht zufrieden, 100 = sehr zufrieden) mit/zu eurem programmierten

Produkt/Plugin?

14) Euer Fachpraktikum soll laut Aufgabenbeschreibung im Rahmen von XP ablau-

fen. Beim XP hat die testgetriebene Entwicklung einen hohen Stellenwert.

Frage: In wie viel Prozent der Fälle hast du einen Test geschrieben, bevor kon-

kret die Funktionen/Methoden programmiert wurden?

15) XPairtise ist entwickelt worden, um das Distributed Pair Programming zu unter-

stützen. Wie siehst du Distributed Pair Programming aus deiner Sichtweise: Hat

es dir Spaß gemacht, gemeinsam zu programmieren und konntest du durch den

gemeinsamen Austausch viel lernen und wurde effektiver programmiert als allei-

ne? Oder hast du lieber alleine programmiert und stehst dem Distributed Pair

Programming eher kritisch gegenüber?

16) Ganz konkret: Wenn du wieder eine größere Programmieraufgabe bewältigen

müsstest (z. B. im Rahmen des Studiums oder beruflich) und du dir aussuchen

könntest, ob du es im Rahmen von Solo- oder Pair-Programming machen kannst,

was würdest du konkret wählen:

a) Pair Programming b) Solo Programming c) Weiß nicht

17) Sonstiges: Anregungen/Kritik/Persönliches

Anhang ● Selbst- und Fremdeinschätzungsfragen XII

A 2 : Selbst- und Fremdeinschätzungsfragen

Selbstein-schätzung

Gruppen-mitglied

1

Gruppen-mitglied

2

Gruppen-mitglied

X… GUI-Entwicklung Netzwerkprogrammierung Objektorientiertes Design Testerfahrung Plugin-Expertise Thread-Programmierung Datenhaltung/Persistenz eXtreme Programming Dokumentation Analyse (z.B. Use-Cases verfassen) Planning Games Aktuelle Stunden/Woche - davon Eigenarbeit (in %) - davon Arbeit mit Pair (in %) Gemeinsame Sessions mit (in %)

Die Felder waren auszufüllen - entweder mit "*" oder mit "Zahlen-Angaben" (die 4 letz-

ten Fragen)

Als Orientierung galt die folgende Bewertungsskala:

* * * * * = Exzellente Kenntnisse * * * * = Gute Kenntnisse * * * = Kenntnisse vorhanden * * = Erste Grundkenntnisse vorhanden * = Sehr wenige bis keine Vorkenntnisse vorhanden k.E. = Keine Einschätzung möglich

Anhang ● Einverständniserklärung XIII

A 3 : Muster der Einverständniserklärung

Einverständniserklärung

Evaluation von Distributed Pair Programming mit XPairtise Name: Geburtsdatum: Matrikelnummer: Im Lehrgebiet „Verteilte Systeme für kooperative Arbeits-/ Lernumgebungen“ der FernUniversi-tät in Hagen wird im Fachpraktikum „CSCW – Entwicklung einer kooperativen Anwendung“ (Kurs 01592) im Wintersemester 2007/2008 eine begleitende Studie in Form einer Evaluation (Evaluation von Distributed Pair Programming mit XPairtise) durchgeführt. Ich erkläre, dass ich durch die Fachpraktikumsbetreuer über Zweck, Ablauf und Bedeutung der begleitenden wissenschaftlichen Studie (Evaluation von Distributed Pair Programming mit XPairtise) im Fachpraktikum für mich ausreichend mündlich aufgeklärt wurde. Alle meine Fra-gen sind zu meiner Zufriedenheit beantwortet worden. Ich hatte genug Zeit, um meine Ent-scheidung zur begleitenden Studienteilnahme zu überdenken und frei zu treffen. Ich wurde da-rüber informiert, dass ich die begleitende Studie jederzeit ohne Angabe von Gründen abbre-chen kann, ohne dass mir daraus Nachteile entstehen. Ich erkläre mich freiwillig bereit, an der oben genannten Studie teilzunehmen. Ich bin damit einverstanden, dass die erhobenen Studiendaten (u.a. Logfiles, Audioaufzeich-nungen, Interviews) in anonymisierter Form gespeichert, weiterverarbeitet und für wissenschaft-liche Darstellungen und Veröffentlichungen verwendet werden dürfen. Mit der vorstehend geschilderten Vorgehensweise bin ich einverstanden und bestätige dies mit meiner Unterschrift. Ort, Datum Unterschrift Student Unterschrift

Fachpraktikumsleiter

Anhang ● Inhalt CD XIV

A 4 : CD

Inhalt:

- Server für Logdatenerzeugung (modifizierter Server für XPairtise)

- Log-Auswertungsprogramm „LogFilter – Analyser XPairtise“

- Java-Quellcode Log-Auswertungsprogramm „LogFilter – Analyser XPairtise“

- Kurzbeschreibung „LogFilter – Analyser XPairtise“

- Übersichten zur Logauswertung

- CVS-Daten-Belegung der Gruppen (anonymisiert)

Documents

Diplomarbeit Evaluation von DPP mit XPairtiseals Diplomarbeit vorgelegt von Dominik Kröger Starenweg 4 48308 Senden (Matrikel-Nr. 5556457) angefertigt am Lehrgebiet Kooperative Systeme