Nello scorso articolo abbiamo parlato del framework AgilePM rispetto ad altre metodologie e di quando è possibile adottarla.

Abbiamo anche detto che AgilePM è un sottoinsieme del framework più comune DSDM: ma cos’è e come funziona?

In questo articolo parliamo di cos’è DSDM, come funziona e quali sono i principi fondamentali su cui si basa.

Cos’è

DSDM sta per Dynamic Systems Development Method ed è chiaramente una metodologia agile distribuita gratuitamente dal consorzio DSDM ai propri membri, fondato nel 1994.

La metodologia DSDM è spesso rappresentata come un piccolo tempio: il valore maggiore da portare al business si ottiene se i progetti sono sempre allineati con gli obiettivi, con rilasci frequenti, con motivazione e con il potere decisionale che permetta di prendere decisioni sia dal punto di vista tecnico che gestionale.

La sua filosofia si basa su quattro pilastri: Process, People, Products e Practices, che sono anche le colonne portanti del tempo; alla base, ci sono il senso comune e il pragmatismo, volti all’utilizzo di una conoscenza generica e non specifica e soprattutto all’essere pratici.

Cos’è DSDM e come rappresentarlo con un tempio

Il processo si riferisce al lifecycle e rappresenta le fasi del metodo -che è comunque rigoroso- in cui ognuna delle sei fasi ha dei nomi ben precisi. Il processo può essere adattato anche in situazioni più complesse, e ci sono fasi che possono ripetersi e che possono semplificarsi.

Non si tratta solo del processo in sé, ma anche di tutto quello che c’è prima e dopo (detto anche pre-project e post-project).

Se dovessimo quindi riferirci a questo principio, utilizzeremmo l’avverbio quando: qual è la fase giusta per questa iterazione?

(quasi) inutile dirlo:persone si riferisce al fatto che all’interno di un progetto agile ci sono diverse persone che appartengono a diversi team e quindi hanno diversi livelli di gestione e di competenze.

La domanda giusta in questo caso risponde all’avverbio chi: chi ha determinate responsabilità?

Parlando di prodotti, questi non sono da intendersi come i deliverable del progetto, ma piuttosto rappresentano i documenti e sono gli strumenti gestionali e quindi prodotti di management.

Se abbiamo quindi bisogno di informazioni e di risultati concreti, e vogliamo rispondere al cosa, facciamo riferimento ai prodotti.

L’ultimo pilastro sono le pratiche nel senso di tecniche che abbiamo a disposizione per gestire il nostro progetto secondo il framework AgilePM, e queste sono in totale cinque.

La domanda da porsi in questo caso usa l’avverbio come: come gestisco questa fase del processo? Quale pratica adottare?

Piccolo spoiler: la prima di queste tecniche è MoSCoW ed è la pratica basata sul concetto di priorità; un’altra è la TimeBoxing, ossia andare a ritagliare il progetti in tanti piccoli intervalli temporali, mai troppo corta o troppo lunga.

Poi c’è Modelling (o modelizzazione) che consiste nell’usare dei modelli per fornire una visualizzazione più chiara del progetto; c’è l’Iterative Development e la cosa interessante è che questa si trovi all’interno di una metodologia come AgilePM anche quando non stiamo realmente sviluppando codice.

Infine c’è la Facilitated Workshop, ossia uno o più incontri per trattare gli aspetti più importanti e più formali del progetto che necessitano della presenza di un mediatore che aiuta a coordinare le attività che che faccia da moderatore.

Variabili di un progetto: come gestirle

Tutta la filosofia che c’è dietro a queste metodologie necessita di una visione comune degli obiettivi, di collaborazione, e soprattutto di accettare che il cambiamento è inevitabile e che tutte le persone coinvoltenel progetto sono necessarie nel processo decisionale.

Rispetto all’approccio tradizionale, dove il cliente parte fin dall’inizio qual è lo scope del progetto e i relativi dettagli, requisiti, deliverable e funzionalità, nell’approccio DSDM si prendono la qualità, il tempo e i costi e si trasformano in costanti.

Come visibile nella figura seguente, nell’approccio DSDM la qualità è il cuore pulsante di un progetto: il tempo e il costo sono ad essa strettamente legati e sono costanti fisse, mentre le funzionalità sono le vere variabili, che evolvono e cambiano con il tempo.

Nell’approccio tradizionale, abbiamo l’inverso: tutto ciò che quindi riguarda le specifiche, le funzionalità e via dicendo sono tutti aspetti che variano e quindi sono quelle che guidano i progetto: le restanti proprietà sono variabili, e dipendono da moltissimi fattori.

Differenze tra approccio tradizionale e DSDM

Ricordiamo un aspetto importantissimo: per la buona riuscita di un progetto è fondamentale che tutti concordino sul metodo utilizzato e che lo conoscano nel dettaglio, ed è fondamentale che i requisiti a livello macroscopico siano definiti.

Ma quali basi utilizza DSDM e quali sono i suoi principi fondamentali?

Principi DSDM

Questo approccio si basa su 8 principi ben distinti e riportati nella figura seguente: il primo gruppo (a sinistra) servono a capire cosa dovrò andare a consegnare, mentre gli altri sulla destra rappresentano il come dovrò andare a consegnare.

