Perché l'aggiunta di più persone a un progetto in ritardo lo rende più tardi?

25

È un adagio abbastanza comune che l'aggiunta di più programmatori a un progetto in ritardo peggiorerà le cose. Perchè è questo?

project-management

— Henry
fonte

14

Il termine per questo è Brooks's Law ( en.wikipedia.org/wiki/Brooks's_law ).

— Macneil,

7

Consiglio: leggi "The Mythical Man-Month" di Brooks. Questo mostrerà da dove viene quell'adagio, è un libro molto leggibile, e tutti nel campo dovrebbero leggerlo comunque.

— David Thornley,

Quella pagina di Wikipedia è scritta molto bene.

— Henry,

Per prove di come la produttività diminuisce con la dimensione del team (oltre 7 membri del team si ottengono rendimenti decrescenti), vedere qsm.com/process_improvement_01.html

— Joeri Sebrechts,

33

Introduzione ambientale

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 assistenza da parte di [a] sviluppatori senior (che li guidano attraverso il processo di compilazione, spiegano il processo di test, li aiutano con insidie nella base di codice, recensioni di codici molto più dettagliate, ecc . ) .

Pertanto, più nuovi sviluppatori si aggiungono al progetto, più tempo deve essere speso per portarli a un punto in cui possono effettivamente contribuire al progetto.

— Baelnorn
fonte

Quindi, se ottimizzi "Introduzione", l'impatto sarà ridotto?

— Henry,

9

@Henry: il problema è che di solito non è possibile ottimizzare quell'aspetto a un livello in cui non è il collo di bottiglia. Un nuovo programmatore all'inizio sa esattamente 0 del tuo progetto, del tuo codice e dei tuoi processi. È lo stesso overhead richiesto sempre quando si aggiunge un nuovo membro del team. Ma quando un progetto è già in ritardo, il team spesso non ha il tempo di fare una presentazione corretta, e se lo fa quel tempo manca dallo sviluppo reale. Pertanto, di solito è una situazione da perdere per il team e la nuova persona impiega molto più tempo prima di poter contribuire in modo significativo al progetto.

— Baelnorn,

Per quanto riguarda il costo di fare un'introduzione, non può essere registrato su nastro una volta e poi trasmesso a molti, in modo che possa addestrare un gran numero di nuovi programmatori contemporaneamente? (Esempi: riunioni o conferenze con gli sviluppatori).

— rwong

7

@rwong: non è una cattiva idea, ma di solito non è pratica. Non puoi semplicemente presentare le informazioni, devi assicurarti che i nuovi ragazzi le capiscano. Inoltre, se sono davvero nuovi (laureati recenti), di solito ci sono troppe informazioni per presentarli tutti in una volta. Abbiamo scoperto che un wiki funziona bene, poiché tutte le informazioni sono in un unico punto e le persone possono pubblicare domande se ci sono bit che non capiscono.

— TMN,

Una possibilità è quella di assegnare una nuova persona molto competente e farle svolgere compiti specifici senza disturbare gli altri. Faranno a pezzi e lavoreranno lentamente, e alcuni manager e / o team non possono sopportare di vederlo. Tuttavia, il nuovo sviluppatore può essere un vantaggio netto se gestito in questo modo.

— David Thornley,

32

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 è insolito), è un grafico completo . Come puoi immaginare, l'aggiunta di un solo sviluppatore può aumentare notevolmente i canali di comunicazione. Con metodi di comunicazione più snelli, l'impatto è inferiore ... ma si aggiunge comunque.

— Steven Evers
fonte

Stavo scrivendo lo stesso nello stesso momento! ma non ho fatto novità aveva un nome (un grafico completo) e la tua spiegazione è migliore, quindi arriva il mio voto.

— Miguel Veloso,

+1. D'accordo, questo è il problema più grande quando si aggiungono più membri del team.

— Martin Wickman,

+1 per il problema più a lungo termine con l'aggiunta di persone a un progetto.

— indyK1ng

23

Il problema citato nel libro ha originariamente promulgato questa legge, The Mythical Man-Month , è la comunicazione. Comincia dicendo:

Uomini e mesi sono merci intercambiabili solo quando un'attività può essere suddivisa tra molti lavoratori senza comunicazione tra loro. Questo vale per la mietitura del grano o la raccolta del cotone; non è neppure approssimativamente vero per la programmazione dei sistemi.

Cita la formazione come parte del problema:

L'ulteriore onere della comunicazione è costituito da due parti: formazione e intercomunicazione. Ogni lavoratore deve essere addestrato nella tecnologia, negli obiettivi dello sforzo, nella strategia generale e nel piano di lavoro. Questa formazione non può essere suddivisa, quindi questa parte del lavoro varia linearmente con il numero di lavoratori.

... ma nota che l'intercomunicazione è di gran lunga il fattore più importante:

Poiché la costruzione del software è intrinsecamente uno sforzo di sistema - un esercizio di interrelazioni complesse - lo sforzo di comunicazione è grande e domina rapidamente la riduzione del tempo di attività individuale determinato dal partizionamento. L'aggiunta di più uomini allunga, non accorcia il programma.

Vale anche la pena notare che Fred Brooks (l'autore) ha le basi per sapere di cosa sta parlando. Gran 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 addirittura escogitano nomi interessanti (eXtreme, Agile, Scrum, ecc.) Quando ci si avvicina ad esso, da allora sembra essersi cambiato poco di essence ¹ .

¹ Per la definizione di "essence", vedere lo stesso autore "No Silver Bullet: Essence and Accident in Software Engineering", incluso nell'edizione del 20 ^° anniversario di The Mythical Man-Month .

— Jerry Coffin
fonte

12

Non è solo un adagio; è verificabile. Dai un'occhiata a The Mythical Man-Month di Brooks .

— John
fonte

1

È un adagio. Può essere verificabile o meno, ma ciò non gli impedisce di essere un adagio.

— Peter Boughton,

3

Non ho questo libro (ovviamente). È supportato da numeri concreti o è aneddotico?

— Henry,

2

@Henry: È da un po 'che non lo leggo ma IIRC, entrambi sono presenti in quantità sufficiente per chiarire il punto in modo conclusivo.

— Steven Evers,

@Peter: modificata la mia risposta.

— Giovanni,

@PeterBoughton È un adagio. Inoltre, non è solo un adagio.

— SantiBailors

6

Ecco alcuni pensieri su questo problema ...

È necessario utilizzare le risorse correnti per accelerare le nuove risorse su ciò che sta accadendo con il progetto.
La nuova risorsa potrebbe non avere familiarità con la base di codice, pertanto è necessario più tempo per abituarsi al codice.

ora, aggiungere nuove risorse per i test potrebbe non essere una cattiva idea ... potrebbe accelerare il processo di test (se i casi di test sono ben scritti), e sì, anche l'utilizzo di strumenti di test sarà di aiuto.

— aggietech
fonte

1

+1 per l'aggiunta di risorse ai test, non allo sviluppo.

— Baelnorn,

4

Perché la programmazione non è il lavoro di base della linea di produzione. Mettersi al passo con un progetto software richiede tempo. Le nuove persone devono porre molte domande che portano a una produttività negativa (ad es. Apprendimento di nuove persone, insegnamento delle persone anziane -> nessun lavoro effettivo svolto).

Per semplificarlo, immagina un progetto one-man relativamente semplice che dovrebbe durare 1 settimana: giovedì ti rendi conto che non sarà fatto in tempo, che invece ci vorrebbe un programmatore più di 6-7 giorni di 5. Se aggiungi un altro programmatore a quel punto, dovranno lavorare con programmatore1 per almeno qualche ora o un giorno o giù di lì, fare un sacco di domande per aggiornarti, ecc. Probabilmente non otterrai qualsiasi produttività netta positiva per il resto della settimana. È probabile che il nuovo programmatore introduca anche alcuni bug aggiuntivi (poiché non conosceranno il codice esistente così come il programmatore1), in modo da far saltare il ciclo di implementazione e test entro un altro giorno o altri due. Il progetto durerà facilmente ben due settimane lavorative invece di quella originale!

— Tavoli Bobby
fonte

Bene, il tuo esempio è un po 'inventato dalla breve scadenza irrealistica lasciata al progetto. Cambialo in un mese e vedrai che non è necessario vero. Personalmente penso che la citazione sia stata abusata. È vero quando si considera un programmatore normale, medio / scarso. Se hai un buon programmatore e la scadenza non è qualcosa di irrealistico come 1 giorno o 1 settimana, allora la citazione è sbagliata: può essere fatta (aiuta il progetto).

— n1ckp,

@ n1ck È una generalizzazione - come "troppi cuochi" - il punto chiave è che semplicemente lanciando la forza lavoro sul progetto non necessariamente la risolverà più velocemente. 1 persona a 2? Probabilmente lo farò. Da 2 a 4? Troppe variabili: dipende dalle dimensioni e dalla struttura del progetto. 4 -> 8? Sicuramente marginale (almeno in termini di ritorno sul costo).

— Murph,

@Murph: sembra che tu stia pensando principalmente alle mie stesse cose, ma hai dimenticato una variabile molto importante nella tua equazione: il livello di abilità della forza lavoro aggiunta. È stato nel mio ultimo commento, quindi trovo strano che te lo sia perso. L'aggiunta cieca di manodopera non è ovviamente la soluzione. L'aggiunta di manodopera molto specializzata (non ne hai bisogno) può ovviamente aiutare ed è ciò che mancava nella mitica citazione del mese-uomo. Questo era il mio punto. Altrimenti so già cosa significa la citazione.

— n1ckp,

Ok, l'esempio potrebbe essere migliore ma la generalizzazione è ancora valida?

— Murph,

1

Ho passato abbastanza tempo per sapere che è una di quelle cose che POTREBBE funzionare in casi molto specializzati, ma il 99% delle volte non lo farà. Non importa quanto sia bello in teoria al momento. Detto questo, sì, non è un assoluto in bianco e nero. È più come dire, come le relazioni aperte non funzionano. La teoria è carina e allettante;) .... ma la natura della bestia è tale che nella maggior parte dei casi finisce per fallire. Sorta di una cosa "le eccezioni dimostrano la regola".

— Tavoli Bobby,

4

Fred Brooks ha scritto un intero libro "The Mythical Man-Month" rispondendo a questa domanda.

Ecco la versione quick-n-dirty:

1) Esiste un limite a quanto è possibile suddividere un progetto in parti distinte da assegnare a più programmatori.

2) Suddividere 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 che aggiungi al progetto aggiungi più di un canale di comunicazione che deve essere navigato nel team. Questo numero cresce geometricamente e aumenta la quantità di comunicazione che deve avvenire. Più comunicazione = Più lavoro.

4) C'è una "curva a J" quando aggiungi ogni membro del team. In altre parole, le risorse produttive esistenti devono passare il tempo ad accelerare le nuove persone che altrimenti avrebbero potuto spendere lavorando al progetto. Alla fine puoi aumentare la capacità, ma rallenta temporaneamente il progetto. Più tardi nel progetto più si deve imparare, quindi più pronunciato l'effetto.

— JohnFx
fonte

4

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 l'attività 3 non viene eseguita perché dipende da 3. Non è utile assumere qualcuno per svolgere l'attività 4 contemporaneamente mentre qualcuno esegue l'attività 3. Spesso alla fine di un progetto , quelle attività che richiedono prima altre cose completate sono le attività rimanenti.

Spesso sono anche alcuni dei compiti più complessi che devono essere svolti, quelli 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 passerebbe più di una settimana ad accelerare (e ad allontanarmi dai miei compiti per una buona protezione di quel tempo per rispondere alle domande) e probabilmente anche se estremamente abili impiegherebbero più tempo per svolgere il compito. Non perché non sia competente, ma a causa della scarsa familiarità con la struttura effettiva del progetto o del back-end del database.

— HLGEM
fonte

+1. Questo è stato un grosso problema nel mio ultimo lavoro. La direzione era in una mania da "mese mensile" per un grande progetto senza riflettere. A un certo punto, il nostro team è stato addestrato per essere lento, perché le nostre cose dovevano integrarsi con quel grande progetto. Ma poi, i nuovi assunti sul grande progetto non sono riusciti ad accelerare abbastanza velocemente, quindi ABBIAMO fatto troppo avanti (su cose che richiedevano il completamento dei loro backend). A un certo punto stavamo sviluppando front-end per back-end semi-cotti e imbracature di prova. Non è un buon flusso.

— Tavoli Bobby,

2

Il adagio che ha sempre funzionato per me è che non puoi convincere nove donne a fare un bambino in un mese.

— replica
fonte

Se pensi che un progetto software sia come un bambino, non vivi nel mondo reale. C'è un po 'di verità nella citazione, ma questo è l'esempio perfetto di prendere le cose fuori dal contesto: -1

— n1ckp

1

Ovviamente no. Ma le persone con cui vendi anche le linee temporali non comprendono lo sviluppo del software. Le analogie sono esattamente per questo scopo che collegano un concetto sconosciuto a un'entità conosciuta.

— riesegui il

2

Un'altra analogia che Brooks fa è quella del cibo in un ristorante. Una cucina ben gestita può fare molti pasti in parallelo, ma ci sono limiti alla velocità con cui può fare un singolo pasto senza cuocerlo troppo o bruciarlo.

— David Thornley,

@rerun: il problema con la tua analogia è che non esiste un'analogia di lavoro per una donna incinta. Le donne nel tuo caso potrebbero essere più facilmente paragonate all'azienda , non ai lavoratori. Ecco perché secondo me fallisce così tanto. Il più vicino a cui riesco a pensare sarebbe il cibo, ma sarebbe più simile a una linea di codici, quindi no, non ai lavoratori.

— n1ckp,

1

@ n1ck: la mia impressione è che non sei d'accordo perché non lo capisci, a dire il vero. Brooks non stava parlando di sostituire le persone inutili con persone competenti, perché si trovava in una situazione in cui tutti ancora impiegati erano considerati competenti.

— David Thornley,

2

Suggerirei anche "Peopleware" di DeMarco e Lister.

E "The Deadline" di DeMarco presenta questo, e una serie di altre malattie e fallacie nella gestione di progetti software in modo spensierato e molto leggibile.

Approfondisce anche la dinamica delle persone che svolgono il lavoro di gruppo / progetto e fornisce alcuni dettagli su COME cose come la comunicazione e l'introduzione riducono il tempo di lavoro disponibile di una squadra.

Questi libri sono abbastanza economici, ti suggerirei di prenderli (Amazon o The Book Depository li hanno) e leggere. Le brevi risposte qui non possono davvero rendere giustizia alla domanda posta.

— quickly_now
fonte

2

Perché nessuno si prende il tempo di avere un processo ben studiato, pianificato e testato per: assumere, addestrare, sviluppare e supervisionare i programmatori e tanto meno metterli al passo con la velocità su un particolare progetto.

Se stai gestendo un team di sviluppatori, dovresti avere subito diversi contatti delle persone che vorresti assumere se hai un'apertura. Unisciti ai gruppi di sviluppatori.

Quanto velocemente puoi ottenere una nuovissima configurazione della macchina di sviluppo e pronta per partire?

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 di poter iniziare a lavorare al progetto se necessario?

Quanto è aggiornato il programma del progetto?

Risparmia per una giornata piovosa perché quando un progetto cade dietro è più simile a un uragano.

— Jeffo
fonte

1

A parte il problema della comunicazione (di cui penso che tutte le altre risposte stiano parlando), è anche molto possibile che una persona aggiunta a un progetto crei bug, perché non conoscono ancora molto bene il codice.

Ogni volta che vengo aggiunto a un progetto, cerco sempre di non rompere le cose. Ciò significa che all'inizio sono molto più lento nel sistemare le cose.

— Paul D. Waite
fonte

0

Vorrei sottolineare qualcosa di totalmente ignorato finora dalle altre risposte.

Quando le persone vengono aggiunte a un progetto in ritardo, in genere molte cose sono andate male in tutta l'organizzazione. La direzione e il cliente non sono contenti. Le persone sono state sotto pressione per andare avanti. Le cose sono piuttosto tese.

Ora immagina di far parte di quella squadra. Ovviamente niente di tutto questo è colpa tua. La pianificazione (nessuna delle quali era tua) è stata troppo ottimista. Tutte le decisioni sbagliate sono state prese senza consultarti. Stai cercando di trarne il meglio e all'improvviso un gruppo di nuove persone vengono portate avanti. Quale messaggio trasmette?

Le persone di sopra ovviamente hanno perso la fiducia in te. Hanno chiamato i ragazzoni per compensare ciò che hai incasinato.

Sarai ancora motivato a rendere questo successo? Oppure ... sarai sempre più frustrato e dopo tutto preferiresti vedere tutto?

Prenditi il tuo tempo :-).

— Martin Maat
fonte