Praktische Stile der Paarprogrammierung

Ausnahmslos in allen Teams, in denen ich Software entwickelt habe, haben die Leute ihre Abneigung gegen Pair Programming zum Ausdruck gebracht. Es ist nicht so, dass die Entwickler es nicht versuchen wollen oder dass sie nicht glauben, dass es hilft. Im Gegenteil, sie sind in der Regel sehr enthusiastisch, wenn es darum geht, es auszuprobieren, und geben der Sache eine mehr als faire Chance. Nach ein paar Tagen sitzen sie dann allein hinter ihrer Tastatur und programmieren wie Zombies mit Kopfhörern. Was ist denn da los? Ist Pair Programming zu schwer? Zahlt es sich nicht aus? In diesem Beitrag werde ich versuchen zu erklären, was meiner Meinung nach passiert, und ich werde Ihnen einige klare Hinweise geben, wie Sie die Fallen vermeiden können. Am Ende werde ich auf verteilte Teams eingehen und darauf, was sich dort ändert. Was sagen die Leute also, wenn sie mit dem Pair Programming aufgehört haben und Sie sie fragen, warum:

• Alleine bin ich schneller
• Ich kann mich nicht mit diesem Kerl paaren, er geht mir auf die Nerven
• Pair Programming ist zu anstrengend
• Wir haben uns die Arbeit aufgeteilt und werden schneller fertig, wenn wir zwei Tastaturen benutzen
• Es gibt zu viele Hintergrundgeräusche
• Ich bremse sie nur aus

Einiges davon mag plausibel klingen, also lassen Sie mich das erst einmal ausräumen. Nein, Sie sind allein nicht schneller, Sie erzeugen nur noch mehr Mist, über den Ihre Kollegen rätseln und den sie schließlich löschen. Der Code, den Sie alleine schreiben, ist scheiße. Der Typ, der Ihnen auf die Nerven geht, versucht Ihnen (unbeholfen) mitzuteilen, dass Ihr Code scheiße ist. Versuchen Sie, auf ihn zu hören, und Sie werden ein besserer Programmierer werden. Oder vielleicht können Sie ihm etwas beibringen und er wird aufhören, Ihnen auf die Nerven zu gehen. Wenn Ihr Code so einfach ist, dass Sie die Arbeit im Voraus aufteilen können, schreiben Sie ihn auf einer zu niedrigen Abstraktionsebene, oder Sie müssen zu zweit daran arbeiten. Wenn Sie den anderen ausbremsen, ist das eine gute Sache. Das wird ihn daran hindern, Code zu schreiben, den Sie nicht pflegen können. Wenn Sie sich des Codes Ihrer Kollegen nicht würdig fühlen, kommen Sie darüber hinweg, oder verlassen Sie das Team.

