The mythical man-monthEdit

Brooks discute diverse cause di errori di pianificazione. Il più duraturo è la sua discussione sulla legge di Brooks: l’aggiunta di manodopera a un progetto software tardivo lo rende più tardi. Man-month è un’ipotetica unità di lavoro che rappresenta il lavoro svolto da una persona in un mese; la legge di Brooks dice che la possibilità di misurare il lavoro utile in man-months è un mito, ed è quindi il fulcro del libro.

I progetti di programmazione complessi non possono essere perfettamente partizionati in compiti discreti che possono essere lavorati senza comunicazione tra i lavoratori e senza stabilire un insieme di complesse interrelazioni tra i compiti e i lavoratori che li eseguono.

Pertanto, assegnare più programmatori a un progetto in ritardo renderà ancora più tardi. Questo perché il tempo necessario per i nuovi programmatori per conoscere il progetto e l’aumento del sovraccarico di comunicazione consumerà una quantità sempre crescente del tempo di calendario disponibile. Quando n le persone devono comunicare tra loro, man mano che n aumenta, la loro produzione diminuisce e quando diventa negativa il progetto viene ritardato ulteriormente con ogni persona aggiunta.

• Formula di intercomunicazione di gruppo: n (n − 1) / 2
• Esempio: 50 sviluppatori danno 50 · (50 – 1) / 2 = 1225 canali di comunicazione.

No silver bulletEdit

Brooks ha aggiunto “No Silver Bullet — Essence and Accidents of Software Engineering”—e ulteriori riflessioni su di esso, “‘No Silver Bullet’ Refired”—all’edizione dell’anniversario del Mitico Mese dell’uomo.

Brooks insiste sul fatto che non esiste un solo proiettile d’argento “” non esiste un singolo sviluppo, né nella tecnologia né nella tecnica di gestione, che di per sé promette anche un miglioramento di un ordine di grandezza entro un decennio in termini di produttività, affidabilità, semplicità.”

L’argomento si basa sulla distinzione tra complessità accidentale e complessità essenziale, simile al modo in cui la legge di Amdahl si basa sulla distinzione tra “strettamente seriale” e “parallelizzabile”.

L’effetto del secondo sistemamodifica

L’effetto del secondo sistema propone che, quando un architetto progetta un secondo sistema, è il sistema più pericoloso che progetterà mai, perché tenderà ad incorporare tutte le aggiunte che originariamente non hanno aggiunto al primo sistema a causa di vincoli di tempo intrinseci. Pertanto, quando si intraprende un secondo sistema, un ingegnere dovrebbe essere consapevole del fatto che è suscettibile di un eccesso di ingegneria it.

La tendenza verso il numero irriducibile di errorimodifica

L’autore fa l’osservazione che in un sistema opportunamente complesso esiste un certo numero irriducibile di errori. Qualsiasi tentativo di correggere gli errori osservati tende a comportare l’introduzione di altri errori.

Progress trackingEdit

Brooks ha scritto “Domanda: come fa un grande progetto software ad essere in ritardo di un anno? Risposta: Un giorno alla volta!”Gli slittamenti incrementali su molti fronti alla fine si accumulano per produrre un grande ritardo complessivo. Ad ogni livello di gestione è necessaria una continua attenzione al raggiungimento di piccole pietre miliari individuali.

integrityEdit concettuale

Per rendere un sistema user-friendly, il sistema deve avere integrità concettuale, che può essere raggiunto solo separando l’architettura dall’implementazione. Un singolo capo architetto (o un piccolo numero di architetti), che agisce per conto dell’utente, decide cosa va nel sistema e cosa rimane fuori. L’architetto o il team di architetti dovrebbero sviluppare un’idea di ciò che il sistema dovrebbe fare e assicurarsi che questa visione sia compresa dal resto del team. Una nuova idea di qualcuno potrebbe non essere inclusa se non si adatta perfettamente al design generale del sistema. Infatti, per garantire un sistema user-friendly, un sistema può deliberatamente fornire meno funzioni di quanto sia in grado di. Il punto è che, se un sistema è troppo complicato da usare, molte funzionalità andranno inutilizzate perché nessuno ha il tempo di impararle.

Il manualEdit

