Wie ich meine Teamkollegen davon überzeugen kann, einige Grundregeln zu befolgen

Ich habe ein Problem mit meinen Teamkollegen. Kurz gesagt: Wir sind drei Studenten, die an einem Projekt für einen Wettbewerb arbeiten. Das Projekt besteht aus zwei separaten Anwendungen: eine für Windows (die ich entwickle) und eine für Android (meine Kollegen sind für die Entwicklung verantwortlich). Unsere Codebasen überschneiden sich nie, die Apps kommunizieren über Tools von Drittanbietern.

Das Problem ist folgendes: Ich habe einige Erfahrung in der Arbeit in Teams, als ich letztes Jahr ein Praktikum bei einem großen Unternehmen gemacht habe, und ich versuche, einige Codierungsstandards für unseren Code durchzusetzen. Ich habe auch eine Git-Repository / Wiki / Collaboration-Software eingerichtet, mit der wir Code / Schreibideen, Dokumentprotokolle usw. übertragen können, aber anscheinend bin ich der einzige, der diese Tools verwendet.

Ich habe versucht, ihnen zu sagen, dass das Schreiben von Qualitätscode und das Dokumentieren jedes Schritts auf lange Sicht von Vorteil ist, aber sie scheinen den Vorteil nicht zu erkennen. Ich habe auch überlegt, einige Integrationstests hinzuzufügen, aber soweit ich weiß, kann ich sie nicht davon überzeugen, wie nützlich Integrationstests sind, solange sie keine aktuellen Tools verwenden, um ihr Leben zu vereinfachen.

Der Großteil des Codes der Peers befindet sich auf ihren Computern, sie haben keine gemeinsame Codebasis und wie ich herausgefunden habe, haben sie ihre Teile integriert, indem sie den Code über einen USB-Stick ausgetauscht haben.

Meine Frage ist: Bin ich in dieser Angelegenheit zu hart? Erzwinge ich ein paar absurde Regeln? Denken Sie daran, dass dies ein kleines Projekt ist, die Anforderungen sehr klar sind (ich habe Dokumente erstellt, in denen angegeben ist, was die Anwendungen tun sollen). Drei erfahrene Entwickler könnten dies in 3-4 Tagen tun, sodass sie die zusätzliche Komplexität der Schreibqualität möglicherweise nicht erkennen Code, solange ihre aktuelle Methode nur funktioniert.

Gibt es eine Möglichkeit, ihnen den Nutzen der Codedokumentation mit git und so weiter zu zeigen?

Meine Frage ist: Bin ich in dieser Angelegenheit zu hart?

Sie können ein Pferd zum Wasser führen, aber Sie können ihn nicht zum Trinken bringen.

Es ist schwer zu sagen, ob Sie "zu hart" sind, aber es kann unrealistisch sein, von Ihren Teamkollegen zu erwarten, dass sie die gesamte von Ihnen erhoffte Infrastruktur übernehmen. Und wirklich, wenn das Team gut zusammenarbeitet, ist es wahrscheinlich übertrieben, ein Wiki zu verwenden, um zwischen drei Personen zu kommunizieren.

Reduzieren Sie Ihre Erwartungen und suchen Sie nach Möglichkeiten, um einige Ihrer Ziele zu erreichen, ohne dass diese Tools verwenden müssen, die sie nicht kennen. Wenn sie nicht wissen, wie man Git benutzt, werden sie wahrscheinlich auf keinen Fall viel Nutzen daraus ziehen. Sie möchten jedoch weiterhin sicherstellen, dass der gesamte Code im Falle eines Festplattenfehlers oder einer anderen Katastrophe gesichert wird. Bitten Sie sie daher, ihren Projektordner regelmäßig auf ein Google Drive, eine Dropbox oder einen ähnlichen Online-Dateifreigabedienst zu kopieren. Stellen Sie sicher, dass Sie dasselbe tun.

Ich bin der Meinung, dass Sie auf große Projekte vorbereitet sein werden, wenn Sie lernen, diese Dinge in kleinen Projekten zu tun.

Wenn sie sich bei diesem Projekt an eine gute Entwicklungspraxis halten, verfügen sie über Code, der den zukünftigen Arbeitgebern präsentiert wird, und sie verfügen über Erfahrungen, die sie als Mitarbeiter wertvoll machen würden.

