Dare alle nuove reclute un sottoprogetto separato da sviluppatori esperti aiuterà i neofiti a crescere più rapidamente?

Abbiamo 7 sviluppatori in un team e dobbiamo raddoppiare il nostro ritmo di sviluppo in un breve periodo di tempo (circa un mese). So che esiste una regola di buonsenso che "se assumi più sviluppatori, perdi la produttività solo per i primi mesi". Il progetto è un servizio web di e-commerce e ha circa 270.000 righe di codice.

La mia idea per ora è quella di dividere il progetto in due sottoprogetti più o meno indipendenti e lasciare che il nuovo team lavori sul più piccolo dei due sottoprogetti, mentre il team attuale lavora sul progetto principale. Vale a dire, il nuovo team lavorerà sulla funzionalità di checkout, che alla fine diventerà un servizio web indipendente al fine di ridurre l'accoppiamento. In questo modo, il nuovo team lavora su progetti con solo 100.000 righe di codice.

La mia domanda è: questo approccio aiuterà gli sviluppatori principianti ad adattarsi facilmente al nuovo progetto? Quali sono altri modi per estendere rapidamente il team di sviluppo senza aspettare due mesi fino a quando i neofiti iniziano a produrre più software che bug?

=======

AGGIORNARE

Questa impresa è fallita completamente, ma non per i motivi menzionati. Prima di tutto, sono stato male informato sulle dimensioni e le capacità del nuovo team. Avrei dovuto valutarli da solo. In secondo luogo, l'assunzione si è rivelata un duro lavoro in quel sito. Nel sito dell'ufficio principale l'assunzione era molto più semplice, ma nella città della seconda squadra apparentemente c'era carenza di sviluppatori con la qualifica richiesta. Di conseguenza, invece di 1,5 mesi previsti, il lavoro è stato prolungato a circa 4,5 mesi ed è stato annullato nel mezzo dal top management.

Un altro errore che ho fatto (ed è stato avvertito da Alex D) è che stavo cercando di vendere refactoring al top management. Non vendi mai refactoring, solo funzionalità.

La startup si è comunque rivelata vincente. Il refactoring che non è mai accaduto si è trasformato in debito tecnico: il sistema è diventato più monolitico e meno mantenibile, la produttività degli sviluppatori è gradualmente diminuita. Non faccio parte del team adesso, ma spero che lo completino nel prossimo futuro. Altrimenti, non darei un soldo per la sopravvivenza del progetto.

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

"... l'aggiunta di più sviluppatori a un progetto ritardato, rende il progetto, ritardare di più ..."

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

La tua idea può aiutare, se, il tuo progetto esistente, è abbastanza organizzato, da moduli, sottosistemi o sottoprogetti.

Quello che potresti voler provare è quello di 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 DB funzionante con i dati e accedervi dal modulo o sottosistema di codice con cui andremo a lavorare.

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

Hai qualche documentazione sull'applicazione come: UML, ER, Codd-Yourdon, qualunque cosa?

In bocca al lupo.

La mia domanda è: questo approccio aiuterà gli sviluppatori principianti ad adattarsi facilmente al nuovo progetto?

"Principiante" potrebbe significare nuovo per te, o potrebbe significare nuovo lavorare come sviluppatori di software. Se hai intenzione di assumere un gruppo di sviluppatori per lavorare su un progetto importante secondo un programma, 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.

Quali sono altri modi per estendere rapidamente il team di sviluppo senza aspettare due mesi prima che inizino a produrre più software che bug?

• Acquista o autorizza un prodotto esistente invece di provare a crearne uno tuo. Hai davvero bisogno di reinventare la ruota del checkout?

• Come ho detto sopra, assumi persone che hanno esperienza nella costruzione del tipo di sistema che desideri.

• Anche prima di assumere questo nuovo team, dovresti pensare a cosa dovranno sapere sulle tue cose esistenti. Assicurati di riservare abbastanza tempo per le sessioni di allenamento per aiutarli ad accelerare.