Das war Ihre kalte Dusche, ich hoffe, sie hat Sie geweckt, der Rest der Post wird schöner. Ich habe ein paar Beschwerden übersprungen. Ich höre Sie, Paarprogrammierung ist hart! Sie werden all die heimlichen Momente der Ruhe vermissen, in denen Sie einen Blick auf Ihre E-Mails werfen, aus dem Fenster schauen, an das Mittagessen denken... Wenn die Umgebung ablenkend ist, sind Sie in einer Zweiergruppe noch mehr für diese Ablenkung empfänglich. Wenn es schwierig ist, mit Ihren Teammitgliedern zu kommunizieren, wird dies durch die Paarprogrammierung schmerzlich deutlich. Jemand muss diesen Mist in Ordnung bringen, und zwar gestern! Schalten Sie alles aus, was für die Sache nicht relevant ist, auch den Kunden. Wenn Sie dem Mann, der für Ihre Zeit bezahlt, sagen, dass Sie nicht effektiv arbeiten können, wenn er vor Ihren Augen mit seiner Frau telefoniert, wird er aufhören und Sie sparen ihm eine Menge Geld. Schalten Sie alle Telefone aus, ziehen Sie einfach den Stecker, es ist in Ordnung. Es gibt noch viele weitere Tipps, aber die Grundregel lautet: Wenn es Sie ablenkt, schalten Sie es aus. Dann können Sie mit dem Pairing loslegen. Um beim Pairing erfolgreich zu sein, müssen Sie wissen, was Sie tun, Sie müssen wissen, was die Dinge besser macht und was das Pairing scheitern lässt. Ich habe festgestellt, dass es vier grundsätzliche Arten von Pairing gibt. Ich werde sie durchgehen und Ihnen Tipps geben, wie Sie zu einem besseren Stil übergehen können, wenn Sie nicht weiterkommen. Bei einem Pairing gibt es einen Mann an der Tastatur und einen Mann, der seine Hände nicht benutzt. Der erste wird als Fahrer bezeichnet, der zweite als Beifahrer. Für manche Stile ist das keine sehr anschauliche Bezeichnung, aber im Zweifelsfall verwende ich diese Begriffe. Ich untersuche Fälle, in denen das Paar über das nötige Wissen verfügt, um die Aufgabe ordnungsgemäß zu erledigen, was wahrscheinlich keine Anfänger-Anfänger-Paarung ist, obwohl ich das Gefühl habe, dass die gleichen Muster auftauchen, wenn das Paar auf dem Weg nach Wissen sucht. Stil 1: The Commander and The Grunt oder The Backseat Driver Der Titel klingt nicht gerade nach einer angenehmen Art der Paarung, aber es ist sehr nützlich zu verstehen, wie sie funktioniert. Einige sehr positive Langzeiteffekte können durch die Anwendung dieses Musters erzielt werden, also haben Sie Geduld mit mir. Diese Art der Paarung kommt natürlich vor, wenn der Fahrer ein Junior ist oder er neu in dem Projekt, der Sprache oder dem Bereich ist. Im Gegensatz dazu ist der Navigator gut informiert und wäre wahrscheinlich schneller, wenn er nicht darauf warten müsste, dass der Fahrer tut, was ihm gesagt wird. Der Grunzer ist dem Kommandanten eindeutig im Weg. Sie können sehen, wie die Gereiztheit steigt, wenn der Kommandant mehr Anweisungen auf niedriger Ebene gibt wie: "Feld extrahieren. NEIN, tippen Sie es nicht ein, drücken Sie Strg-Alt-F! Nein nicht da, wählen Sie zuerst den Methodenaufruf aus, nein nein nein, Sie müssen nicht jeden Buchstaben auswählen, haben Sie diese IDE schon einmal benutzt? Geben Sie mir die Tastatur und ich mache es." Als der Kommandant feststellt, dass der Grunzer ein anderes Betriebssystem und ein anderes Tastaturlayout verwendet und sein Muskelgedächtnis hier nicht funktioniert, ist die Freude groß. Er geht zu seinem eigenen Schreibtisch, setzt einen Kopfhörer auf und ist in 20 Minuten mit der Aufgabe fertig. Wir sollten dieses Muster den Trottel und den Idioten nennen und nie wieder darüber sprechen, oder? Falsch! Der Trick ist das Muskelgedächtnis. Es gibt eine dünne Schicht guter Gewohnheiten zwischen dem Muskelgedächtnis und dem, worüber der Kommandant spricht, wenn er erklärt, was er getan hat. Der einfache Soldat weiß das (noch) nicht und er muss es lernen. Es wäre äußerst ineffizient, den Kommandanten dazu zu bringen, es aufzuschreiben und den Soldaten dazu zu bringen, es zu lernen. Daher ist diese Art der Paarung ein äußerst effizienter Weg, um diese Art von implizitem Wissen zu vermitteln. Als ich auf dem College war, hatte mein Hausfreund sein eigenes Geschäft und er musste etwas erledigen. Er hatte auch ein RSI-Syndrom und sein Arzt riet ihm, die Tastatur in Ruhe zu lassen. Er war überfordert und ich bot ihm an, ihm zu helfen, unter der Bedingung, dass er mir Smalltalk beibringt. Ich hatte noch nie in meinem Leben eine Zeile Smalltalk programmiert und ich hatte noch nicht einmal die IDE gesehen. Ich war nach allem, was man hört, ein ziemlich mieser Entwickler, aber wir waren gute Freunde und ich brauchte nur die Tasten zu drücken, sagte man mir. Wie schwer kann das schon sein, dachten wir. In der ersten Stunde erklärte mir mein Freund die Domäne und die Funktionsweise von Smalltalk, dann gab er auf, fluchte über die Schmerzen und schrie mir Tastenkombinationen ins Ohr. Drei Stunden später nippte er am Espresso, während ich ein paar Builder-Methoden implementierte. Am Nachmittag ging er auf die Toilette, während ich einen Testfall fertigstellte. Am Ende des Tages zeichnete er auf einer Tafel und ich implementierte, was da war, während er mir gelegentlich Anweisungen gab, wie ich Dinge anders benennen oder den Debugger verwenden sollte, anstatt den Code zu lesen. Es war recht angenehm und ich hatte das Gefühl, dass ich Smalltalk-Code selbst schreiben könnte. Als ich es am nächsten Tag alleine versuchte, war ich völlig verloren, aber ich konnte das tun, was mein Navigator wollte, ohne ihn zu verärgern, und das nach nur einem Tag des Ausprobierens. Die Lektion hier ist, dass Sie jemanden in Ihrem Team an einem einzigen Tag produktiv machen können, wenn Sie es müssen. Sie werden einen harten Tag haben, aber wenn Sie dies bewusst tun und sich im Voraus darauf einigen, dass es sich lohnt, ist die Rendite ziemlich überzeugend. Nach einem Tag sind Sie aus diesem Stil herausgerutscht, ohne es zu merken, und die Dinge werden besser und besser. Stil 2: Die Rallye Dies ist der Stil, der die Metapher von Fahrer und Navigator vorweggenommen hat. Bei einer Rallye waren sowohl der Fahrer als auch der Navigator schon einmal dort, wo sie sind, sie kennen sich sehr gut und brauchen nur ein kleines Wort zur Kommunikation. In einem Rallyeauto werden Sie Dinge hören wie: "Hart rechts. 3", "Alles raus", "Links 6". Wenn der Navigator eine Anweisung vergisst, wird der Fahrer einfach das Richtige tun und der Navigator fährt mit der nächsten fort. Das Risiko eines Unfalls wird durch die Anwesenheit des Navigators stark reduziert. In der Programmierung spricht man von "The Zone" oder "The Flow", um einen Zustand der totalen Konzentration oder sogar eine leichte Trance zu beschreiben, die mit hoher Produktivität verbunden ist. Beim Rallye-Pairing geht das Paar gemeinsam in die Zone. Es ist viel schwieriger, sie zu stören, weil sie sich in einer Sprache unterhalten, die nur sie selbst verstehen und alles andere als den Code auf dem Bildschirm ignorieren. Das Gefühl, das ich in diesem Zustand habe, ähnelt sehr dem, das ich als Kind beim Spielen bestimmter Spiele hatte, bei denen man sich eine Welt ausdenkt, indem man eine Fantasie teilt. Die Geschichte existierte in den Köpfen mehrerer Kinder und es war nur sehr wenig Kommunikation nötig, um das Ganze konsistent zu halten. Es ist tatsächlich hilfreich, die Geschichte mit anderen zu teilen, denn dann können Dinge, die nicht hineinpassen (wie ein Compilerfehler), mit weniger Störung herausgefiltert werden. Manchmal haben Leute beschrieben, dass der Navigator verhindern kann, dass der Fahrer aus dem Fluss gerät, aber meiner Erfahrung nach macht das Brechen der Verbindung (was Sie dann tun müssten) den Navigator in wenigen Sekunden unbrauchbar, also ist es besser, die Störung gemeinsam zu ignorieren. Wenn Sie sich auf sehr vertrautem Terrain bewegen (wie bei der Rallye), würde das funktionieren, aber normalerweise geht es bei der Entwicklung von Software darum, neue Probleme zu entdecken, während Sie vorankommen. Wenn Sie sich nicht auskennen, ist es sehr schwer, den Anschluss zu finden. Sie haben vielleicht schon geahnt, dass Sie diese Art der Paarung anstreben sollten. Hier sind also einige Tipps, wie Sie es schaffen, wenn Sie die richtige Balance gefunden haben. Als Fahrer sollten Sie:

