Pair Programming/Collaboration in einem kleinen Unternehmen

softwareengineering.stackexchange https://softwareengineering.stackexchange.com/questions/209390

Frage

Ich arbeite bei einer kleinen Entwicklungsfirma als leitender Entwickler.Wir haben zwei weitere Entwickler sowie meinen Chef, der Entwickler ist, aber nicht mehr wirklich viel programmiert.

Das Problem, das ich zu lösen versuche, ist vielschichtig.Wir haben alle die Tendenz, ohne viel Zusammenarbeit an unseren eigenen Projekten zu arbeiten.Tatsächlich frage ich (als fortgeschrittenster Entwickler) die Meinung/Hilfe der anderen mehr als sie nach meiner, weil ich den Input eines außenstehenden Auges schätze.

Ich möchte unsere Zusammenarbeit verstärken und habe ihnen das auch gesagt.Zum großen Teil, weil ich ihnen einige Dinge zeigen möchte, wie man bessere Entwickler wird und bessere Praktiken befolgt.Aber angesichts der Persönlichkeitstypen unserer anderen Entwickler denke ich, dass sie sich wohler fühlen, wenn sie alleine arbeiten.

Ich habe über Paarprogrammierung gelesen und (in einigen Foren) gelesen, dass es nicht gut funktioniert, wenn ein Entwickler fortgeschrittener ist als die anderen (was ich bin).Und doch halte ich es für unerlässlich, dass wir anfangen, zusammenzuarbeiten, damit unsere Arbeit nicht so disparat ist.

Meine Frage ist, ob jemand schon einmal in einer ähnlichen Situation war und was für ihn funktioniert hat?

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

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

War es hilfreich?

Lösung 6

Einige Monate nachdem ich diese Frage gestellt 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 jeden geeignet ist.

Ich habe festgestellt, dass es am besten ist, jeden seine eigene Arbeit machen zu lassen.Und im Laufe der Zeit haben wir ein gegenseitiges Vertrauen entwickelt, bei dem wir die anderen zu Hilfe rufen, wenn wir auf ein Problem stoßen.Ich glaube nicht, dass jemand mit jemandem arbeiten möchte, der ihm über die Schulter schaut.Gelegentlich sitze ich hinter jemandem und helfe ihm manchmal bei einem Problem, ohne dass ich dazu aufgefordert werde.Manchmal habe ich nichts hinzuzufügen, und ich ärgere sie vielleicht ein bisschen.Aber sie verstehen, dass ich nicht da bin, um sie zu beschimpfen.Ich bin meistens dort, um eine Pause von dem zu machen, was ich tue, und ein bisschen Zusammenarbeit einzuführen.

Was ich herausgefunden habe ist, dass die RICHTIGEN Leute im Laufe der Zeit (in einem kleinen Team) aufgreifen und sich damit synchronisieren, was andere tun.Es besteht keine Notwendigkeit, ständig Mikromanagement zu betreiben oder jemandem zu sagen, was er falsch macht.

Setzen Sie sich von Zeit zu Zeit mit jemandem zusammen und arbeiten Sie ein Problem durch, egal ob Sie ein Experte oder jemand sind, der lernt, oder beides.Erklären Sie, warum Sie etwas auf die eine oder andere Weise tun oder nicht tun würden.Gute Ideen setzen sich normalerweise durch, während andere auf der Strecke bleiben.Und am Ende des Tages haben Sie eine produktive, zusammenhängende Gruppe von Menschen, die vielleicht an verschiedenen Dingen arbeiten, aber ein gemeinsames Ziel haben.

Andere Tipps

Da es bereits in anderen Antworten Warum Pair Programming keine Lösung für Sie ist besprochen wurde, werde ich darauf eingehen, womit wir derzeit experimentiert haben und mit den Ergebnissen zufrieden sind.