• Hai creato una serie scritta di requisiti? In caso contrario, fallo ora. Se si prevede di progettare il progetto invece di lasciare che il nuovo team lo faccia, è necessario preparare anche un documento di progettazione chiaro, ma essere aperto alle modifiche in risposta all'input dei nuovi membri del team.

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

• Non aspettarti miracoli. Si consiglia di assumere un team di sette persone e li hanno lavorare in modo produttivo in una questione di settimane, ma volendo non significa che si può avere questo. A seconda di dove ti trovi, potrebbe essere necessario molto più di un mese solo per trovare sette persone adatte. Cercare di affrettare le cose ora causerà dolore e spese solo in seguito.

L'IMHO che mette tutti i nuovi sviluppatori nel nuovo progetto, separati dal team esistente, è destinato a causare 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 accelerare ... e anche allora potrebbero andare nella direzione sbagliata.

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

Altrimenti, sono d'accordo con Caleb per quanto riguarda la documentazione dei requisiti chiari, la definizione del processo e degli strumenti di sviluppo e la riserva di tempo per l'addestramento ... e anche che aspettarsi che un team di 7 persone venga assunto e aggiornato entro un mese è irrealistico.

Dmitry, raddoppiare il tuo ritmo di sviluppo in breve tempo è un obiettivo incredibilmente ambizioso. Alcuni buoni suggerimenti sono stati pubblicati qui; ma, qualunque cosa tu provi, tieni presente che potrebbe non accadere . se il tuo ritmo di sviluppo non raddoppia, quali sarebbero le conseguenze, dal punto di vista aziendale? 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 "scadenze" accettabili per un cliente: fare rilasci incrementali; rilasciare una versione che ha un sottoinsieme delle funzionalità richieste e, man mano che sono disponibili più funzionalità, rilasciarle in modo incrementale, fino alla versione finale.

Quindi stai cercando di essere la squadra che non cade vittima del Mese dei Miti . Avrai diversi problemi, qualcuno nel team dovrà fare le interviste tecniche, quindi dovrai aspettare alcune settimane dopo aver accettato la posizione prima di poter iniziare. Potrebbero passare due mesi prima che i nuovi sviluppatori siano davanti alle loro tastiere.

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

L'altra parte del MMM era che, man mano che il team cresce, aumentano anche i problemi di comunicazione. Le riunioni diventano più grandi, le catene di e-mail diventano più lunghe ...

Li porterei in gruppi più piccoli e saprei che per lungo tempo la produttività non sarà proporzionale all'aumento delle dimensioni della squadra. Considera 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 menzionato "Non sono le scadenze che stiamo cercando, la sua capacità dimostrabile di offrire nuove funzionalità". Passa quindi a uno stile di sviluppo che definisca le funzionalità in blocchi più piccoli e più spesso. Chiedi ai nuovi membri del team di testare le nuove funzionalità, che li aiuteranno a comprendere la base di codice.

Faresti meglio a non assumere nessuno nuovo e guardare i tuoi processi per vedere dove è possibile apportare modifiche per rendere le cose più veloci. Prima vengono rilevati i bug, meno tempo ci vuole per risolverli, quindi come stai testando? Stai facendo recensioni di codice? Stai prestando attenzione alla qualità del requisito? Hai build automatizzati e processi di deplotyment? Hai dei test automatici? Stai organizzando riunioni stand-up quotidiane (Incredibile quanto può essere più veloce lo sviluppo quando qualcuno ti chiederà il tuo progresso ogni giorno!)? Stai usando processi agili? Hai alcuni difetti di progettazione di base che dovrebbero essere affrontati per rendere più veloce il resto dello sviluppo (una cattiva progettazione può rallentare incredibilmente un progetto di sviluppo)?

Si prega di leggere il Mito Man-month. Avrai chiaramente bisogno di essere in grado di dire al senior management perché stanno facendo le scelte consumate per accelerare un progetto. .

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