Amministrazione di progetto
Amministratore di progetto
Scopo dell'amministrare un progetto è quello di evitare conflitti che si manifestano quando ci sono sovrapposizioni di ruoli e di responsabilità. L'amministratore di un progetto[1] non dirige (non compie scelte gestionali) ma deve far sì che l'infrastruttura di lavoro sia operante; attua le scelte tecnologiche concordate con i responsabili aziendali e di progetto e si assicura che vengano seguite dai membri del progetto.
Documentazione di progetto
Uno dei compiti dell'amministratore di progetto è quello di gestire la documentazione. I documenti devono essere chiaramente identificati, corretti nei contenuti, verificati, approvati, aggiornati (specificandone la data) e dotati di versione. La loro diffusione dev'essere controllata: i destinatari devono essere chiaramente identificati e ogni documento ha una sua lista di distribuzione (oppure è pubblico). La documentazione raccoglie tutto ciò che documenta le attività e si divide nelle seguenti due categorie.
- Documentazione di sviluppo:
- documentazione fornita dal cliente;
- diagrammi di progettazione;
- codice;
- piani di qualifica e risultati delle prove;
- documentazione di accompagnamento del progetto.
- Documentazione di gestione del progetto:
- documenti contrattuali;
- piani e consuntivi delle attività;
- piani di qualità.
Ogni documento contiene un "diario delle modifiche", in cui vengono riportate tutte le modifiche rispetto alla versione precedente del documento. Lo stile del diario delle modifiche dev'essere molto sintetico e, a questo scopo, è bene che si avvalga di riferimenti numerici all'interno del testo (numero della sezione modificata, ad esempio).
Ambiente di lavoro
L'amministratore di progetto si occupa dell'ambiente di lavoro, cioè l'insieme di persone, di ruoli, di procedure e l'infrastruttura[2] la cui qualità determina la produttività del progetto. L'ambiente di lavoro dev'essere:
- completo (offre tutto il necessario per svolgere le attività previste);
- ordinato (è facile trovare ciò che vi si cerca);
- aggiornato (il materiale obsoleto non deve causare intralcio).
Configurazione e versionamento di un prodotto
Oltre all'aspetto temporale (cioè il ciclo di vita), ogni prodotto ha anche un aspetto più "spaziale", in quanto si compone di parti. Quali esse sono e il modo in cui stanno assieme è detto "configurazione". E ogni sistema composto di parti va gestito con:
- controllo di configurazione;
- controllo di versione (versione non del prodotto ma di ogni parte della configurazione del prodotto).
Data la complessità di un prodotto software, la gestione della configurazione va automatizzata con strumenti adatti. Ogni parte della configurazione (configuration item, CI) dev'essere univocamente identificato (oltre ad avere nome, data, autore, registro delle modifiche e stato corrente). Due concetti centrali della gestione di configurazione sono i seguenti.
- Quello di baseline indica un punto d'arrivo tecnico dal quale non si retrocede; la baseline è fatta di elementi della configurazione e, poiché ogni parte è versionata, possiamo conoscere la differenza tra una baseline e l'altra. Una baseline è qualcosa di stabile — non usa e getta! — e sta in un repository[3]; serve da base per gli avanzamenti futuri e può essere cambiata solo tramite procedure di controllo di cambiamento.
- Il concetto di milestone indica un punto nel tempo associato ad un valore strategico. Ogni milestone di calendario è associata a uno specifico insieme di baseline. Ogni milestone dev'essere: specifica, raggiungibile, misurabile (per quantità d'impegno necessario), traducibile in compiti assegnabili e dimostrabile agli stakeholder[4].
Anche il controllo di versione fa affidamento sul repository, per permettere di lavorare su vecchi e nuovi CI senza rischio di sovrascritture accidentali, di condividere il lavorato nello spazio comune e di poter verificare la bontà di ogni modifica di baseline. Ogni versione è una istanza di prodotto funzionalmente distinta dalle altre. Invece, si dice "variante" una istanza di prodotto funzionalmente identica ad altre ma diversa per caratteristiche non funzionali. Infine, si dice "rilascio" (release) una istanza di prodotto resa disponibile a utenti esterni.
Modifiche
Anche nel corso del suo sviluppo, un progetto non è esente da richieste di modifiche (dagli utenti, dagli sviluppatori o semplicemente per competizione). Le richieste di modifica vanno sottoposte a un rigoroso processo di analisi, decisione, realizzazione e verifica; di ogni richiesta va tenuta traccia.
Norme di progetto
Un progetto necessita di linee guida per le attività di sviluppo. Le norme — che vanno accertate dagli amministratori — comprendono:
- organizzazione e uso delle risorse di sviluppo;
- convenzioni sull'uso degli strumenti di sviluppo;
- organizzazione della comunicazione e della cooperazione;
- norme di codifica;
- gestione dei cambiamenti.
Le norme di progetto descrivono come dovrà essere il way of working. Individuiamo due categorie di norme: regole (sottoposte a verifica) e raccomandazioni (suggerimenti, senza verifica). Tra le norme di progetto, particolare rilevanza hanno le norme di codifica; queste hanno l'obiettivo di far sì che il codice sorgente sia leggibile (anche a distanza di tempo) e costituiscono una misura preventiva che garantisce verificabilità, manutenibilità e portabilità.