Wie können neue Teammitglieder mit dem Projekt auf dem Laufenden gehalten werden? [geschlossen]

Wir sind dabei, 1-2 neue Ingenieure für das Software-Team einzustellen (bestehend aus 3 Entwicklern, 1 Tester).

Was sind die Schritte, um sie in das Team zu integrieren?

Meine Ideen sind:

• Dokumentation lesen (Kodierungsstandards, Dokumente in Entwicklungsmethoden, die wir verwenden)
• Lassen Sie sie den vorhandenen Code lesen
• weisen Sie ihnen einige einfache Aufgaben zu
• am Ende machen Sie sie für den Codeteil verantwortlich

Was könnten wir noch tun?

Das Projekt befindet sich in einem medizinischen Bereich (Ultraschallsystem) und läuft bereits seit 5 Jahren. Wir haben jährliche Releases und stehen kurz vor dem Abschluss eines Releases, wenn wir 1-2 Ingenieure hinzufügen möchten.

Das Projekt befindet sich in der Wartungsphase (Refactoring des Legacy-Codes sowie Hinzufügen neuer Funktionen). Die Dinge liegen ziemlich im Zeitplan (mehr oder weniger).

Ich stamme von jemandem, der in meiner Karriere viele verschiedene Codebasen auf den neuesten Stand bringen musste. Ich würde Folgendes vorschlagen:

1. Verbringen Sie einen kurzen Zeitraum (möglicherweise ein oder zwei Tage) mit Aktivitäten im Zusammenhang mit der Verwendung des Produkts, damit Sie sich mit der Funktionsweise des Produkts vertraut machen können. Dies kann das Überprüfen von Fehlern oder das Ausführen von QS-Testplänen oder das Durchlaufen von Benutzerschulungen sein.
2. Arbeiten Sie an kleinen, lokalisierten Fehlern. Dadurch wird der Techniker mit dem Erstellen und Debuggen der Anwendung vertraut gemacht, ohne viel über die Architektur lernen zu müssen.
3. Schreiben Sie im Idealfall eine kleine neue Funktion, die lokalisiert ist. Auf diese Weise können sie einen Codeabschnitt schreiben und werden beim Schreiben mit den umgebenden Codeabschnitten vertraut, mit denen der neue Code arbeiten muss.

Erweitern Sie von dort aus den Umfang und die Komplexität von Aufgaben im Laufe der Zeit je nach Erfahrung und Eignung des Ingenieurs. Dadurch kann der Entwickler sein Wissen über die Codebasis auf natürliche Weise erweitern.

Ich würde es vermeiden, nur Aufgaben (Dokumentation oder Code) zu lesen. Das Lesen der Dokumentation wird sehr schnell langweilig und das Lesen von Zufallscode ist nicht hilfreich, da sie keinen Kontext haben, mit dem sie arbeiten können. Es ist schwer genug, Code für Code-Reviews zu lesen, wenn Sie das Produkt und die Codebasis bereits kennen. Ich sehe nichts Nützliches, wenn ein brandneuer Ingenieur nur den Code liest.

Ich habe das Gefühl, dass die meisten Menschen nur eine relativ geringe Toleranz für das Lesen von Dokumenten haben (gut für ein oder zwei Tage, aber darüber hinaus werden sie wahrscheinlich Lust haben, etwas praktischeres zu tun).

Ich glaube nicht, dass Sie den Code einer Anwendung wirklich verstehen können, ohne ein angemessenes Verständnis für die Anwendung selbst zu haben. Die Software verfügt vermutlich über zahlreiche Funktionen, mit denen sie als Benutzer „spielen“ kann. Sie müssen es eventuell testen können, daher würde ich davon ausgehen, dass es ziemlich wichtig ist, dass sie wissen, wie man es installiert, konfiguriert und allgemeine Aufgaben damit ausführt

Ich persönlich finde, dass ein Überblick über die Architektur auf hoher Ebene in der Regel sehr hilfreich ist, um ein grundlegendes Gefühl für die Funktionsweise zu bekommen. Weisen Sie einem leitenden Ingenieur in der ersten Woche möglicherweise ein oder zwei Stunden Zeit (oder sich selbst, falls erforderlich?) Zu, um dies einfach durchzuarbeiten die Grundnahrungsmittel der Hauptanwendung. B. alle Subsysteme verstehen und wissen, wie die Dinge miteinander verbunden sind, welche Bits von Software / Bibliotheken von Drittanbietern verarbeitet werden und welche Bits intern gewartet werden müssen. (Wenn Ihre Organisation nicht über eine aktuelle Dokumentation von wirklich außergewöhnlicher Qualität verfügt, können sie diese Dinge vermutlich nicht in den Griff bekommen, ohne dass ihnen jemand dies direkt mit einem Whiteboard erklärt: ))

Wenn Sie ihnen etwas zum Anfassen geben möchten, sind Wartungs- / Fehlerbehebungsaufgaben möglicherweise eine gute Möglichkeit, sie für eine Weile auf den neuesten Stand zu bringen (ein paar Wochen / Monate?) - sie befinden sich in Situationen, in denen bestimmte Funktionsbereiche betroffen sind müssen verstanden, getestet und getestet werden; Hilfestellung beim Aufbau von Kenntnissen über den Code, die Anforderungen, die vom Unternehmen verwendeten Tools, die Entwicklungsprozesse und die Produkte als Ganzes, ohne hoffentlich zu viel Zeit vom Rest des Entwicklungsteams in Anspruch nehmen zu müssen

Als Lead verbringe ich mindestens 2 Tage mit neuen Entwicklern. Ich habe festgestellt, dass die Entwicklung einer Beziehung, in der es sich angenehm anfühlt, die unvermeidliche Frage zu stellen, "wie ist Ihr Fortschritt?" ist ein Muss. Es gibt in jeder neuen Gemeinschaft Angst, sich einzufügen ... wir verbergen Fehler, handeln perfekt, machen Dinge besser als sie sind, verringern Schwierigkeiten. Ein Manager, der zwei Tage mit jemandem zusammen verbringt, lässt ihn wissen, dass es nicht um diese Kultur geht, und lässt ihn mit gutem Beispiel vorangehen. Neue Programmierer benötigen eine Geschichtsstunde darüber, woher Sie gekommen sind und wie weit Sie unterwegs sind. Dokumente werden der Aufgabe einfach nicht gerecht.

Ich habe nur 10 Monate in der Industrie gearbeitet (Praktikum), aber ich habe festgestellt, dass mir Folgendes geholfen hat:

• Verbünde dich mit anderen Entwicklern und beobachte, wie sie Probleme angehen.
• Das Testen der Software hat geholfen, ich müsste Feature x testen, was bedeutet, dass ich die Dokumentation zu Feature x lese. Ich habe das viel gemacht, es hat geholfen.

Beide haben mir ein gutes Stück geholfen. Viel Glück.

Ich würde von hoch auf niedrig gehen.

Demo der App so schnell wie möglich

Eines der wichtigsten Dinge ist, dass der Entwickler eine Idee hat, woran er arbeiten wird. Zeigen Sie während der Demo einige der Dinge auf, die in letzter Zeit entwickelt wurden, und die Richtung, in die die App geht.

Erläutern Sie die Architektur auf hoher Ebene

Das ist auch sehr wichtig. Lassen Sie den neuen Entwickler zuhören und Fragen stellen. Tun Sie dies als Gruppenübung mit den anderen Entwicklern, die hoffentlich mitmachen und Ihnen helfen werden. Dadurch wird dem neuen Entwickler mitgeteilt, dass es in Ordnung ist, offen und ehrlich zu sprechen.

Halten Sie ein großartiges Borddokument bereit

Ein großartiges Onboarding-Dokument hilft nicht nur neuen Entwicklern, sondern auch alten. Es kann Erwartungen, nützliche Links und Informationen zur Einrichtung der Umgebung enthalten. (Ich kann Ihnen nicht sagen, wie oft ich unser On-Boarding verwendet habe, um meine Umgebung einzurichten, als ich einen neuen Computer bekam ...) Dies sollte gut strukturiert und auf den Punkt gebracht sein und nicht verweilen und nicht für jeden eine Müllhalde sein kleines Detail.

Ermutigen Sie ihn / sie, Fragen zu stellen (und verfügbar zu sein, um sie zu beantworten)

Führen Sie sie mit den Antworten, aber sagen Sie ihnen nicht, was sie tun sollen. Geben Sie ihnen Hinweise, aber lassen Sie sie es endlich selbst herausfinden.

Helfen Sie den anderen Teammitgliedern, den Neuling willkommen zu heißen

Es gibt zwei Seiten der Medaille, wenn sich jemand einem Team anschließt. Das Team muss über die Tools verfügen, um den neuen Entwickler ebenfalls willkommen zu heißen.

Lassen Sie sie ein oder zwei kleine Aufgaben übernehmen

Erlauben Sie ihnen, dem Projekt etwas Neues und Sichtbares hinzuzufügen, das demo-fähig ist. Wenn es vorgeführt wird, rufen Sie an, wer es getan hat und was für eine gute Arbeit sie geleistet haben. Dies kann das Selbstwertgefühl wirklich steigern. Je schneller sie sich wertschöpfend fühlen, desto schneller fühlen sie sich als Teil des Teams. Je schneller sie sich befähigt fühlen, das Beste zu tun, was sie können.

Ermutigen Sie sie, schwierige Aufgaben zu erledigen, sobald sie sich immer wohler fühlen

Gute Kandidaten werden dies natürlich tun.

Ein "Orientierungs" -Fluss, den ich durchlaufen habe (und für nützlich befunden habe), lautete:

1. Eine kurze Präsentation, die dem "Big Picture" zeigt, was die Komponenten sind, wie sie sich einfügen und wie die allgemeine Architektur aussieht.
2. Eine Übersicht über den Code, Einführung in die Funktionen, die die Hauptlogik für die mir zugewiesenen Komponenten handhaben. Behandelte einige Dinge im Zusammenhang mit Kodierungskonventionen und Stil.
3. Eine Reihe offener Probleme und Fehler mit niedriger Priorität wurden zugewiesen (die größtenteils auf die mir zugewiesene Komponente beschränkt und recht einfach waren).
4. Ich sollte über die Anwendung debuggen und um Hilfe bei Dingen bitten, die ich nicht entziffern konnte.
5. Nachdem die Fehlerbehebung vorgenommen wurde, wurde ich durch den Prozess der Freigabe für die Integration geführt (Codeüberprüfung, Testen auf Entwicklerebene usw.).
6. Wiederholen Sie diesen Vorgang für die verbleibenden zugewiesenen Aufgaben / Fehler.

Ich halte diesen Ansatz (und Variationen davon) für nützlich, weil:

• Dies war praktischer und relativ unabhängig (konstant kein Händchenhalten usw.). Somit hat die neue Person genügend Zeit, um sich an den Code und die Arbeitsweise im Team zu gewöhnen.
• Dies ist auch für das gesamte Team von Vorteil, da einige Aufgaben / Fehler mit niedriger Priorität behoben werden können. Die Person, die den neuen Menschen hilft, hat auch mehr Zeit für die Bearbeitung der ihnen zugewiesenen Aufgaben, da ein ständiges Händchenhalten nicht erforderlich ist und die Zeit speziell für die Behandlung von Problemen / Problemen eingeplant werden kann, mit denen die neue Person möglicherweise konfrontiert ist.

