Come aggiungere un nuovo sviluppatore al team

Gestisco una piccola azienda composta da solo 2 sviluppatori. Stiamo creando un'applicazione molto grande per uno dei nostri clienti. Lo sviluppo di questo progetto è andato avanti per 1,5 anni.

Ora questo cliente ha ottenuto un'importante sponsorizzazione e sta organizzando eventi legati a questo progetto. Quindi ora abbiamo una scadenza tra 2 mesi e non possiamo mancare.

Stiamo pensando di aggiungere un nuovo sviluppatore al team e mi chiedo cosa possiamo fare per aiutare la sua integrazione.

Questa è la situazione:

• Ci stiamo avvicinando alla soglia della legge di Brooks : il punto in cui aggiungere nuovi sviluppatori sarà controproducente.
• L'applicazione è relativamente ben progettata, ma l'implementazione è caotica in alcuni punti (in particolare il codice più vecchio).
• Esistono test unitari solo per codici più recenti. Quando è iniziato questo progetto, non abbiamo condotto regolarmente test.
• Documentazione e commenti sono incompleti.
• L'applicazione è ampia e complessa.
• Il cliente ha scritto quasi ogni dettaglio del suo progetto, in un modo molto chiaro e "adatto ai programmatori".

È una buona idea aggiungere una persona ora? In tal caso, cosa possiamo fare per aiutare il nuovo sviluppatore a integrarsi nel team?

MODIFICARE:

Lo sponsor sta organizzando un evento sportivo basato su Internet per la prossima primavera. Deve iniziare in un giorno specifico dell'anno. Non possiamo cambiarlo.

Quello che noi sviluppatori (sono uno dei due) dobbiamo fare è:

• Completamento dell'applicazione esistente (circa il 25% del lavoro da svolgere).

• Creazione di un nuovo modulo, essenziale per l'organizzazione di questo evento (circa il 75% del lavoro da svolgere). Questo nuovo modulo non può essere sviluppato senza comprendere l'API del programma principale.

Non riesco a fare una stima esatta del tempo, ma ci troviamo in una situazione rischiosa.

La cosa migliore da fare è non gettare il nuovo sviluppatore nel fuoco, ma invece ritagliarsi alcune funzionalità e / o correzioni di bug che lo sviluppatore non dovrebbe avere problemi a saltare dentro. Trova un'area che necessita di lavoro che non richieda a una persona di conoscere l'intera architettura, i requisiti e la base di codici contemporaneamente. Magari fai lavorare lui o lei sulla documentazione per apprendere più velocemente il sistema.

Anziché aggiungere un nuovo sviluppatore al team, è consigliabile aggiungere un consulente esperto per il periodo da due a tre mesi per gestire l'aumento temporaneo del carico di lavoro della propria azienda. L'idea è quella di ottenere qualcuno in grado di gestire un tempo di avvio prossimo allo zero, ma allo stesso tempo potrebbe non essere necessariamente la migliore aggiunta alla tua squadra.

Anche se pensi che l'aumento del carico di lavoro non sia temporaneo, ora probabilmente non è il momento migliore per far crescere organicamente il tuo team: aggiungere un terzo sviluppatore è una cosa stressante per un team anche senza una pressione dalla scadenza del progetto; una scadenza stretta 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.

È una buona idea aggiungere una persona ora?

No. Se possibile, cerca di far concordare al cliente la riduzione dell'ambito.

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

Non farlo

Ancora.

Vista tradizionale

Nella tua domanda, fai riferimento alla legge di Brooks di Mythical Man-Month .

L'aggiunta di manodopera a un progetto software tardivo lo rende più tardi.

Ignorare la legge di Brook ha un prezzo. Non multitasking. 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 esaurito e vedrai quanto può richiedere molto tempo.

Larry Page e Sergei Brin hanno trascorso due anni a scegliere il team iniziale per Google. Anche la scelta del dipendente numero tre dovrebbe essere accurata.

Agile, New Millenium View

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

Potenzialmente, i team Agile tengono conto dei vincoli nei loro programmi. Non sono in ritardo perché sono ottimizzati per le risorse disponibili. L'integrazione di nuovo personale costituisce un ulteriore vincolo ed è considerata 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 staff può utilizzare:

• mischie giornaliere
• programmazione in coppia
• refactoring
• aggiunta di test unitari mancanti
• ingrassare la documentazione magra
• recensioni di codice

L'agnello sacrificale

In " Modelli organizzativi di sviluppo software agile" James Coplien discute le dinamiche di gruppo e i costi per l'aggiunta di nuovi membri del team. Il suo modello "Sacrificial Lamb" assegna tutto il tutoraggio e l'addestramento a una persona, proteggendo il resto della squadra dall'interruzione.

È una strategia che potresti prendere in considerazione per l'implementazione.

Un'altra strategia è quella di assegnare nuovi mentori di assunzione che coprono domande di nuovi assunti per determinate ore ogni giorno. Se riesci a risparmiare un solo ragazzo, forse lavora senza interruzioni la mattina o il pomeriggio e risponde alle domande rispettivamente nel pomeriggio o nella mattina. Il gruppo in cui mi trovo ha avuto dieci stagisti l'estate scorsa, quindi molte persone sono state interrotte molto.

Attualmente il tutoraggio è svolto da una persona, principalmente durante e immediatamente dopo la nostra mischia mattutina (dalle 8:30 alle 9:15 circa, combinate) e nel pomeriggio tra le 12 e le 3:30 (lavora dalle 7:00 alle 3:30 pm).

Sono lieto che tu abbia menzionato la legge di Brook. Ben fatto. Il problema principale con l'aggiunta di un altro sviluppatore è l'overhead nel velocizzarli e l'overhead dello stato di sincronizzazione con loro su dove ti trovi nel progetto. Pertanto, se decidi di ottenere un terzo sviluppatore, proverei questo:

• Dare al nuovo ragazzo un'area in cui i costi rapidi sono bassi e può iniziare il più rapidamente possibile. Questo dipenderà molto da chi assumi e da quali abilità possiede.
• Assicurarsi che quest'area sia liberamente accoppiata con altre aree dell'applicazione in modo che l'overhead della sincronizzazione sia inferiore. Inviarlo a svolgere un intenso lavoro di DB e riorganizzare le tabelle potrebbe essere troppo.
• Fai il possibile per mantenere alto il morale. Come altri hanno notato, l'aggiunta di 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 è quello di attirare la nuova persona senza essere colpiti con troppo rallentamento nella tua squadra attuale. Alla fine la nuova persona sarà pronta e potrai superare la gobba.

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

1. Questi sono estremamente necessari come protezione dagli errori di regressione, che ti bruceranno più velocemente di qualsiasi rallentamento di Brooks.
2. La nuova persona imparerà il fegato del tuo sistema. È un po 'una prova del fuoco - ma il loro output non sta andando nel codice di produzione, quindi c'è poco rischio lì.
3. Poni un limite duro alla quantità di tempo che gli altri membri del team possono impiegare. Ad esempio, fagli mettere in coda le domande e consenti solo 30 minuti al giorno di interagire con gli altri membri del team fino al raggiungimento della scadenza.

Inoltre, ammettiamolo: dovrai gestire l'ambito e le aspettative del cliente indipendentemente dal fatto che tu abbia assunto o meno una nuova persona. Il payoff arriva il prossimo ciclo.

Ed Yourdon ha fatto un grande commento sulla legge di Brook. Ha detto: naturalmente, l'aggiunta di persone ti farà andare più lentamente, ma quando un progetto è a rischio è l'unica volta che la gestione porterà nuove persone. Quindi: prendili, riduci al minimo l'impatto sulla versione attuale e sbarazzati di artisti scadenti il ​​prima possibile. In questo modo, nel tempo, puoi costruire una squadra forte.

Se lavori su altri progetti che puoi concedergli, questo consentirà ai 2 sviluppatori attuali di risparmiare tempo per concentrarsi sui risultati finali che potrebbero aiutare.

Dici che devi completare il 25% dell'opera originale, oltre a nuove opere. E devi farlo in due mesi - quando hai impiegato 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 focalizzato sul codice - cioè, pensi che le cose ti porteranno da circa la metà a un terzo di quanto facciano davvero.

Heroics potrebbe permetterti di consegnare il prodotto per il quale hai contratto, ma non farà alcun favore a te o ai tuoi clienti. Sarà scadente e pieno di bug in queste condizioni, e starai fumando.

Tieni presente che il tempo che impieghi per assumere avrà anche un impatto importante sulla tua disponibilità: questo non è qualcosa che puoi fare solo in un fine settimana, ci vuole tempo per trovare dipendenti di talento che si adattino bene. Aspettatevi di trascorrere almeno un paio di settimane a cercare, intervistare, ecc. Aspettatevi che voi e il vostro dipendente esistente perdiate circa 10 ore a settimana di tempo produttivo durante la ricerca.

La mia raccomandazione:

Siediti con il tuo cliente, spiega che sei sopra la testa e lavora con lui per ridurre al minimo l'ambito.

Modifica Ho appena visto la data qui. Come è andata a finire? (Grazie Ars Technica per aver pubblicato una domanda di tre mesi;)

Ci sono un paio di modi diversi che prenderei in considerazione per indagare:

1. Aspetta di assumere il nuovo sviluppatore fino al termine della scadenza, in modo che sia più facile concentrarsi sul passaggio delle conoscenze di dominio al nuovo ragazzo. Questa sarebbe la mia preferenza in quanto potrebbe essere leggermente impegnativo in alcuni modi.

2. Porta il nuovo sviluppatore a lavorare su documentazione, unit test e altre cose che non cambiano il codice esistente. Questo sarebbe ciò che suggerirei se attiri il nuovo ragazzo per cercare di ridurre al minimo l'impatto sul carico di lavoro corrente.

La data è già passata, ma per chiunque la legga più tardi.

La cosa fondamentale da considerare è che il cliente in questa situazione ha molto più da perdere di te. Hanno già speso un sacco di soldi e hanno in programma un evento chiave che potrebbe fare o rompere il loro business. Hai già i loro soldi e perdere un singolo cliente non dovrebbe rovinare la tua attività. In tal caso, hai altri seri problemi di business oltre alla terribile gestione del progetto.

La tua scommessa migliore è quella di negoziare un sottoinsieme essenziale di funzionalità e quindi fare gli straordinari per farlo. Se non riesci a far succedere un sottoinsieme più piccolo o non sei disposto a fare gli straordinari in quella situazione, probabilmente non dovresti essere in affari. Questo può 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 l'ambito giù, allora si è impostato per fallire.

Non vi è alcuna possibilità di consegnare questo progetto completamente nei tempi previsti. Se ritieni di avere ancora il 25% su un progetto che ha impiegato finora 18 mesi per essere realizzato, allora ti restano almeno 6 mesi (di ~ 2 sviluppatori). L'aggiunta di un'altra persona non cambierà questo in modo significativo.

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

Spero che questo abbia funzionato per te.