Wird ein separates Teilprojekt von erfahrenen Entwicklern dazu beitragen, dass die Neulinge schneller auf Touren kommen?

Wir haben 7 Entwickler in einem Team und müssen unser Entwicklungstempo in kurzer Zeit (ungefähr einem Monat) verdoppeln. Ich weiß, dass es eine vernünftige Regel gibt: "Wenn Sie mehr Entwickler einstellen, verlieren Sie nur in den ersten Monaten an Produktivität." Das Projekt ist ein E-Commerce-Webdienst mit rund 270.000 Codezeilen.

Meine Idee ist es, das Projekt in zwei mehr oder weniger unabhängige Unterprojekte aufzuteilen und das neue Team an dem kleineren der beiden Unterprojekte arbeiten zu lassen, während das aktuelle Team am Hauptprojekt arbeitet. Das neue Team wird nämlich an der Checkout-Funktionalität arbeiten, die schließlich zu einem unabhängigen Webdienst wird, um die Kopplung zu verringern. Auf diese Weise arbeitet das neue Team an Projekten mit nur 100.000 Codezeilen.

Meine Frage ist: Hilft dieser Ansatz neuen Entwicklern, sich leicht an das neue Projekt anzupassen? Wie kann das Entwicklerteam auf andere Weise schnell erweitert werden, ohne zwei Monate warten zu müssen, bis Neulinge mehr Software als Fehler produzieren?

=======

AKTUALISIEREN

Dieses Unternehmen ist völlig gescheitert, aber nicht aus den von Ihnen genannten Gründen. Zunächst einmal war ich über die Größe und Leistungsfähigkeit des neuen Teams falsch informiert. Ich hätte sie selbst bewerten sollen. Zweitens stellte sich heraus, dass die Einstellung an diesem Standort eine harte Aufgabe war. Am Standort des Hauptbüros war die Einstellung viel einfacher, aber in der Stadt des zweiten Teams gab es anscheinend einen Mangel an Entwicklern mit der erforderlichen Qualifikation. Infolgedessen verlängerte sich die Stelle anstatt der geplanten 1,5 Monate auf etwa 4,5 Monate und wurde in der Mitte vom Top-Management abgebrochen.

Ein weiterer Fehler, den ich gemacht habe (und vor dem Alex D gewarnt hat), ist, dass ich versucht habe, das Refactoring an das Top-Management zu verkaufen. Sie verkaufen niemals Refactoring, sondern nur Funktionen.

Der Start stellte sich trotzdem als erfolgreich heraus. Das Refactoring, das nie stattfand, wurde zu einer technischen Verschuldung: Das System wurde monolithischer und weniger wartbar, und die Entwicklerproduktivität nahm allmählich ab. Ich bin jetzt nicht im Team, aber ich hoffe, dass sie es in naher Zukunft abschließen. Sonst würde ich keinen Cent für das Überleben des Projekts geben.

Trotzdem stimme ich wie alle anderen hier zu, dass:

"... einem verzögerten Projekt mehr Entwickler hinzuzufügen, macht das Projekt, um mehr zu verzögern ..."

Ich habe das Gefühl, du wirst es überall tun, also ...

Ihre Idee kann hilfreich sein, wenn Ihr vorhandenes Projekt nach Modulen, Subsystemen oder Subprojekten organisiert ist.

Was Sie vielleicht versuchen möchten, ist es, ihnen kleine Teile / Module / Formen / Klassen Ihres Projekts zu geben, mit denen Sie arbeiten können, anstatt mit dem gesamten Projekt.

Wenn Sie eine Datenbank verwenden, möchten Sie möglicherweise eine Kopie einer funktionierenden Datenbank mit Daten erstellen und über das Modul oder das Subsystem des Codes, mit dem Sie arbeiten möchten, darauf zugreifen.

Es reicht nicht aus, neue Entwickler zu haben, die die Programmiersprache oder die Programmierumgebung kennen, da Softwareanwendungen sehr komplex werden können.

Haben Sie eine Dokumentation der Anwendung wie: UML, ER, Codd-Yourdon, was auch immer?

Viel Glück.