• Denken Sie laut nach: "Wenn ich das Problem jetzt mit A löse, muss ich nicht erst B überarbeiten, bevor ich sehen kann, ob es funktioniert" "Ich führe den Test durch, bevor ich die Eigenschaftsdatei repariere, das können wir später tun"
• Sprechen Sie Ihre Erwartungen aus: "Dieser Test wird jetzt bestehen" "Ich sollte drei Aufrufe für diese Attrappe erhalten, weil ich x vereinfacht habe"
• Fragen Sie das Offensichtliche: "Was kommt als Nächstes?" "Ach ja, wir müssen noch die Eigenschaftsdatei korrigieren" "Können wir das so übertragen?"
• Geben Sie eine Vorwarnung: "Wenn wir das erledigt haben, werden wir ein Problem in Modul A sehen, das wir auch beheben müssen". Und dann vertrauen Sie Ihrem Navigator, dass er sich darum kümmert, während Sie so schnell wie möglich dorthin kommen.

Als Navigator sollten Sie:

• Folgen Sie der Handlung und stoppen Sie den Fahrer, wenn sie keinen Sinn ergibt.
• Aktiv Annahmen bestätigen oder verwerfen
• Fragen Sie nach Argumenten, wenn ein Fahrer eine nicht offensichtliche Lösung wählt: "Warum tun Sie das? Wenn wir diese Eigenschaft ändern, funktioniert es doch schon, oder?"
• Suchen Sie den nächstgelegenen Ausgang: "Wenn Sie diesen Test jetzt korrigieren, können wir zuerst einen Commit machen, der Build wird grün sein.
• Denken Sie voraus. Wenn der Fahrer Sie vorwarnt, kann es sein, dass er eine Sackgasse nicht sieht. Denken Sie ein paar Sekunden nach und sagen Sie es ihm, wenn Sie nicht glauben, dass Sie auf eine Lösung zusteuern.
• Finden Sie einen Ausweg, bevor Sie blockiert werden. Dies ist die schwierigste Aufgabe. Selbst wenn Sie nicht sicher sind, dass Sie in eine Sackgasse laufen, ist es gut, nach alternativen Wegen zu einem Ausgang Ausschau zu halten. Das spart Zeit, wenn Sie aus einer Sache aussteigen müssen.

