Pair Programming / Collaboration in einer kleinen Firma

20

Ich arbeite bei einer kleinen Entwicklungsfirma als Hauptentwickler. Wir haben zwei andere Entwickler sowie meinen Chef, der ein Entwickler ist, aber nicht mehr viel von der eigentlichen Programmierung macht.

Das Problem, das ich zu überwinden versuche, ist vielfältig. Wir neigen alle dazu, an unseren eigenen Projekten zu arbeiten, ohne viel Zusammenarbeit zwischen uns. Tatsächlich frage ich (als der fortschrittlichste Entwickler) die Meinung / Hilfe der anderen mehr als meine, weil ich die Eingabe eines äußeren Auges schätze.

Ich möchte unsere Zusammenarbeit verstärken und habe dies gegenüber ihnen zum Ausdruck gebracht. Zum großen Teil, weil ich ihnen einige Dinge zeigen möchte, wie man bessere Entwickler werden und bessere Praktiken befolgen kann. Aber angesichts der Persönlichkeitstypen unserer anderen Entwickler denke ich, dass sie es bequemer haben, alleine zu arbeiten.

Ich habe über Paarprogrammierung gelesen und (in einigen Foren) gelesen, dass es nicht gut funktioniert, wenn ein Entwickler weiter fortgeschritten ist als die anderen (die ich bin). Und doch halte ich es für unbedingt erforderlich, dass wir zusammenarbeiten, damit unsere Arbeit nicht so unterschiedlich ist.

Meine Frage ist, ob sich jemals jemand in einer ähnlichen Situation befunden hat und was für sie funktioniert hat.

Mir ist klar, dass dies keine allumfassende Situation ist, aber ich bin bereit, mehreren Ansätzen eine Chance zu geben.

Wir arbeiten alle in einem gemeinsamen Bereich, Entwickler haben keine einzelnen Büros / Kabinen.

Ryan Williams
quelle
2
Haben Sie und die anderen Entwickler einzelne Büros, Kabinen oder sitzen Sie in einem gemeinsamen Bereich?
@hatchet Wir arbeiten alle in einem gemeinsamen Bereich.
Ryan Williams

Antworten:

12

Da bereits in anderen Antworten besprochen wurde, warum die Paarprogrammierung für Sie keine Lösung darstellt , werde ich auf das eingehen, womit wir derzeit experimentiert haben, und mit den Ergebnissen zufrieden sein.

Meiner Ansicht nach können Sie die Zusammenarbeit verbessern, indem Sie zwei Personen an jedem Projekt beteiligen. Jeder von ihnen arbeitet an einem anderen Teil des Projekts, aber da diese Teile integriert werden müssen, müssen die beiden Entwickler zusammenarbeiten. Dazu müssen die beiden Programmierer auch die Architektur (Ebenen und Schnittstellen) des Projekts erörtern und dann entscheiden, unterschiedliche Rollen zu übernehmen.

Wenn diese Vorgehensweise die Anzahl der Projekte einschränkt, die Ihr Unternehmen gleichzeitig bearbeiten kann, können Sie diesem zusammenarbeitenden Paar zwei Projekte gleichzeitig zuweisen.

Wir haben kürzlich mit diesem Ansatz experimentiert, wobei einer von ihnen Modelle und die Integration mit APIs entwickelt hat und der andere Programmierer Ansichten und Controller handhabt . Wir haben folgende Vorteile dieser Einstellung festgestellt:

  1. Die Codestruktur ist viel besser, als wenn nur einer an allen Aspekten des Projekts arbeitet.
  2. Wir müssen sie nicht daran erinnern, Code in das Repository usw. zu schreiben.
  3. Sie müssen sich bemühen, den jeweils anderen Code zu testen, anstatt sich ausschließlich auf unsere engagierte Qualitätssicherung zu verlassen.