Principi DSDM

Questi principi devono essere sempre validi, perché sono raccomandazioni e quindi vanno bene per qualsiasi progetto e qualsiasi circostanza!

Ma partiamo dall’inizio: il primo principio si basa sul fatto che la ownership è sempre del cliente, quindi spetta a lui decidere quali sono o meno le esigenze, ed è l’aspetto su cui dovremo concentrarci maggiornamente.

Il secondo principio dice che bisogna sempre consegnare in tempo e quindi ogni volta che pensiamo ad una scadenza, quella dev’essere rispettata e soprattutto rispettabile; questo vale non solo per la scadenza finale del progetto, ma anche quella dei singoli step del progetto.

Nel terzo principio di parla di collaborazione: questa è fondamentale per la buona riuscita del progetto e riguarda la collaborazione tra tutti gli attori del processo, non solo tra i singoli team.

L’ultimo principio a sinistra, e quindi il quarto, è molto chiaro: qualsiasi sia l’obiettivo del progetto o della singola fase, questa dovrà avere la miglior qualità possibile.

Passiamo ai principi posti sulla destra e partiamo con il quinto: in questo caso si parla di come lavorare per fasi incrementali.

Ogni progetto DSDM possiede delle fasi iniziali che richiedono come primo step una fase di fattibilità del prodotto; dopodiché vengono definite le fasi (o incrementi) del progetto che portano al rilascio finale.

L’avvio del progetto rappresenta la prima foundation e, ogni volta che stiamo per cambiare incremento, si riparte dalla fase di foundation. Questo vuol dire ricontrollare nei documenti iniziali di fattibilità l’andamento del progetto e foundation rappresenta proprio una fase su cui ripasso più volte (questa fase sarà chiarita nei prossimi articoli!).

Nello sviluppo iterativo -sesto principio- si ha un modo di lavorare per cui si cerca di portare avanti un’attività per piccoli cicli, raccogliendo più feedback possibili e facendo i giusti test (anche delle review o dei controlli formali o informali sono certamente utili allo scopo).

Gli ultimi due principi descrivono il tipo di interazione continua che ci dev’essere con il cliente, che consiste in una comunicazione costante e chiara -settimo principio.

Infine, nell’ultimo principio e quindi l’ottavo, invece di seguire un approccio comando-controllo, in cui si gestisce e comanda dall’alto, si cerca di non fare pressione sulle persone coinvolte né di usare delle metriche per misurare le performance delle stesse, favorendo un controllo ove necessario.

Ad esempio, il team che sviluppa si dovrebbe incontrare ogni giorno (attraverso degli stand-up meeting, ad esempio) e raccontare quello che hanno fatto ogni giorno; qui il Project Manager non deve assumere il controllo, ma può piuttosto partecipare solo come osservatore, proprio perché questi incontri sono fatti dal team di sviluppo per il team di sviluppo.

Questo principio serve a ricordare che l’utilità del PM è nel gestire situazioni in cui ci sono problemi o contrasti che devono essere sanati e/o mediati.

Se sei curioso/a di sapere come lavora un Project Manager, leggi qui l’intervista!

I principi appena descritti sono necessari al mindset di tutto il team, e quindi non sono solo per il PM, ma per tutti gli attori del progetto.

Ogni membro del team deve essere incoraggiato a parlare e il PM per questo ha, per esempio, un questionario a disposizione che permette di capire se le persone che fanno parte del team hanno compreso tutto e sanno applicare questi principi.

Chiavi del successo

Nella scorsa puntata abbiamo già accennato al fatto che questo metodo non deve e non può essere adottato in qualsiasi progetto: infatti, un buon PM è tenuto a controllare i rischi di un progetto ed eventualmente cambiare “rotta” o framework qualora ci siano delle incompatibilità con il progetto.

Ma quali sono le chiavi del successo di questo metodo?

Il primo è che se questo approccio, ove adottato, vale per tutti e che viene concordato da tutti, questo garantisce la buona riuscita di un progetto, che ha quindi come base una “lingua” comune su cui sono tutti d’accordo.

Il secondo fattore è stabilire e coinvolgere le giuste persone, scegliendole per motivazione, stabilità e competenze condivise: un team solido è fondamentale per qualsiasi progetto.

Altro fattore è avere un business coinvolto attivamente e durante tutto il processo: il cliente dev’essere partecipe durante l’intero processo e fornire quanti più feedback possibili, affinché il risultato sia quello sperato e desiderato.

In questo senso, lo sviluppo iterativo e un delivery incrementale con testing continuo sono ancor più di sostegno, perché consentono dei piccoli rilasci che mostrano le singole fasi di lavoro e quindi dei prodotti parziali della soluzione finale che possono essere lavorati ed elaborati.

Ultimo, ma non ultimo, la trasparenza: più si riesce ad essere chiari e più la comunicazione è trasparente, anche attraverso l’utilizzo di strumenti di condivisione, più l’intero processo è efficace e trasparente.

Nella prossima puntata, vediamo i ruoli e le responsabilità delle persone all’interno di un progetto DSDM!

Risorse utili

• “DevOps” di Fabio Mora - Apogeo Editore
• Corso di Metodologia AgilePM
• I principi di DSDM e AgilePM