Stil 3: Die Tour Dieser Stil kommt vor, wenn ein Navigator die Konzentration verliert und der Fahrer ihn im Grunde herumführt. Sie können immer noch zurück in den Rallye-Stil wechseln, aber das erfordert ein wenig Anstrengung auf beiden Seiten. Stellen Sie sicher, dass Sie beide in Topform sind, beginnen Sie mit der Tour und halten Sie sich an die oben genannten Verhaltensweisen und schon bald sollten Sie sehen, dass Sie wieder Rallye fahren. Wenn das nicht innerhalb von weniger als zehn Minuten der Fall ist, wechseln Sie die Paare (Sie können den Fahrer wechseln, was Sie wahrscheinlich zum Grunt-Commander macht, und wenn nichts funktioniert, versuchen Sie es eine Weile mit einem anderen Teammitglied). Stil 4: Das unzusammenhängende Paar oder der schlafende Navigator Dies ist die am häufigsten verwendete und am wenigsten nützliche Art der Kopplung. Zwei Entwickler besprechen zunächst das Design, gehen den Code durch und wenn der Fahrer unterwegs ist, schaltet der Navigator sein Gehirn ab. Der Fahrer weiß, was er tut, und weil der Navigator nicht mitbekommt, was er sagt, schweigt er und wird schneller. Der Navigator sieht, dass es dem Fahrer gut geht und beschließt, ihn nicht zu bremsen, sondern Abstand zu nehmen und ein wenig aus dem Fenster zu schauen. Wenn Sie dies in verteilten Teams tun, können Sie während der Navigation Ihre E-Mails abrufen oder Musik hören. Oder Sie können selbst etwas programmieren. Wenn Sie dies jedoch tun, nehmen Sie die Paarprogrammierung nicht ernst und es wird sich weder für Sie noch für Ihr Team positiv auswirken. Seien Sie sich dieses Stils bewusst, wenn Sie Paarprogrammierung betreiben. Wenn dies der Fall ist, ist jede Veränderung eine gute Veränderung. Als Fahrer können Sie plötzlich alle Ihre Änderungen rückgängig machen und sehen, ob der Navigator es merkt. Als Navigator können Sie aufstehen und weggehen, um einen Kaffee zu holen. Geben Sie einfach zu, dass Sie die Verbindung unterbrochen haben und sich etwas ändern muss. Das sind die vier wichtigsten Arten des Pairing, die ich kenne, und ich habe sie alle ausgiebig ausprobiert, sowohl in kollokierten als auch in verteilten Teams. Bevor ich auf einige Dinge eingehe, die beim verteilten Pairing wichtiger sind, möchte ich noch einmal auf den Punkt zurückkommen, dass Pairing ermüdend ist. Pairing ist anstrengender, weil Sie härter arbeiten. In meinem Fall sogar viel härter. Das Problem ist, dass es schwer ist, sich daran zu erinnern, dass Ihr Gehirn eine Menge Dinge braucht, um seine Arbeit zu erledigen. In der Reihenfolge ihrer Wichtigkeit sind dies:

1. eine kleine Pause mindestens alle 45 Minuten (alle 20 Minuten ist besser)
2. Wasser (die meisten Kopfschmerzen werden durch Dehydrierung verursacht)
3. Glukose (essen Sie Fett oder Proteine, die viel effektiver sind als Rohzucker, aber Sie müssen sie länger im Voraus essen)
4. eine gute Nachtruhe
5. Koffein (Kaffee wirkt wirklich und soll auch noch gesund sein;) )

Das Problem beim Pairing ist, dass Menschen (insbesondere Entwickler) gerne so tun, als wären sie Maschinen und bräuchten keine Pausen zu machen. Ein guter Navigator bittet nach jedem Commit um eine Pause und sorgt dafür, dass es jede halbe Stunde einen Commit gibt. Wenn Sie zusammenarbeiten, können Sie sich sogar am Kaffeeautomaten darüber unterhalten, wie die Dinge laufen, wie weit Sie noch von einem Commit entfernt sind usw. Dort können Sie auch ein Glas Wasser und ein Sandwich zu sich nehmen, wenn Ihnen danach ist. Sie sollten auch bedenken, dass die meisten Menschen höchstens 6 Stunden am Tag harte Gehirnarbeit leisten können. Sie können dies durch Sport und eine gesunde Ernährung noch steigern, aber es ist normal, dass Sie nach 8 Stunden nicht mehr können. Gehen Sie einfach nach Hause... Verteiltes Pairing Verteiltes Pairing ist schwieriger als kollokiertes Pairing, aber es hat auch einige Vorteile. Die erste Regel beim verteilten Pairing lautet, sich nicht an den Tools aufzuhängen. Das Tolle daran ist, dass die meisten Schwierigkeiten beim verteilten Pairing technische Probleme sind, die behoben werden können. Egal, ob Sie GNU Screen oder ein viel ausgefalleneres Tool verwenden, stellen Sie sicher, dass Sie die Informationen an Ihren Pairing-Partner weitergeben, damit er alles sehen kann, was relevant ist. Als erstes sollten Sie sich ein Headset kaufen. Seien Sie dabei nicht geizig, kaufen Sie ein gutes Mikrofon mit Geräuschunterdrückung und etwas, das Sie bequem tragen können. Ich bin ein großer Fan meines Sennheiser-Headsets, aber es gibt ein Skype-Headset, das sogar eine bessere Geräuschunterdrückung haben soll. Ich bin kein Experte auf diesem Gebiet, aber es lohnt sich auf jeden Fall, etwas Zeit und Geld dafür auszugeben. Nehmen Sie sich ein wenig Zeit, um den anderen Entwickler kennenzulernen. Videokonferenzen sind wirklich hilfreich und ich beginne meine Sitzung normalerweise mit einem gemeinsamen Video und einem kleinen Chat. Man vergisst leicht, wie viel mehr man von jemandem mitnehmen kann, mit dem man gerade noch an der Kaffeemaschine einen Witz gemacht hat, aber natürlich werden Sie diesen Entwickler nicht am anderen Ende der Welt an der Kaffeemaschine treffen. Fragen Sie unbedingt nach seinem Zeitplan, seinen Plänen für das Mittagessen usw. Wenn jemand kurz nach Ihrem Mittagessen mit Ihnen ein Pairing beginnt und er noch nicht gegessen hat, wird sich das irgendwann bemerkbar machen. Seien Sie eifriger bei kleinen Schritten, denn der Wechsel des Fahrers ist nicht so einfach. Ich habe viele Möglichkeiten ausprobiert, jemandem die Kontrolle über Ihre Tastatur zu geben, und sie sind alle schlecht. Die Netzwerklatenz wird Sie in 20 Sekunden in den Wahnsinn treiben. Wenn Sie sich wirklich nicht 30 Minuten Zeit nehmen können, ist es zwar einfach, einen Patch zu erstellen und diesen rüberzuschicken, aber es wird trotzdem viel mehr Zeit in Anspruch nehmen, als wenn Sie die Tastatur einfach rüberschieben. Das Gute am verteilten Pairing ist, dass Sie sich, sobald das Tool eingerichtet ist, nicht mehr um die Logistik kümmern müssen: Sie müssen nicht mehr auf den Sitzen herumrutschen und sich den Hals verrenken, um zu sehen, was der andere auf dem Bildschirm hat. Sie können einfach bequem in Ihrem eigenen Stuhl sitzen und den anderen Entwickler hören, als ob er Ihnen ins Ohr flüstern würde, natürlich ohne die Pheromone einzuatmen. Ich fühle mich irgendwie unwohl, wenn sich andere Menschen in meinem persönlichen Raum aufhalten, und ich bin nicht so unsensibel, dass ich die gleichen Befürchtungen bei anderen Entwicklern vermisse. Remote Pairing beseitigt all diese negativen sozialen Einflüsse.Wie das Pairing funktioniert, ist von Paar zu Paar unterschiedlich. Die Kennzeichnung des Paarungsstils mag hilfreich sein, um darüber zu sprechen, was vor sich geht, aber es ist nie ganz möglich, sich für einen Paarungsstil zu entscheiden und dabei zu bleiben.Zur Veranschaulichung sollte ich Ihnen von meinem Lieblingsnavigator und meinem Lieblingsfahrer erzählen. Mein Lieblingsnavigator ist ein ruhiger indischer Typ. Wenn ich mich mit ihm zusammentue, bin ich ungefähr 3-mal produktiver. Der Trick ist, dass ich all das tue, was ich von Natur aus tue, aber er lässt mich einfach nicht in die falsche Richtung gehen. Es ist, als würde man mit einer kleinen Muse auf der Schulter programmieren. Wie Sie sich vielleicht denken können, ist das eine Rallye-Paarung mit mir am Steuer. Dann haben wir eines Tages den Fahrer gewechselt. Die Dinge liefen furchtbar, ich war ständig im Weg und sagte ihm, welche Tasten er drücken musste, wie er ein Feld benennen sollte, und die Dinge kamen zum Stillstand. Mein Kumpel sagte mir, er wisse nicht, was los sei, aber er sei auf jeden Fall viel langsamer, als wenn er alleine kodieren würde. Wir wechselten zurück, die Musik setzte ein und wir hatten einen Lauf, der die nächsten 4 Stunden anhielt (natürlich mit einigen Pausen). Der Punkt ist, Sie müssen es nicht auf eine bestimmte Art und Weise machen, machen Sie es einfach so, wie es funktioniert und versuchen Sie herauszufinden, warum es funktioniert, damit Sie es noch besser machen können. Mein Lieblingsfahrer ist ein unverblümter Holländer. Er ist schnell am Steuer und wenn er die Idee, die ich ihm zu vermitteln versuche, nicht versteht, tippt er einfach etwas ein, um zu sehen, ob das funktioniert. Wenn er versteht, was ich murmle, ist es schneller auf dem Bildschirm, als wenn ich es selbst getippt hätte. So habe ich keine Zeit, mich darüber zu ärgern, dass die Dinge nicht so sind, wie sie wären, wenn ich die Tastatur hätte. Und das gibt mir Zeit, nach Auswegen und Schwachstellen zu suchen. Als ich ihn über die Änderung seiner Eclipse-Standardeinstellungen belehrte, hat er das nicht nur genau so behoben, wie ich es mir erhofft hatte, sondern er hatte auch noch eine Handvoll anderer Änderungen und Vorlagen, die äußerst nützlich sind. Das ist die perfekte Geschichte über den Übergang von Stil 1 zu Stil 2, der sich Stil 3 nähert. Wenn wir uns jetzt paaren, muss ich sicherstellen, dass ich den Überblick behalte. Das ist genau die Art von Herausforderung, die einen Navigator produktiv hält. Letztendlich geht es nur darum, in die Rallye-Stilpaarung zu kommen. Wenn Sie sich in einer Situation befinden, in der Sie auf dem Rücksitz sitzen, versuchen Sie, dies in eine Lernerfahrung zu verwandeln, die sich in den Rallye-Stil verwandelt. Wenn Sie sich in einer Tour befinden, versuchen Sie, den Beifahrer mehr in die Handlung einzubeziehen. Wenn Sie den Anschluss verlieren, halten Sie an und reden Sie darüber. Ein Fahrerwechsel ist in der Regel hilfreich, aber nicht, wenn er Sie von Stil 1 zu Stil 4 bringt. Im Zweifelsfall sollten Sie den erfahrensten Entwickler zum Navigator machen. Aber am wichtigsten ist, dass Sie versuchen, das Pairing zu einer natürlichen und angenehmen Erfahrung zu machen. Lassen Sie mich wissen, wie es läuft!