Pair-Programmierung, wenn Fahrer und Beobachter unterschiedliche Fähigkeiten und Erfahrungen haben


30

Ich weiß, dass die Paarprogrammierung eine agile Softwareentwicklungstechnik ist, bei der zwei Programmierer an einer Arbeitsstation zusammenarbeiten. Einer, der Fahrer, schreibt Code, während der andere, der Beobachter, jede Codezeile überprüft, während sie eingegeben wird.

Aber ich frage mich nur, ob die Strategie in dem Fall noch funktioniert. Beispielsweise

  • wenn sie eine ganz andere Programmierkenntnis haben.
  • wenn man nie erfahrungen in der problemdomäne hat während andere haben.
  • Ist es noch in Ordnung, wenn die Programmierkenntnisse niedrig sind?

Könnten Sie die Paarprogrammierungsstrategie im obigen Fall vorschlagen?


13
Stellen Sie sicher, dass sich die beiden einig sind, wer das höhere Können hat und den anderen coachen soll. Wenn diese Rollen / Fähigkeitsstufen nicht klar sind, funktioniert die Paarprogrammierung wahrscheinlich nicht und führt zu Konflikten.
Giorgio

Wenn Sie dies jedoch so tun, wie Sie es vorschlagen, kann dies eine enorme Lernmöglichkeit sein.
Mawg

Antworten:


27

Unter der Annahme, dass die erfahrenere Person in dem Paar das Temperament hat, die andere Person zu betreuen, würde die Paarung einer Person mit wenig Erfahrung in der Sprache oder im Problembereich mit einer erfahrenen Person den Wissenstransfer erleichtern. Die weniger erfahrene Person hätte einen Mentor, der sie in der Sprache, der Domäne, der Anwendung und den Best Practices oder Konventionen des Teams unterrichtet.

Im C2-Wiki gibt es eine interessante Zusammenfassung zum Wissenstransfer mithilfe der Paarprogrammierung . Die erfahrenere Person, die als Team-Mentor herangezogen wurde, lernte viel von den Junior-Programmierern und sein Wissen nahm sogar zu, da sie mit weniger erfahrenen Junior-Software-Entwicklern zusammenarbeitet. Es gibt noch einige andere Geschichten darüber, wie Experten-Programmierer mit Domain-Experten zusammenarbeiten.


Einverstanden. Ich habe einen Junior im Team und Paarprogrammierung hat die Qualität seines Codes dramatisch erhöht. Es war jedoch auch sehr hilfreich, seinen Code paarweise zu überprüfen.
Sulthan

2
Sie müssen nur darauf achten, dass die ältere Person nicht zu 100% der Fahrer ist.
HLGEM

13
@HLGEM Ich würde sogar argumentieren, dass die weniger erfahrene Person die meiste Zeit der Fahrer sein sollte, während die erfahrenere Person den Code auf Fehler und Stil überprüft oder Testfälle dagegen schreibt.
Thomas Owens

1
Ich bin mit @ThomasOwens einverstanden. Ein weniger erfahrener Partner bringt seine / ihre "Erfahrung" schneller als jede andere Methode zum Vorschein und ermöglicht es ihnen, ihre eigenen Ideen und Einsichten mit dem erfahreneren Partner zu teilen. Es wird nicht lange dauern, bis ihre Kenntnisse viel näher sind.
Eric King

1
Ich frage mich, ob dies den älteren Entwickler gezwungener macht, das zu praktizieren, was er predigt.
JeffO

16

Dies ist genau der Anwendungsfall, für den die Paarprogrammierung gemacht wurde: Erfahrungsaustausch zwischen altem Bart und junger Heuschrecke.

Dies ist ein wechselseitiges Teilen: Bewegliche Insekten haben dem rheumatischen Gehirn viel zu lehren.


1
Obwohl Sie mich wahrscheinlich für einen halten würden, würde ich mich auf die "rheumatischen Gehirne" konzentrieren ...
Marjan Venema

1
Ich denke nicht, dass der Begriff "User Story" hier verwendet werden kann. User Stories beschreiben die geschäftlichen Anforderungen an eine Software.
Konrad Rudolph

Ja, ich denke er bedeutet "Use Case".
Jörg W Mittag

Abgestimmt: kein Wort über eine Strategie, wie mit den genannten Fällen umgegangen wird.
try-catch-finally

10

Als ich in mein aktuelles Team befördert wurde, war ich der Neuling in J2EE, aber ich war der Experte auf diesem Gebiet. Mein Senior (der neue Teamleiter) war erfahren in J2EE, aber nicht in der Plattform.

Ich glaube, ich habe in diesen 4 Monaten mit Pair Programming mehr über Java2EE gelernt als in einem Buch, und der Teamleiter hat auch etwas über die Plattform gelernt.