Wenn Sie mehr Material wünschen, um sie zu überzeugen, verweise ich auf den Pragmatic Programmer oder Code Complete .

Auf der anderen Seite sollten Sie sie etwas lockerer schneiden. Wenn es sich bei dem Projekt um einen Proof-of-Concept handelt, der direkt nach dem Wettbewerb in die Gänge kommt, sollten Sie in Betracht ziehen, ihn einfach tun zu lassen, was er möchte. Möglicherweise haben sie Schwierigkeiten, den Code erst einmal zu schreiben, ohne den mentalen Aufwand für gute Praktiken.

Ich fürchte, die von Ihnen beschriebenen Regeln sind überhaupt nicht grundlegend.

Die einfachste Aufgabe IMO ist es, Ihre Teamkollegen davon zu überzeugen, einige Codierungsstandards zu verwenden. Und eine einfache Möglichkeit, dies zu erreichen, besteht darin, ihnen dasselbe Codefragment zu zeigen, sobald es gut formatiert und dann schlecht gestaltet ist. Bitten Sie sie, den Code zu lesen, zu verstehen, was er tut, und sich selbst ein Urteil zu bilden.

Die Verwendung eines Git-Repositorys kann Anfängern zu schaffen machen. Als ich in einem 3-köpfigen Team an einem Android-Projekt arbeitete, hatten wir zunächst große Probleme mit unserem Versionskontrollsystem. Ich gehe davon aus, dass auch Ihre Teamkollegen Probleme haben werden.

Sie haben erwähnt, dass es 3-4 Tage dauern würde, bis erfahrene Entwickler das Projekt abgeschlossen haben (ich gehe davon aus, dass Ihr Team 2-3-mal so lange brauchen würde). Dies ist eine sehr kurze Zeitspanne, sodass das Argument, dass die Verwendung neuer Tools auf lange Sicht hilfreich sein wird, einfach nicht funktioniert.

Sie können kurze und einfache Demos erstellen, um zu zeigen, wie diese Tools verwendet werden. Behandeln Sie zunächst die grundlegendsten Funktionen, setzen Sie sich an ihre Seite und helfen Sie ihnen beim Umgang mit den Werkzeugen. Bereiten Sie sich darauf vor, alle Aufgaben wie das Konfigurieren des Git, das Erstellen der Wiki-Seitenstruktur usw. zu erledigen.

Bearbeiten : Als Antwort auf den Kommentar denke ich, dass es wichtiger ist, klare Aufgaben, Schätzungen und Fristen festzulegen und die aufgewendete Zeit im Auge zu behalten, als Git oder ähnliche Tools zu verwenden. Wenn Sie später an der Anwendung arbeiten möchten, ist es sehr wichtig, zu verfolgen, was bereits getan wurde und wie lange die einzelnen Funktionen gedauert haben. Ich schlage vor, Sie beginnen mit der Aufgabenverwaltung und fahren dann mit den Tools fort, die Sie verwenden möchten.

Eigentlich mag ich Joel Spolskys eigene Gedanken darüber, wie er in " Dinge erledigen, wenn du nur ein Grunzer bist" dargelegt hat . Zusammenfassen:

1. Mach es einfach - Schreibe Makefiles, erstelle einen täglichen Build-Server usw.
2. Niemand nutzt Quellcodeverwaltung oder Bug-Datenbanken? Fangen Sie an, sie selbst zu benutzen. Wenn jemand einen Fehler gegen Ihre Arbeit meldet, bitten Sie ihn höflich, die Fehlerdatenbank zu verwenden, um Ihnen Fehler zu melden, damit Sie den Überblick behalten können. Andernfalls können Sie sie nicht gerade im Kopf halten und reparieren. Bei jedem nicht trivialen Projekt gibt es eine Situation, die nur mit der Quellcodeverwaltung gelöst werden kann: Verwenden Sie die Quellcodeverwaltung für den Code selbst und greifen Sie heldenhaft ein, um den Tag zu retten, an dem eine solche Situation auftritt. Sobald dies einige Male passiert, werden sie überzeugt sein
3. Erstellen Sie eine Tasche voller Exzellenz - Tun Sie das Richtige für sich selbst: Sprechen, Planen usw. Da dies kein Arbeitsprojekt zu sein scheint, können Sie diesen Rat nicht vollständig befolgen, da Sie ihn nicht einstellen können neue Teammitglieder, die an Ihre Botschaft glauben
4. Werden Sie von unschätzbarem Wert - Zeigen Sie, dass Sie einen wichtigen Beitrag zur Stärkung Ihres Einflusses im Team leisten. Andernfalls laufen Sie Gefahr, als eine Person bekannt zu werden, die Prozesse und Werkzeuge über Ergebnisse stellt

