Dare ai nuovi assunti un sottoprogetto separato da sviluppatori esperti aiuta i neofiti a salire più rapidamente?

In alto, sono d'accordo come tutti gli altri qui, che:

"... l'aggiunta di altri sviluppatori a un progetto in ritardo, rende il progetto, per ritardare di più ..."

Ho la sensazione, lo farai, ovunque, quindi ...

La tua idea potrebbe aiutarti, se il tuo progetto esistente è abbastanza organizzato, da moduli, sottosistemi o sottoprogetti.

Che cosa potresti voler provare, è dare loro piccoli pezzi / moduli / forme / classi del tuo progetto, con cui lavorare, invece di tutto il progetto.

Se usi un database, potresti voler fare una copia di un D.B. con i dati e accedervi dal modulo o sottosistema di codice con cui lavoreremo.

Avere nuovi sviluppatori che conoscono il linguaggio di programmazione o l'ambiente di programmazione, non è sufficiente, le applicazioni software possono diventare molto complesse.

Hai una documentazione dell'aplicazione come: U.M.L., E.R., Codd-Yourdon, qualunque cosa?

Buona fortuna.

My question is will this approach help newbie developers to adapt easily to the new project?

"Newbie" potrebbe significare nuovo per te, o potrebbe significare nuovo per lavorare come sviluppatori di software. Se intendi assumere un gruppo di sviluppatori per lavorare su un progetto importante in base a una pianificazione, assicurati che almeno la maggior parte dei nuovi assunti siano sviluppatori esperti, e preferibilmente quelli che hanno scritto progetti simili a quello che stai provando costruire.

What are other ways to extend the development team rapidly without waiting two months until they start producing more software then bugs?

• Acquista o concedi in licenza un prodotto esistente invece di provare a crearne uno tuo. davvero hai bisogno di reinventare la ruota del checkout?

• Come ho detto sopra, assumi persone che hanno esperienza nel creare il tipo di sistema che desideri.

• Anche prima di assumere questo nuovo team, dovresti pensare a quello che avranno bisogno di sapere sulle tue cose esistenti. Assicurati di riservare abbastanza tempo per le sessioni di allenamento per aiutarle a migliorarle.

• Hai creato una serie scritta di requisiti? Altrimenti, fallo ora. Se prevedi di progettare il progetto invece di lasciare che il nuovo team lo faccia, dovresti preparare anche un documento di design chiaro, ma sii aperto alle modifiche in risposta all'input dei nuovi membri del team.

• Hai un processo di sviluppo ben definito? Database di bug? Controllo della versione? Processo di revisione del codice? Guida di stile? Metti a posto queste cose.

• Non aspettarti miracoli. vuoi assumere una squadra di sette persone e farle lavorare in modo produttivo in poche settimane, ma volerlo non significa che tu possa averlo. A seconda di dove ti trovi, potrebbe volerci molto più di un mese solo per trovare sette persone adatte. Cercare di affrettare le cose ora causerà solo dolore e spese più tardi.

IMHO che mette tutti i nuovi sviluppatori sul nuovo progetto, separati dal tuo team esistente è destinato a portare problemi. Sì, questo (può) lasciare che la tua vecchia squadra continui a lavorare più o meno al suo ritmo attuale. Tuttavia, i nuovi ragazzi non avranno la minima idea dell'architettura generale e del quadro generale, quindi impiegheranno molto tempo ad alzarsi alla velocità ... e anche allora potrebbero essere nella direzione sbagliata.

Suggerisco di dividere la tua squadra esistente in due e di assumere nuovi membri in entrambi i team. In questo modo ci sono persone in entrambe le squadre che possono guidare i nuovi arrivati e assicurare che venga mantenuta una visione architettonica comune e coerente.