Meiner Meinung nach können Sie die Zusammenarbeit verbessern, indem Sie zwei Personen für jedes Projekt zusammenstellen.Jeder von ihnen arbeitet an einem anderen Teil des Projekts, aber weil diese Teile integriert werden müssen, müssen die beiden Entwickler zusammenarbeiten.Dies erfordert auch, dass die beiden Programmierer die Architektur (Schichtung und Schnittstellen) des Projekts besprechen und sich dann entscheiden, unterschiedliche Rollen einzunehmen.

Und wenn dieser Ansatz die Anzahl der Projekte begrenzt, die Ihr Unternehmen gleichzeitig bearbeiten kann, können Sie diesem kooperierenden Paar zwei Projekte gleichzeitig zuweisen.

Wir haben kürzlich mit diesem Ansatz experimentiert, indem einer von ihnen Modelle + Integration mit APIs entwickelte und der andere Programmierer Ansichten und Controller handhabte .Wir haben folgende Vorteile dieser Einstellung festgestellt:

  1. Die Codestruktur ergibt sich viel besser, als wenn man nur an allen Aspekten des Projekts arbeitet.
  2. Wir müssen sie nicht daran erinnern, Code in das Repository zu übertragen usw.
  3. Sie müssen sich Mühe geben, den Code des anderen zu testen, anstatt sich ausschließlich auf unsere dedizierte QA zu verlassen.

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

Es gibt zwei unterschiedliche Rollen in einer Paarprogrammierung.Der Beobachter ist da, um den vom Fahrer geschriebenen Code zu überprüfen und Feedback dazu 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 von Ihnen geschriebenen Code 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 zur Mitarbeiterschulung und -entwicklung 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 Erleuchtungen verwenden, ein Dokument zu Codierungsstandards schreiben, eigenständige Aufgaben von Ihrer eigenen Arbeit abtrennen und sicherstellen, dass ordnungsgemäße Codeüberprüfungsprozesse vorhanden sind.

TL;DR : Ich glaube nicht, dass Paarprogrammierung für Sie funktionieren würde.Stattdessen sollten Sie versuchen, die Leute über die langfristige Qualität ihres Codes zu beunruhigen und sie dazu zu bringen, Antworten zu finden.Dies muss formlos erfolgen.

Über Kultur und Qualität

Meiner Meinung nach geht es in dieser Ausgabe nicht um Programmiermethodik, sondern um Kultur . Meiner Erfahrung nach ist es möglich, Kultur zu lenken, aber selten, indem man den Leuten davon erzählt.Das heißt, der Versuch, Menschen einen bestimmten Arbeitsablauf aufzuzwingen, der sich nicht natürlich entwickelt hat oder zu weit von der bestehenden Praxis entfernt ist, hat zwangsläufig negative Folgen.

Mit anderen Worten, Sie wollen nicht wie der Anzug aussehen, der die neuesten Schlagworte herumschwirrt, auch wenn Sie es letztendlich sind.Die meisten Programmierer, die ich kenne, würden Sie mental als Hintergrundgeräusch markieren.Seien Sie keine Unternehmensbiene.

Meiner Meinung nach lautet die wichtigste Frage, die Sie sich stellen sollten: „Bin ich mit der Qualität und dem geschäftlichen Wert des von meiner Organisation herausgegebenen Codes 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 jemand anderes in Ihrer Organisation nachdenken können (und sollten).

Paarprogrammierung und Mikromanagement

Auf die Gefahr hin, dass es etwas voreilig und hart klingen mag, scheint es mir, dass Sie beim Lesen über Pair Programming tatsächlich über eine Form von Mikromanagement nachgedacht haben oder umgekehrt.MM ist ein todsicheres Rezept, um die meisten Menschen zu entfremden.

Zur Verteidigung des Pair Programming: Beim Pair Programming geht es nicht darum, dass ein Typ einem anderen über die Schulter schaut.Das ist so mikro wie Management bekommt.Bei PP geht es darum, mit zwei Köpfen gleichzeitig über zwei Ebenen nachzudenken – eine Person befasst sich mit übergeordneten , großen Zusammenhängen, während die andere sich um die Grundlagen kümmert, die für die Erstellung von funktionierendem Code erforderlich sind.Und meiner bescheidenen Meinung nach funktioniert es selten gut, wenn die beiden Teilnehmer nicht in der Lage sind, die Plätze zu tauschen.Sie sollten ähnlich erfahren genug sein, um ein ähnliches professionelles Arsenal an Konzepten und ein gemeinsames professionelles Vokabular zu haben (wir sind nicht geistesverbunden – noch nicht , muhahaha).

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

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

    SO kann Wunder für neue Entwickler bewirken, da es ständiges Feedback liefert und dem Herzschlag der Community folgt.

  • Sehen Sie sich einen Teil des Codes an, den sie einchecken, und fordern Sie sie informell mit einigen Fragen zu seiner langfristigen Entwicklung heraus.Die meisten Programmieranfänger sind einfach nicht daran gewöhnt, daran zu denken, ihren Code lesbar und wartbar zu machen.Sobald Sie diese Probleme in ihre Köpfe bekommen haben, suchen sie selbst nach weiteren Informationen, von Ihnen oder anderen Quellen.

Ich glaube nicht, dass Paarprogrammierung 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 eines Programmierers über die Paarprogrammierung mit Ingenieuren unterschiedlicher Fähigkeitsstufen. Obwohl es Vorteile wie Wissensaustausch und weniger Fehler gibt, erfordert Pair Programming eine größere Zeitinvestition.Mit einem Team von drei Entwicklern und nur vier Personen mit Entwicklungshintergrund/-erfahrung scheint es schwierig zu sein, eine Paar-Programmierroutine aufrechtzuerhalten.

Ich denke, dass Code-Reviews in Ihrer Situation eine bessere Alternative sind, insbesondere wenn Sie sie entsprechend anpassen.Ein Code-Review kann aus allem bestehen, von einer Person, die sich ein wenig Code ansieht und mehreren Personen (sogar dem gesamten Team) in einem Raum für ein oder zwei Stunden Feedback gibt, um das Design und die Implementierung einer gesamten Komponente durchzusehen.Diese können entsprechend der auszuführenden Arbeit variiert werden, insbesondere basierend auf den Kenntnissen, Erfahrungen und Bedürfnissen des Teams.Sie können immer noch den Aspekt des Wissensaustauschs erhalten, indem Sie mehrere Personen an der Überprüfung teilnehmen lassen, um Probleme zu finden, Vorschläge zu machen und Wissen zu erlangen, indem Sie die Ergebnisse der Überprüfung lesen, um die Kommentare in ihre eigene Arbeit einzubeziehen, bevor sie sie überprüfen lassen.Dies hat auch den Vorteil, dass die anderen Entwickler individuell arbeiten können, bis sie ihre Arbeit für erledigt halten, bietet aber dennoch einen Ort, an dem Sie Ihre gewünschten Ziele erreichen und gleichzeitig das Wissen und die Fähigkeiten des gesamten Teams nutzen können.

Meine Frage ist, ob jemand schon einmal in einer ähnlichen Situation war und was für ihn funktioniert hat.

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

Ich weiß nicht genau, welche Details ich erzählen soll, aber der Prozess hat sehr gut funktioniert.Er wollte betreut werden, was ich vorher nicht angedeutet hatte.Es hat also die Kommunikation in beide Richtungen auf sehr positive Weise geöffnet.

Tatsächlich frage ich (als fortgeschrittenster Entwickler) die Meinung/Hilfe der anderen mehr als sie nach meiner, weil ich den Input eines außenstehenden Auges schätze.

Es hört sich so an, als könnten Sie dies als logische Weiterentwicklung dessen einrahmen, was Sie derzeit tun.

Lizenziert unter: CC-BY-SA mit Zuschreibung
scroll top