Ozair Kafray
quelle
1
Ich werde auch darüber nachdenken. Mir gefällt die Trennung der Entwicklung der Views und Controller von den Modellen sehr, da sie die Entwickler dazu zwingt, eine gute API für die Modelle zu entwickeln. Um gleichzeitig arbeiten zu können, müssen entsprechende Tests geschrieben werden.
Ryan Williams
1
Ich habe mich dazu entschlossen, diese Antwort zu akzeptieren, da ich davon überzeugt bin, dass der beste Weg, um eine Zusammenarbeit herbeizuführen, darin besteht, die Rollen im selben Projekt zu verteilen, nachdem ich es mit einigen Teammitgliedern besprochen habe. Es mag nicht funktionieren, aber es scheint die beste Anpassung zu sein, die ich gehört habe.
Ryan Williams
7

Meiner Meinung nach ist die Paarprogrammierung nicht die Lösung für das von Ihnen angesprochene Problem.

Bei einer Paarprogrammierung gibt es zwei unterschiedliche Rollen. Der Beobachter ist da, um den vom Fahrer geschriebenen Code zu überprüfen und eine Rückmeldung zu geben . Wenn Sie versuchen, Ideen zu vermitteln, um die Entscheidungen Ihrer Junior-Programmierer zu verbessern, frage ich mich, wie effektiv Sie ihre Fähigkeit finden, den Code, den Sie schreiben, kritisch zu überprüfen, wenn Sie die Rolle des Treibers übernehmen.

Ohne diese Dynamik geht der Vorteil der Paarprogrammierung verloren.

Als leitender Programmierer würde ich vorschlagen, dass Sie ein stärkeres Programm für die Schulung und Entwicklung der Mitarbeiter mit Ihrem Chef in Betracht ziehen. Ihre Junior-Programmierer sollten einen Rahmen erhalten, um ihre Fähigkeiten zu verbessern. In der Regel können Sie Methoden wie Aufklärung verwenden, ein Dokument mit Codierungsstandards schreiben, eigenständige Aufgaben von Ihrer eigenen Arbeit trennen und sicherstellen, dass ordnungsgemäße Codeüberprüfungsprozesse vorhanden sind.


quelle
Ich werde Ihre Gedanken berücksichtigen. Es ist ein bisschen zu analysieren und mental zu korrigieren, was wir gerade tun. Ein ehrliches Gefühl, das ich habe, ist ein bisschen Unsicherheit in meiner Position als leitender Entwickler. Nicht weil ich mich aus Sicht der Fähigkeiten nicht wohl fühle, sondern weil unsere beiden anderen Entwickler älter sind als ich (einer signifikant, einer nicht) und einer sogar ein paar Jahre mehr Erfahrung hat. Unter diesen Umständen erscheinen herkömmliche Codeüberprüfungen unangenehm, da ich nicht den Eindruck erwecken möchte, dass ich ihnen den Hals runteratme. Andererseits ist es vielleicht das, was ich tun muss.
Ryan Williams
Eine andere Sache. Denken Sie, dass es weniger Vorteile gibt, als es sich lohnt, ein Programm mit ihnen zu koppeln, wenn ich der Fahrer bin? Es könnte immer noch als ein Weg genutzt werden, um auf Best Practices hinzuweisen, und es könnte immer noch ein Input und Feedback zu meinen Aktivitäten gegeben werden (auch wenn die Beziehung sicherlich unausgewogen wäre).
Ryan Williams
Wenn die Paarprogrammierbeziehung eine Möglichkeit ist, würde ich vorschlagen, dass sie Ihre Kollegen nicht anspricht und sie vielleicht sogar ein wenig bevormunden würde. Abhängig davon, wie Sie es modellieren, könnte dies leicht als "So programmiere ich und es ist der beste Ansatz" herauskommen. Sie würden diese Paarprogrammierung eigentlich nicht nennen, da sie nicht beide Komponenten enthält.
Ich glaube, das ist es, wovor ich Angst habe. Danke für die Gedanken. Ich werde deine Antwort akzeptieren, weil du der Erste bist. (Es gab auch ein paar andere gute.)
Ryan Williams
Bei @RyanWilliams Code-Bewertungen geht es nicht darum, "den Hals runterzuatmen". Es geht nicht darum, dass du sie kontrollierst. Bei uns nutzen wir ReviewBoard als Plattform und kommentieren den jeweils anderen Code. Es gibt keine "Hierarchie". Das Lernen ist in diesem Fall "implizit". Sie lernen aus dem Lesen Ihres und ihres Codes, aus Ihren und den anderen Entwicklerfragen und den Antworten / Kommentaren zu diesen Fragen. Und sie lernen andere Teile der Codebasis kennen, was meiner Meinung nach sehr nützlich ist.
Johannes S.
5

