Die praktischen Aspekte der verteilten Paarprogrammierung

Auf dem heutigen Markt wird es immer wahrscheinlicher, dass sich die Entwickler eines Teams nicht am selben Ort befinden. Dies ist auf Outsourcing zurückzuführen, aber auch auf andere Gründe wie die zunehmende Konzentration auf Open-Source-Projekte. In einem verteilten Szenario hat Pair Programming enorme Vorteile gegenüber Meetings und dem Herumschicken von Kommentaren zu Problemen. Es ist (immer noch) der schnellste Weg, um detaillierte Informationen zwischen Menschen auszutauschen, und es erledigt die Arbeit tatsächlich dort, wo ein Meeting nicht ausreicht.Der zusätzliche Vorteil von Pair Programming in einem verteilten Team ist, dass es die Kluft zwischen dem lokalen Team und dem entfernten Team überbrückt, die dadurch entsteht, dass die informelle Kommunikation behindert wird. Die Forschung hat gezeigt, dass Pair Programming in verteilten Teams funktioniert[1]. Die Herausforderung besteht darin, herauszufinden, wie es für Sie funktioniert.In meinem letzten Blog über Pair Programming habe ich mich auf die verschiedenen Stile konzentriert, die ich in meiner täglichen Praxis erlebe, und auf Möglichkeiten zur Verbesserung der Dynamik in einem Pair. Dies gilt sowohl für die kollokierte als auch für die verteilte Paarprogrammierung. Bei meinem aktuellen Kunden bin ich auf die besonderen Probleme der verteilten Paarprogrammierung gestoßen. Daher werde ich in diesem Blog die gewohnheitsmäßigen und technischen Voraussetzungen für eine erfolgreiche verteilte Paarprogrammierung erläutern.

Wie ich bereits in meinem letzten Blog erwähnt habe, gibt es einige Dinge, die Sie benötigen, um ein Programm mit einer Fernbedienung zu koppeln. Ich werde sie hier ausführlicher auflisten. Hardware Sie brauchen Ihre Hände frei und eine gute Audioverbindung, Rückkopplungsschleifen und Hintergrundgeräusche sind tödlich. Ein gutes Headset und eine Webcam sind spottbillig im Vergleich zu den Kosten eines Fehlers, der durch eine Fehlkommunikation verursacht wird. Netzwerk Sie müssen in der Lage sein, einen Bildschirm mit einer angemessenen Auflösung gemeinsam zu nutzen, daher ist eine gute Netzwerkverbindung unerlässlich. Ich habe die Erfahrung gemacht, dass es bei einer Verzögerung von mehr als 1 Sekunde zwischen Bildschirm und Ton plötzlich viel schwieriger wird, zu verstehen, was der andere sagt. Als Fahrer merkt man das nicht sofort, und so kann es dazu führen, dass der Navigator vom Rallye-Stil in den Tour-Stil abgleitet. Software Es gibt viele Möglichkeiten, Ihren Bildschirm gemeinsam zu nutzen. Probieren Sie ein paar aus und stellen Sie sicher, dass das gesamte Team mit einigen Optionen vertraut ist. Ich mag Yuuguu, weil es plattformunabhängig ist, aber Mikogo ist auch nicht schlecht. Ich halte nichts von IDE-Plugins als primäre Option, weil sie die schnelle gemeinsame Nutzung anderer Tools wie der Kommandozeile oder eines Texteditors verhindern. Das soll ausdrücklich nicht heißen, dass ich dedizierte Sharing-Tools komplett ablehne, denn sie sind viel schneller und unterstützen standardmäßig die native Auflösung, neben vielen anderen Dingen, die beim einfachen Screen-Sharing nicht möglich sind[2]. Eine typische Pairing-Sitzung in einer kolokalen Situation ist sehr einfach aufgebaut. Der Aufbau eines Remote-Paares erfordert etwas mehr Aufwand. Das ist der Grund, warum viele Teams eine Kluft zwischen einem lokalen und einem entfernten Team erleben. Das Pairing findet statistisch gesehen häufiger vor Ort statt, und die Teammitglieder haben das Gefühl, nichts von dem mitzubekommen, was auf der anderen Seite passiert. Um diese Kluft zu überbrücken, bevorzugen Sie verteilte Paare gegenüber kolokalen Paaren. Um ein verteiltes Pairing zu etablieren, ist es gut, wenn Sie es während des Standups arrangieren können (vorausgesetzt, Sie haben ein gutes verteiltes Standup). Wenn Sie das nicht können, müssen Sie sie auf andere Weise einrichten. Eine Möglichkeit, die mir sehr gut gefallen hat, ist ein offener Team-Chat (Sie können dafür irc oder eine andere verfügbare Lösung verwenden) in dem Kanal, in dem Sie rufen, wenn Sie ein Paar suchen, und von dort aus werden die Dinge geregelt. Es gibt Software, die speziell für das Pairing entwickelt wurde und auch die Paarsuche unterstützt. Sobald Sie ein Paar gefunden haben, müssen Sie sich etwas mehr Mühe geben, um die Dinge zu organisieren:

• Legen Sie die Dauer der Pausen genau fest
• Planen Sie, was in der Pairing-Sitzung getan werden soll, und machen Sie sich klar, wann sie zu Ende ist.
• Berücksichtigen Sie bei Ihrer Planung explizit Zeitunterschiede

All diese Punkte vermindern das Risiko, dass ein Teil des Paares untätig bleibt und darauf wartet, dass der andere Teil von seiner Kaffeepause zurückkehrt, die sich in ein kurzes Meeting verwandelt hat, an dessen Ende die betreffende Person ihre Sachen packt und für den Tag abreist. Glauben Sie mir, das wird passieren... Mit diesen Vorsichtsmaßnahmen kann verteiltes Pairing meiner Erfahrung nach sogar effektiver sein als lokales Pairing. Es spricht einiges für strikte Absprachen darüber, wer zu einem bestimmten Zeitpunkt die Tastatur berührt... Letzter Ratschlag Verteilte Paarprogrammierung ist sogar noch anstrengender als Paarprogrammierung. Versuchen Sie nicht, 8 Stunden am Tag zu programmieren. Das Schöne an Offshore-Teams ist, dass sie normalerweise in einer anderen Zeitzone leben. Das bedeutet, dass die Überschneidung (Kernzeit) weniger als 8 Stunden beträgt. So bleibt Ihnen viel Zeit für die lokale Paarprogrammierung und das Lesen von E-Mails, und das ist auch gut so, denn Sie brauchen diese Zeit. Wie ich bereits in meinem vorigen Beitrag erwähnt habe, ist es wichtig, dass Sie gut ausgeruht, gut ernährt und gut hydriert sind, bevor Sie sich in kurze Läufe stürzen. Viel Spaß und teilen Sie Ihre Erfahrungen! Referenzen

1. Verteiltes Pair Programming: Empirische Studien und unterstützende Umgebungen
2. Verstehen von Tools und Praktiken