È un detto abbastanza comune che aggiungere più programmatori a un progetto in ritardo peggiorerà le cose. Perché è questo?
Ogni nuovo sviluppatore deve essere introdotto nella base di codice e nel processo di sviluppo che richiede non solo il tempo della nuova persona ma richiede anche l'assistenza di [uno] sviluppatore senior (guidandoli attraverso il processo di costruzione, spiega il processo di test, aiutarli con le insidie nella base di codice, recensioni di codice molto più dettagliate, ecc. .
Pertanto, più nuovi sviluppatori aggiungi al progetto più tempo deve essere speso per portarli a un punto in cui possono effettivamente contribuire al progetto.
Oltre alle altre risposte: un altro fattore da considerare è la comunicazione.
Il caso peggiore per la quantità di canali di comunicazione in una squadra (che non è raro), è un grafico completo . Come puoi immaginare, l'aggiunta nello sviluppatore solo 1 può aumentare molto i canali di comunicazione. Con metodi di comunicazione più snelli, l'impatto è inferiore ... ma si aggiunge ancora.
Il problema citato nel libro che ha originariamente promulgato questa legge, The Mythical Man-Month , è la comunicazione. Inizia dicendo:
Men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them. This is true of reaping wheat or picking cotton; it is not even approximately true of systems programming.
Ha menzionato l'allenamento come parte del problema:
The added burden of communication is made up of two parts: training and intercommunication. Each worker must be trained in the technology, the goals of the effort, the overall strategy, and the plan of work. This training cannot be partitioned, so this part of the work varies linearly with the number of workers.
... ma nota che l'intercomunicazione è di gran lunga il fattore più grande :
Since software construction is inherently a systems effort -- an exercise in complex interrelationships--communication effort is great, and it quickly dominates the decrease in individual task time brought about by partitioning. Adding more men lengthens, not shortens, the schedule.
Vale anche la pena notare che Fred Brooks (l'autore) ha le basi per sapere di cosa sta parlando. La maggior parte del libro si basa sulla sua esperienza nella gestione del progetto OS / 360 di IBM. Nonostante decenni di aderenti che predicano ogni sorta di metodi di gestione "migliorati", e alcuni arrivano anche con nomi interessanti (eXtreme, Agile, Scrum, ecc.) Quando ci si avvicina, piccolo di essenza 1 sembra essere cambiato da allora.
1 Per la definizione di "essence", vedi lo stesso autore "No Silver Bullet: Essence and Accident in Software Engineering", incluso nella 20 th Anniversary Edition di The Mythical Man-Month .
Non è un semplice adagio; è verificabile Dai un'occhiata a The Mythical Man-Month di Brooks .
Ecco alcune considerazioni su questo problema ...
ora, l'aggiunta di nuove risorse per i test potrebbe non essere una cattiva idea ... potrebbe velocizzare il processo di test (se i casi di test sono ben scritti), e anche l'uso di strumenti di test sarà utile.
Perché la programmazione non è una linea di produzione di base. Arrivare alla velocità su un progetto software richiede tempo. Le nuove persone devono fare molte domande che portano a una produttività negativa (es. Apprendimento di nuove persone, insegnamento di persone anziane - > nessun lavoro effettivo viene svolto).
Per semplificarlo, immagina un progetto one-man relativamente semplice che è programmato per 1 settimana: giovedì, ti rendi conto che non verrà fatto in tempo, che ci vorrebbe un solo programmatore come il 6- 7 giorni invece di 5. Se a quel punto aggiungi un altro programmatore, dovranno lavorare con programmatore1 per almeno un'ora o un giorno circa, fare molte domande per essere al passo, ecc. Probabilmente hai vinto ottenere una produttività netta positiva per il resto della settimana. È probabile che il nuovo programmatore introduca anche altri bug (dato che non conosceranno il codice esistente così come programmatore1), in modo da far saltare il ciclo di implementazione e test di un altro o due giorni. Il progetto durerà facilmente due settimane lavorative complete invece dell'originale! - E molto probabilmente più a lungo se il primo programmatore avesse semplicemente un paio di giorni in più per finirlo da solo.
Fred Brooks ha scritto un intero libro "The Mythical Man-Month" rispondendo a questa domanda.
Ecco la versione quick-n-dirty:
1) C'è un limite a quanto puoi spezzare un progetto in parti distinte da assegnare a più programmatori.
2) La suddivisione di un progetto in più persone aumenta la quantità di comunicazione richiesta per coordinare tutte le parti dell'applicazione. Più comunicazione = Più lavoro.
3) Per ogni persona aggiunta al progetto si aggiunge più di un canale di comunicazione che deve essere navigato nel team. Questo numero cresce in modo geometrico e aumenta la quantità di comunicazione che deve avvenire. Più comunicazione = Più lavoro.
4) C'è una "J-Curve" quando aggiungi ciascun membro della squadra. Cioè, le risorse produttive esistenti devono trascorrere del tempo a far crescere le nuove persone che altrimenti avrebbero potuto impiegare nel progetto. In definitiva, è possibile aumentare la capacità, ma rallenta temporaneamente il progetto. Più avanti nel progetto, più si deve imparare, quindi più pronunciato è l'effetto.
Un altro fattore che non ho visto menzionato è che alcune attività devono essere eseguite in un ordine specifico. Non è possibile eseguire l'attività 4 fino a quando non viene eseguito l'attività 3 poiché dipende da 3. Non è utile assumere qualcuno per eseguire l'attività 4 nello stesso momento in cui qualcuno sta eseguendo l'attività 3. Spesso alla fine di un progetto , quelle attività che hanno bisogno di altre cose completate prima sono le attività rimanenti.
Spesso sono anche alcune delle attività più complesse che è necessario eseguire, proprio quelle che richiedono la migliore comprensione dell'intero progetto per evitare di rompere ciò che è già stato completato. Di solito richiedono anche la più ampia conoscenza del dominio aziendale. Potrei, dopo aver lavorato al progetto per mesi, essere in grado di svolgere il compito in una settimana o meno. Qualcuno nuovo spenderebbe più di una settimana per accelerare (e allontanarmi dai miei compiti per una buona protezione di quel tempo per rispondere alle domande) e probabilmente anche se estremamente esperti impiegheranno più tempo per svolgere il compito. Non essere causa che lui o lei non è competente, ma a causa della non familiarità con la struttura effettiva del progetto o del back-end del database.
L'adagio che ha sempre funzionato per me è che non puoi avere nove donne per fare un bambino in un mese.
Suggerirei anche "Peopleware" di DeMarco e Lister.
E "The Deadline" di DeMarco presenta questo, e un certo numero di altre malattie e errori di gestione del progetto software in un modo spensierato e molto leggibile.
Scava anche sulle dinamiche delle persone che svolgono il lavoro di progetto / di squadra, e va in dettaglio su solo come cose come la comunicazione e l'introduzione riducono l'orario di lavoro disponibile di un team.
Questi libri sono piuttosto economici, ti suggerisco di prenderli (Amazon o The Book Depository li hanno) e avere una lettura. Le risposte brevi qui non rendono giustizia alla domanda posta.
Perché nessuno impiega il tempo necessario per un processo ben ponderato, pianificato e testato per: assumere, addestrare, sviluppare e supervisionare i programmatori e tanto meno farli accelerare su un particolare progetto.
Se gestisci un team di sviluppatori, dovresti avere diversi contatti in questo momento di persone che vorresti assumere se hai un'opinione. Unisciti ai gruppi di sviluppatori.
Quanto velocemente si può ottenere una nuova macchina di sviluppo e pronta per l'uso?
Hai mai testato la documentazione e le specifiche del tuo progetto mostrandole a uno sviluppatore su un altro progetto? Lo hanno guardato e hanno deciso che avrebbero potuto iniziare a lavorare sul progetto, se necessario?
Quanto è aggiornato qualsiasi programma di progetto?
Risparmia per un giorno di pioggia perché quando un progetto cade dietro è più simile a un uragano.
A parte il problema della comunicazione (di cui penso tutte le altre risposte stanno parlando), è anche molto probabile che una persona aggiunta a un progetto crei bug, perché non conoscono il codice molto bene ancora.
Ogni volta che vengo aggiunto a un progetto, cerco sempre di non rompere le cose. Ciò significa che sono molto più lento a sistemare le cose all'inizio.
Leggi altre domande sui tag project-management