12.0 Cascata vs. Gestione dei progetti ciclici (Parte 5) – Condizioni per la gestione di progetti ciclici

Utenti/clienti partecipano attivamente #

Ogni ciclo di gestione ciclica del progetto comporta lo sviluppo di requisiti, progettazione, esecuzione e test. Ciò implica che molte scelte devono essere fatte nel corso di un ciclo. Se il programma deve rappresentare accuratamente i desideri del cliente, il cliente deve essere un membro attivo del team di progetto.

I clienti devono comunicare le proprie esigenze a programmatori e progettisti nel modo più chiaro possibile. Ciò comporta spesso una partecipazione settimanale (o almeno bisettimanale) al team di progetto.

All’interno di un progetto, i consumatori contribuiscono alla definizione delle caratteristiche richieste e alla pianificazione del ciclo. Collaborano ai test di accettazione, approvano o rifiutano i risultati provvisori e contribuiscono alla direzione generale del progetto. Inoltre, il coinvolgimento attivo del cliente si traduce in risultati migliori quando si utilizza il metodo a cascata.

La squadra ha il potere di fare delle scelte. #

All’interno di un ciclo, il team di progetto deve essere autorizzato a prendere le proprie decisioni. Se al team di progetto manca questa autorità, il modello ciclico di gestione del progetto non funzionerà. Se è richiesta l’approvazione costante dei superiori durante un ciclo, ciò può comportare la stagnazione. Inoltre, gli estranei spesso non sono consapevoli di ciò che sta accadendo perché non sono attivamente coinvolti nel team di progetto; questo rende loro difficile prendere decisioni razionali.

L’output del progetto (software) può essere scomposto in componenti più piccoli. #

La gestione ciclica del progetto è un metodo di gestione dei progetti in cui parti del progetto vengono completate in una serie di cicli. Ciò è possibile solo se il software in fase di sviluppo è scomponibile in un numero di componenti più o meno distinti.

I requisiti della direzione per il software di gestione dei progetti sono principalmente globali; il management non impone requisiti diretti, concreti o specifici. Uno dei vantaggi della gestione ciclica del progetto è la stretta collaborazione tra il cliente, i progettisti, i programmatori e gli eventuali tester durante i cicli. Se vengono stabiliti requisiti specifici e concreti all’inizio di un progetto, ciò limita la capacità del team di progetto di utilizzare il proprio miglior giudizio quando effettua le scelte progettuali. Numerosi requisiti di un progetto si rivelano bisognosi di adattamento durante il processo e quindi non dovrebbero essere (troppo) saldamente stabiliti all’inizio.

Il cliente comprende le attività. #

Se all’interno di un ciclo deve svolgersi un lavoro tecnico significativo che è difficile da comprendere per il cliente, esiste il rischio che il cliente non sia in grado di contribuire efficacemente al team. In una situazione del genere, il cliente ha pochissima voce in capitolo nelle decisioni di progettazione che devono essere prese.

Un rischio simile esiste quando il cliente non è a conoscenza dei progressi. Ad esempio, gran parte del lavoro può essere dedicato alla codifica, con poca attenzione all’interfaccia utente. È fondamentale che i clienti abbiano una visione sufficiente della sostanza e della progressione di un ciclo per evitare di essere messi in disparte.

Dovrebbe essere possibile tornare sui propri passi. #

Anche nella gestione ciclica dei progetti, i team a volte perseguono percorsi che si rivelano errati. In tal caso dovrebbe essere possibile fare un passo indietro. Se un nuovo modulo creato durante un ciclo risulta insufficiente, deve essere possibile riprendere a lavorare con il modulo precedente. Ciò impone requisiti, in particolare per l’archiviazione e la documentazione dei materiali del progetto. CVS e Subversion sono due strumenti utili per questi compiti (vedi Appendice 3 per un elenco completo degli strumenti).

Oltre alle capacità di programmazione, i programmatori dovrebbero essere in grado di interagire efficacemente con i clienti e viceversa. I membri del team devono essere pensatori intellettuali. La disciplina è necessaria per continuare con il lavoro.

