Il corso di Project Management è nato qualche anno fa su sollecitazione delle imprese, che considerano importante per il loro successo introdurre al loro interno la cultura del project management. Le competenze che fornisce sono utili a chi farà il project manager, a chi farà l'architetto e anche, semplicemente, a chi parteciperà a un progetto: cioè, prima o poi, a chiunque lavori nella produzione di software.
Il punto di partenza dichiarato è che la gestione di un progetto può essere effettuata seguendo numerosi approcci, e ogni approccio può essere applicato seguendo uno dei tanti template proposti in letteratura oppure customizzati per le esigenze specifiche dell'impresa o del progetto. Il corso non insegna quindi «il» metodo giusto: cerca di fornire le conoscenze per orientarsi in questo contesto.
Il corso considera acquisite le basi di Ingegneria del Software. Ci sono limitate sovrapposizioni programmate con altri insegnamenti, al solo scopo di raccordare i temi; il baricentro resta comunque la gestione dei progetti, con l'obiettivo esplicito di separare gli aspetti di base dagli approcci specifici e dai corrispondenti template.
Il corso deve trovare un equilibrio tra due esigenze opposte: quella dello studente di avere punti di riferimento concreti (esempi pratici, template) e l'obiettivo di mantenere una certa apertura mentale verso il mondo assai variegato della gestione di progetti di sviluppo software (e non solo). Tenere insieme le due cose è, in piccolo, lo stesso problema che avrete come project manager.
I testi principali usati per costruire il corso sono i seguenti; ritornano più volte nei capitoli successivi come fonte delle definizioni e dei template.
| Autore / ente | Testo | Anno |
|---|---|---|
| PMI | Guida al Project Management Body of Knowledge (Guida al PMBOK®), sesta edizione | 2018 |
| PMI | Software Extension to the PMBOK Guide, quinta edizione | 2013 |
| PMI | Guida alle Pratiche dell'Agile | 2018 |
| F. P. Brooks | The Mythical Man-Month: essays on software engineering — Anniversary Edition | 1995 |
| R. K. Wysocki | Effective Project Management: Traditional, Agile, Extreme, 8th Edition | 2019 |
| Leli, Pugliese, Puliti, Roggero | Guida Galattica per Agilisti (guidagalatticaperagilisti.com) | — |
| Chemuturi, Cagley | Mastering Software Project Management: Best Practices, Tools and Techniques | 2010 |
| H. Kerzner | Project Management: pianificazione, scheduling e controllo dei progetti (ed. it. Bianco, Caramia) | 2013 |
| A. Sinibaldi | Gestione di Progetti IT | 2008 |
| Osterwalder, Pigneur | Creare modelli di business | 2012 |
La frequenza è consigliata ma non obbligatoria, e c'è la massima disponibilità verso gli studenti che hanno difficoltà a seguire le lezioni frontali. Il ricevimento è su appuntamento (mail, studio 4144 dell'area DISI, telefono) ed è presentato come «un'importante opportunità che ogni studente dovrebbe sfruttare».
L'esame è orale e prevede due cose insieme: la verifica delle conoscenze acquisite durante il corso e la discussione di un elaborato. L'elaborato consiste nella simulazione delle attività di «gestione di un progetto di sviluppo software», reale o di fantasia, e deve essere concordato con il docente.
L'obiettivo dell'elaborato non è implementare il software — l'implementazione non deve essere eseguita — ma dimostrare la capacità di gestire un progetto. Tutto ciò che scrivete verrà letto con questa lente.
| Deliverable | Contenuto atteso |
|---|---|
| Descrizione dell'approccio utilizzato | Come si è scelto di gestire il progetto, giustificando ogni scelta e illustrando tutta la documentazione allegata. L'organizzazione del documento è libera, ma ci si aspetta di trovare descritti tutti gli aspetti rilevanti di scoping/initiating, planning, launching/execution, monitoring & controlling e closing. Per ogni documento allegato va illustrato il contenuto (utile un indice del materiale). Per i meeting previsti va documentato l'ordine del giorno, i partecipanti e una sintesi dell'ipotetico svolgimento. |
| Documentazione di progetto | L'insieme dei documenti che lo studente ha deciso di utilizzare: POS, RBS, WBS, PDS, analisi dei rischi, Gantt, ecc. Formato libero; è incoraggiato l'uso di software di supporto (MS Project e simili), eventualmente allegando snapshot se il docente non dispone del programma. |
Alla consegna (via mail) si suggerisce un file compresso con due cartelle — una per la descrizione dell'approccio, una per la documentazione — oppure un unico PDF con tutto il materiale.
Due regole operative da non dimenticare: l'elaborato va concordato con il docente e consegnato almeno una settimana prima dell'orale. Anche quando gli appelli sono a date prefissate, è consentito fissare l'esame su appuntamento.
L'introduzione al project management parte da Fred Brooks, informatico e ingegnere del software responsabile dei progetti della famiglia IBM System/360 e del sistema operativo IBM OS/360. La sua notorietà è dovuta al libro The Mythical Man-Month (1975) e agli articoli che lo hanno accompagnato, che hanno generato un dibattito ancora vivo oggi. Il suo enunciato più celebre è la Legge di Brooks:
«Adding people to a late software project just makes it later.»
Le idee di Brooks non vanno prese come verità assolute: molti principi sono ancora condivisibili, altri sono dibattuti o considerati obsoleti, e gli approcci agile sembrano in contrasto con parecchi di essi. Servono come base di discussione per i temi che accompagneranno tutto il corso.
Il primo tema è il mito del garage. Già negli anni Settanta Brooks osservava che si leggeva spesso di piccoli gruppi di programmatori che, in un qualche garage, scrivevano software capace di competere con quello prodotto da aziende con team molto più numerosi e organizzati — esattamente come accade anche oggi. La sua domanda era: «why, then, do we not replace large teams — no matter how well-run — with two and a half men coding away in garages?»
La risposta, fornita da Brooks stesso, è semplice: «the small systems don't really compare with the products that require large teams». I software scritti in un garage non hanno richiesto un'approfondita analisi dei requisiti e dell'architettura, un insieme di test sufficiente, un piano di manutenzione, una documentazione dettagliata.
La leggenda vuole che Steve Jobs e Steve Wozniak svilupparono il loro primo PC in un garage. Recentemente Wozniak ha confessato che la maggior parte del lavoro l'ha svolta nel suo «cubicolo» presso HP, che però non ha creduto nel suo progetto. L'essenza non cambia: Wozniak e Jobs hanno sviluppato il loro primo PC. Certo che il risultato, seppur funzionante, era tutto tranne che un «prodotto». La domanda da farsi è: che cosa gli mancava per esserlo?
Larry Page e Sergey Brin scrissero la prima versione di Google quando erano entrambi studenti di dottorato a Stanford, nel loro garage. L'idea non era originale: sul mercato c'erano già molti «web searcher» e directory. I fattori di successo furono quattro: funzionava meglio degli altri (l'algoritmo PageRank dava risultati migliori dei concorrenti); un modello di business innovativo (valorizzare il dato raccolto, invece di limitarsi a vendere pubblicità o posizionamenti); la facilità di utilizzo (interfaccia essenziale, focalizzata sul servizio); un progetto chiaro focalizzato sul «fare» (execution). Alcuni autori sottolineano che il progetto è ancora più importante dell'idea, che può evolvere e cambiare: da qui lo slogan «execution over idea».
Facebook non nasce in un garage ma in un campus: nel 2003 Mark Zuckerberg crea «Facemash», un'applicazione che confrontava foto di compagni di università. È un ottimo esempio di ottima idea più ottima execution: la soluzione interessava molto il pubblico, l'infrastruttura funzionava, scalava e offriva un'ottima UX. Mancava il modello di business: per lungo tempo Facebook non ha saputo come produrre utili dalla sua soluzione. Nel 2020 il modello era focalizzato per il 98,3% sulla pubblicità — ed è lecito chiedersi se sia un problema e se il modello possa essere migliorato.
Non basta l'idea, e non basta nemmeno la capacità di tradurla in una soluzione concreta: è necessario definire il modello che consentirà alla soluzione di produrre utili per i finanziatori, indispensabili per portare il prodotto sul mercato.
In un garage possono nascere buone idee e prototipi interessanti, ma non prodotti. Per portare sul mercato un prodotto è necessario fare un piano; e se siamo una start-up in cerca di finanziatori, la prima cosa da scrivere è un business plan con un modello di business convincente. Gli elementi fondamentali si riassumono in due parole chiave: goal e progetto.
| Elemento | Ruolo |
|---|---|
| Goal | Definisce che cosa deve essere fatto. La definizione del goal è parte integrante del progetto. |
| Progetto | Consente di raggiungere il risultato atteso. Richiede un'attenta gestione per garantire il rispetto del goal, far fronte ai cambiamenti e alla complessità, impiegare bene le risorse disponibili (tempo e denaro compresi), organizzare e dirigere il team, le comunicazioni, la documentazione. |
Definire approcci e buone pratiche di riferimento — è la scoperta che il corso propone — può essere di grande aiuto. Le definizioni formali di progetto e di gestione di progetto arrivano nei capitoli 3 e 4; qui si evidenziano gli aspetti rilevanti già identificati da Brooks.
Per Brooks, fare un progetto significa svolgere un'approfondita analisi dei requisiti e dell'architettura e produrre una documentazione dettagliata; il risultato dell'analisi è un progetto a cui attenersi rigidamente. Questa visione può risultare limitata e datata, ma è lo stesso autore a sostenere che «the only constancy is change itself», aggiungendo la raccomandazione «plan the system for change».
Oggi alcuni approcci progettuali (per esempio quelli agile) non impongono un'analisi dettagliata e vincolante, ma assumono a priori che i requisiti possano essere modificati in corso d'opera: il progetto deve essere sufficientemente flessibile per accogliere i cambiamenti.
Il cambiamento può riguardare la soluzione che si sta sviluppando (modifica dell'idea iniziale, cambio di tecnologia) oppure le risorse a disposizione (taglio del budget, ritardi che riducono il tempo). In entrambi i casi va gestito, e un buon piano aiuta ad affrontarlo nel modo migliore. Sarà importante prevedere i possibili cambiamenti dove possibile ed essere pronti a gestirli correttamente.
Il cambiamento è fonte di stress per il personale coinvolto nel progetto, e lo stress può produrre ulteriori problemi. È un effetto di secondo ordine che i piani ignorano quasi sempre.
La metafora scelta da Brooks per questa condizione è la tar pit, la palude di bitume (come i La Brea Tar Pits dipinti da Charles R. Knight): «Software like a tar pit: the more you fight it, the deeper you sink!»
Progetti molto complessi non possono essere suddivisi in tanti task «indipendenti» eseguibili senza comunicazioni tra gli sviluppatori e senza un insieme di complesse interrelazioni tra task e sviluppatori. Il punto centrale è questo:
La complessità non riguarda la difficoltà di implementazione di alcune parti del sistema, ma le interrelazioni tra i diversi task e gli sviluppatori. La progettazione, per quanto accurata e approfondita, non rimuove la complessità: consente di gestirla.
Un programma è un insieme di istruzioni che implementa una o più funzionalità: scrivere un programma non equivale a realizzare un prodotto. Solitamente un team di 2–3 programmatori in un garage produce un programma.
Brooks stima che mediamente il costo per realizzare un prodotto sia tre volte il costo per realizzare un programma, e che il costo di un sistema sia tre volte quello di un prodotto — quindi nove volte il costo di un programma. Non è importante determinare se le stime siano corrette: è importante il principio, cioè che ci sia un fattore moltiplicativo non trascurabile.
| Tipo | Che cos'è | Si può ridurre? |
|---|---|---|
| Accidental complexity | Gli aspetti tecnici relativi alle tecnologie impiegate: linguaggi di programmazione, librerie, strumenti di test e di building. | Sì, anche in modo sensibile, migliorando le tecnologie a disposizione — come di fatto sta avvenendo. |
| Essential complexity | Il problema che bisogna risolvere per realizzare il sistema: le sue diverse componenti che devono essere integrate. | Difficile da ridurre. |
Da qui il famoso claim del «no silver bullet»: «there is no single development, in either technology or management technique, which by itself promises even one order of magnitude improvement within a decade in productivity, in reliability, in simplicity.»
La domanda fondamentale di Brooks è: «Why does software fail?». I motivi principali sono sei.
Sul terzo punto Brooks si appoggia a Dorothy Sayers, che in The Mind of the Maker suddivide il processo creativo in tre fasi — l'idea, l'implementazione e l'interazione — e ne dà questa sintesi: «A book, then, or a computer, or a program comes into existence first as an ideal construct, built outside time and space, but complete in the mind of the authors. It is realized in time and space, by pen, ink, and paper, or by wire, silicon, and ferrite. The creation is complete when someone reads the book, uses the computer, or runs the program, thereby interacting with the mind of the maker.» La conseguenza è una triste realtà: gli sviluppatori sono ottimisti, e gli errori e le inconsistenze dell'idea iniziale emergono solo durante l'implementazione e l'interazione degli utenti con la soluzione.
Tutti i task hanno una probabilità non nulla di fallire o subire ritardi. Di conseguenza la probabilità che tutto vada bene è prossima allo zero: pianificare come se ogni task andasse a buon fine è, statisticamente, pianificare l'impossibile.
I costi dipendono strettamente dalle risorse impiegate — compreso il tempo/uomo del personale — ma la velocità di avanzamento di un progetto non dipende strettamente dalla quantità di risorse allocate. Il semplice uso del man month come misura delle risorse disponibili è sbagliato e pericoloso.
«Esiste un tempo minimo di sviluppo che non può essere ridotto ulteriormente, anche aumentando le risorse disponibili.» Esempio: un progetto che richiede 100 mesi/uomo non dura un mese se si impiegano 100 sviluppatori.
L'esempio didattico è il pit-stop di Formula 1. Assumendo che siano sempre disponibili due meccanici dedicati esclusivamente al sollevamento dell'auto: con un solo meccanico per il cambio delle quattro gomme si impiega un tempo T; con due meccanici si può sperare di dimezzare T; con tre? con quattro? con otto? con cinquanta? La funzione non è affatto lineare — e si noti che nel pit-stop reale ogni meccanico ha assegnato un ruolo ben preciso.
Modello illustrativo costruito sulle quattro curve della Tavola 1.2. La quota non partizionabile del lavoro non si divide mai; ogni coppia di sviluppatori aggiunge un costo di comunicazione.
I costi per il test di ciò che è stato implementato sono sempre sottostimati. Brooks suggerisce che il tempo complessivo di sviluppo sia mediamente così partizionato:
«Question: how does a large software project get to be one year late? Answer: one day at a time!» Le stime sono spesso sbagliate per mancanza di coraggio (gutless estimating) da parte degli sviluppatori, che non riescono a contrastare le richieste del management che impone tempi più stretti e irrealistici. E i ritardi che si riscontrano nella fase finale dei test sono i più difficili da recuperare, perché tendono a deprimere e a mandare nel panico gli sviluppatori — che così diventano meno produttivi sia in qualità sia in quantità.
Data una schedulazione originale con le milestone A, B, C e D, che cosa si fa quando A slitta di un mese? Brooks mette a confronto tre reazioni possibili, con esiti molto diversi.
La reazione 1 è la più diffusa proprio perché è la più indolore da comunicare: sposta A e lascia il resto invariato, cioè assume un recupero che nessuno ha pianificato. La reazione 2 è onesta ma costa un mese al cliente. La reazione 3 sembra la più energica ed è quella contro cui la Legge di Brooks mette in guardia: le persone nuove vanno formate, e chi le forma sono proprio quelli già in ritardo.
Nella gestione di un progetto è necessario tener conto sia degli aspetti positivi (le «gioie») sia di quelli negativi (i «dolori») del realizzare software. Sui primi si può far leva per motivare lo staff; i secondi nascondono le insidie che emergeranno durante il progetto.
Le domande aperte che il corso lascia in sospeso e che ritorneranno più volte: come si motiva lo staff facendo leva sugli aspetti positivi? Come incide sull'organizzazione del progetto la flessibilità del mezzo? Quali insidie nascondono gli aspetti negativi, e come si possono eliminare o gestire?
Seleziona le caratteristiche che il tuo software possiede oggi: la classificazione di Brooks si aggiorna in tempo reale.
«Adding people to a late software project just makes it later»: aggiungere persone a un progetto software già in ritardo lo fa ritardare ulteriormente. È controintuitiva perché il «mese-uomo» suggerisce che risorse e tempo siano intercambiabili. Non lo sono: il lavoro non è perfettamente partizionabile, le nuove persone vanno formate (tempi di training) e ogni persona in più aggiunge comunicazioni, cioè interrelazioni tra task e sviluppatori.
Un programma è un insieme di istruzioni che implementa una o più funzionalità (tipicamente prodotto da 2–3 programmatori in un garage). Un prodotto è qualcosa di più: deve essere adeguatamente testato, utilizzabile in ambienti e con set di dati diversi, eseguibile/testabile/modificabile da chiunque, con documentazione dettagliata e completa. Un sistema è un insieme di prodotti che interagiscono tra loro per supportare processi complessi: richiede integrazione definita con precisione, tracciati di input e output precisi (le interfacce), test di integrazione, e opera con risorse limitate. Le stime di Brooks: prodotto ≈ 3 × programma, sistema ≈ 3 × prodotto = 9 × programma.
La accidental complexity riguarda gli aspetti tecnici delle tecnologie impiegate (linguaggi, librerie, strumenti di test e building) e può essere ridotta anche sensibilmente migliorando le tecnologie. La essential complexity riguarda il problema da risolvere e le sue componenti da integrare, ed è difficile da ridurre. Su questa seconda si fonda il claim «no silver bullet»: nessun singolo sviluppo, né tecnologico né gestionale, promette da solo un miglioramento di un ordine di grandezza in un decennio in produttività, affidabilità o semplicità.
1) Mancato rispetto degli obiettivi, con integrità concettuale violata; 2) difficoltà nella stima corretta dei tempi, con sottostima spesso voluta per compiacere il management; 3) troppo ottimismo; 4) la convinzione che l'impegno da solo assicuri l'avanzamento (Effort ≠ Progress); 5) mancato monitoraggio dello stato di avanzamento rispetto al preventivato; 6) ritardi dovuti all'aggiunta di nuovo personale al progetto.
Afferma che «esiste un tempo minimo di sviluppo che non può essere ridotto ulteriormente, anche aumentando le risorse disponibili». Un progetto da 100 mesi/uomo non dura un mese con 100 sviluppatori: esiste un pavimento sotto il quale nessuna aggiunta di risorse porta.
1/3 progettazione e pianificazione; 1/6 implementazione (scrittura del codice); 1/4 test dei componenti (early system test); 1/4 test del sistema quando i componenti sono integrati. Metà del tempo è quindi test — e i costi del test sono sempre sottostimati, anche perché scrivere il codice di test di una funzionalità può costare più del codice della funzionalità stessa.
Perché mostra che una buona idea più una buona execution non bastano: l'infrastruttura funzionava, scalava e offriva un'ottima UX, ma mancava il modello di business e per lungo tempo l'azienda non ha saputo come produrre utili. Nel 2020 il modello era focalizzato per il 98,3% sulla pubblicità. Serve definire il modello che consentirà alla soluzione di produrre utili per i finanziatori.
Quattro: funzionava meglio degli altri (PageRank dava risultati migliori); un modello di business innovativo (valorizzazione del dato raccolto invece della sola vendita di pubblicità o posizionamenti); la facilità di utilizzo (interfaccia essenziale, focalizzata sul servizio); un progetto chiaro focalizzato sul «fare». Da qui il principio «execution over idea»: il progetto conta più dell'idea, che può evolvere e cambiare.
È la metafora di Brooks per il progetto software che si impantana: «the more you fight it, the deeper you sink». Si lega alla sua posizione sul cambiamento: «the only constancy is change itself», da cui la raccomandazione «plan the system for change» — cioè progettare il sistema perché possa cambiare, invece di sperare che i requisiti stiano fermi.
Nella simulazione delle attività di gestione di un progetto di sviluppo software, reale o di fantasia, concordato con il docente. Prevede due sezioni: la descrizione dell'approccio utilizzato (con la giustificazione di ogni scelta e la copertura di scoping, planning, launching, monitoring & controlling, closing, incluse agende e partecipanti dei meeting) e la documentazione di progetto (POS, RBS, WBS, PDS, analisi dei rischi, Gantt, ecc.). Non si valuta la soluzione software ma la gestione; sono premiati contributi originali e uso di strumenti di supporto; all'orale bisogna saper argomentare le proprie scelte e conoscere le alternative.
Perché mostra che il tempo non scala con il numero di persone: con un meccanico si impiega T, con due si può sperare di dimezzare T, ma con tre, quattro, otto o cinquanta la funzione non è affatto lineare — e a un certo punto le persone si ostacolano. Si noti inoltre che nel pit-stop ogni meccanico ha un ruolo ben preciso: la partizionabilità non è solo questione di numeri, ma di organizzazione.