Approccio Tradizionale vs DSDM: Modalità d’uso delle principali variabili di progetto

I progetti, generalmente, hanno necessità di bilanciare diversi variabili che spesso sono in conflitto tra loro. Le quattro variabili più comuni sono: le tempistiche, i costi, le feature/requisiti e la qualità dei prodotti deliverati da un progetto. Tentare di fissare, all’inizio di un progetto, le quattro variabili è irrealistico, tale tentativo funzionerebbe esclusivamente in un mondo perfetto dove il business non abbia mai necessità di cambiare, dove qualsiasi cosa sia totalmente compresa prima di realizzarla e i progetti non incorrano mai in nessun tipo di criticità o rischio. Il desiderio di fissare ogni cosa, in fase iniziale, è la causa del fallimento di molti progetti. La mancanza di adeguata contingenza porta, in molti casi, a prendere decisioni che si riveleranno, successivamente, sbagliate e tra l’altro difficoltose da correggere in quanto riscontrabili, il più delle volte, verso la fine dei progetti stessi. In funzione di ciò, è importante in fase di avvio di un progetto porsi una domanda: “Se durante il progetto si incontra un problema, cosa bisogna proteggere (fix) e cosa invece è necessario negoziare (vary)?”. Il tipo di risposta indirizza il modello di gestione che si vuole applicare al progetto:  modello tradizionale o Agile(DSDM).

Variabili di Progetto - Tradizionale vs DSDM
Figura 1: Variabili di progetto – Approccio  Tradizionale vs Agile

In un approccio tradizionale, come si deduce dal diagramma di sinistra della figura 1, i requisiti sono protetti (fissati) mentre le tempistiche, i costi e la qualità (seppur quest’ultima in modo parziale) sono soggetti a variazione. Attraverso un esempio specifico si vuole mostrare, rispetto a un modello di gestione tradizionale, le modalità d’uso di tali variabili e l’impatto che ne consegue sul business delle organizzazioni. Un progetto fixed-price contestualizzato in un rapporto commerciale cliente/fornitore è un tipico esempio di progetto gestito con un approccio tradizionale. Infatti si suppone che vi sia un cliente che specificherà il risultato desiderato (requisiti fissi) e pagherà probabilmente il progetto, nonché un fornitore che renderà disponibili le risorse e le competenze necessarie per consegnare tale risultato e al quale sarà corrisposto un importo per un ambito di lavoro definito (requisiti fissi) indipendentemente dal costo e dall’impegno sostenuto. In questa direzione, dove il cliente è responsabile della creazione di un documento (capitolato tecnico) con tutte le specifiche necessarie, i dettagli e le varie scadenze, i requisiti saranno  fissati e quindi protetti. Saranno vincolati, allo stesso modo, anche i costi e i tempi poiché frutto di una quantificazione puntuale calcolata dal fornitore in funzione del capitolato tecnico, redatto dal cliente, allegato a una richiesta di proposta (RFP)

Quindi in un rapporto commerciale cliente/fornitore di tipo fixed-price, l’immutabilità delle tematiche costi e tempistiche di progetto come si coniuga con la variabilità delle stesse tipiche di un approccio tradizionale?

La variabilità dei costi e delle tempistiche, in effetti, deriva da un costo-tempistica di base ipotizzato per il progetto sommato ad una riserva di contingency finalizzata a coprire eventuali variazioni degli stessi correlate a problemi/questioni che potrebbero emergere durante la vita del progetto. In sostanza l’immutabilità dei costi e dei tempi disciplinata da un contratto di tipo fixed-price, maschera una variabilità legata agli eventuali accantonamenti di contingency utili a gestire i rischi identificati e accettati e per i quali si svilupperanno risposte contingenti o di mitigazione.

La protezione della feature di progetto congiuntamente alla negoziazione delle variabili tempi e costi quali effetti genera sul business di un’organizzazione?

La variabilità dei costi e soprattutto delle tempistiche, seppur mascherata all’interno di un contratto di tipo fixed-price, può spesso minare i razionali che ci sono dietro l’origine di un progetto specie quando sono coinvolte opportunità di marketing o sfidanti milestone di tipo normativo o legale. Consegnare una soluzione in linea con una tempistica adeguata rispetto alle esigenze di progetto è spesso il più importante fattore critico di successo di quest’ultimo. In questa direzione l’accantonamento della contingency in termini di tempi e costi, tipica di un approccio tradizionale, può compromettere i benefici derivati, a titolo di esempio, dalla riduzione del tempo TTM(Time to Market)  necessario per introdurre nel mercato (è il caso ad esempio di un’azienda che vuole imporsi sul mercato prima dei concorrenti) un nuovo prodotto o servizio oppure dalla massimizzazione del ROI(Return on investment) mediante una delivery più rapida e incrementale.