Anfängliche Einstellungen erfordern eine kleine, aber nicht zu kleine und genau festgelegte Aufgabe, an der gearbeitet werden muss. Auf diese Weise können sie ein Gefühl dafür bekommen, wie der Code strukturiert ist, indem sie versuchen, herauszufinden, wie sie ihre Aufgabe erfüllen können. Im Verlauf des Vorgangs werden Fragen gestellt, und an diesem Punkt können Sie sie an die Dokumentation oder andere Ressourcen weiterleiten, die sie zur Internalisierung der Codebasis verwenden können. Es hilft auch, wenn Ihr Entwicklungs-, Festschreibungs- und Bereitstellungszyklus kurz ist und sie die Früchte ihrer Arbeit so schnell wie möglich in Aktion sehen können.

So gehe ich vor

1. Geben Sie ihnen einige Aufgaben, die sich auf das Projekt beziehen (z. B .: Wenn es sich bei Ihrem Projekt um eine Datenbankanwendung handelt, bitten Sie sie, einfach eine Anwendung zu erstellen, um eine Verbindung mit der Datenbank herzustellen und eine einfache Operation auszuführen.)
2. Wenn Sie feststellen, dass sie die Idee der Arbeit verstanden haben, stellen Sie ihnen das Projekt vor
3. Bitten Sie sie, die Dokumentation zu lesen.
4. Machen Sie sie mit den Codierungsstilen und -standards vertraut
5. Geben Sie ihnen später einige Debugging-Übungen (um den Ablauf des Projekts zu kennen).
6. Bitten Sie sie, einen Punkt zu korrigieren, den Sie bereits korrigiert haben (nur um ihre Logik damit herauszufinden).
7. Machen Sie sie schließlich zu einem Teil des Projekts.

Denken Sie daran: Egal wie viel Sie versuchen, solange der Teilnehmer das Projekt nicht vollständig versteht, wird er seine Arbeit nicht am effizientesten erledigen können.

Nummer eins - lernen Sie zuerst, wie Sie die Software verwenden, um herauszufinden, welche Probleme sie aus der Sicht des Benutzers löst. Wenn es keine Benutzeroberfläche hat (z. B. ein Back-End-Service oder ähnliches), lassen Sie es die Benutzeroberfläche verwenden, die verfügbar ist, um sie zu nutzen. Es ist immer gut, die Sichtweise eines Benutzers auf Ihre Software auf den neuesten Stand zu bringen, und es kann dem neuen Mitarbeiter helfen, Dinge zu erkennen, die Sie nicht sehen können, da Sie bereits in das Projekt eingebettet sind.

Danach könnte ein gutes erstes Projekt so etwas wie ein Add-On oder ein neues Modul sein, das der Software hinzugefügt wird, um den Wissensbedarf der vorhandenen Codebasis zu minimieren. Es wird immer einfacher sein, etwas Neues zu schreiben, als eine Fehlerbehebung durchzuführen, die viele Änderungen in vielen Quelldateien erforderlich machen kann. Meiner Meinung nach wird ein neuer Mitarbeiter durch eine Fehlerbehebungsaufgabe wahrscheinlich von Ihrem Unternehmen ausgeschlossen.

Ihr Entwurf, um die neuen mit dem Projekt vertraut zu machen, erscheint vernünftig. Aber denken Sie daran, dass sie am Anfang viel zu lernen haben werden. Dies ist normalerweise eine überwältigende Situation. Sie müssen geduldig sein und die gleichen Fragen wiederholt beantworten. Das ist normal, neue Entwickler müssen viel lernen, unterschätzen Sie das nicht. Wenn Sie sich über diese wiederholten Fragen ärgern, riskieren Sie, dass sie nicht fragen und versuchen, Dinge herauszufinden, die möglicherweise sehr langsam, aber häufig unmöglich sind. Auch müssen sie den Jargon lernen. Die meisten Teamprojekte entwickeln ihre eigene Sprache. Versuchen Sie beim Erklären bewusst, den Jargon zu meiden. Erkläre dieses Zeug so, als würdest du es deiner Mutter erklären. Nochmals, sei geduldig.

