Per la riuscita di un progetto uno degli elementi fondamentali è il team, e la sua corretta composizione è un prerequisito per una gestione efficiente. La composizione è fortemente influenzata dall'ambito del progetto e dalle metodologie che si intende utilizzare.
Il corso mette a confronto due proposte molto alternative:
Sono solo due esempi, ma permettono di individuare i ruoli principali che devono essere coperti dai componenti di un team — indipendentemente dall'organizzazione che poi si sceglie.
Per l'organizzazione del lavoro in un generico progetto di sviluppo software, Harlan Mills suggerì un approccio che nella sua essenza è adottato ancora oggi: affidare i task a team di dimensioni limitate, organizzati come una squadra chirurgica. Nove figure, con un centro di gravità evidente.
| Ruolo | Mansione |
|---|---|
| Chirurgo | Dirige il team. Prende tutte le decisioni su architettura e specifiche, sia funzionali sia di performance; codifica le parti più impegnative, testa il codice e scrive la documentazione. |
| Copilota | Alter-ego del chirurgo, in grado di fare tutto ciò che fa lui ma con meno esperienza. Il chirurgo condivide con lui tutte le scelte progettuali, ma il suo parere può essere ignorato. |
| Amministratore | Il chirurgo ha pieni poteri e controlla anche gli aspetti amministrativi, ma ha bisogno di un esecutore delle sue direttive. In genere è condiviso da più team. |
| Editor | La documentazione è responsabilità del chirurgo, ma l'editor la corregge, la organizza e la aggiorna a fronte di modifiche. |
| Toolsmith | Realizza, installa e manutiene tutti gli strumenti e le risorse necessarie agli sviluppatori. |
| Tester | Prepara ed esegue i test per i diversi casi d'uso, cercando insiemi di dati rappresentativi delle situazioni operative — inclusi i dati di casi reali che hanno causato malfunzionamenti. |
| Program clerk | Impiegato che supporta amministratore ed editor, ma con conoscenze e responsabilità tecniche. |
| Segretario | Supporta in particolare amministratore ed editor; non deve avere conoscenze tecniche. |
| Language lawyer | Definisce come usare il linguaggio di programmazione per implementare particolari parti di codice. Agli albori dell'informatica era fondamentale. |
L'evoluzione tecnologica e metodologica ha trasformato alcuni ruoli, in certi casi depotenziandoli (il language lawyer, il segretario) e in altri potenziandoli (il toolsmith, oggi vicino a chi cura CI/CD e piattaforma). Il punto che regge nel tempo: indipendentemente dall'organizzazione adottata, quelle mansioni esistono e qualcuno le deve fare.
All'estremo opposto c'è Scrum, framework di project management proposto negli anni Novanta da Ken Schwaber e Jeff Sutherland per lo sviluppo iterativo e incrementale di prodotti software. Il termine, che nel rugby indica la mischia, descrive un approccio in cui le persone sono concentrate sullo stesso obiettivo: il successo del progetto. Nel rugby lo sprint è quel tratto di corsa che si fa per portare avanti il pallone: «il portatore di palla corre in avanti seguito dai suoi compagni che lo sostengono: spirito di gruppo, comunicazione, empatia sono tutte caratteristiche importanti».
In Scrum il lavoro viene suddiviso in iterazioni (gli sprint), di durata ben precisa e predeterminata, e sono previsti solo tre ruoli.
Ha la responsabilità del prodotto, conosce l'utente e i suoi bisogni. È responsabile del «cosa» sarà contenuto all'interno del prodotto, ma non del «come» questo verrà realizzato, che è di competenza del team di sviluppo.
Il suo ruolo non è quello del «capo» del team, come il termine master potrebbe far pensare: è un coach al servizio del team, che ne aiuta la crescita, agevola la comunicazione, fa in modo che si rispettino le indicazioni.
È composto da persone che dovrebbero avere tutte le competenze per sviluppare la soluzione, cioè le user story inserite nel loro backlog. Per questo motivo dovrebbero sempre avere la massima autonomia sulle scelte tecniche, in particolare sul come implementare le funzionalità.
La separazione cosa / come non è un'invenzione agile: è la stessa che Brooks pone tra architetto e implementatore (paragrafo 5). Cambia chi la presidia — un Product Owner al posto di un architetto — e cambia il momento in cui viene fissata, ma il confine è lo stesso.
Il dimensionamento del team di sviluppo è un tema molto dibattuto, ma c'è accordo su un punto: team troppo numerosi sono di difficile gestione, perché richiedono un alto overhead per le comunicazioni.
Secondo Jeff Bezos, un team deve avere un numero di componenti che possono essere sfamati da due pizze. Quante persone si possono accontentare di due pizze? L'idea è ormai condivisa da una vasta platea di professionisti, che quantifica le dimensioni ideali in circa 4–8 sviluppatori.
Quindi, indipendentemente dalle dimensioni dell'azienda e dal numero di sviluppatori coinvolti in un progetto, i team non devono superare un certo numero di componenti. Sulla composizione, invece, resta aperta la scelta tra team generalisti (per esempio full-stack), specialisti (che coprono uno specifico dominio) o un mix dei due.
Muovi il cursore e osserva quanti collegamenti bisogna tenere allineati.
Il rispetto della conceptual integrity è molto importante e al tempo stesso difficile da definire. Per produrre un sistema efficace, efficiente e user-friendly è necessario che le funzionalità e la loro implementazione rispondano solo e solamente ai requisiti definiti in fase di progettazione.
Il motivo è semplice: se un sistema è troppo complicato da usare, molte delle sue funzionalità non saranno usate, perché nessun utente ha il tempo e la pazienza di impararle.
Per mantenere l'integrità concettuale è necessario separare l'architettura dall'implementazione. Uno o più architetti decidono cosa deve essere presente nel sistema e cosa no, tenendo in considerazione le esigenze dell'utente finale; devono poi assicurarsi che la loro visione sia condivisa dal resto del team. Il come il sistema dovrà essere implementato lo definisce invece il team che si prende carico dell'implementazione.
Delegare l'implementazione al team permette una gestione più efficiente ed evita di sovraccaricare l'architetto, che rischia altrimenti di diventare un collo di bottiglia. Brooks riassume così: «Architecture is what happens, and implementation is how it happens», e parla in questo contesto di aristocracy e democracy.
Il primo sistema che si progetta e implementa prevede solitamente solo le funzionalità richieste dall'utente e ha un'implementazione «pulita». Appena è completato ci si accorge che potrebbe essere migliorato, modificando l'implementazione di alcune funzionalità o aggiungendone di nuove: queste idee vengono riservate per il prossimo progetto.
Per questa ragione il secondo sistema viene progettato aggiungendo «tutto» ciò che si ritiene di aver dimenticato nel primo. Ma passare da un better design a un over design è molto facile — e l'over design ha un impatto negativo anche sui costi, perché non valuta correttamente il rapporto costi/benefici.
La raccomandazione di Brooks è che il management punti su personale con almeno due progetti/sistemi alle spalle: chi ha già attraversato l'effetto del secondo sistema è vaccinato. È una posizione discutibile — il corso la propone esplicitamente come domanda aperta: cosa ne pensate?
Come si comunica in un progetto? Brooks distingue tre canali, dal più informale al più strutturato.
| Canale | Che cos'è |
|---|---|
| Informally | Telefono, pausa caffè, instant message, pub… |
| Meetings | Riunioni a cadenza regolare o al bisogno, dove i team informano gli altri (colleghi, altri team, manager) sullo stato di avanzamento, sulle criticità riscontrate, su proposte progettuali o implementative. |
| Workbook | Contenitore in cui sono riportate formalmente tutte le informazioni riguardanti un progetto. Anni fa erano documenti stampati su carta, oggi sono sempre più spesso fruibili via web usando intranet aziendali, soluzioni cloud, ecc. |
Brooks apre il tema con una confessione istruttiva: «For several years I diligently lectured my software engineering class on the necessity and propriety of good documentation, exhorting them even more fervently and eloquently. It didn't work. I assumed they had learned how to document properly and were failing for lack of zeal. Then I tried showing them how the job is done. This has been much more successful.»
Documentare il proprio lavoro è fondamentale per: indicare il funzionamento di un programma o di un componente; ricordarsi a distanza di tempo cosa si è fatto; condividere il proprio lavoro con i colleghi; definire formalmente le interfacce tra componenti; tenere traccia di problemi e soluzioni (per esempio i bug); stabilire i test case e definirne l'utilizzo.
Le specifiche scritte dell'architetto potrebbero essere fornite sotto forma di manuale, che riporta in dettaglio tutte le specifiche dell'interfaccia, cioè tutto ciò che l'utente vede. Il manuale è anche uno strumento per la progettazione, spesso sottovalutato: può essere modificato dai feedback degli utenti finali e del team di implementazione, e nei capitolati di progetto sarebbe buona norma riportarlo, perché costituisce un insieme di specifiche molto dettagliato e molto efficace nella fase di test e validazione da parte del cliente. (Domanda aperta del corso: al giorno d'oggi, che fine hanno fatto i manuali?)
«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.» Ogni utente necessita di una descrizione in prosa del software, sintetica ma esaustiva — compito non facile — e questa documentazione dovrebbe essere già disponibile prima che il software sia implementato. Brooks individua i quesiti a cui bisogna dare risposta:
| Quesito | Domanda |
|---|---|
| Purpose | Qual è la funzione principale del software? |
| Environment | Su quale macchina, configurazione e sistema operativo girerà? |
| Domain and Range | Quale dominio dell'input è valido? Quale output si ritiene ammissibile? |
| Function Realized and Algorithm Used | Precisamente cosa permette di fare il software, e come? |
| Input-Output Formats | Qual è il formato e il mezzo per input e output? La descrizione deve essere completa e precisa. |
| Operating Instruction | Come si usa? Quali sono le eccezioni e come si gestiscono? |
| Options | Quali scelte può effettuare l'utente? Come vanno specificate? |
| Running Time | Quanto tempo impiega per eseguire una funzionalità su un input di una certa dimensione e su una macchina di data configurazione? |
| Accuracy and Checking | Quanto è precisa la soluzione fornita? Ci sono funzionalità per il controllo di accuratezza e correttezza? |
Le domande cambiano: come consentire modifiche e correzioni in futuro? Come riutilizzare il lavoro fatto in passato? Come consentire anche ad altri di intervenire sul codice? Servono tutti i dettagli dell'implementazione: chi modifica il codice ha bisogno di una descrizione chiara e precisa della struttura interna dei componenti. Gli elementi utili sono:
Martin Fowler sostiene che il codice stesso può essere considerato la documentazione principale di un sistema software, ma ricorda anche che non deve essere l'unica documentazione disponibile. Un modo efficace ed efficiente per documentare il codice è inserire la documentazione nel codice stesso: commenti, nomi delle variabili, indentazione. Il vantaggio è che la documentazione è immediatamente disponibile e allineata con il codice — a patto che lo sviluppatore aggiorni i commenti con costanza. Usando particolari regole sintattiche nella scrittura dei commenti si può anche produrre documentazione in automatico (Doc++, Doxygen).
Il confronto proposto a lezione è impietoso. Ecco la prima versione:
float O[ND,NG];
float P[ND];
float S[ND];
F1(ND,NG,O);
F2(ND,P)
for (i=0; i<ND; i++)
{
S[i] = 0.0;
for (j=0; j<NG; j++)
{
if (O[i,j]>8)
S[i] += (8 + 1.2 * (O[i,j]-8)) * P[i];
else
S[i] += O[i,j] * P[i];
}
}E questa è la stessa identica logica, riscritta. Clicca su una riga per la spiegazione:
Non è cambiata una sola istruzione: sono cambiati i nomi e c'è un commento. La regola dello straordinario pagato il 20% in più era già lì, nel numero 1.2, ma nessuno poteva vederla.
Molti progetti di sviluppo software iniziano con numerose riunioni per definire la struttura, poi si inizia subito a scrivere il codice. Anche per progetti di piccole dimensioni sarebbe opportuno produrre della documentazione. Per gestire un progetto software è necessario quanto meno produrre i documenti seguenti, che Brooks organizza per domanda.
| Domanda | Documento | Contenuto |
|---|---|---|
| What | Objective | I bisogni che devono essere soddisfatti, gli obiettivi, i desiderata, i vincoli e le priorità. |
| What | Product specifications | La prima versione può essere una proposta sintetica, ma deve evolvere in un documento completo: il manuale (ciò che vede l'utente) più una descrizione dettagliata dell'implementazione (a uso interno). |
| When | Schedule | L'organizzazione di tutte le attività di progetto (Gantt, ecc.). Può prevedere l'uso di strumenti software specifici (per esempio Microsoft Project). |
| How much | Budget | Tra i documenti più importanti per la gestione: il budget può influenzare anche le scelte tecniche. |
| Where | Space allocation | Nella produzione del software non è di solito un tema fondamentale, ma non va sottovalutato e va comunque considerato. |
| Who | Organization chart | Documentare l'organizzazione delle risorse coinvolte è fondamentale sia per attribuire compiti e responsabilità, sia per stabilire la rete delle comunicazioni (e quindi la rete delle responsabilità). |
L'organizzazione delle risorse umane e l'assegnazione delle mansioni hanno una forte interrelazione con l'architettura da implementare: per questo la documentazione riguardante l'organizzazione deve avere una corrispondenza biunivoca con la documentazione tecnica. È la formulazione «di progetto» di ciò che oggi chiamiamo legge di Conway.
Clicca prima una domanda, poi il documento che le corrisponde.
La citazione da mandare a memoria, perché lega documentazione e ruolo del manager: «The task of the manager is to develop a plan and then to realize it. But only the written plan is precise and communicable. Such a plan consists of documents on what, when, how much, where, and who. This small set of critical documents encapsulates much of the manager's work. If their comprehensive and critical nature is recognized in the beginning, the manager can approach them as a friendly tools rather than annoying busywork.»
Tutto ciò che si è detto finora è in linea con un approccio tradizionale al project management. Negli ultimi anni, nello sviluppo software, si sono imposti numerosi approcci che sembrano «violare» molti di quei principi: il movimento di maggior successo è Agile.
Le idee ispiratrici sono riassunte nel Manifesto for Agile Software Development (agilemanifesto.org), redatto nel febbraio 2001, quando 17 sviluppatori si incontrarono allo Snowbird Resort nello Utah per discutere di metodi di sviluppo «leggeri». A quanto pare non avevano le stesse idee, ma trovarono un accordo su quattro punti.
Dallo stesso agilemanifesto.org: «The Agile movement is not anti-methodology, in fact, many of us want to restore credibility to the word methodology. We want to restore a balance. We embrace modeling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes. We plan, but recognize the limits of planning in a turbulent environment.» Agile non significa «niente modelli, niente documenti, niente piano».
Per ogni affermazione, scegli se è in linea con l'impostazione tradizionale di Brooks o con il Manifesto Agile.
Il pregio è di evidenziare le mansioni che dovrebbero essere coperte all'interno di un team, indipendentemente dall'organizzazione adottata. Oggi, soprattutto nelle aziende medio-piccole, alcuni ruoli sono interpretati dalla stessa persona, e la tendenza è verso team «orizzontali» in cui gli sviluppatori gestiscono direttamente molte delle mansioni del surgical team; ma quelle mansioni continuano a esistere.
Il Product Owner ha la responsabilità del prodotto, conosce l'utente e i suoi bisogni, ed è responsabile del «cosa» sarà contenuto nel prodotto. Il team di sviluppo è responsabile del «come»: dovrebbe avere tutte le competenze per sviluppare le user story del proprio backlog e la massima autonomia sulle scelte tecniche. Lo Scrum Master non è il capo: è un coach al servizio del team, che ne agevola crescita e comunicazione e fa in modo che si rispettino le indicazioni.
È la regola attribuita a Jeff Bezos secondo cui un team deve avere un numero di componenti sfamabili da due pizze. La platea professionale quantifica le dimensioni ideali in circa 4–8 sviluppatori. La ragione tecnica è l'overhead di comunicazione: team troppo numerosi sono di difficile gestione.
È la proprietà per cui le funzionalità e la loro implementazione rispondono solo e solamente ai requisiti definiti in fase di progettazione: il sistema fa tutto ciò per cui è stato progettato (efficacia), lo fa nel modo migliore (efficienza), e nessuna funzionalità non prevista viene implementata. Si difende separando l'architettura dall'implementazione: gli architetti decidono cosa deve esserci e cosa no, tenendo conto dell'utente finale, e assicurano che la visione sia condivisa; il team decide come implementare. «Architecture is what happens, and implementation is how it happens.»
Per due motivi. Primo, efficienza: non delegare sovraccarica l'architetto, che diventa un collo di bottiglia. Secondo, motivazione: agli sviluppatori deve essere lasciata la «gioia» di dare libero sfogo alla propria creatività, purché sia rispettata l'integrità concettuale di quanto progettato. I tre pericoli per gli architetti sono infatti: specifiche troppo ricche che ignorano i costi di implementazione; prendersi tutto il divertimento lasciando pochi margini creativi; non coinvolgere gli sviluppatori quando le specifiche sono pronte o mentre vengono definite.
Il primo sistema prevede solo le funzionalità richieste e ha un'implementazione pulita. Appena è completato nascono idee di miglioramento, che vengono riservate per il progetto successivo. Il secondo sistema viene quindi progettato aggiungendo tutto ciò che si ritiene di aver dimenticato nel primo, e il passaggio da better design a over design è molto facile. L'over design ha impatto negativo anche sui costi, perché non valuta correttamente il rapporto costi/benefici. La raccomandazione di Brooks: puntare su personale con almeno due progetti alle spalle.
Organizzati per domanda: what (objective: bisogni, obiettivi, desiderata, vincoli, priorità — e product specifications: manuale più descrizione dettagliata dell'implementazione), when (schedule: Gantt e organizzazione delle attività), how much (budget, che può influenzare anche le scelte tecniche), where (space allocation, non fondamentale nel software ma da non sottovalutare), who (organization chart, per attribuire compiti e responsabilità e stabilire la rete delle comunicazioni).
Perché l'organizzazione delle risorse umane e l'assegnazione delle mansioni hanno una forte interrelazione con l'architettura che si deve implementare. La documentazione sull'organizzazione deve quindi avere una corrispondenza biunivoca con la documentazione tecnica: la rete delle comunicazioni è anche la rete delle responsabilità.
Sostiene che il codice stesso può essere considerato la documentazione principale di un sistema software, ma ricorda che non deve esserne l'unica. Documentare dentro il codice (commenti, nomi delle variabili, indentazione) è efficace ed efficiente perché la documentazione è immediatamente disponibile e allineata — a patto che lo sviluppatore aggiorni i commenti con costanza. Con regole sintattiche apposite si può generare documentazione automatica (Doc++, Doxygen).
Individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; responding to change over following a plan. La clausola finale, spesso dimenticata: «while there is value in the items on the right, we value the items on the left more» — la colonna di destra non viene negata, viene messa in secondo piano.
No, e il Manifesto lo precisa esplicitamente: il movimento non è anti-metodologia, anzi molti dei firmatari vogliono restituire credibilità alla parola metodologia. Abbracciano il modeling, ma non per archiviare diagrammi in un polveroso repository aziendale; abbracciano la documentazione, ma non centinaia di pagine mai manutenute e raramente usate; pianificano, ma riconoscendo i limiti della pianificazione in un ambiente turbolento.
Su tre canali: informally (telefono, pausa caffè, instant message, pub); meetings, a cadenza regolare o al bisogno, dove i team informano gli altri su stato di avanzamento, criticità e proposte; workbook, il contenitore in cui sono riportate formalmente tutte le informazioni del progetto — un tempo su carta, oggi via web su intranet o cloud.