Pair-Design, Pair-Programming, Cross-disciplinary Pairing – bringt das was?

Auf der Suche nach einem spannenden Thema für meine Bachelorarbeit hatte ich viele Ideen, mich interessierte Vieles, aber das Spannendste an meinem Studiengang war nun mal die Interdisziplinarität. Deshalb bestand auch die Möglichkeit, den praktischen Teil der Bachelorarbeit in einer Zusammenarbeit zu erarbeiten. Während des ganzen Studiums hatten wir bereits immer wieder in Gruppen (Designer und Informatiker gemischt) gearbeitet und ich traf die Entscheidung, mit dem Informatiker Yannick Bättig gemeinsam die Bachelorarbeit anzugehen. (Weshalb das die beste Entscheidung war, folgt!)

Kennt ihr diese Zwickmühle: Das Design ist endlich ausgearbeitet, alle Vorgaben wurden eingehalten und ab an die Entwickler damit. Nach einigen Wochen erhält man die Umsetzung oder einen Teil zum Review… ?… Das Design sieht aber ganz anders aus, gewisse Elemente wurden nicht richtig umgesetzt. Man ruft den Entwickler an und bespricht die Änderungen. Nach einem Tag wieder ein Review, die Änderung wurde immer noch nicht richtig umgesetzt und es gibt ein neues Problem dadurch… ?… und so geht es eine Weile, bis entweder zu viel Zeit vergangen ist, oder eine Seite aufgibt. Was ist da los und wie lässt sich das ändern?

Meine Bachelorarbeit war in dieser Hinsicht sehr lehrreich und möchte euch ein bisschen Hintergrund geben und meine Erkenntnisse teilen.

Pair-Design mit Generator & Synthesizer

Cooper führte 1997 das Konzept des Pair-Designs ein (siehe auch UX Collective). Dabei definierte er die Rolle des Generators und Synthesizers. Die Aufgabe des Generators besteht darin, so kreativ wie möglich zu sein und möglichst viele Ideen zu erzeugen. Der Synthesizer hingegen analysiert diese Ideen und stellt wichtige Fragen, um die Lösungen mit einem breiteren Kontext zu verknüpfen. Oft wird bei einem Synthesizer/Generator Pairing nur ein Stift verwendet. Dies führt dazu, dass nur einer schreiben kann und so die Konzentration des Mini-Teams gefördert wird. Analog dazu wird im Pair-Programming von Driver und Navigator gesprochen, wobei der Driver die Tastatur bedient und der Navigator die Orte der für Änderung und Ausbau bestimmt. (Williams & Kessler, Pair Programming Illuminated, Addison-Wesley, 2003) Dabei fällt ihm die Überblicksaufgabe zu wie dem Synthesizer im Pair-Design. Der Überblick und den Kontext zu behalten stehen hier im Vordergrund.

Pair-Design mit Lead & Support

Die zweite Arbeitsweise wird durch eine führende und eine unterstützende Position besetzt. Dabei wechseln Designer sich aber in den Rollen ab. Also ein Designer aus einer Führungsposition zum Beispiel wird in einem anderen Projekt als Unterstützung eingesetzt. Dabei können Designer ihr eigenes Toolkit erweitern und voneinander lernen. Hier stehen als Entwicklung und Lernen im Vordergrund.

Cross-Disciplinary Pairing

Ein Cross Pairing entsteht, wenn zwei Designer aus unterschiedlichen Bereichen zusammenarbeiten. Dabei kann in bestimmten Situationen bei einem pairing mehr erreicht werden, als in einer normalen Zusammenarbeit. Die Kombination von Fachdomänen ist hier das Ziel.

Auch Designer und Entwickler profitieren von einem Pairing. Vor allem bei der Arbeit mit High-Fidelity-Prototypen oder Front-End-Code. Dabei können Designer ihre Designvorstellungen in Echtzeit entwickeln und in Echtzeit experimentieren. Dabei können Arbeitsverschwendung und Kommunikationsaufwand reduziert werden.

Während meines Studiums konnte ich verschiedenste Pairings ausprobieren. Durch die verschiedensten Schwerpunkte der einzelnen Mitstudierenden profitierten die Arbeitsergebnisse sehr und ich lernte auch viel mehr. Während unserer Abschlussarbeit haben Yannick und ich bewusst, aber auch unbewusst einige Styles des Pair-Designs angewendet. Eine Episode war der Entwurf unsere Story-Konzepts. Dank Yannicks Auge für die Umsetzung und Umsetzbarkeit verhinderten wir hier, dass ich mich zu sehr in Details verliere und Elemente nicht vergessen gehen, die für eine durchgängige Interaktion notwendig sind. Dafür konnte ich den Dialog mit den Nutzern direkt in den Quellcode einfügen und sparte uns so die Zeit, die an komplexeren Stellen der Programmierung notwendig war. Da wir beide über Grundwissen im Stärkenbereich des jeweils anderen verfügen, konnten wir uns jeweils gegenseitig unterstützen und auf das gleiche Ziel hinarbeiten: das gemeinsame Produkt. Intuitiv funktioniert dann auch der Rollenwechsel, den das Pair-Design vorsieht, was uns zu gleichberechtigten Partnern im Vorhaben macht.

Insgesamt hat sich das Pair-Design und Pair-Programming für uns ausgezahlt. Wir haben unmittelbarer und effizienter gearbeitet und unsere Stärken und Ziele das Produkt betreffend schneller kennen und verstehen gelernt. Wir waren konsequent visuell unterwegs und produzierten wenig Missverständnisse. Mühsame Meetings kann man fast vermeiden, weil alles ein Zusammenarbeiten aus einzelnen und gemeinsamen Phasen ist. Ich arbeite sehr gerne wieder so eng mit Entwicklern zusammen, das Ergebnis spricht einfach für sich.