Hallo allerseits, das ist wieder Dima Vdovin. In meinem vorherigen Artikel über die Integration von Juns in ein Team habe ich kurz die Paarprogrammierung als effektive Lehr- und Lernpraxis angesprochen. Jetzt möchte ich ausführlicher auf die Praxis der Paarprogrammierung in Teams eingehen. Ich habe verschiedene Variationen davon in verschiedenen Projekten ausprobiert, und heute möchte ich nur mitteilen, was ich darin als die Vorteile dieses Ansatzes sehe.
Paar-Programmierung
Es scheint mir, dass wir das Beispiel des Rallye-Rennens verwenden können, um einfach zu erklären, wie die Paarprogrammierung funktioniert. Es gibt einen Fahrer (Fahrer) und einen Navigator (Navigator). Der Fahrer konzentriert sich direkt auf das Fahren. Der Navigator steuert, wohin wir jetzt gehen, und informiert den Piloten über die bevorstehenden Kurven und Sprünge.
Bei der Paarprogrammierung ist es dasselbe.
Der Fahrer konzentriert sich darauf, hier und jetzt Code zu schreiben. Zu diesem Zeitpunkt hält der Navigator das gesamte Bild vor sich, prüft, ob der Fahrer keine Fehler macht, und sagt, wo und wie er weiterfahren soll.
Der einzige große Unterschied zum Rallye-Rennen besteht darin, dass Fahrer und Beifahrer bei der Paarprogrammierung regelmäßig die Plätze wechseln müssen. Die Verteilung der Funktionen fällt fast vollständig zusammen.
Es ist die vollständige Einbeziehung beider Teilnehmer in die Paarprogrammierung in den Prozess, die diese Methode von anderen Lern- und Kontrollmethoden unterscheidet. Einerseits erlauben wir dem Fahrer nicht, den Code vollständig unabhängig zu schreiben, und geben das fertige „Produkt“ nicht zur Überprüfung durch den bedingten Navigator. Gleichzeitig konzentriert sich der Treiber nicht nur auf bestimmte Codezeilen, sondern muss den von ihm erstellten Bereich in einer weiten Perspektive sehen. Gleiches gilt für unseren Navigator.
Zusätzlich zu diesem klassischen Paarprogrammierungsschema wurden im Laufe der Jahre des Bestehens der Branche mehrere effektivere Ansätze entwickelt. Beispielsweise ist der Ping-Pong- oder Backseat-Navigator-Ansatz beliebt. Einige Leute üben im Allgemeinen das Mischen verschiedener Techniken. Es ist in Ordnung. Die Wirksamkeit dieser oder jener Methode hängt von den Zielen und der Zusammensetzung der Teilnehmer ab: Wer nimmt an dem Paar teil, was sie erreichen wollen, wie erfahren beide Programmierer sind. Übrigens ist die Paarprogrammierung nicht nur bei einem Mentor-Junior-Paar anwendbar, über das ich im letzten Artikel gesprochen habe, sondern auch bei einem Paar von zwei erfahrenen Programmierern mit ungefähr demselben Niveau.
Lassen Sie uns als Nächstes die Setup-Optionen für Treiber und Navigator etwas ausführlicher diskutieren, abhängig von den Zielen der Paarprogrammierung.
Anfängertraining
Die Paarprogrammierung eignet sich hervorragend für Anfänger und wird am häufigsten genau dafür verwendet. Wenn Sie jedoch diese Methode zum Trainieren Ihres Jun verwenden, sollten Sie verstehen, dass Sie die Entwicklungsgeschwindigkeit der unmittelbaren Funktion opfern, wenn die Entwicklung in einem echten Code erfolgt. Gleichzeitig gewinnt das Team langfristig ernsthaft: Die Paarprogrammierung mit einem erfahrenen Kollegen erhöht die Geschwindigkeit beim Einsteigen und Lernen eines Jun erheblich.
Im Zusammenhang mit dem Fall "Anfängertraining" erscheint der Juni jedoch nicht immer. Beispielsweise kann die Paarprogrammierung verwendet werden, um eine bedingte neu eingestellte Mitte zu integrieren, die schnell in ein Projekt integriert werden muss. In diesem Fall sinkt die Geschwindigkeit nicht so stark, und der Mentor kann ein Kollege sein, der in Bezug auf das Qualifikationsniveau mit einem Neuling im Projekt vergleichbar ist. Hier geht es bereits um den Transfer von Erfahrung und Wissen nicht in der Programmierung, sondern um Wissen über ein bestimmtes Projekt.
Auf der anderen Seite ist das Codieren in einem Paar aus zwei Mitten etwas riskanter als ein Paar aus June + Middle oder June + Signor. Der Anführer in einem Zweierpaar muss mit großer Verantwortung an den Prozess herangehen. Wenn jedoch alle Bedingungen erfüllt sind, sind die Vorteile für das gesamte Team greifbar.
Wissensaustausch und Liquidation des "Turms"
Ein häufiges Problem für viele Teams ist die Verfügbarkeit unersetzlicher Spezialisten. Dies gilt meistens für Start-ups oder kleine isolierte Gruppen von Entwicklern, die selbst einige Funktionen oder ein separates Projekt gesehen haben. Ein unersetzlicher Spezialist ist einer, der entweder einen bestimmten Abschnitt des Codes / Projekts gründlich und individuell versteht oder nur ein vollständiges Verständnis dafür hat, wie alles funktioniert. Der Wissenspool über das Projekt eines solchen Spezialisten wird auch als "Turm des Wissens" bezeichnet.
Ein unersetzlicher Spezialist oder "Turm" ist ein gefährlicher Engpass, der auf jeden Fall vermieden werden muss. Weil ein banaler Krankenstand während der Integration neuer Funktionen in den Kampfteil des Projekts (oder während eines Umzugs oder in einer anderen ernsten Phase) - und die Arbeit des Teams gelähmt ist. Ganz zu schweigen von der Entlassung solcher Entwickler.
Um einen solchen Engpass zu beseitigen, sollten unverzichtbare Spezialisten ihr Wissen mit anderen Entwicklern teilen.
Wie bereits klar ist, eignet sich die Paarprogrammierung erneut hervorragend zum Austausch von Wissen. Nur in diesem Fall erhalten wir keine Fortbildung und Einarbeitung für Anfänger, sondern den Wissenstransfer über Aspekte des Projekts innerhalb des Teams. Wenn Sie eine Funktion in einem Paar ausführen, wissen bereits mindestens zwei Personen davon, und während des Schreibens wird der Hintergrund eines der Mitglieder des Paares verschärft.
Die Liquidation des "Tower of Knowledge" hat einen weiteren Vorteil, der für viele nicht offensichtlich ist. Neben der Dezentralisierung des Wissens über bestimmte Funktionen und Bereiche des Projekts reduzieren wir auch die Belastung für den Entwickler, um den dieser „Turm“ ursprünglich gebaut wurde. In der Tat muss das Team, wenn es einen unersetzlichen Spezialisten hat, häufig in einem Verschleißmodus arbeiten, mit Überstunden, sieben Tage die Woche während der Veröffentlichung und im Allgemeinen rund um die Uhr verfügbar sein. All dieser ständige Druck führt früher oder später zu professionellem Burnout oder bestenfalls zu dem Wunsch, einen ruhigeren Job zu finden.
Die proaktive Verwendung der Paarprogrammierung ist auch eine gute Möglichkeit, um zu vermeiden, dass aus heiterem Himmel Türme des Wissens erstellt werden. Die ständige Weitergabe von Wissen über Funktionen und verschiedene Teile des Projekts innerhalb des Teams ist ein normaler Prozess, der leider erst mit der Entlassung eines wichtigen Mitarbeiters organisiert wird. Zwar ist die Paarprogrammierung nicht die einzige Möglichkeit, mit "Towers" umzugehen und das Verständnis für das Projekt im Team zu verbessern, aber dies ist eine ganz andere Geschichte.
Komplexe Probleme lösen
Die Paarprogrammierung kann wie ein lokales Brainstorming-Tool verwendet werden, dh das Sprichwort "Ein Kopf ist gut, zwei ist besser" wird buchstäblich angewendet. Die Paarprogrammierung eignet sich hervorragend für Fälle, in denen Sie eine komplexe Funktion oder Logik gemäß den Geschäftsanforderungen des Projekts implementieren müssen. Hier geht es nicht mehr um den Wissenstransfer vom Leiter zum Nachfolger, sondern darum, ein System von zwei Entwicklern zu schaffen, die in Erfahrung und Verständnis des Projekts gleich sind und sich ihren Bemühungen anschließen.
Einige Entwickler mögen argumentieren, dass sie es bequemer haben, nur in komplexen Bereichen zu arbeiten, aber die Praxis zeigt, dass zwei starke Codierer in einem Paar eher qualitativ hochwertigen Code produzieren als getrennt zu arbeiten.
Die Stärken der Paarprogrammierung in solchen Situationen liegen gerade außerhalb des Codierungsprozesses. Der Gewinn wird vielmehr durch die Fähigkeit erzielt, aktiv auf gleicher Augenhöhe mögliche Wege zur Lösung des Problems zu diskutieren - der Prozess des Schreibens von Code ist in einem solchen Fall zweitrangig und kein Problem. Aber wie und was genau geschrieben werden soll, ist das Problem. Die Möglichkeit einer direkten Kommunikation, Diskussion und eines begründeten Streits zwischen zwei Spezialisten wirkt sich positiv auf die Qualität der getroffenen Entscheidungen aus. Die Zeit, die erforderlich ist, um eine erfolgreiche Lösung für unser Problem zu finden, wird ebenfalls reduziert.
Gemischte Aufgaben
Der letzte Fall ist ein Team aller oben beschriebenen Fälle. Hier haben wir zwei erfahrene Entwickler mit unterschiedlichen Fachgebieten, die sich zusammenschließen, um an einer Aufgabe zu arbeiten. Vielleicht kann einer von ihnen gut Code schreiben, und der andere ist mit den Anforderungen des Projekts bestens vertraut. Und es ist nicht notwendig, dass dies zwei Programmierer waren. Dies können Paare von Codierer und QS-Ingenieur oder Codierer und Analyst sein.
Hier erhalten wir eine reine Win-Win-Situation: Bei gemischten Problemen ergänzt jedes Mitglied des Paares das andere. Auf diese Weise schöpfen wir das Maximum aus dem Potenzial beider Spezialisten aus, beseitigen ihre Schwächen und nutzen nur ihre Stärken.
Gleichzeitig deckt die Lösung gemischter Probleme alle zuvor beschriebenen Fälle ab: Onboarding, wenn es sich um unzureichende Kenntnisse der Projektanforderungen handelt, Liquidation des "Turms" und Lösung eines komplexen Falls.
Gesamt
Es ist wichtig zu verstehen, dass die Paarprogrammierung kein Patentrezept ist und die Antwort auf jedes Entwicklungsproblem und jede Herausforderung darstellt. In fast allen Fällen führt diese Methode zu einer Verringerung der Entwicklungsgeschwindigkeit. Es lohnt sich daher, diesen Ansatz mit Vorsicht anzuwenden.
Wir dürfen auch den menschlichen Faktor nicht vergessen: Wenn wir über das Unterrichten von Jun sprechen, muss der Mentor im Paar in der Lage sein, auf der richtigen Ebene mit dem Anfänger zu interagieren, damit der Lernprozess nicht zu Prügeln und Spott wird. Wenn wir versuchen, den "Turm" zu liquidieren, muss die Zusammensetzung des Paares entsprechend angepasst werden, damit der Wissenstransfer in die richtige Richtung erfolgt. Gleiches gilt für komplexe und gemischte Probleme: Sie können nicht zwei zufällige Entwickler auf einen Computer setzen und warten, sie erhalten in N Stunden eine fertige Lösung.
Aber trotz der angesprochenen Schwierigkeiten ist die Paarprogrammierung eine großartige Methode, die nicht nur das Problem des Einbindens und Lehrens von Neulingen löst, sondern es Ihnen auch ermöglicht, die Wissenslücken anderer Teammitglieder über das Projekt zu schließen oder ein komplexes Problem effektiv zu lösen.