Nel mondo di oggi in cui il cambiamento è all’ordine del giorno, dove le esigenze sono il frutto di continui mutamenti normativi, legali, di marketing o comunque contestuali ai dinamici processi di un’azienda, il rischio di consegnare una soluzione (contemplante tutte le feature fissate in fase d’inizio di un progetto) non più conforme con il risultato atteso da parte del business è molto alto. Le esigenze di business sono mutevoli, tale dinamicità si accentua quando la raccolta e l’approfondimento dei requisiti si concentra in un’unica finestra temporale (fase di analisi di dettaglio) generalmente a ridosso, in linea con l’approccio tradizionale/sequenziale, dell’inizio del progetto.

In un rapporto commerciale cliente/fornitore di tipo fixed-price approcciato secondo un modello waterfall (tradizionale), il tentativo da parte del fornitore di analizzare nel dettaglio fin da subito, tutte le feature confinate nel capitolato tecnico specificato dal cliente, eventualmente anticipando possibili scenari piuttosto che prevedendo future necessità di business, comporta, con buona probabilità, di consegnare una soluzione troppo lontana dalle necessità reali del business probabilmente mutate, nel corso del tempo, rispetto alle esigenze iniziali.

In progetti molto complessi e duraturi dove il ciclo di vita del progetto prevede fasi sequenziali lunghe e articolate, la consegna di un prodotto non “adatto all’uso” da parte del business e la conseguente mancata realizzazione del valore atteso rappresentano un rischio ancor più concreto. Inoltre consegnare una soluzione non adatta all’uso, soprattutto in progetti complessi e duraturi dove il tempo necessario per l’analisi, il disegno e la realizzazione è la causa frequente del ritardo della delivery dei prodotti, può impattare sulla scarsa manutenibilità, sulla limitata semplicità nel modificare la soluzione e conseguentemente sul costo complessivo TCO(Total Cost of Ownership) del progetto. I costi d’implementazione delle maggior parte delle soluzioni contribuiscono per una piccola quota al TCO. È quindi auspicabile costruire soluzioni semplici, allineate, nel momento in cui vengono consegnate, alle necessità del business e di conseguenza più facili da manutenere e adeguare.

La qualità, invece, tende a diventare una variabile non pianificabile o meglio una variabile che all’inizio viene fissata, ma che purtroppo subisce in molti contesti una variazione non prevista. Infatti poiché il testing è tipicamente pianificato verso la fine del progetto, si tende generalmente, nel tentativo di recuperare un eventuale ritardo che si è accumulato durante la fase di sviluppo, a tagliare l’impegno e il tempo previsto inerente tutte quelle attività che sono appunto finalizzate ad assicurare la buona qualità dei prodotti.

In un approccio Agile, nello specifico in DSDM, quali sono le variabili che è necessario negoziare e quali invece devono essere protette?

Come si deduce dal diagramma a destra della figura 1, in DSDM, contrariamente all’approccio tradizionale, i costi, le tempistiche e la qualità di progetto vengono fissate alla fine della fase di Foundation del processo DSDM e comunque all’inizio di ogni ciclo di Timebox, mentre la contingenza è garantita adattando lo “scope” di progetto (requisiti), che rimane flessibile in funzione delle esigenze di rapidità di sviluppo e del massimo valore erogabile nei tempi, nei costi e nella qualità concordata.

Pertanto, in una logica di tipo Timebox, in presenza di un problema o di una questione che possa mettere a rischio la deadline o i costi di progetto concordati, le feature identificate dai ruoli di business come quelle di minor “valore” non verranno deliverate nel timeframe corrente, ma verranno consegnate eventualmente in un successivo Timebox piuttosto che “cancellati” dallo scope di progetto. In questa direzione l’effort e quindi il tempo recuperato, a fronte della mancata elaborazione dei requisiti identificati a bassa priorità, verrà utilizzato come riserva di contingency utile alla consegna delle feature classificate dai ruoli di business come quelle apportanti “valore” nel rispetto dei tempi, dei costi e della qualità concordata.