TL; DR : Ich glaube nicht, dass Pair Programming für Sie funktionieren würde. Stattdessen sollten Sie versuchen , die Menschen über die langfristige Qualität ihres Codes betroffen zu bekommen und sie wollen Antworten finden. Dies muss informell erfolgen.


Über Kultur und Qualität

Meiner Meinung nach geht es bei diesem Thema nicht um Programmiermethoden, sondern um Kultur . Meiner Erfahrung nach ist es möglich, Kultur zu lenken, aber selten, indem man Leuten davon erzählt. Das heißt, der Versuch, Menschen, die sich nicht auf natürliche Weise weiterentwickelt haben oder zu weit von der bestehenden Praxis entfernt sind, einen bestimmten Workflow aufzuzwingen, hat negative Konsequenzen.

Mit anderen Worten, Sie möchten nicht so aussehen wie der Anzug, der die neuesten Schlagworte spricht, auch wenn Sie es letztendlich sind. Die meisten Programmierer, die ich kenne, würden Sie mental als Hintergrundgeräusch bezeichnen. Sei keine korporative Biene.

Meiner Meinung nach lautet die Hauptfrage, die Sie sich stellen sollten, "bin ich mit der Qualität und dem geschäftlichen Wert des Codes, den meine Organisation ausgibt, zufrieden?" und wenn die Antwort darauf negativ ist, sollten Sie fragen: "Wie drehe ich das um?".

Letztendlich sind Qualität und Wert menschliche Definitionen, über die nur Sie oder eine andere Person in Ihrem Unternehmen nachdenken können (und sollten).

Pair-Programmierung und Mikromanagement

Auf die Gefahr hin, ein bisschen vorwärts und hart zu klingen, scheint es mir, dass das Lesen über die Paarprogrammierung Sie tatsächlich dazu gebracht hat, über eine Form von zu denken Mikromanagements oder umgekehrt. MM ist ein sicheres Rezept, um die meisten Menschen zu entfremden.

Zur Verteidigung der Paarprogrammierung: Bei der Paarprogrammierung geht es nicht darum, dass jemand einem anderen über die Schulter schaut. Das ist so klein wie das Management. Bei PP geht es darum, mit zwei Köpfen gleichzeitig über zwei Ebenen nachzudenken - eine Person kümmert sich um allgemeine Probleme auf hoher Ebene , während die andere sich um die Schrauben und Muttern kümmert, die für die Erstellung von Arbeitscode erforderlich sind. Und meiner bescheidenen Meinung nach funktioniert es selten gut, wenn die beiden Teilnehmer nicht in der Lage sind, die Plätze zu wechseln. Sie sollten ähnlich erfahren genug sein, um ein ähnliches professionelles Arsenal an Konzepten und ein gemeinsames professionelles Vokabular zu haben (wir sind nicht daran gebunden - noch nicht , muhahaha).

Für Ihre Situation würde ich sagen, da Sie ein kleines Team sind und der einzige mit wirklicher Erfahrung sind (so klingt Ihr Beitrag für mich), die Sie die meiste Zeit nicht paarweise programmieren oder den größten Teil des Codes überprüfen würden funktioniert nicht. Sie haben nur 24 Stunden am Tag. Stattdessen einige Lösungen, die Sie in Betracht ziehen könnten:

  • Ermutigen Sie sie, unter dem entsprechenden Sprach-Tag an SO teilzunehmen oder einige Code-Snippets zur Überprüfung in Code Review SE zu veröffentlichen. Starten Sie einen kleinen informellen Wettbewerb darüber, wer die meisten SO-Wiederholungspunkte pro Woche sammeln kann.

    SO kann für Anfängerentwickler Wunder wirken, da es konstantes Feedback liefert und dem Herzschlag der Community folgt.

  • Schauen Sie sich einige der Codes an, die sie einchecken, und fordern Sie sie informell mit einigen Fragen zur langfristigen Entwicklung heraus. Die meisten Programmieranfänger sind einfach nicht daran gewöhnt, ihren Code lesbar und wartbar zu machen. Sobald Sie diese Probleme in den Kopf bekommen, werden sie selbst mehr Informationen von Ihnen oder anderen Quellen einholen.

