Skip to main content

Che cos'è DSDM?

Dynamic Systems Development Method (DSDM) è un framework agile per la gestione dei progetti nato per la prima volta nel 1994 e, in quel periodo, veniva utilizzato per lo sviluppo software. Era destinato a rappresentare un miglioramento rispetto al Rapid Application Development (RAD), che dava priorità alla prototipazione rapida e all'iterazione basata sul feedback degli utenti. Come molti metodi di consegna agilista, il DSDM Agile Project Framework si è evoluto da una soluzione specifica per il software a uno strumento più generale di gestione dei progetti.

Gli elementi del Dynamic Systems Development Method includono:

  • Si differenzia da altri metodi per la dipendenza da solide fondamenta e governance
  • Approccio incrementale e iterativo al progresso 
  • Il feedback dell'utente o del cliente è fondamentale per i miglioramenti continui 
  • Si basa su vincoli rigorosi di costi, qualità e tempi 
  • Dà priorità allo scope secondo le categorie Must Have, Should Have, Could Have o Won't Have

Oltre alla pratica stessa, DSDM ha portato anche alla creazione del DSDM Consortium nel 1994. Ingegneri software ed altri esperti si sono uniti per sviluppare e perfezionare il framework come valida alternativa alle più comuni metodologie di Rapid Application. All'epoca, il gruppo includeva rappresentanti di organizzazioni come British Airways, American Express, Oracle, Logica, Data Sciences e Allied Domecq. Il gruppo è ora stato rinominato e prende il nome di Agile Business Consortium.

Want more from The CTO Club?

Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.

This field is for validation purposes and should be left unchanged.
Name*

Il Manuale DSDM è stato reso consultabile e utilizzabile gratuitamente online nel 2014.

Upgrade your inbox with more tech leadership wisdom for delivering better software and systems.

Upgrade your inbox with more tech leadership wisdom for delivering better software and systems.

This field is for validation purposes and should be left unchanged.
Name*

DSDM vs RAD vs Agile

La metodologia RAD era estremamente popolare all'inizio degli anni '90 come metodologia di sviluppo sistemi per il software e altri progetti informatici. In questo periodo si passò dall’esperienza utente "green screen" tradizionale alle interfacce grafiche utente che oggi sono sinonimo di tecnologia. Questo cambiamento ha permesso anche una modifica nei cicli di sviluppo, impiegando queste nuove UI visive per la comunicazione, la prototipazione rapida e l’iterazione. 

La metodologia RAD si caratterizzava come uno sviluppo di sistemi agile ma caotico. Non possedeva un approccio o una definizione universalmente accettata. Agile DSDM rappresentava un approccio più strutturato a questo tipo di modello di sviluppo software. Il Dynamic Systems Development Method era estremamente focalizzato su budget di tempi e costi attraverso una rigorosa prioritizzazione dello scope. Dava inoltre priorità alla comunicazione (e alle conseguenti azioni) tra tutte le parti interessate. 

Oltre a essere rigido per quanto riguarda scadenze e budget, DSDM tende anche ad avere un ordine fermo delle fasi: fase Pre-progetto, fase di ciclo di vita del progetto e fase Post-progetto. I metodi di sviluppo software RAD sono invece più orientati al lavoro libero, lasciando creatività e indipendenza anche a scapito delle risorse. 

Scrum vs DSDM

Scrum e DSDM condividono molte somiglianze ma presentano anche alcune differenze importanti. Alcune sono solo terminologiche, ad esempio DSDM suddivide il lavoro in "engineering activity" (ovvero la fase di sviluppo) e "emerging solution" (cioè il risultato). Invece con Scrum, il risultato viene chiamato "incremento potenzialmente rilasciabile". 

Entrambi i metodi prevedono elenchi di sottoattività che vengono completate rispettando scadenze strette. Entrambe le metodologie portano alla realizzazione di un progetto completato, che in Scrum viene segnalato quando il progetto raggiunge la “Definition of Done”. Tuttavia, non esiste un momento specifico all'interno del progetto in cui tale "Definition of Done" venga concordata. Questa è una differenza chiave tra Scrum e DSDM. 

In DSDM esiste una fase ben precisa in cui viene concordata la definizione del lavoro (e del lavoro finito): la Foundation Phase del progetto. Questo avviene abbastanza presto, il che a volte può significare che assunzioni ancora infondate colorino il processo di pianificazione. Per ovviare a ciò, la definizione di lavoro "finito" deve essere rivista periodicamente durante tutto il ciclo di vita del progetto. Un altro punto da rimarcare è che i team leader devono evitare il Big Design Up-Front (BDUF), pratica tipica delle metodologie a cascata e non di quelle agili. 

I Principi DSDM

I principi agili DSDM sono la forza guida dietro ogni progetto. In totale sono 8.

  1. Focus sulla necessità aziendale
  2. Consegna puntuale
  3. Collaborazione
  4. Non compromettere mai la qualità
  5. Costruire in modo incrementale da solide fondamenta
  6. Sviluppare in modo iterativo
  7. Comunicare in modo continuo e chiaro
  8. Dimostrare controllo

Tecniche e Pratiche DSDM

Ciò che distingue DSDM dagli altri metodi di sviluppo dei sistemi sono le seguenti tecniche e pratiche. 

Timeboxing: DSDM segue standard di scadenza rigorosi. Per riuscirci, bisogna suddividere l’intero progetto in elementi più piccoli, ciascuno con un budget e una tempistica ben definiti. Per gestire questo processo, i requisiti vengono prioritizzati. Se il tempo o il denaro stanno terminando, i requisiti a priorità più bassa vengono eliminati. Un progetto completato nasce quindi solo dagli elementi più essenziali. 

MoSCoW: Questo è il sistema di prioritizzazione utilizzato per classificare gli elementi dal livello più alto di importanza fino al più basso. I gruppi di prioritizzazione sono Must Have (deve avere), Should Have (dovrebbe avere), Could Have (potrebbe avere) e Won’t Have (non avrà). La gestione della configurazione aiuta a gestire tutte queste consegne concorrenti, spesso sviluppate contemporaneamente.

Modellazione e Sviluppo Iterativo: La modellazione aiuta a visualizzare i diversi aspetti del progetto lungo il percorso. Questo aiuta a presentare ogni elemento in fase di sviluppo e consente uno sviluppo iterativo grazie al feedback regolare e all’implementazione dei miglioramenti. 

Prototipazione: Come molte metodologie agili, la prototipazione è essenziale per testare il progetto in una fase iniziale e concettuale. È un modo per mappare le funzioni di base, scoprire debolezze evidenti e consentire agli utenti di testare il software. 

Workshop: Utenti e stakeholder vengono riuniti per discutere requisiti, problemi, risultati e test. DSDM si basa su alti livelli di interazione con l’utente, fin dal primo momento. Il testing è fondamentale per DSDM, poiché garantisce risultati di alta qualità. 

Ruoli DSDM

Qualsiasi sviluppo di sistemi agile prevede una serie di ruoli che devono essere coperti. DSDM non fa eccezione. Secondo il loro manuale, questi sono i ruoli essenziali in qualsiasi ambiente DSDM. 

1. Executive Sponsor (il “Project Champion”) - L’organizzazione utente e/o il cliente fornirà qualcuno per questo ruolo. È anche la persona che può assegnare fondi e risorse, se necessario. È il "giudice finale" nelle decisioni importanti.

2. Visionary - Con obiettivi concreti e una comprensione del business degli utenti, il Visionary avvia il progetto individuando da subito i requisiti a più alta priorità e guidando il team sulla base di questi. 

3. Ambassador User - Un “test user” ideale che porta la prospettiva della comunità utenti nel progetto. Diventa una fonte chiave di feedback durante l’intero processo. 

4. Advisor User - Un altro tipo di utente che dovrebbe portare punti di vista fondamentali al progetto in corso. Potrebbe possedere intuizioni uniche o una competenza che lo rende il candidato ideale. 

5. Project Manager - Un project manager è colui che gestisce l’intero progetto. 

6. Technical Co-ordinator - Progetta l’architettura del sistema ed è responsabile del controllo qualità di tutti gli elementi tecnici. 

7. Team Leader - È il capo del team, responsabile della coordinazione e della facilitazione della collaborazione. 

8. Solution Developer - Gestisce ogni requisito di sistema, modella il sistema, sviluppa i codici di consegna e crea prototipi.

9. Solution Tester - Testa il prodotto e fornisce commenti e documentazione in caso di errori. Si occupa anche di ripetere i test dopo l’implementazione delle correzioni. 

10. Scribe - Registra i requisiti, gli accordi, le decisioni e qualsiasi altra informazione utile al progresso del progetto. 

11. Facilitator - Si occupa di motivare e preparare il workshop per garantire un progresso costante e regolare. Deve essere un eccellente comunicatore, mantenendo tutti sulla giusta direzione. 

12. Ruoli specialistici - Questi sono ruoli ricoperti da specialisti del loro settore o industria, che forniscono supporto aggiuntivo in base alle esigenze del progetto. Possono cambiare da progetto a progetto e da team a team. Ruoli come questi possono includere Business Architect, Quality Manager, System Integrator e altri. 

Consigli per la gestione di progetti DSDM

Questi consigli possono aiutare a ottenere il massimo dal proprio progetto DSDM, anche se tutti i sistemi Agile possono trarre vantaggio dall’uso di parte di queste conoscenze. 

1. Il top management e tutti i dipendenti devono comprendere e condividere la metodologia scelta per un progetto. 

2. Il team che guida il progetto deve impegnarsi nel testing con gli utenti, raccogliere feedback e coinvolgere gli utenti durante tutto il processo, dalla concezione al lancio.

3. Deve esserci un team core del progetto stabile e responsabilizzato. I membri del team devono avere potere decisionale per fare in modo che il processo non rimanga impantanato in procedure di proposta e approvazione inutilmente complesse. Il team deve inoltre avere tutto ciò che serve per funzionare al meglio, come la giusta tecnologia, un ambiente di sviluppo sano, strumenti di project management e altro ancora. 

4. Deve esserci una relazione di supporto e proattiva tra il cliente e il fornitore, sia che il progetto venga sviluppato internamente sia che venga affidato a terzi. 

5. Il team deve dimostrare coraggio nel dare priorità alle esigenze del progetto e nel eliminare senza esitazione gli elementi a bassa priorità quando necessario. Solo così si rispettano tempi e budget.