Meine Frage ist, ob dieser Ansatz neuen Entwicklern hilft, sich leicht an das neue Projekt anzupassen.

"Neuling" kann für Sie neu oder für die Arbeit als Softwareentwickler neu sein. Wenn Sie eine Gruppe von Entwicklern beauftragen, nach einem festgelegten Zeitplan an einem wichtigen Projekt zu arbeiten, stellen Sie sicher, dass mindestens die meisten der neuen Mitarbeiter erfahrene Entwickler sind, vorzugsweise solche, die Projekte geschrieben haben, die Ihren Vorstellungen ähneln bauen.

Wie kann das Entwicklerteam auf andere Weise schnell erweitert werden, ohne zwei Monate warten zu müssen, bis mehr Software als Fehler produziert wird?

• Kaufen oder lizenzieren Sie ein vorhandenes Produkt, anstatt zu versuchen, ein eigenes zu erstellen. Müssen Sie das Kassenrad wirklich neu erfinden?

• Wie ich bereits sagte, stellen Sie Leute ein, die Erfahrung im Aufbau des von Ihnen gewünschten Systems haben.

• Noch bevor Sie dieses neue Team einstellen, sollten Sie darüber nachdenken, was es über Ihre vorhandenen Aufgaben wissen muss. Stellen Sie sicher, dass Sie genügend Zeit für Schulungen reservieren, um sie auf den neuesten Stand zu bringen.

• Haben Sie schriftliche Anforderungen erstellt? Wenn nicht, mach das jetzt. Wenn Sie das Projekt entwerfen möchten, anstatt das neue Team dazu zu bewegen, sollten Sie auch ein übersichtliches Designdokument vorbereiten. Sie sollten jedoch offen für Änderungen sein, die sich aus den Beiträgen der neuen Teammitglieder ergeben.

• Haben Sie einen genau definierten Entwicklungsprozess? Fehlerdatenbank? Versionskontrolle? Code-Überprüfungsprozess? Gestaltungsrichtlinie? Bringen Sie diese Dinge an Ort und Stelle.

• Erwarten Sie keine Wunder. Sie möchten ein Team mit sieben Mitarbeitern einstellen, das innerhalb weniger Wochen produktiv arbeitet. Wenn Sie dies jedoch möchten, bedeutet dies nicht, dass Sie das können. Je nachdem, wo Sie sich befinden, kann es viel länger als einen Monat dauern, bis Sie sieben geeignete Personen gefunden haben. Der Versuch, Dinge jetzt zu beschleunigen, wird erst später Schmerzen und Kosten verursachen.

IMHO alle neuen Entwickler auf das neue Projekt zu setzen, von Ihrem bestehenden Team getrennt, ist verpflichtet, Probleme zu bringen. Ja, dies (kann) dazu führen, dass Ihr altes Team mehr oder weniger im aktuellen Tempo weiterarbeitet. Die neuen Leute haben jedoch keine Ahnung von der Gesamtarchitektur und dem Gesamtbild, daher werden sie viel Zeit in Anspruch nehmen, um sich auf dem Laufenden zu halten ... und selbst dann könnten sie in die falsche Richtung gehen.

Ich schlage vor, Ihr bestehendes Team in zwei zu teilen und neue Mitglieder in beide Teams einzustellen. Auf diese Weise gibt es in beiden Teams Leute, die die Neuankömmlinge betreuen und sicherstellen können, dass eine gemeinsame, kohärente architektonische Vision aufrechterhalten wird.

Ansonsten stimme ich Caleb zu, wenn es darum geht, klare Anforderungen zu dokumentieren, den Entwicklungsprozess und die Tools zu definieren und Zeit für Schulungen zu reservieren. Außerdem ist es unrealistisch, zu erwarten, dass ein 7-köpfiges Team innerhalb eines Monats eingestellt und auf den neuesten Stand gebracht wird.

Dmitry, das Verdoppeln Ihres Entwicklungstempos in kurzer Zeit ist ein unglaublich ehrgeiziges Ziel. Einige gute Vorschläge wurden hier veröffentlicht. Beachten Sie jedoch, dass dies möglicherweise nicht der Fall ist . Wenn sich Ihr Entwicklungstempo nicht verdoppelt, was wären die Konsequenzen aus geschäftlicher Sicht? Versuchen Sie, eine Frist einzuhalten?