Sie können auch versuchen, sie in die anderen Mitglieder des Teams zu integrieren, indem Sie einige Aufgaben im Assessment Center-Stil ausführen, z. Wir verwenden diese Technik in einem praktischen Kurs in Software-Engineering, um eine Gruppe von 8 Studenten dazu zu bringen, das Eis zu brechen, bevor sie 3 Wochen lang an einem einzelnen Projekt arbeiten. Es hilft, die Phasen der Teambildung zu beschleunigen.

1) Erklären Sie ihnen die Regeln und Richtlinien für Ihren Code. Erläutern Sie außerdem allgemein die Funktionsweise Ihrer Anwendung und die allgemeine Codestruktur.

2) Finden Sie einige kleine Fehler oder Projekte, die von anderem Code weitgehend unabhängig sind. Erklären Sie, was wo im Code zu tun ist, und überprüfen Sie diese regelmäßig.

3) Geben Sie ihnen langsam immer größere Projekte, während Sie sie immer weniger überprüfen.

4) Setzen Sie sich von Zeit zu Zeit neben sie. Sie können viel lernen, indem Sie nur schauen, wie jemand anderes ein Problem angeht. Kleinigkeiten wie "Oh, Sie können nach Funktionen in Ihrem Code suchen, indem Sie Strg- drücken." sind sehr nützlich.

Nun habe ich festgestellt, dass es zwei Extreme gibt :

• Jemand, der alle fünf Minuten eine Frage stellt. Msgstr "Was macht dieser Pfad?" Sie sollten zuerst bei Google nach einer Antwort suchen und erst dann zu Ihnen kommen, wenn sie keine Antwort finden.

• Und das andere Extrem, jemand, der einen halben Tag arbeitet, ohne eine einzige Frage zu stellen. Sie sollten das Gefühl haben, dass es gut ist, Fragen zu stellen. Ich möchte nur, dass sie es zuerst selbst ausprobieren.

Dies war meine Formel und wurde bei mehreren Neueinsteigern verwendet - diese Schritte erwiesen sich als äußerst effektiv.

a) Alle neuen Entwickler erhalten 2 Tage lang eine Einführung in die Projektanforderungen und Entwicklungsprozesse.

b) Zuweisung von 3 Wochen für das Schreiben von Junit-Tests für den Code, der nicht ausreichend abgedeckt ist.

c) Wenn 3 erledigt ist, weisen Sie kleine Aufgaben zu

d) Komplexe Aufgaben zuweisen und erledigt.

Ich denke, Sie müssen nur ein paar kleine Aufgaben zuweisen, sie bitten, ein paar Komponententests zu schreiben und sie dazu zu bringen, Fehler bei der Regression zu beheben. Nichts zu groß oder anspruchsvoll, aber genug, um sie auf den Beinen zu haben.

Sie sollten auch einen Senior-Entwickler beauftragen, vorzugsweise einen neuen Entwickler, der den Kandidaten als Mentor unterstützt.

Und ja, lassen Sie sie dokumentieren, was sie über das System lernen. Ich gehe hier davon aus, dass Sie eine Art interne Wiki-Seiten haben. Wenn nicht, ist es auf lange und kurze Sicht definitiv ein Muss. Wiki-Seiten sollten nicht nur die Codedokumentation enthalten, sondern auch Dinge wie bekannte Einschränkungen (dies ist Software: D), Problemumgehungen, Zeit- / Speicherleistungsmetriken usw.

Erklären Sie nicht nur die bewährten Methoden und Standards für die Codierung, sondern auch den Aufbau des gelesenen Codes. Erläutern Sie, was die Software tun soll und wie dies erreicht wird oder wird.

Sie werden es erst verstehen, wenn ein Job zu erledigen ist. Ich schlage daher vor, sich in zwei Teile zu teilen, einen, bevor sie mit der eigentlichen Arbeit beginnen, und den zweiten Teil, nachdem sie mit der Arbeit begonnen haben. Sie werden in einigen Codes oder Dokumentationen nachsehen und " WTF !? " denken . In diesem Fall begleitet Sie jemand und erklärt Ihnen die kleinen Details.