Come aggiungere un nuovo sviluppatore al team

La cosa migliore da fare è non gettare nel fuoco il nuovo sviluppatore, ma invece ritagliare alcune funzionalità e / o correzioni di bug che lo sviluppatore non dovrebbe avere problemi a saltare dentro. Trova un'area che ha bisogno di un lavoro che non richieda a una persona di conoscere l'intera architettura, i requisiti e il codice base in una sola volta. Forse ha lui o il suo lavoro sulla documentazione per imparare il sistema più velocemente.

Invece di aggiungere un nuovo sviluppatore al team, valuta la possibilità di aggiungere un consulente esperto per il periodo da due a tre mesi per gestire l'aumento temporaneo del carico di lavoro della tua azienda. L'idea è di ottenere qualcuno in grado di gestire un tempo di avviamento quasi zero, ma allo stesso tempo potrebbe non essere necessariamente la migliore aggiunta alla tua squadra.

Anche se ritieni che l'aumento del carico di lavoro non sia temporaneo, ora probabilmente non è il momento migliore per far crescere il tuo team in modo organico: aggiungere un terzo sviluppatore è una cosa stressante per una squadra anche senza una pressione dalla scadenza del progetto; la scadenza ristretta non fa che peggiorare la transizione.

Il compromesso è che in cambio di un aiuto temporaneo otterrai codice scritto da un estraneo. Per mitigare questo rischio, assicurati che entrambi eseguiate tutte le revisioni del codice con lui. Assicurati di rivedere e comprendere anche tutti i suoi test unitari.

Is it a good idea to add a person now?

No. Se possibile, prova a chiedere al cliente di accettare la riduzione dell'ambito.

L'aggiunta di una persona in ritardo comporta un rischio significativo e la scadenza non può essere spinto (per quanto ho capito).

Non farlo.

Ancora.

Visualizzazione tradizionale

Nella tua domanda, fai riferimento alla legge di Brooks da Mese mitico .

Adding manpower to a late software project makes it later.

Ignorare la legge di Brook ha un prezzo. Non multitask. Concentrati sulla consegna del tuo prodotto minimo vitale (MVP). Quindi concentra le tue energie su reclutamento, risorse, formazione e gestione di un nuovo membro del team.

Due mesi sono così brevi. Pianifica il reclutamento con un elenco di burn down e vedrai quanto può essere dispendioso in termini di tempo.

Larry Page e Sergei Brin hanno trascorso due anni a scegliere il team iniziale per Google. La scelta per il dipendente numero tre dovrebbe essere anche attenta.

Agile, New Millenium View

La competizione guida il team dinamico più ora che nell'epoca in cui è stato scritto Mythical Man-Month (metà degli anni '60). Le lunghe carriere in una compagnia sono sparite. Ora migriamo frequentemente tra progetti e aziende. Il rapido team building crea successo. L'accelerazione lenta è un grave fattore limitante. Ottimi esempi provengono da progetti open source, start-up e un maggiore uso di progetti di team in corsi di informatica.

Potenzialmente, i team Agile vincolano i vincoli nei loro programmi. Non sono in ritardo perché sono ottimizzati per le risorse disponibili. L'integrazione di nuovo personale è un ulteriore ostacolo e considerato un compromesso tra obiettivi a breve e a lungo termine. Il team Agile integra continuamente il codice, quindi perché non anche le persone?

L'integrazione tecnica e sociale del team agile per il nuovo personale può utilizzare:

• scrums giornalieri
• coppia programmazione
• refactoring
• aggiunta di test unitari mancanti
• ingrasso di documentazione snella
• recensioni di codice

L'agnello sacrificale

In " Modelli organizzativi di sviluppo software agile" James Coplien parla delle dinamiche di gruppo e dei costi relativi all'aggiunta di nuovi membri del team . Il suo modello "Sacrificial Lamb" assegna tutto il mentoring e l'allenamento a una persona, proteggendo il resto della squadra dall'interruzione.

È una strategia che potresti voler prendere in considerazione.

Un'altra strategia consiste nell'assegnare nuovi mentori di noleggio che coprono le domande dei nuovi assunti per ore particolari ogni giorno. Se puoi risparmiare solo un ragazzo, forse lavora senza interruzioni al mattino o al pomeriggio e risponde alle domande rispettivamente nel pomeriggio o nella mattina. Il gruppo in cui sono stato ha avuto dieci stagisti la scorsa estate, quindi molte persone sono state interrotte molto.

Attualmente il tutoraggio è fatto da una persona, principalmente durante e immediatamente dopo la mischia mattutina (dalle 8:30 alle 9:15 del mattino, in combinazione), e nel pomeriggio tra le 12 e le 3:30 (lavora alle 7 del mattino - 3:30 pm).

Sono rincuorato che tu abbia menzionato la legge di Brook. Ben fatto. Il problema principale con l'aggiunta di un altro sviluppatore è il sovraccarico nel farli accelerare e il sovraccarico dello stato di sincronizzazione con loro su dove ci si trova nel progetto. Pertanto, se decidi di ottenere un terzo sviluppatore, proverei questo:

• Dai al nuovo ragazzo un'area in cui i costi di up-to-speed sono bassi e può iniziare il più rapidamente possibile. Ciò dipenderà molto da chi assumi e quali competenze hanno.
• Assicurati che quest'area sia liberamente accoppiata con altre aree dell'applicazione in modo che l'overhead di sincronizzazione sia inferiore. Inviarlo a fare intenso lavoro su DB e riorganizzare le tabelle potrebbe essere troppo.
• Fai quello che puoi per far salire il morale. Come altri hanno notato, aggiungere un nuovo membro del team può essere stressante, quindi forse un investimento in bevande gassate potrebbe aiutare.

Se segui rigorosamente la legge di Brook, probabilmente non farai mai crescere la tua squadra.

Il trucco è portare la nuova persona senza subire troppi rallentamenti sulla tua squadra attuale. Alla fine la nuova persona sarà in grado di accelerare, e tu potrai superare la gobba.

Nel tuo caso? Vorrei raccomandare alla nuova persona di scrivere tutti quei test unitari mancanti.

1. Quelle sono estremamente necessarie come salvaguardia contro gli errori di regressione, che ti brucerà più velocemente di qualsiasi rallentamento di Brooks.
2. Una nuova persona imparerà il coraggio del tuo sistema. È un po 'a prova al fuoco - ma il loro output non sta andando nel codice di produzione, così poco rischio lì.
3. Posiziona un limite rigido su quanto tempo gli altri membri del team hanno potere prendere. Ad esempio, invitali a mettere in fila le domande e consenti solo 30 minuti al giorno che interagiscono con gli altri membri del team fino alla scadenza è soddisfatto.

Inoltre, diciamocelo: dovrai gestire la portata e le aspettative del cliente indipendentemente dal fatto che tu porti una nuova persona o meno. Il pagamento è il prossimo ciclo.

Ed Yourdon ha avuto un grande commento su Brook's Law. Ha detto: naturalmente, l'aggiunta di persone ti farà andare più lentamente - ma quando un progetto è a rischio è l'unico momento in cui la gestione porterà nuove persone. Quindi: prendili, minimizza l'impatto sull'attuale versione e sbarazzati degli artisti poveri il prima possibile. In questo modo, nel tempo, puoi creare una squadra strong.

Se hai progetti su altri progetti che puoi dargli, libererai tempo per i 2 attuali sviluppatori di concentrarti sui risultati finali di grande scadenza che potrebbero aiutarti.

Dici di aver bisogno di completare il 25% del lavoro originale, più un nuovo lavoro. E hai bisogno di farlo in due mesi - quando ci sono voluti 18 mesi per fare il 75% del lavoro. Per essere molto schietto, questo mi indica che le tue capacità di stima sono nella media per un programmatore incentrato sul codice - cioè, pensi che le cose ti porteranno da circa la metà a un terzo, a patto che lo facciano davvero.

Gli Heroics ti consentono di consegnare il prodotto per il quale hai stipulato un contratto, ma questo non porterà benefici a te o ai tuoi clienti. Sarà malridotto e infestato da cimici in queste condizioni, e tu correrai sui fumi.

Tieni presente che il tempo trascorso con l'assunzione avrà anche un impatto importante sulla tua disponibilità: non è qualcosa che puoi fare solo in un weekend, ci vuole del tempo per trovare dipendenti di talento che si adattino bene. Aspettatevi di passare almeno un paio di settimane a cercare, intervistare, ecc. Aspettatevi che voi e il vostro dipendente attuale perderete circa 10 ore alla settimana di tempo produttivo durante la ricerca.

La mia raccomandazione:

Siediti con il tuo cliente, spiega che sei fuori di testa e lavora con lui per ridurre lo scope al minimo.

Modifica Ho appena visto la data qui. Quindi come è finita? (Grazie Ars Technica per aver postato una domanda di tre mesi;)

Ci sono un paio di modi diversi in cui prendere in considerazione di investigare:

1. Impedisci all'assunzione del nuovo sviluppatore fino a dopo la scadenza, in modo che sia più facile concentrarsi sul passaggio della conoscenza del dominio al nuovo ragazzo. Questa sarebbe la mia preferenza in quanto potrebbe essere leggermente difficile in alcuni modi.

2. Avvicinati al nuovo sviluppatore per lavorare su documentazione, test unitari e altre cose che non modificano alcun codice esistente. Questo sarebbe quello che suggerirei se portassi il nuovo ragazzo per cercare di minimizzare l'impatto sul carico di lavoro corrente.

La data è già passata, ma per tutti coloro che lo leggono più tardi.

La cosa fondamentale da considerare è che il cliente in questa situazione ha molto più da perdere rispetto a te. Hanno già speso un sacco di soldi e hanno un evento chiave in arrivo che potrebbe creare o distruggere la loro attività. Hai già i loro soldi e perdere un solo cliente non dovrebbe interrompere la tua attività. Se lo fa, allora hai altre serie questioni commerciali oltre la terribile gestione del progetto.

La soluzione migliore è negoziare un sottoinsieme essenziale di funzionalità e quindi eseguire gli straordinari per farlo. Se non riesci a creare un sottoinsieme più piccolo o non sei disposto a fare straordinari in quella situazione, probabilmente non dovresti esserlo. Ciò potrebbe significare mettere in attesa altri clienti, tuttavia suppongo che i tuoi altri clienti non abbiano pagato per 3 anni di tempo, quindi metti le tue risorse dove sono i soldi.

Se non sono disposti a negoziare lo scope verso il basso, allora sei impostato per fallire.

Non c'è alcuna possibilità di consegnare questo progetto completamente nel tempo. Se pensate di aver lasciato il 25% su un progetto che ha richiesto 18 mesi per essere consegnato finora, vi restano almeno 6 mesi (di ~ 2 sviluppatori). L'aggiunta di un'altra persona non cambierà significativamente la situazione.

Come è stato sottolineato, il reclutamento richiede tempo. La mia esperienza è che ci vuole un mese al minimo. Quindi aggiungi allenamento e il tuo tempo è scaduto.

Spero che questo abbia funzionato per te.