Wenn Sie versuchen, einen Termin einzuhalten, können Sie diesen dann zuverlässiger durchführen, indem Sie Features kürzen? Ich habe einen großartigen Weg gefunden, um "versäumte Fristen" für einen Kunden akzeptabel zu machen, indem ich inkrementelle Releases durchführe. Geben Sie eine Version mit einer Untergruppe der erforderlichen Funktionen frei. Sobald weitere Funktionen verfügbar sind, geben Sie diese schrittweise bis zur endgültigen Version frei.

Sie versuchen also, das Team zu sein, das nicht dem Monat des mythischen Mannes zum Opfer fällt . Sie werden mehrere Probleme haben, jemand im Team wird die technischen Interviews durchführen müssen, dann müssen Sie ein paar Wochen warten, nachdem sie die Position angenommen haben, bevor sie beginnen können. Es kann zwei Monate dauern, bis die neuen Entwickler vor ihren Tastaturen stehen.

Jeder neue Mitarbeiter hat in den ersten Monaten eine negative Produktivität. Es wird noch schlimmer, weil die derzeitigen Entwickler sie betreuen müssen, was die Produktivität der Systeme weiter senkt.

Der andere Teil des MMM war, dass mit dem Wachstum des Teams auch die Kommunikationsprobleme auftreten. Meetings werden größer, E-Mail-Ketten länger ...

Ich würde sie in kleineren Gruppen aufführen und wissen, dass die Produktivität für eine lange Zeit nicht proportional zur Größe des Teams sein wird. Beachten Sie auch, dass die Belastung des Cashflows in den ersten Monaten aufgrund der Kosten für das Boarding und der Ausrüstung erheblich sein kann.

In Ihrem Kommentar zu Alex D haben Sie erwähnt: "Es sind nicht die Fristen, die wir einhalten, sondern die nachweisliche Fähigkeit, neue Funktionen bereitzustellen." Wechseln Sie also zu einem Entwicklungsstil, der die Features in kleineren Blöcken und häufiger ausspielt. Lassen Sie die neuen Mitglieder des Teams die neuen Funktionen testen, damit sie die Codebasis besser verstehen.

Es ist besser, wenn Sie niemanden neu einstellen und Ihre Prozesse überprüfen, um festzustellen, wo Sie Änderungen vornehmen können, damit die Dinge schneller laufen. Je früher Fehler gefunden werden, desto weniger Zeit wird für deren Behebung benötigt. Wie testen Sie? Machst du Code-Reviews? Achten Sie auf die Qualität der Anforderung? Haben Sie automatische Build- und Deplot-Prozesse? Haben Sie automatisierte Tests? Haben Sie tägliche Stand-up-Meetings (Erstaunlich, wie viel schneller die Entwicklung sein kann, wenn Sie jeden Tag jemand nach Ihrem Fortschritt fragt!)? Verwenden Sie agile Prozesse? Haben Sie einige grundlegende Designfehler, die behoben werden sollten, damit der Rest der Entwicklung schneller vonstatten geht (schlechtes Design kann ein Entwicklungsprojekt unglaublich verlangsamen)?

Bitte lesen Sie den Mythical Man-Monat. Sie müssen dies unbedingt tun, um der Geschäftsleitung mitteilen zu können, warum sie die richtigen Entscheidungen trifft, um ein Projekt zu beschleunigen. .

Also willst du sie von einer Klippe werfen und sehen, ob sie fliegen können? Ich denke, wenn Sie Dinge auf eigene Faust entdecken, bleiben sie auf lange Sicht eher bei Ihnen als nur Lösungen. Dies setzt jedoch voraus, dass Sie tatsächlich bessere Lösungen finden. Ich verstehe nicht, warum Sie nicht zulassen können, dass dieses Team einen qualifizierten Leiter hat, der es ihnen erlaubt, selbst Fehler zu machen und ihnen durch das Lernen aus Qualitätsbeispielen Anleitung und Anweisungen zu geben.