La protezione delle variabili costi, tempi e qualità congiuntamente alla negoziazione dei requisiti quali effetti genera sul business di un’organizzazione?

Un progetto gestito con l’approccio DSDM consegnerà sempre, mediante la rigorosa applicazione delle pratiche MoSCoW e TimeBox, una soluzione adatta all’uso e quindi in linea con le reali necessità del business nel rispetto dei costi, delle tempistiche e della qualità concordata.

In un progetto DSDM, in virtù dell’immutabilità delle variabili costi e tempistiche di progetto, è necessario comprendere, da parte di tutti gli stakeholder, ma in particolare dai ruoli di business, cosa è vitale e indispensabile (in termini di requisiti, user stories, prodotti, criteri di accettazione,…) affinché una soluzione frutto dell’elaborazione di uno specifico timeframe (project, increment, timebox) si possa reputare come adatta allo scopo.

In questo senso, MoSCoW è una tecnica di prioritizzazione utile a comprendere e gestire le priorità. Tale tecnica consente ai ruoli del business di identificare, per ciascun timeframe,  quattro tipologie di requisiti:

  • i requisiti Must Have o meglio quelli che si è identificato consegnare necessariamente, senza i quali la soluzione o parte di essa non avrebbe senso di esistere;
  • le feature Should Have o meglio quelle ritenute importanti ma non vitali, senza le quali la soluzione rimane ancora attuabile seppur priva di requisiti importanti;
  • le feature Could Have o meglio quelle reputate, da parte del business, meno importanti se confrontate con le feature Should Have;
  • i requisiti Won’t Have o meglio quelli che si è identificato non consegnare, almeno nel timeframe corrente. Classificare un requisito come Won’t Have consente al business di circostanziare l’ambito di progetto e quindi assumere consapevolezza delle proprie aspettative.

DSDM raccomanda, in fase di prioritizzazione dei requisiti, che l’effort previsto per la consegna dei Must Have non ecceda il 60% dell’effort disponibile allocato per tutti i requisiti contemplati nel timeframe corrente. In caso contrario, la consegna del set di requisiti classificati come vitale (Must Have) verrebbe messa a serio rischio. Inoltre DSDM suggerisce che l’effort pianificato per la consegna dei Could Have sia approssimativamente il 20% dell’effort totale assegnato a tutti i requisiti compresi nel timeframe corrente. In DSDM le feature Could Have rappresentano il principale serbatoio di contingenza. In caso di problemi o questioni che possano compromettere la deadline del timeframe, una parte o l’intero set dei Could Have costituirebbe la prima scelta di quello che, in termini di feature, non verrebbe implementato. Nel caso fosse necessario (worst case), al fine di garantire la delivery dei Must Have, i requisiti Should Have verrebbero rimossi dal timeframe e l’effort previsto per questi ultimi verrebbe utilizzato per portare a termine le feature classificate come vitali. Tuttavia nella maggior parte delle circostanze l’aspettativa del business è che venga consegnato un prodotto che abbia un peso maggiore, in termine di valore, del minimo garantito (Must Have).

DSDM definisce il Timebox come un periodo fissato di tempo a valle del quale un obiettivo deve essere soddisfatto. Soddisfare un obiettivo significa realizzare uno o più deliverable utili a produrre un Solution Increment. La lunghezza ottimale per un TimeBox è tipicamente tra le due e le quattro settimane, lasso di tempo abbastanza ampio per consegnare qualcosa di “valore” e abbastanza breve per focalizzare l’attenzione del team di sviluppo sugli obiettivi concordati all’inizio del Timebox stesso. Quindi l’applicazione della pratica MoSCoW in combinazione con la tecnica TimeBox garantisce la delivery on-target e quella on-time o meglio la consegna dei prodotti in linea con le necessità reali del business nel rispetto dei costi e dei tempi (delivery on-time) concordati all’inizio del timebox. La delivery on-target e on-time garantita dall’uso combinato di MoSCoW e Timebox, viene assicurata, per propagazione, anche ai timeframe di più alto livello (increment e project).

