Tipps / Tricks zum Verwalten eines neuen Teams mit neuem Code [geschlossen]

Wie gehen Sie mit sich selbst in einem neuen Team um, in dem Sie der älteste Entwickler sind und die meisten anderen im Team mehrere Jahre jünger als Sie sind? Die Aufgabe vor dem Team hat noch niemand in Ihrer Karriere zuvor erfüllt.

Das Management besteht auf einer höheren Produktivität des gesamten Teams, und als leitender Entwickler sind Sie verantwortlich.

Irgendwelche Tipps, um in einer solchen Situation Trümpfe herauszuholen? Natürlich braucht das gesamte Team Zeit zum Lernen und wir dürfen die neuen des Teams nicht vergessen. Aber auch die Fristen stehen vor der Tür ...

Lassen Sie sich nicht von einer engen Frist oder der Neuheit des Projekts in die gute Ingenieurspraxis einmischen. Richten Sie ein Software-Repository ein, stimmen Sie einem Codierungsstil zu, erstellen Sie eine Testsuite usw. Die Neuheit der Aufgabe sollte keine große Rolle spielen, solange Sie qualifizierte Mitarbeiter unter sich haben, die dazu bereit sind arbeite hart und lerne die vor ihnen liegende Aufgabe.

Oder anders ausgedrückt: Sie wurden beauftragt, weil das Management der Ansicht ist, dass Ihr Hintergrund und Ihre Erfahrung Ihnen die Tools gegeben haben, die zum Erstellen hochwertiger Software erforderlich sind. Vergessen Sie nicht plötzlich Ihre Fähigkeiten, nur weil diese Aufgabe jetzt entmutigend erscheint.

Beginnen Sie zuerst mit der Verwendung eines Quellcode-Steuerungssystems ab der ersten Codezeile. Gewöhnen Sie sich an, Code früh und häufig einzuchecken.

Zweitens entscheiden Sie sich für eine Teststrategie . Das sollte natürlich Unit-Tests bedeuten, aber Sie sollten auch überlegen, wie Abnahmetests automatisiert werden können.

Drittens richten Sie einen kontinuierlichen Integrationsserver ein, damit Ihr Code regelmäßig erstellt und regelmäßig getestet wird.

Sobald Sie das haben, legen Sie als Team einige einfache Codierungsstandards fest . Sie möchten, dass Ihr Code für alle leicht lesbar ist. Es ist nicht wirklich wichtig, was die Standards sind. Einrücken mit Tabulatoren, Einrücken mit Leerzeichen, geschweifte Klammer in derselben Linie, was auch immer. Es ist egal, was sie sind, nur dass jeder sie konsequent anwendet.

Da das Team hauptsächlich aus Nachwuchsentwicklern besteht, sollten Sie den Code häufig überprüfen , um sicherzustellen, dass Ihrem System nicht zu viele technische Schulden entstehen.

Erwägen Sie schließlich die Verwendung von SCRUM . Wenn Sie dies tun, mieten Sie einen Trainer oder gehen Sie zu einem Training. Da Sie alle etwas tun, was Sie noch nie getan haben, ist es einfach unmöglich, realistische Fristen festzulegen. Mit SCRUM hat Ihr Management Einblick in Ihre täglichen Aktivitäten, sodass es sehen kann, welche Fortschritte erzielt werden (oder nicht). Und da Ihre Fristen anscheinend Ihnen gegeben wurden, garantiert SCRUM zumindest, dass Sie, wenn Sie die Frist nicht einhalten können, zumindest abgeschlossene Geschichten schrittweise liefern, was wohl besser ist, als mit einem Riesen zum Ende zu kommen System, das überhaupt nicht funktioniert.

Zusätzlich zur Antwort von @chrisaycock ... Unterschätzen Sie nicht die Zeit, die Sie für Mentoring / Training usw. benötigen. Als Lead müssen Sie lernen, die Details loszulassen und Ihrem Team zu vertrauen. Ihre Aufgabe ist es, der Enabler zu werden, Straßensperren zu entfernen und Störungen zu verursachen, wenn das Management dort einspringt. In einem "normalen" Team, bei etwa 7 oder 8, programmiert der Lead nicht mehr. In Ihrer Situation sinkt dieser Wert auf 3 oder 4 (vielleicht sogar weniger), Sie sind keine Programmierressource für das Projekt.

Konzentrieren Sie sich auf die Kommunikation in zwei Bereichen.

Es ist nicht einfach, dies zu tun, und das ist ein Grund, warum dieser Job schwierig ist. Wenn das Einhalten der Frist das Schneiden von Funktionen bedeutet, gehen Sie darüber hinaus. Das einzige, was Sie bei all dem vermeiden möchten, ist ein schneller Code, um eine Frist festzulegen. Dies ist der Anfang vom Ende einer Codebasis, die nicht gut hält, und der Beginn einer technischen Verschuldung, die erstickt.

2) Kommunikation zwischen Teams. Richten Sie formelle Praktiken ein, wie sie Bryan und andere empfehlen. Stellen Sie sicher, dass Sie sich regelmäßig als Team treffen, z. B. einmal pro Woche zusätzlich zu den täglichen Scrums. Gewinnen Sie Respekt und Vertrauen, indem Sie zuhören , Ihrem wichtigsten Werkzeug. Stellen Sie sicher, dass Sie sich darauf konzentrieren, zu helfen. Vermeiden Sie negative Kritik um jeden Preis. Verwenden Sie bei Bedarf positive Kritik und Ermutigung, z. B. "Das ist großartig. Wenn Sie einmal X in Betracht ziehen möchten, ist dies nicht das, was wir brauchen. Sie müssen stattdessen X tun."

Was ich getan habe, ist die fähigen zu identifizieren und zu teilen und zu erobern. Ich nehme die Top 2 oder 3 und mache sie zu Kapitänen. Die anderen werden dann gleichmäßig in Teams aufgeteilt, die den Kapitänen zu ihren eigenen kleinen Teams folgen.

Ich gebe den Kapitänen Chunks oder Module für ein Programm.

Die Kapitäne geben den Neulingen kleinere Programmier- oder Forschungsaufgaben, während sie sich selbst erklären, was sie tun, damit Mentoring währenddessen stattfindet.

Ich versuche, den Raum so zu gestalten, dass sich jeder im selben offenen Raum befindet, aber jedes Team seinen eigenen Computerkreis hat. Ich mag es, in schreiender Entfernung zu allen zu sein, damit sich die Dinge schnell bewegen.

Dies funktioniert bisher für etwa 10-20 Programmierer gut. Die kleineren Gruppen sind einfach besser in einer Gruppe zu sein und ich habe noch mit nichts Größerem gearbeitet.