Idobie
quelle
Wie alle anderen schätze ich Ihre Beiträge. Das einzige, was ich beim Posten bemerkt habe, ist, dass es mir unangenehm ist, derjenige zu sein, der über ihre Schultern schaut. Sie sind beide tatsächlich älter als ich und man hat deutlich mehr Erfahrung. Ich stelle sie mir also nicht als Leute vor, die auf CE herumlaufen und nach Codeüberprüfungen fragen. Sie sind keine Neulinge. Aber sie kommen aus verschiedenen Sprachen und unorthodoxen Praktiken.
Ryan Williams
Aha. Ich finde es gut, dass Sie sich nicht wohl fühlen, wenn Sie über ihre Schultern schauen, weil ich nicht denke, dass Sie das sollten. Niemand möchte, dass jemand jeden Tastenanschlag, den er ausführt, noch einmal errät (übertrieben).
Idobie
4

Ich denke nicht, dass Pair Programming etwas ist, das Ihnen in Ihrer Umgebung helfen würde. Es ist nicht so, dass es den weniger erfahrenen Entwicklern nicht helfen würde, ihre Fähigkeiten zu verbessern - es gibt sogar eine Frage des Programmierers bezüglich der Paarprogrammierung mit Ingenieuren mit unterschiedlichen Fähigkeiten . Obwohl es Vorteile wie Wissensaustausch und weniger Fehler gibt, erfordert die Paarprogrammierung einen höheren Zeitaufwand. Bei einem Team von drei Entwicklern und nur vier Personen mit Entwicklungserfahrung scheint es schwierig zu sein, eine Paarprogrammierroutine zu pflegen.

Ich denke, eine bessere Alternative in Ihrer Situation sind Codeüberprüfungen, insbesondere wenn Sie sie entsprechend anpassen. Eine Codeüberprüfung kann aus einer Person bestehen, die sich einen kleinen Teil des Codes ansieht und mehreren Personen (sogar dem gesamten Team) in einem Raum ein oder zwei Stunden lang Feedback gibt, um das Design und die Implementierung einer gesamten Komponente zu überprüfen. Diese können je nach Arbeitsaufgabe variiert werden, insbesondere basierend auf den Kenntnissen, Erfahrungen und Bedürfnissen des Teams. Sie können den Aspekt des Wissensaustauschs weiterhin erhalten, indem mehrere Personen an der Überprüfung teilnehmen, um Probleme zu finden, Vorschläge zu unterbreiten und Kenntnisse zu erwerben, indem Sie die Ergebnisse der Überprüfung lesen, um die Kommentare in ihre eigene Arbeit zu integrieren, bevor sie überprüft werden .

Thomas Owens
quelle
Scheint eine populäre Meinung zu sein. Ich mag die Idee von Code Reviews. Aber in meinen Gedanken würde ich vermuten, dass ich es mit ihren Persönlichkeiten und Fähigkeiten sein werde, der das Review macht und sie einfach nur zuhören (meistens unbeteiligt). Aber vielleicht gibt es eine Möglichkeit, sie stärker einzubeziehen. Ich denke, ich muss darüber nachdenken.
Ryan Williams
Um klar zu sein, habe ich auch nicht über Pair Programming gesprochen, wie wir es die ganze Zeit tun. Wenden Sie vielmehr einen bedeutenden, aber nicht sehr großen Teil der Arbeitswoche für größere oder komplexere Funktionen auf. (Das ist teilweise aus praktischen Gründen notwendig. Ich habe meine eigenen Anforderungen, die erfüllt werden müssen.)
Ryan Williams
2

Meine Frage ist, ob sich jemals jemand in einer ähnlichen Situation befunden hat und was für sie funktioniert hat.

