Indice
Premessa
Definizione
Questa introduzione usa alcune idee di Fred Brooks come base di discussione sui problemi ricorrenti nella gestione dei progetti software.
Brooks e noto per il libro The Mythical Man-Month e per il lavoro sui progetti IBM System/360 e OS/360. Le sue osservazioni non vanno trattate come verita assolute: alcune restano attuali, altre sono discusse o considerate datate.
La frase piu nota associata a Brooks e la Legge di Brooks:
Legge di Brooks
“Adding people to a late software project just makes it later”.
In pratica: se un progetto software e gia in ritardo, aggiungere persone non garantisce di recuperare tempo. Le nuove persone devono essere formate, devono comunicare con il team e possono aumentare il coordinamento necessario.
Dal Garage al Prodotto
Il Mito del Garage
Definizione
Il mito del garage e l’idea secondo cui piccoli gruppi informali possono creare soluzioni capaci di competere con prodotti sviluppati da grandi team organizzati.
Le slide citano esempi come Apple, Google e Facebook. In tutti i casi il punto non e negare che grandi idee possano nascere in contesti piccoli, ma distinguere tra prototipo, programma e prodotto.
Un piccolo gruppo puo scrivere una prima versione funzionante. Pero, secondo Brooks, i piccoli sistemi non sono davvero comparabili con i prodotti che richiedono grandi team: mancano spesso analisi dei requisiti, architettura, test, manutenzione e documentazione.
Esempi dalle slide
- Apple: il primo PC di Jobs e Wozniak era funzionante, ma non ancora un prodotto completo.
- Google: il successo non dipendeva solo dall’idea, ma da PageRank, modello di business, facilita d’uso ed execution.
- Facebook: aveva idea ed execution, ma per lungo tempo mancava un modello di business chiaro.
In pratica: una demo che funziona non basta per il mercato. Serve trasformarla in qualcosa di affidabile, testabile, mantenibile, documentato e sostenibile economicamente.
Goal e Progetto
Definizione
Il goal definisce cosa deve essere fatto; il progetto e il percorso organizzato che consente di raggiungere il risultato atteso.
La definizione del goal e parte integrante del progetto. Un progetto richiede gestione per rispettare il goal, affrontare cambiamenti e complessita, usare bene risorse come tempo e denaro, organizzare il team, curare comunicazioni e documentazione.
Note
Per portare un prodotto sul mercato, soprattutto in una start-up, serve anche un piano: le slide richiamano il business plan e un modello di business convincente.
Cambiamento e Complessita
Cambiamento
Definizione
Il cambiamento e la modifica, interna o esterna al progetto, che puo riguardare requisiti, idea iniziale, tecnologie, budget, tempi o risorse disponibili.
Brooks osserva che “the only constancy is change itself” e raccomanda di pianificare il sistema per il cambiamento. Gli approcci Agile assumono in modo esplicito che i requisiti possano cambiare durante il lavoro.
In pratica: un buon piano non serve per fingere che tutto restera stabile. Serve per capire come reagire quando cambia qualcosa.
The Tar Pit
Brooks usa la metafora della tar pit, una palude di bitume: “Software like a tar pit: The more you fight it, the deeper you sink!“.
Il cambiamento puo generare stress nel personale coinvolto. Se non viene gestito, lo stress puo produrre ulteriori problemi, peggiorando qualita, produttivita e capacita decisionale.
Complessita
Definizione
La complessita di un progetto software riguarda soprattutto le interrelazioni tra task, componenti e sviluppatori, non solo la difficolta tecnica di singole parti.
Progetti complessi non possono essere divisi in tanti task completamente indipendenti. Anche una progettazione accurata non elimina la complessita: aiuta a gestirla.
Brooks distingue tre livelli:
- Programma: insieme di istruzioni che implementa una o piu funzionalita.
- Prodotto: programma testato, documentato, utilizzabile in diversi ambienti e modificabile da altri.
- Sistema software: insieme di prodotti integrati tra loro, con interfacce, input, output e integrazione da testare.
Note
Brooks stima un fattore moltiplicativo: un prodotto costa circa tre volte un programma; un sistema circa tre volte un prodotto. Il numero puo essere discusso, ma il principio resta: passare da programma a prodotto e sistema aumenta molto il costo.
Accidental ed Essential Complexity
Definizione
La accidental complexity dipende da tecnologie, strumenti e linguaggi; la essential complexity dipende dal problema da risolvere e dalle componenti da integrare.
La complessita accidentale puo ridursi con strumenti migliori. Quella essenziale e piu difficile da eliminare. Per questo Brooks sostiene che non esiste una singola “silver bullet” capace di produrre da sola un ordine di grandezza di miglioramento in produttivita, affidabilita o semplicita.
The Mythical Man-Month
Definizione
Il man-month e una misura del lavoro basata sui mesi-uomo, ma usarla come se tempo e persone fossero sempre intercambiabili e sbagliato e pericoloso.
Brooks si chiede: “Why does software fail?“. Le cause indicate nelle slide includono mancato rispetto degli obiettivi, stime errate, troppo ottimismo, confusione tra impegno e avanzamento, scarso monitoraggio e aggiunta di personale a progetto gia in ritardo.
Danger
Effort != Progress: l’impegno da solo non assicura l’avanzamento del progetto.
Tutti i task hanno probabilita non nulla di fallire o ritardare. La probabilita che tutto vada bene e quindi molto bassa. Inoltre i costi dipendono dalle risorse impiegate, ma la velocita non cresce linearmente con il numero di persone.
Pit-stop di Formula 1
Aggiungere meccanici puo ridurre il tempo fino a un certo punto, ma solo se i ruoli sono chiari e il lavoro e partizionabile. Oltre un certo limite, coordinamento e interrelazioni impediscono miglioramenti lineari.
Brooks evidenzia anche il peso dei test. La sua ripartizione media del tempo di sviluppo e:
- 1/3 progettazione e pianificazione.
- 1/6 implementazione.
- 1/4 test dei componenti.
- 1/4 test del sistema integrato.
Ritardi
“How does a large software project get to be one year late? One day at a time!”
I ritardi finali sono difficili da recuperare perche aumentano pressione, panico e demotivazione. Aggiungere persone richiede training e puo peggiorare la situazione se le interrelazioni aumentano.
Team e Organizzazione
Definizione
Il team e uno degli elementi fondamentali per la riuscita di un progetto; la sua composizione influenza direttamente la gestione del lavoro.
Le slide confrontano due modelli: un team tradizionale con ruoli specializzati e un team agile con pochi ruoli e maggiore autonomia. Non sono gli unici modelli possibili, ma aiutano a capire quali mansioni devono essere coperte.
The Surgical Team
Definizione
Il surgical team, proposto da Harlan Mills, organizza il lavoro in team limitati con ruoli specializzati, come in una sala operatoria.
I ruoli indicati sono: chirurgo, copilota, amministratore, editor, segretaria, program clerk, toolsmith, tester e language lawyer.
- Chirurgo: dirige il team, prende decisioni su architettura e specifiche, codifica le parti piu impegnative, testa e documenta.
- Copilota: alter ego del chirurgo, meno esperto ma coinvolto nelle scelte.
- Amministratore ed editor: supportano aspetti amministrativi e documentali.
- Toolsmith e tester: curano strumenti, risorse e test.
- Program clerk, segretario e language lawyer: coprono supporto tecnico, organizzativo e competenze sul linguaggio.
Note
Oggi alcuni ruoli possono essere svolti dalla stessa persona, soprattutto in aziende medio-piccole. Il valore del modello sta nel rendere visibili le mansioni necessarie.
The Scrum Team
Definizione
Scrum e un framework di project management per lo sviluppo iterativo e incrementale di prodotti software.
Scrum usa iterazioni chiamate sprint, con durata definita. Il termine richiama la mischia del rugby: il team e concentrato sullo stesso obiettivo e lavora con comunicazione, empatia e spirito di gruppo.
I ruoli dello Scrum Team sono tre:
- Product Owner: responsabile del prodotto e del “cosa” deve essere realizzato.
- Scrum Master: coach al servizio del team, facilita crescita, comunicazione e rispetto delle indicazioni.
- Team di sviluppo: gruppo con competenze per sviluppare la soluzione, autonomo sulle scelte tecniche e sul “come” implementare.
Dimensioni del Team
Definizione
La dimensione ideale del team e quella che consente coordinamento efficace senza eccessivo overhead comunicativo.
Team troppo numerosi sono difficili da gestire. Le slide richiamano la Two-Pizza Team Rule di Jeff Bezos: un team dovrebbe avere una dimensione tale da poter essere sfamato con due pizze. La quantificazione riportata e circa 4-8 sviluppatori.
Integrita Concettuale e Second-System Effect
Definizione
L’integrita concettuale e il rispetto coerente della visione del sistema: funzionalita e implementazione devono rispondere solo ai requisiti definiti in progettazione.
Un sistema efficace, efficiente e user-friendly deve fare cio per cui e stato progettato, nel modo migliore, senza funzionalita inutili. Se diventa troppo complicato, molte funzionalita non verranno usate.
Per mantenere integrita concettuale, Brooks distingue tra architettura e implementazione:
- Architettura: decide cosa deve essere presente nel sistema.
- Implementazione: decide come realizzare tecnicamente cio che e stato definito.
Note
Brooks sintetizza: “Architecture is what happens, and implementation is how it happens”.
Second-System Effect
Il second-system effect e la tendenza a sovraccaricare il secondo sistema con tutte le idee non inserite nel primo, passando facilmente da better design a over design.
L’over design aumenta i costi e puo peggiorare il rapporto costi/benefici. Per questo Brooks raccomanda attenzione all’esperienza delle persone coinvolte nella progettazione.
Comunicazione e Documentazione
Definizione
La documentazione di progetto rende precise, comunicabili e verificabili le decisioni prese durante il progetto.
Le comunicazioni possono essere informali, tramite meeting o raccolte in un workbook, cioe un contenitore formale delle informazioni del progetto.
Documentare serve a:
- indicare il funzionamento di programmi e componenti;
- ricordare cosa e stato fatto;
- condividere il lavoro con i colleghi;
- definire interfacce tra componenti;
- tracciare problemi, bug e soluzioni;
- stabilire test case e modalita di utilizzo.
Manuale e Uso del Programma
Definizione
Il manuale puo contenere le specifiche dell’interfaccia, cioe cio che l’utente vede, ed essere usato anche come strumento di progettazione.
Secondo Brooks, la documentazione per usare un programma dovrebbe rispondere a domande su purpose, environment, domain and range, funzionalita e algoritmo, formati di input-output, istruzioni operative, opzioni, running time, accuratezza e controlli.
Warning
“Most documentation fails in giving too little overview. The trees are described, the bark and leaves are commented, but there is no map of the forest.”
Modificare un Programma
Per consentire modifiche future servono dettagli sull’implementazione: struttura interna dei componenti, strutture dati, input e output, algoritmi, tecnologie usate, limiti e possibili miglioramenti.
Le slide richiamano anche i self-documenting programs: nomi chiari, commenti, indentazione e strumenti come Doxygen aiutano a documentare il codice. Tuttavia, seguendo Fowler, il codice puo essere documentazione principale ma non deve essere l’unica documentazione disponibile.
Documenti Formali
Per gestire un progetto software Brooks indica almeno questi documenti:
- What: objective: bisogni, obiettivi, desiderata, vincoli e priorita.
- What: product specifications: manuale e descrizione dell’implementazione.
- When: schedule: organizzazione temporale delle attivita.
- How much: budget: risorse economiche e influenza sulle scelte tecniche.
- Where: space allocation: spazi e risorse fisiche, quando rilevanti.
- Who: organization chart: compiti, responsabilita e rete delle comunicazioni.
Tip
Scrivere le decisioni non e burocrazia fine a se stessa: aiuta a scoprire inconsistenze, comunicare al team e mantenere una checklist aggiornata del progetto.
La Rivoluzione Agile
Definizione
Il movimento Agile raccoglie approcci allo sviluppo software che valorizzano adattamento, collaborazione e consegna frequente di software funzionante.
Le slide presentano Agile come una possibile tensione rispetto al project management tradizionale. Il riferimento centrale e il Manifesto for Agile Software Development, redatto nel 2001 da 17 sviluppatori software.
I quattro valori del Manifesto sono:
- Individuals and interactions over processes and tools.
- Working software over comprehensive documentation.
- Customer collaboration over contract negotiation.
- Responding to change over following a plan.
Note
Il Manifesto non dice che gli elementi a destra non abbiano valore: dice che quelli a sinistra sono valorizzati di piu.
I principi Agile citati nelle slide includono soddisfare il cliente con consegne anticipate e continue, accogliere il cambiamento, consegnare software funzionante frequentemente, collaborazione quotidiana tra business e sviluppatori, team motivati, comunicazione face-to-face, sostenibilita, eccellenza tecnica, semplicita e team auto-organizzati.
Precisazione dalle slide
Agile non e anti-metodologia, anti-modellazione, anti-documentazione o anti-pianificazione. Cerca un equilibrio: si pianifica riconoscendo i limiti della pianificazione in ambienti turbolenti.
Prossimi Argomenti
Continueremo con:
- Definizione di Progetto - formalizzazione di progetto, gestione di progetto e pratiche di riferimento del corso.