L’approccio iterativo e incrementale di DSDM garantisce che i requisiti prioritizzati mediante MoSCoW siano costruiti ad un livello di qualità concordato nelle prima fasi del ciclo di vita di un progetto. In DSDM, come assevera il quarto principio denominato Never Compromise Quality, la qualità non deve mai diventare una variabile. I livelli di qualità concordati sono garantiti focalizzando l’attenzione da parte del team sui requisiti classificati, mediante MoSCoW, con più alta priorità prima di iniziare lo sviluppo dei requisiti classificati con priorità più bassa ( in questo modo si assicura che i requisiti con priorità alta siano sviluppati in linea con gli standard accordati e che i criteri di accettazione siano soddisfatti).

Quindi a parità di tempistiche, costi e team di progetto, un cliente, in un contesto di gestione DSDM, rischia di avere, per lo stesso progetto, meno feature (variabilità dei requisiti) rispetto ad un contesto di gestione tradizionale? Si deduce, di conseguenza, che i progetti DSDM rischiano di consegnare soluzioni non aderenti, in termini di  qualità della soluzione, alle necessità del business?

Assolutamente no. Intanto a parità di progetto, di risorse e competenze messe a disposizione per la sua implementazione, le tempistiche e i costi, in un contesto DSDM, sono generalmente inferiori a quelli pianificati mediante la maggior parte degli approcci tradizionali, in particolar modo nei progetti di tipo fixed-price. Infatti a parità di attività, task, work package di progetto.., la pianificazione dei costi e quindi delle tempistiche, in un contesto DSDM, non contempla le risorse finanziare e di timing adottate nella maggior parte degli approcci tradizionali per gestire e mitigare i rischi di progetto. In DSDM la prioritizzazione di MoSCoW insieme alla tecnica di TimeBox, come descritto in precedenza, consente di deliverare, senza eccezioni, una soluzione che aderisce alle necessità reali del business (scope) e contestualmente di salvaguardare la qualità tecnica delle feature che dovranno essere consegnate.

In merito al secondo quesito, bisogna intanto sottolineare che in DSDM la qualità di una soluzione è misurata mediante due dimensioni.

La prima misura l’ambito di progetto che dovrà essere consegnato (dimensione quantitativa), la seconda dimensione è inerente la qualità tecnica delle feature che dovranno essere consegnate (dimensione qualitativa). Queste due dimensioni, insieme, rispondono alla domanda: “I prodotti consegnati dal progetto sono adatti all’uso?”.

Per la maggior parte degli approcci tradizionali, la delivery di una soluzione che non contempli il 100% dei requisiti, analizzati nelle prime fasi di progetto, è sintomo di una soluzione non in linea con la qualità attesa. Contrariamente, in DSDM, la qualità della soluzione, in termini di dimensione quantitativa, è misurata valutando se i prodotti consegnati incontrino le necessità reali del business. Una soluzione che soddisfa esclusivamente i requisiti classificati come Must Have sarà certamente considerata fattibile, ma probabilmente non risponderà al valore di business atteso. In questo scenario la qualità della soluzione, in termini di completezza e valore atteso, dovrebbe essere considerata inferiore rispetto alle aspettative del business. Una soluzione, invece, che incontra i requisiti classificati come Must Have e Should Have rappresenterà una soluzione in linea, in termini di completezza e valore atteso, con le aspettative del business. Una soluzione che soddisfa, oltre i Must Have e Should Have, anche i requisiti classificati come Could Have, rappresenterà una soluzione che supera, in termini di completezza e valore atteso, le aspettative del business.

Una soluzione, in termini di dimensione qualitativa, si può definire come adatta all’uso qualora soddisfi i criteri di accettazione concordati. I criteri di accettazione, gli standard architetturali e le appropriate strategie per le attività di review e testing sono accordate alla fine della fase di Foundation del ciclo di vita di un progetto DSDM e rappresentano il livello di qualità che una soluzione deve traguardare al fine di essere valutata come adatta all’uso. Il rilassamento o la rimozione di uno o più criteri di accettazione contraddice, anche in caso di raggiungimento dei vincoli di costi e timeline di progetto, il principio Never Compromise Quality e quindi metterebbe a serio rischio la bontà della soluzione consegnata.

In conclusione, i progetti DSDM garantiscono la delivery di una soluzione adatta all’uso ( ambito e qualità) in linea con i tempi e  i costi  concordati nelle fasi iniziali del ciclo di vita di un progetto.

 

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *