La legge di Brooks è un principio valido nell'ambito dell'ingegneria informatica che dice: Aggiungere forza lavoro ad un progetto software in ritardo, lo farà ritardare ancora di più[1].
Spiegazione
[modifica | modifica wikitesto]La legge venne enunciata per la prima volta nel 1975 da Fred Brooks nel suo saggio The Mythical Man-Month e, per stessa ammissione dell'autore, è da considerarsi una semplificazione paradossale[1], ma che cattura lo spirito del principio che vuole esprimere. I principali fattori considerati da Brooks sono:
- Affinché il nuovo personale aggiunto al progetto diventi produttivo, è necessario un certo tempo. I progetti software sono in genere complessi e i nuovi progettisti devono essere prima di tutto informati dal personale già occupato, su ciò che è già stato fatto. Questo distoglie risorse dal progetto stesso diminuendo temporaneamente la produttività. Il nuovo personale va poi integrato nel gruppo di lavoro preesistente e ciò comporta un ulteriore lasso di tempo in cui non sarà pienamente produttivo. Inoltre, durante questa fase, i progettisti esperti diminuiscono la loro produttività, sia per dedicarsi all'inserimento dei nuovi, sia proprio per delegare parte del proprio lavoro a questi ultimi, lavoro che verrà svolto con un grado di produttività minore, proprio per la loro inesperienza nel progetto che li indurrà a scrivere un software con più errori che necessiteranno in seguito di essere corretti.
- Il sovraccarico di lavoro necessario per l'intercomunicazione tra i vari progettisti aumenta ovviamente con l'aumentare del personale. Il numero di canali di comunicazione necessari in una squadra di progetto aumenta circa col quadrato del numero dei componenti, quindi raddoppiare i progettisti significa quadruplicare il tempo usato per la comunicazione tra loro.
Eccezioni e soluzioni
[modifica | modifica wikitesto]La legge di Brooks viene spesso citata per spiegare perché non si riesca ad evitare che alcuni progetti software siano in ritardo, malgrado tutti gli sforzi fatti per cercare di gestire la situazione. In realtà vanno considerati alcuni punti chiave che consentono soluzioni a questo tipo di situazioni[2][3].
Innanzi tutto la legge di Brooks prende in considerazione progetti che siano già in ritardo. Il processo può essere tenuto sotto controllo se l'aumento di personale avviene quando il progetto è ancora relativamente in tempo. Spesso il ritardo viene gestito semplicemente spostando le date di scadenza, tenendo anche conto di una stima troppo ottimistica dei tempi di sviluppo.
Inoltre vanno considerati il ruolo, la quantità e la qualità dei progettisti aggiunti. Buoni progettisti hanno bisogno di meno tempo di inserimento, inoltre l'inserimento in ruoli chiave può aggirare la legge di Brooks.
Note
[modifica | modifica wikitesto]- ^ a b Frederick P. Brooks Jr, The Mythical Man Month, Addison-Wesley, 1995.
- ^ "In spite of Brooks' Law, adding people to a late project remains commonplace" ... "I have evangelized this well-worn software engineering chestnut many times myself, but I no longer think it's true". (McConnell, 1999)
- ^ "The trouble is that there are important exceptions that many people do not take the time to consider when using Brooks' law to justify something". (Berkun, 2006)
Collegamenti esterni
[modifica | modifica wikitesto]- (EN) Brooks' Law repealed?, su stevemcconnell.com.
- (EN) Exceptions to Brooks' Law, su scottberkun.com.
- (EN) Brooks' Law and open source: The more the merrier?, su www-106.ibm.com.