Dokumentation, Wiki, Versionssoftware, Methoden usw. sind Erfahrungen und Erkenntnisse, die im Laufe der Zeit gewonnen wurden. Arbeiten von mehreren Projekten und wahrscheinlich über mehrere Teams. Und es bleibt in der Regel bei denen, die bereits beschäftigt sind oder ihre Branche ernst nehmen. Sie sind Studenten, daher sind ihre Interessen wahrscheinlich auf das beschränkt, was in Zukunft passiert. :)

Aber um Ihre Frage zu beantworten:

Wenn Sie mit ihnen in einem Team sind, müssen Sie das, was Sie für wichtig halten, so anwenden, dass es ihren Interessen zugute kommt. Als Beispiel: Sollten sie sich darüber beschweren, dass ihr Code viel kaputt geht, wenn die USB-Geräte ihn teilen? Dann geben Sie ihnen vielleicht eine einfache (nicht komplizierte) Möglichkeit, SVN (anstatt git) als Versionierungswerkzeug zu verwenden.

Ich stimme auch dem Kommentar von arnaud zu.

Sie haben den Nutzen all dieser Tools gesehen, als Sie mit ihnen gearbeitet haben, und so haben Sie den Wert in ihnen gesehen und warum Sie deren Verwendung verstanden haben. Wenn Ihre Teamkollegen keinen Mehrwert darin sehen, wie sie die Dinge derzeit tun, werden sie ihn nicht anwenden. Und das Traurige ist, dass dies sogar für Teams gilt, die aus Personen mit unterschiedlichem Erfahrungsniveau bestehen.

Der Ansatz hat Probleme:

1. Ihr Ansatz ist nicht symmetrisch. Ihre anderen Teammitglieder müssen sich ändern, aber Sie lernen nicht ihre guten Praktiken. In einer solchen Situation ist es schwierig, Regeln durchzusetzen. Besser wäre es, gute Regeln und Praktiken von allen Teammitgliedern zu sammeln, und dann liest jeder nur das resultierende Dokument.

2. Lernen ist schwierig. Die Regeln anderer Leute machen einfach keinen Sinn, weil diese Regeln nicht die logische Struktur haben, die Ihre Programmierer erwarten. Das Erzwingen von Regeln, die keinen Sinn ergeben, ist keine nützliche Aktivität.

3. Jeder lernte verschiedene Dinge. Es ist natürlich, dass Programmierer mit unterschiedlichem Hintergrund verschiedene Dinge gelernt haben. Ihre Stärken sind unterschiedlich, und die Schreibweise von Code ist unterschiedlich. Die Werkzeuge, die sie verwenden, sind unterschiedlich. Das Durchsetzen einer Reihe von Regeln / Tools / Stilen wird zum Albtraum, da die Einschränkungen die Stärke verlieren, die Entwickler über Jahre hinweg gelernt haben.
4. Veränderung braucht Zeit. Während es der Person, die die Regeln erfunden hat, die Sie durchsetzen, ziemlich leicht fällt, die Regeln zu befolgen, leiden alle anderen und verbringen Zeit damit, die neuen Regeln zu lernen. Dies ist ein Grund, warum jeder im Team in der Lage sein sollte, die Regeln zu ändern.
5. Die Auswahl von Tools / Codierungskonventionen oder -stilen für ein ganzes Team ist schwierig . Es kann nur langsam im Laufe der Zeit durchgeführt werden, um zu testen, was funktioniert und was nicht. Einem Team 2 Wochen Zeit zu geben, um 50 Regeln zu befolgen, wird nicht funktionieren.

Ich habe genau dieses Problem an der Universität gefunden. Viele Menschen sind einfach nicht bereit, eine andere (und vielleicht professionellere) Arbeitsweise zu erlernen.

Wenn Sie jedoch über Systeme verfügen und erklären, wie Sie das System verwenden, sind viele Leute bereit, es auszuprobieren. Ich denke auch, dass die Repositorys unter den verwendeten Werkzeugen sind und die Leute normalerweise nur so etwas wie eine Dropbox verwenden.