Altrimenti, sono d'accordo con Caleb per quanto riguarda la documentazione di requisiti chiari, la definizione del processo di sviluppo e degli strumenti, e il tempo dedicato all'allenamento ... e anche il fatto che aspettarsi che un team di 7 venga assunto e aggiornato entro un mese sia irrealistico.

Dmitry, raddoppiando il tuo ritmo di sviluppo in breve tempo è un obiettivo ambizioso incredibilmente . Alcuni buoni suggerimenti sono stati pubblicati qui; ma, qualunque cosa tu provi, tieni presente che potrebbe non succedere . se il tuo ritmo di sviluppo non è non doppio, quali sarebbero le conseguenze, dal punto di vista del business? Stai cercando di spingere per rispettare una scadenza?

Se stai cercando di rispettare una scadenza, potresti farlo in modo più affidabile tagliando le funzionalità? Ho trovato un ottimo modo per rendere "accettabili le scadenze" accettabili per un cliente è quello di fare rilasci incrementali; rilascia una versione con un sottoinsieme delle funzionalità richieste, quindi, man mano che altre funzionalità sono pronte, rilascialo in modo incrementale, fino alla versione finale.

Quindi stai cercando di essere la squadra che non è vittima del mese di Mythical Man . Avrai diversi problemi, qualcuno nel team dovrà fare le interviste tecniche, quindi dovrai attendere alcune settimane dopo aver accettato la posizione prima che possano iniziare. Potrebbero essere passati due mesi prima che i nuovi sviluppatori si trovino di fronte alle loro tastiere.

Ogni nuovo dipendente ha una produttività negativa nei primi mesi. È peggiorato perché gli attuali sviluppatori avranno bisogno di guidarli, riducendo ulteriormente la produttività dei sistemi.

L'altra parte del MMM è stata la crescita del team, così come i problemi di comunicazione. Le riunioni diventano più grandi, le catene di email diventano più lunghe ...

Li porterei in gruppi più piccoli e so che per molto tempo la produttività non sarà proporzionale all'aumento della dimensione della squadra. Comprendere anche che il drenaggio del flusso di cassa durante i primi mesi può essere significativo, a causa dei costi di imbarco e delle attrezzature.

Nel tuo commento ad Alex D hai detto "Non sono le scadenze che ci aspettano, la sua capacità dimostrabile di offrire nuove funzionalità". Quindi passa a uno stile di sviluppo che definisce le funzioni in blocchi più piccoli e più spesso. Chiedi ai nuovi membri del team di testare le nuove funzionalità, in modo da aiutarle a capire il codice base.

Sarebbe meglio non assumere nessuno di nuovo e osservare i tuoi processi per vedere dove è possibile apportare modifiche per rendere le cose più veloci. Prima vengono trovati i bug, meno tempo ci vuole per risolverli, quindi come stai testando? Stai facendo recensioni di codice? Stai prestando attenzione alla qualità del requisito? Avete processi di compilazione e disinstallazione automatizzati? Hai test automatici? Stai facendo incontri giornalieri standup (Incredibile quanto più veloce sviluppo può andare quando qualcuno ti chiederà il tuo prion ogni giorno!)? Stai usando processi agili? Hai alcuni difetti di progettazione di base che dovrebbero essere risolti per far andare più velocemente il resto dello sviluppo (un design errato può rallentare incredibilmente un progetto di sviluppo).

Leggi il mese di Mythical Man. Avrete chiaramente bisogno di essere in grado di dire agli alti dirigenti perché stanno facendo le scelte usurate per accelerare un progetto. .

Quindi vuoi buttarli da un dirupo e vedere se riescono a volare? Penso che quando scopri le cose da solo, tendono a restare con te a lungo termine piuttosto che semplicemente avere soluzioni a te. Tuttavia, ciò presuppone che in realtà trovi soluzioni migliori. Non vedo perché non si possa permettere a questa squadra di avere un leader qualificato che si equilibri lasciandoli fare degli errori da soli insieme a dare loro guida e istruzioni imparando dagli esempi di qualità.