Il mio team di 4 sviluppatori esperti lavora su una grande applicazione Windows modulare (circa 200 KLoC). Mi sono concentrato sul codice base originario dall'inizio del progetto (3 anni fa) e gradualmente sono passato a una posizione di sviluppatore di semi-conduttori, anche se non sono il responsabile della squadra.
La nostra iterazione corrente è un aggiornamento dell'interfaccia utente ad alta priorità richiesto dal management superiore, che comporta circa 15 modifiche alla base di codice principale. Quando ho chiesto al gestore, ho stimato che ciascuna delle 15 modifiche avrebbe richiesto meno di quattro ore per il completamento di , per un totale di meno di 7 giorni lavorativi. Allora mi sono offerto volontario per eseguire il lavoro. Invece, il manager ha deciso di dividere in modo uniforme tutti e 15 i compiti per tutti e quattro gli sviluppatori.
Nei tre giorni da quando abbiamo iniziato a lavorare, ho osservato due cose:
-
Gli altri membri del team inesperti hanno completato circa 1 o meno task ciascuno.
-
Legge di Brook in azione: ho trascorso circa la metà del mio tempo di fornire assistenza (tentando di istruirli sull'utilizzo dei componenti). Di conseguenza, ho solo terminato 2 compiti da solo, invece dei 5 o 6 previsti.
Mi sono avvicinato al mio manager con la mia preoccupazione per il fatto che eravamo in ritardo e di nuovo ho suggerito di completare le attività rimanenti. La mia richiesta è stata gentilmente respinta, e le ragioni dichiarate per suddividere il carico in modo uniforme erano duplici:
- Limita il fattore camion / autobus - aumentando gli altri sviluppatori su queste abilità ora, così che in futuro qualsiasi lavoro possa essere dato a chiunque, non solo a me.
- Eliminare un "collo di bottiglia" (io) e portare a termine il lavoro più rapidamente.
Per essere chiari, non ho problemi con: a) investire il tempo nell'insegnamento, b) le persone che toccano il mio codice, o c) la sicurezza del lavoro. In effetti, suggerisco regolarmente al team leader di addestrare altri sviluppatori su alcuni aspetti del corebase principale per ridurre il rischio.
In questa iterazione abbiamo anche una vasta raccolta di correzioni di bug ad alta priorità mirate, quindi sembrerebbe che si potrebbero fare più progressi se il carico di lavoro fosse ridistribuito.
In Mythical-Man-Month, Brooks suggerisce un " Team chirurgico " dove ogni squadra è composta da un lead + sub-lead (il manager e me) e alcuni ruoli minori. Mi sento come se cadessimo naturalmente in questa organizzazione, ma il mio manager sta lavorando contro di essa. Sento che il fattore bus è già stato curato (il manager è ben preparato nel codice core) e che il collo di bottiglia non esiste realmente (il coinvolgimento di più sviluppatori non renderà il lavoro più veloce). Penso che a questo proposito, un team chirurgico è una buona cosa.
Questi sono i miei sentimenti, ma non sono un manager esperto, né abbiamo dovuto affrontare il fattore bus (knock on wood). Was Brooks ha ragione? Hai lavorato in un "Team chirurgico" in cui è entrato in gioco il fattore bus? Esistono tecniche migliori per la gestione delle competenze di distribuzione?
Domande simili: