DSDM Atern 101

Tempo di lettura: 10 minuti

Il framework Dynamic System Development Method (o DSDM) è una metodologia Agile che ben si integra con altre. Anche in questo caso il contesto nel quale nasce e si sviluppa è quello IT.

Progetti svolti con questo approccio hanno una durata dai tre ai sei mesi e pongono grande attenzione sulla qualità della soluzione proposta e sulle persone, poiché si ritiene che esse, più che la tecnologia che deve essere sviluppata, possano essere la principale causa di fallimento di un progetto. In particolare, i problemi legati alle persone possono essere i seguenti: comunicazione non efficace, ritardo nelle consegne, divergenza tra soluzione consegnata e aspettative del business che l’ha commissionata, implementazione di funzionalità che poi non vengono utilizzate, rischio di Scope creep (ambito poco definito e implementazione di funzionalità non collegate a reali esigenze del cliente), cambiamento continuo dei requisiti e sviluppo di ciò che è più giusto, superamento del budget, assenza del giusto numero di processi formali, stime errate e non raffinate con il tempo, insufficienza dei test sul prodotto, mancanza di controllo, progetti che non vengono chiusi anche quando sono solo un esborso continuo di denaro, riduzione del ROI, insufficienza di risorse, ruoli e responsabilità poco chiari, eccessivo sviluppo di funzionalità non richieste, conflitto tra priorità e riluttanza nel firmare accordi tra le parti.

L’obiettivo di questo framework è quindi quello di aiutare le persone a lavorare meglio insieme in modo da sviluppare nuove soluzioni e migliorare quelle già esistenti. L’idea alla base di tutto è che bisogna rilasciare subito anche soluzioni non perfette perché l’80% del prodotto può essere sviluppato nel 20% del tempo; il resto sarà tempo passato a sistemare eventuali problemi e difettosità.

I princìpi di DSDM

Anche in questo caso si possono individuare una serie di princìpi ispiratori, elencati di seguito:

  • focus on the business need: necessità di comprendere le richieste del business e decidere il minimo di funzionalità realmente da implementare;

  • deliver on time: consegnare un prodotto utilizzabile in tempo utile permette di sfruttare al meglio le opportunità offerte dal mercato e rispettare tempistiche contrattuali particolarmente stringenti;

  • collaborate: collaborazione intesa come confronto aperto e coraggio nell’esprimere le proprie idee e nel raggiungere il successo;

  • never compromise quality: la qualità dell’elaborato è quanto di più importante si vuole fornire al cliente;

  • build incrementally from firm foundations: approccio incrementale, tipico di tutte le metodologie Agile, nella realizzazione del prodotto finale;

  • develop iteratively: sviluppare il prodotto (ed il progetto in generale) in maniera iterativa definendo correttamente le modalità di coinvolgimento del cliente;

  • communicate continously and clearly: la comunicazione con il cliente e tra membri del team deve essere la più chiara possibile. A questo scopo possono essere utilizzati tutti gli strumenti a disposizione come modelli, riunioni, workshop, prototipi, modalità comunicative faccia-a-faccia, ecc…;

  • demonstrate control: controllare tutto il progetto in maniera proattiva e non farsi sovrastare dal mutare delle situazioni.

I processi di DSDM

Il ciclo di vita di un progetto portato avanti con metodologia DSDM Atern, come detto, è breve ed ha un approccio iterativo. In particolare, possiamo evidenziare cinque fasi (oltre a quella di avvio del progetto) che troviamo rappresentate nella figura seguente.

Processo DSDM su Agile Business

La prima fase è quella di pre-progetto, una fase che ha l’obiettivo di descrivere in maniera chiara il problema, identificare stakeholders e sponsor e garantire l’avviamento di un progetto in linea con le caratteristiche del business dell’azienda. Tutto deve essere fatto in un tempo molto breve.

Le due fasi successive, che vengono svolte in sequenza, sono quelle di feasability e foundation. La prima mira a fornire le migliori pratiche di gestione dei progetti in grado di fornire previsioni accurate in merito alla redditività del progetto e alla sua effettiva fattibilità. Questa è evidentemente un’indagine di alto livello che si andrà via via ad affinare durante tutto il ciclo di vita del progetto stesso. La seconda delle due fasi appena indicate mira a gestire la fase iniziale del progetto gettando fondamenta solide ma flessibili per sviluppare la soluzione desiderata. In particolare, si recepiscono maggiori informazioni in modo da dettagliare tutto al meglio sia in termini di business case che di architettura che si vuole ottenere e qualità da raggiungere.

La quarta fase è quella di exploration e mira a definire una prima soluzione seguendo i principi elencati in precedenza. In questo modo si dimostra l’effettiva possibilità di realizzare il progetto e si iniziano a definire correttamente le priorità tra i vari requisiti indicati dal cliente.

Le ultime due fasi sono quella di engineering, durante la quale la soluzione viene effettivamente sviluppata con opportuni aggiustamenti, e quella di deployment che punta ad accompagnare la soluzione verso la fase di effettiva produzione. I risultati di questa ultima fase possono portare a differenti sviluppi:

  • i requisiti richiesti dal cliente sono stati completamente soddisfatti, il progetto è concluso e si può passare alla fase di post-progetto che servirà per assicurare l’effettivo funzionamento di quanto realizzato. Questa fase conclusiva può durare dai tre ai sei mesi;

  • se si è individuata una soluzione migliore, si torna alla fase di foundation;

  • se si sono individuate nuove funzionalità da implementare, si torna alla fase di exploration;

  • se vi è necessità di sviluppare il nuovo incremento che si è fornito, si torna alla fase di engineering.

Attori di DSDM

A differenza di quando accade per altri framework, quello DSDM Atern definisce dei ruoli e delle figure chiave che devono guidare e interessarsi al progetto. Per una migliore comprensione e distinzione, si è deciso di riportarli suddivisi per area di interesse.

Le figure legate direttamente al business sono: Business sponsor e Project champion (responsabili nella stesura del business case e nella formalizzazione dei benefici richiesti e sperati), Business visionary (acquisisce e gestisce richieste provenienti dalla persone interessate al progetto), Business ambassador (collaboratore diretto del team di sviluppo con l’obiettivo di definire correttamente uno scenario di business), Business advisor (utilizzatore finale del prodotto o servizio realizzato) e il Business analyst (figura con l’obiettivo di assicurare la corretta analisi delle necessità del business).

Gli attori che sono interessati agli aspetti del project management sono: Project manager (responsabile della gestione e dello sviluppo della soluzione), Workshop facilitator (gestisce le riunioni, cuore di questo framework) e l’Atern coach (ha il compito di far meglio comprendere la metodologia e dimostrare come vi siano calate all’interno le differenti fasi progettuali).

Infine, le figure tecniche, responsabili dell’effettiva implementazione della soluzione, sono: Technical co-ordinator (gestisce ogni aspetto della soluzione tecnica), Team leader (responsabile del lavoro di un singolo team, dialogo direttamente con il Project manager), Solution developer (traduce le richieste del business in requisiti funzionali e non), Solution tester (esegue i test sul prodotto), Scribe (presenzia alle riunioni scrivendo i punti più importanti di ognuna di esse) e Specialist roles (tutte le figure specializzate che possono servire a realizzare adeguatamente il prodotto).

Pratiche di DSDM

Il framework DSDM Atern individua cinque pratiche che permettono di calare meglio nella realtà tutto quanto indicato nella teoria vista precedentemente.

La prima pratica prende il nome di Facilitated workshop. Far interagire le persone al meglio è uno degli obiettivi di DSDM Atern, per tanto si realizzano incontri finalizzati alla realizzazione di un prodotto. I partecipanti saranno guidati da un facilitatore che ha l’obiettivo di rendere più efficaci le sessioni. Esse, infatti, possono essere un modo molto utile per ridurre le tempistiche nella ricerca di una soluzione, considerando il fatto che tutti gli stakeholders vengono coinvolti direttamente durante questi incontri. Il facilitatore deve essere una figura in grado di saper ascoltare, osservare, sintetizzare, comunicare in maniera chiara, identificare gli assunti e i diversi punti di vista di ognuno e deve essere in grado di costruire fiducia tra le persone facenti parte del gruppo che prende parte ai workshop.

La seconda patica aiuta nel fornire una corretta priorità a richieste e funzionalità da sviluppare ed il suo nome è MoSCoW prioritisation. Questo è l’acronimo di Must have (requisiti fondamentali da sviluppare), Should have (requisiti importanti ma non fondamentali), Could have (desiderati ma non importanti) e Won’t have this time (requisiti sui quali non si è trovato un completo accordo e che quindi non verranno sviluppati nell’immediato futuro). Fornire una corretta priorità è fondamentale perché permette di capire come si riesca ad ottenere l’80% dei benefici sperati solo sviluppando gli elementi presenti nei primi due gruppi.

Altre pratiche derivano direttamente dai principi classici delle metodologie Agile e sono:

  • iterative development: la soluzione deve evolvere partendo da un’idea di alto livello per poi scendere sempre più nello specifico e nella definizione di livelli di dettaglio sempre inferiori;

  • timeboxing: le iterazioni devono avere una durata finita che permetta di raggiungere meglio gli obiettivi, fornire la giusta priorità alle cose, mantenere alta la concentrazione sugli obiettivi, gestire le dipendenze del progetto e prevenire il rischio di scope creep;

  • modelling: uno degli obiettivi primari è che la comunicazione tra le parti sia efficace e per far sì che ciò si realizzi è bene utilizzare qualunque strumento messo a disposizione, soprattutto l’uso di modelli e/o prototipi che possono sia avere finalità puramente illustrative che essere realizzati per soddisfare una qualche necessità progettuale.


Alcuni link utili per approfondire:

Avanti
Avanti

Lean Software Development 101