Il capo architetto produce un manuale di specifiche di sistema. Dovrebbe descrivere le specifiche esterne del sistema in dettaglio, cioè tutto ciò che l’utente vede. Il manuale dovrebbe essere modificato man mano che il feedback arriva dai team di implementazione e dagli utenti.

Il sistema pilota

Quando si progetta un nuovo tipo di sistema, un team progetterà un sistema usa e getta (che lo intenda o meno). Questo sistema agisce come un “piano pilota” che rivela tecniche che successivamente causeranno una riprogettazione completa del sistema. Questo secondo sistema più intelligente dovrebbe essere quello consegnato al cliente, poiché la consegna del sistema pilota non causerebbe altro che agonia al cliente e forse rovinerebbe la reputazione del sistema e forse anche l’azienda.

Documenti formalimodifica

Ogni project manager dovrebbe creare un piccolo nucleo di documenti formali che definiscono gli obiettivi del progetto, come devono essere raggiunti, chi li raggiungerà, quando saranno raggiunti e quanto costeranno. Questi documenti possono anche rivelare incongruenze che sono altrimenti difficili da vedere.

Stima del progettomodifica

Quando si stimano i tempi del progetto, si deve ricordare che i prodotti di programmazione (che possono essere venduti a clienti paganti) e i sistemi di programmazione sono entrambi tre volte più difficili da scrivere dei semplici programmi interni indipendenti. Si dovrebbe tenere presente quanto della settimana lavorativa sarà effettivamente speso per questioni tecniche, al contrario di compiti amministrativi o altri compiti non tecnici, come le riunioni, e in particolare le riunioni “stand-up” o “all-hands”.

CommunicationEdit

Per evitare il disastro, tutti i team che lavorano su un progetto dovrebbero rimanere in contatto tra loro nel maggior numero possibile di modi: e—mail, telefono, riunioni, memo ecc. Invece di assumere qualcosa, gli implementatori dovrebbero chiedere agli architetti di chiarire il loro intento su una caratteristica che stanno implementando, prima di procedere con un’ipotesi che potrebbe benissimo essere completamente errata. L’architetto(s) sono responsabili per la formulazione di una foto di gruppo del progetto e comunicarlo ad altri.

Il team chirurgicomodifica

Proprio come un team chirurgico durante l’intervento è guidato da un chirurgo che esegue il lavoro più critico, mentre dirige il team per assistere con parti meno critiche, sembra ragionevole avere un “buon” programmatore sviluppare componenti di sistema critici mentre il resto di un team fornisce ciò che è necessario al momento giusto. Inoltre, Brooks pensa che i programmatori” buoni ” siano generalmente da cinque a dieci volte più produttivi di quelli mediocri.

Blocco del codice e versione del sistemamodifica

Il software è invisibile. Pertanto, molte cose diventano evidenti solo una volta che una certa quantità di lavoro è stato fatto su un nuovo sistema, consentendo a un utente di sperimentarlo. Questa esperienza produrrà intuizioni, che cambierà le esigenze di un utente o la percezione delle esigenze dell’utente. Il sistema dovrebbe, quindi, essere modificato per soddisfare i requisiti modificati dell’utente. Questo può verificarsi solo fino a un certo punto, altrimenti il sistema potrebbe non essere mai completato. Ad una certa data, non dovrebbero essere consentite ulteriori modifiche al sistema e il codice dovrebbe essere congelato. Tutte le richieste di modifiche devono essere ritardate fino alla prossima versione del sistema.

Specialized toolsEdit

Invece di ogni programmatore che ha il proprio set speciale di strumenti, ogni team dovrebbe avere un produttore di strumenti designato che può creare strumenti altamente personalizzati per il lavoro che il team sta facendo, ad esempio, uno strumento generatore di codice che crea codice in base a una specifica. Inoltre, gli strumenti a livello di sistema dovrebbero essere creati da un team di strumenti comuni, supervisionato dal project manager.

Abbassamento di sviluppo software costsEdit

Ci sono due tecniche per abbassare il software costi di sviluppo, Brooks scrive:

• gli Esecutori possono essere assunti solo dopo che l’architettura del sistema è stata completata (un passo che potrebbe richiedere diversi mesi, durante i quali prematuramente assunto implementatori può avere nulla a che fare).
• Un’altra tecnica che Brooks menziona non è quella di sviluppare software, ma semplicemente di acquistarlo “off the shelf” quando possibile.