Inizio del progetto
È necessario predisporre le risorse di base del progetto in una fase iniziale denominata inizio del progetto.
In questo argomento
Riunione di pianificazione
Sviluppo iterativo
Definizione del progetto come basato sull'ambito o basato sui dati
Pianificare le risorse del progetto
Definire ruoli e responsabilità
Definire un piano di comunicazione
Identificare le parti interessate
Strutturare il piano del progetto
Rivedere il piano del progetto
Ottenere l'impegno sul progetto
Riunione di pianificazione
In una fase iniziale del progetto è consigliabile riunire diversi esperti in materia e parti interessate per discutere del progetto e creare il piano del prodotto.È consigliabile scegliere le parti interessate in base alla natura e alla complessità del progetto e dei risultati finali del prodotto.
A seconda della dimensione e della complessità del progetto, la riunione può richiedere da giorni a più settimane.
Sviluppo iterativo
Un'importante tecnica nella gestione dei rischi consiste nel pianificare il progetto in iterazioni, in genere di quattro o fino a sei settimane.Un piano di iterazione è un elenco di funzionalità che il team di progetto svilupperà e testerà.Ogni funzionalità specifica un'attività o una variante migliorata di un'attività che l'utente sarà in grado di eseguire utilizzando il prodotto.Alla fine di ogni iterazione, vengono presentate le funzionalità pianificate.Alla fine di alcune iterazioni, il prodotto parzialmente completato viene reso disponibile per la valutazione da parte di un insieme limitato di utenti.
I commenti e suggerimenti ottenuti da tali presentazioni e valutazioni viene utilizzato per rivedere il piano.
Il piano del prodotto viene organizzato in modo che gli scenari utente principali e i componenti principali del sistema vengano provati in una fase iniziale, anche se solo in modo semplificato.
Uno dei rischi più significativi nella maggior parte dei progetti è costituito dall'errata interpretazione dei requisiti.I requisiti possono essere interpretati erroneamente non solo dal team di sviluppo, ma anche dagli utenti finali e dalle parti interessate.Tali soggetti, ad esempio, potrebbero non comprendere come l'installazione di un nuovo sistema possa influire sulle attività aziendali.
Il contesto aziendale, inoltre, potrebbe cambiare per la durata del progetto, modificando i requisiti del prodotto.
Un processo iterativo garantisce che qualsiasi cambiamento relativo ai requisiti individuato presentando il prodotto possa essere adeguato prima della fine del progetto, senza provocare una costosa rielaborazione.
Un altro rischio significativo è rappresentato dalla valutazione errata dei costi di sviluppo.Per sviluppatori impegnati in una nuova area e talvolta anche in una nuova piattaforma, può risultare difficile definire in anticipo stime accurate dei costi di sviluppo per il progetto.In alcuni casi, può essere difficile determinare se una strategia di implementazione specifica avrà prestazioni sufficientemente soddisfacenti.Rivedendo il piano alla fine di ogni iterazione, tuttavia, il team può sfruttare l'esperienza acquisita nelle iterazioni precedenti.Si tratta di uno dei motivi per cui un piano di prodotto efficace comporta la pianificazione di attività per ogni componente principale in una fase iniziale.
Definizione del progetto come basato sull'ambito o basato sui dati
Per alcuni progetti è necessario che tutti i requisiti vengano soddisfatti prima della consegna.Questi tipi di progetti sono anomali in un contesto software.Un esempio reale può essere rappresentato dalla costruzione di un ponte.In questo caso, una campata solo parzialmente completata risulterebbe inservibile.D'altro canto, un progetto software parzialmente completato ma pianificato in modo appropriato può essere distribuito e utilizzato da un insieme limitato di utenti.Il progetto potrà quindi essere completato in modo incrementale nel corso di diversi aggiornamenti.
Determinare innanzitutto se il progetto è effettivamente basato sull'ambito.In tal caso, è necessario attendere prima di definire una data di fine, in modo da disporre di stime accurate e di un piano dettagliato.Questo modo di procedere ha un prezzo.Aumenta infatti l'overhead relativo alla pianificazione, mentre la predisposizione del buffering come piano di emergenza per gestire stime non accurate comporta ulteriori ritardi nella data di consegna, con un conseguente aumento dei costi.È pertanto opportuno essere assolutamente certi prima di definire il progetto come basato sull'ambito.Questo tipo di progetto è più probabile in un ambiente di progettazione di sistemi complessi che non nel caso di un prodotto o un servizio puramente software.
La maggior parte dei progetti software è basata sui dati, in quanto tali progetti possono essere resi disponibili in modo incrementale.Se, ad esempio, un videogioco deve essere rilasciato per le vacanze natalizie in Italia, dovrà essere pronto per novembre.La mancata consegna a novembre influirà gravemente sulle vendite tra novembre e Natale e, se la pianificazione subisce un ritardo di due mesi, l'opportunità di vendita potrebbe svanire del tutto.
Pianificare le risorse del progetto
È necessario predisporre il personale appropriato per un progetto, in modo che questo possa essere consegnato nella data desiderata.È consigliabile utilizzare i dati cronologici dei progetti precedenti per organizzare una discussione sulle risorse sufficienti.
Dopo avere individuato i requisiti del personale, creare un organigramma del progetto che identifichi in modo chiaro la struttura del team del progetto, i livelli di reperimento delle risorse e la distribuzione geografica, se necessario.Salvare tutte le informazioni relative al personale nel portale del progetto.
Definire ruoli e responsabilità
Descrivere ogni ruolo del progetto e le relative responsabilità e pubblicarli nel piano del progetto.Ogni persona inclusa nel progetto deve essere consapevole del proprio ruolo e delle proprie responsabilità nel progetto.
Definire un piano di comunicazione
È importante definire un piano di comunicazione per il progetto.I canali di comunicazione consentono di gestire i costi di coordinamento del progetto.È importante definire i partecipanti alle riunioni, la frequenza delle riunioni, i canali di comunicazione e le modalità di inoltro dei problemi che non possono essere risolti dai partecipanti abituali alle riunioni.
L'obiettivo di un buon piano di comunicazione consiste nel garantire che le attività di coordinamento per il progetto vengano eseguite il più agevolmente possibile per evitare attività superflue dovute a errori di comunicazione.
Il piano di comunicazione deve essere pubblicato nel portale del progetto e gestito come richiesto.Un piano di comunicazione è un utile strumento per tutto il personale e in particolare per i nuovi membri,a cui consente di comprendere il funzionamento di un team di dimensioni maggiori e come realizzare gli obiettivi comunicando in modo efficace tramite modalità diverse, con svariati membri del team e per diversi scopi.
Identificare le parti interessate
Identificare tutte le parti interessate pertinenti per il progetto.Oltre ai membri principali del team, l'elenco deve includere persone che operano nel settore aziendale e tecnici interessati alla corretta implementazione del progetto o ai possibili effetti del prodotto quando questo sarà operativo.Tali parti interessate potranno trovarsi a monte o a valle dell'attività di progettazione software.
Strutturare il piano del progetto
Creare una bozza del primo piano del progetto, da rivedere all'inizio dello sviluppo.Lo scopo di questa versione consiste nel semplificare la discussione su risorse e scale cronologiche con gli sponsor del progetto.Tale bozza dovrà inoltre delineare le funzionalità principali e le date di consegna stimate.Per ulteriori informazioni, vedere Pianificazione del progetto (CMMI).
Rivedere il piano del progetto
Pubblicare la struttura del piano del progetto nel portale del progetto.Benché la stesura del piano sia stata molto impegnativa, si tratta di un piano di alto livello in cui vengono rinviate molte decisioni dettagliate relative alla pianificazione.Si tratta di una scelta voluta.Troppi dettagli a questo punto provocherebbero sprechi e perdite di tempo in seguito.
Laddove i requisiti risultino ancora incerti, pianificarli solo nella struttura, rinviandone i dettagli fino quando non saranno disponibili ulteriori informazioni.Pianificare l'ottenimento di tali informazioni.
Pianificare una riunione di revisione con tutte le parti interessate.Il confronto personale costituisce sempre la scelta migliore per questo tipo di attività.Assicurarsi di pianificare tempo sufficiente per una revisione completa e per l'esposizione delle opinioni discordanti.
Ottenere l'impegno sul progetto
Quando tutte le parti interessate concordano sul piano del progetto, ottenere da ciascuno l'impegno ad approvarlo.
Raccogliere le dichiarazioni di impegno e archiviarne i dettagli nel portale del progetto.
Risorse supplementari
Per ulteriori informazioni, vedere le risorse Web seguenti:
Guida pratica allo sviluppo basato sulle funzionalità, Stephen R.Palmiere e John Malcolm Felsing; Prentice Hall PTR, 2002.
Compendio della misurazione IT: stima e benchmark dell'esito positivo tramite la misurazione funzionale delle dimensioni, Manfred Bundschuh e Carol Dekkers; Springer, 2008.