Anche l’organizzazione in cui viene condotto il progetto deve fornire un supporto sufficiente per questa modalità di funzionamento. Per supportare i progetti sono necessari sistemi di monitoraggio del tempo, archiviazione e pianificazione. Questi sistemi di registrazione forniscono l’apertura essenziale per garantire un’equa allocazione delle risorse tra progetti e periodi di tempo.

Priorità #

Ai progetti dovrebbe essere data un’importanza adeguata e i membri del team dovrebbero essere messi a loro disposizione. Richiedere ai membri del team di lavorare su troppe attività contemporaneamente è inefficace. Se un’organizzazione non è adeguatamente adattata al lavoro basato su progetti, è probabile che la flessibilità ciclica della gestione del progetto provochi il caos. Inoltre, la tecnica a cascata beneficia di un approccio organizzato alla gestione del progetto (vedi Wijnen, 2004, p. 111).

Il direttore di un’azienda di sviluppo software, che era più visionario che manager, aveva una grande idea quasi ogni mese e avviava costantemente nuove iniziative nella sua azienda. Di conseguenza, i progetti più vecchi non sono mai stati completati e i lavoratori hanno lavorato a ben cinque progetti contemporaneamente. Il carismatico direttore aveva appena finito di leggere un libro sullo sviluppo rapido di applicazioni (RAD) e ne era molto entusiasta, soprattutto per l’elemento “rapido”. Ha registrato le idee fondamentali della RAD sulla fotocopiatrice e poi si aspettava che tutti avrebbero iniziato a lavorare con queste nozioni. Dopotutto, era una tecnica eccellente.

Rischi della gestione ciclica del progetto #

Le tecniche di gestione ciclica del progetto a volte lasciano un tempo inadeguato per eseguire le funzionalità richieste. Poiché la durata del progetto è fissa, quasi sicuramente verranno aggiunte meno funzioni di quanto inizialmente previsto.

Sebbene questa sia una preoccupazione legittima, è anche inerente all’approccio a cascata . La fase di definizione dell’approccio a cascata comporta un esame approfondito dei requisiti. È probabile che questa analisi porti a una migliore gestione del tempo. Spesso non è così nella realtà, per i motivi sopra esposti.

Inoltre, le funzionalità sono omesse in questo approccio a causa della mancanza di fondi per svilupparle.

I requisiti sono trattati pragmaticamente negli approcci ciclici. Ad esempio, le esigenze in cicli possono essere classificate utilizzando i criteri MoSCoW (Stapleton, 2003) come segue:

  • Must Have: requisiti critici di sistema
  • Dovrebbero avere: bisogni critici che gli utenti desiderano veramente
  • Potrebbe avere: bisogni desiderabili che possono essere facilmente ignorati
  • Vuoi avere: requisiti che questa volta non saranno soddisfatti: requisiti che possono aspettare fino a tardi

Indipendentemente dal fatto che determinate funzionalità non siano più disponibili, i project manager DANS ritengono che il lavoro ciclico porti a una maggiore soddisfazione del cliente rispetto all’approccio a cascata. In ogni caso, le aspettative vengono regolarmente controllate in modo più efficace e i progetti producono regolarmente risultati che funzionano, anche se sono meno complessi di quanto inizialmente previsto.

Comprendere i potenziali svantaggi #

Uno svantaggio comunemente citato di XP è che una potenza significativa viene trasferita ai programmatori. Se abusano di questa autorità, possono sfruttare la mancanza di competenza tecnica del cliente a proprio vantaggio. Per evitare questo scenario è necessario un capo progetto in grado di prestare attenzione sia agli interessi dei programmatori che a quelli del cliente. Questi project leader aiutano i loro clienti nella selezione e pianificazione dei cicli, nel rendere comprensibili le basi tecniche delle loro selezioni e nel fornire amministrazione e reporting.

Infine, un altro svantaggio di XP è che l’implementazione del metodo richiede un’elevata curva di apprendimento per programmatori, manager e consumatori.