Da Sie Erfahrung einladen, ist hier, was ich tat. Ich entschied mich für den risikoarmen Ansatz und bat jemanden, der Jahrzehnte jünger war als ich, einige Zeit zusammenzuarbeiten. Wir haben die Aktivität nicht gekennzeichnet. Niemand außer mir wusste, dass wir eine neue Technik ausprobieren.

Ich weiß nicht genau, mit welchen Details ich mich befassen soll, aber der Prozess hat sehr gut funktioniert. Er wollte betreut werden, worüber ich im Vorfeld keine Ahnung hatte. Es hat also die Kommunikation in beide Richtungen auf sehr positive Weise geöffnet.

Tatsächlich frage ich (als der fortschrittlichste Entwickler) die Meinung / Hilfe der anderen mehr als meine, weil ich die Eingabe eines äußeren Auges schätze.

Es hört sich so an, als ob Sie dies als logische Abfolge Ihrer aktuellen Aktivitäten einordnen könnten.

dcaswell
quelle
Ich mache mir Sorgen, dass ich nicht so sicher bin, ob sie "betreut" werden wollen. Sie sind beide älter als ich und einer (deutlich älter) hat tatsächlich ein paar Jahre mehr Erfahrung als ich. Aber ich mag den zweiten Teil Ihres Ratschlags.
Ryan Williams
Und es ist ganz natürlich, sich Sorgen zu machen, bevor Sie etwas unternehmen - weil Sie keine Informationen haben. Ich habe die Erfahrung gemacht, dass die Leute, wenn Sie es einfach tun, spüren, dass Sie sich keine Sorgen machen und dass Sie entspannt sind und sie mitmachen. Und wenn es funktioniert, fahren Sie fort, und wenn nicht, versuchen Sie etwas anderes.
Dcaswell
Vielleicht könnte es ein bisschen einfacher werden, sie in ein größeres Projekt einzubeziehen, das ich normalerweise selbst machen würde. Zum Beispiel überarbeiten wir bald unser CMS. Es würde allerdings ein bisschen dauern, bis ich mich an die Idee gewöhnt hätte.
Ryan Williams
0

Einige Monate, nachdem ich diese Frage aufgeworfen habe, muss ich sagen, dass ich mit unseren Ergebnissen zufrieden bin. Aber es ist nicht genau das, was ich am Anfang akzeptiert habe. Denken Sie daran, dass dies ein kleines Team ist, sodass diese Lösung nicht für alle geeignet ist.

Ich habe festgestellt, dass es am besten ist, alle ihre eigene Arbeit machen zu lassen. Und im Laufe der Zeit haben wir Vertrauen ineinander aufgebaut, und wenn wir auf ein Problem stoßen, rufen wir die anderen zu unserer Hilfe. Ich glaube nicht, dass jemand mit jemandem zusammenarbeiten möchte, der über die Schulter schaut. Ich sitze gelegentlich hinter jemandem und helfe ihm manchmal durch ein Problem, ohne dass ich darum gebeten werde. Manchmal habe ich nichts hinzuzufügen, und ich nerve sie vielleicht ein bisschen. Aber sie verstehen, dass ich nicht da bin, um auf ihnen zu harfen. Ich bin meistens da, um eine Pause von dem zu machen, was ich mache, und ein bisschen Zusammenarbeit einzuführen.

Was ich herausgefunden habe ist, dass die RECHTEN Leute im Laufe der Zeit (in einem kleinen Team) das aufnehmen und synchronisieren, was andere tun. Es ist nicht nötig, jemanden die ganze Zeit über zu überwachen oder ihm mitzuteilen, was er falsch macht.

Setzen Sie sich von Zeit zu Zeit mit jemandem zusammen und lösen Sie ein Problem, egal ob Sie ein Experte sind oder jemand, der etwas lernt, oder beides. Erklären Sie, warum Sie etwas anders als anders machen würden oder nicht. Gute Ideen setzen sich in der Regel durch, während andere zurückbleiben. Und am Ende des Tages haben Sie eine produktive, zusammenhängende Gruppe von Menschen, die an verschiedenen Dingen arbeiten, aber einen gemeinsamen Zweck haben.

Ryan Williams
quelle