Die Erfahrung Lücke zwischen den beiden ist der Schlüssel zur Paarung Programmierung imho.


2
Einverstanden. Ich könnte mir vorstellen, mit mir selbst ein Paar zu programmieren, und ich denke, das wäre ziemlich sinnlos. Die Lücke schafft die verschiedenen Perspektiven, die relevant sind, damit 4 Augen mehr Spielraum im VIN-Diagramm der Möglichkeiten abdecken. Zwei Personen mit identischen Fähigkeiten und Erfahrungen würden die gleichen Dinge sehen und keinen Nutzen daraus ziehen.
Jimmy Hoffa

5

Ich werde meine Erfahrung beschreiben und versuchen, eine "Strategie" daraus zu machen.

Ich habe mal mit einem kompletten Nicht-Programmierer gepaart. Er war Experte für das Thema des von uns entwickelten Softwareprodukts. Im Gegenteil, ich hatte keine Erfahrung im Problembereich. Und er war im Moment auch mein Vorgesetzter (ich weiß, dass das seltsam klingen mag :)

Der Hauptvorteil dieser Methodik war, dass ich die Implementierung vieler Dinge aus seinem Wissensbereich erklären musste, um die Genauigkeit der Implementierung und sein Verständnis des Prozesses zu gewährleisten, was bedeutete, dass er verstand, warum dies Zeit in Anspruch nahm.

Ein weiterer Vorteil ist die einfache Konzentration auf die Aufgabe, keine Ablenkungen (ha-ha, stellen Sie sich vor, Sie öffnen Twitter vor der Nase Ihres Chefs).

Es war jedoch manchmal ziemlich einschüchternd, da sogar eine Teepause zu einer "Ablenkung von der Arbeit" wurde (nicht aus seiner Sicht; es war einfach unpraktisch, nach einer Pause zu fragen und so weiter).

Das ist also keine Paarprogrammierung, da er den Code während der Eingabe so gut wie nicht überprüfen konnte. Es schien jedoch eine vernünftige Strategie zu sein (zumindest für einige Zeit). Letztendlich funktionierte es überhaupt, da sowohl die Entwicklungsmethodik (ich meine, es waren keine komplexen Software-Designtechniken wie OOP-Patterns beteiligt) als auch die Inhalte relativ einfach waren. Dies würde nicht funktionieren, wenn wir einen Compiler entwickeln müssten, denke ich. Ich glaube, es könnte immer noch funktionieren, wenn ein Beobachter, der kein Programmierer ist, an der Entwicklung kleiner, klar definierter Teile beteiligt ist. Sagen wir, es ist in Ordnung, dass er die Programmierung einer Funktion "Berechne den Parameter X aus Y und Z mit einem gegebenen Algorithmus" beobachtet, aber es ist möglicherweise nicht in Ordnung, dass er den gesamten Systementwurfsprozess beobachtet (dh die Entwicklung der Softwarearchitektur, dh die Hierarchie von Klassen,

Ich denke, es würde noch besser funktionieren, wenn er grundlegende Programmierkenntnisse hätte, da ich nicht erklären müsste, was ein Array ist.

Ich hoffe es hilft :)


Es ist eine gute erfahrene Erklärung!
Sakares

2

Nach meiner Erfahrung kann es ein Problem sein, wenn beide Programmierer über geringe Kenntnisse verfügen. In diesem Fall besteht häufig die Tendenz, das Kopieren und Einfügen zu versuchen. Ich denke, es kann eine gute Idee sein, zwei Anfänger-Programmierer nicht zusammenzupaaren, bis sie ein bestimmtes, vom Team festgelegtes Level erreicht haben.

Andernfalls kann Pair Programming eine großartige Idee sein, vorausgesetzt natürlich, zwei Jungs sind bereit zu teilen, was sie wissen. Dies ist nicht nur eine großartige Möglichkeit, alle über den Quellcode auf dem Laufenden zu halten, sondern auch ein guter Ort für neue Ideen und Diskussionen.


Entwickler mit geringen Kenntnissen kopieren und fügen sie weniger häufig ein, wenn sie selbst programmieren? Dies ist normalerweise der Fall, wenn niemand zusieht.
JeffO

1

Solange die Teammitglieder Respekt voreinander haben, kann die Paarprogrammierung ungeachtet der Erfahrung der Programmierer von Vorteil sein. Selbst wenn ein Junior-Programmierer nur ein paar Syntaxfehler (die wir alle machen!) Vor dem erfahreneren Programmierer entdeckt, spart das immer noch Zeit beim Kompilieren von Code.

Ich denke auch, dass es die Einstellung eines Programmierers gegenüber den Fähigkeiten anderer Mitglieder seines Teams öffnen kann, besonders wenn sie offen sind und erwarten, dass jeder Ihnen etwas beibringen kann.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.