Pair Programming / Collaboration in einer kleinen Firma

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.

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.

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.

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.

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 .

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.

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.