Che cos’è e importanza della Definition of Done in Scrum

Che cos’è e importanza della Definition of Done in Scrum

Il Framework Scrum

Scrum è un framework pensato per creare prodotti. Scrum ha inizio nel momento in cui ci sono soggetti chimati stakeholder di progetto che hanno necessità di un prodotto.

Scrum è un processo basato sul team. Un Team Scrum prevede tre ruoli, il Product Owner, lo Scrum Master, e i membri del Team di Sviluppo. Il Product Owner ha la responsabilità di decidere quale lavoro dovrà essere eseguito. Lo Scrum Master agisce come un servant leader, aiutando il team e l’azienda ad utilizzare Scrum al meglio. Il Team di Sviluppo costruisce il prodotto in maniera incrementale, in una serie di brevi intervalli di tempo chiamati Sprint. Uno Sprint è un intervallo di tempo predefinito, da una a quattro settimane, con una preferenza per gli intervalli più brevi. In ogni Sprint il Team di Sviluppo costruisce e rilascia un incremento del prodotto. Ogni incremento è un sottoinsieme funzionante del prodotto che sia riconoscibile dall’utente e che costituisca un chiaro miglioramento. Inoltre ogni incremento deve soddisfare criteri di accettazione concordati e garantire un livello di qualità condiviso chiamato Definition of Done (Definizione di Completato).

Scrum definisce tre artefatti essenziali, il Product Backlog, lo Sprint Backlog, e l’Incremento di Prodotto. Il Product Backlog è una lista ordinata di idee per il prodotto, mantenuta nell’ordine in cui ci aspettiamo di svilupparle. Lo Sprint Backlog è il piano dettagliato di sviluppo per ogni Sprint. L’Incremento di Prodotto è il risultato atteso al termine di ogni Sprint. È una versione integrata del prodotto, mantenuta ad un livello qualitativo tale da poter essere rilasciata qualora il Product Owner decida di farlo. In aggiunta a questi artefatti, Scrum richiede trasparenza sia all’interno del team che nei confronti degli stakeholder. Per questo motivo, il Team Scrum visualizza in maniera chiara e fruibile sia i piani che l’avanzamento dei lavori.

Scrum definisce, infine, anche cinque Attività o meeting. Questi sono il Product Backlog Refinement, lo Sprint Planning, il Daily Scrum, la Sprint Review, e la Sprint Retrospective (Retrospettiva).

Che cos'è il Product Backlog in Scrum

Definition of Done

Quando l’incremento di Prodotto viene rilasciato, è necessario che venga “completato” in base a una definizione condivisa di cosa significhi “completato” (Definition of Done, DoD in italiano la definizione di finito). La definizione è diversa per ciascun Team Scrum, e man mano che il team matura, la Definition of Done evolve, espandendosi e diventando più severa (o stringente).

La Definition of Done deve sempre includere il fatto che l’Incremento di Prodotto ha una qualità sufficiente per essere rilasciato: il Product Owner potrebbe decidere di rilasciarlo immediatamente. L’Incremento di Prodotto include le funzionalità degli Incrementi di Prodotto precedenti ed è completamente testato, garantendo che tutti gli elementi di Product Backlog completati in precedenza continuino a funzionare regolarmente.

Chi scrive la Definition of Done

In agile, se da un lato la Definition of Done è strettamente correlata alle attività del team, dall’altro ha molto a che fare con i processi organizzativi dell’azienda. Per questo motivo, se a livello di organizzazione esiste una lista di criteri, linee guida o standard minimi che definiscono che cosa è richiesto per il completamento di un incremento, il team dovrebbe come minimo adottare questa lista ed eventualmente estenderla per adattarla alle proprie esigenze.

In assenza di standard a livello di organizzazione o azienda, il team di sviluppo ha il compito di definire una DoD che sia adeguata per il prodotto.

Esempio pratico di DoD

Un esempio di DoD è il seguente:

  1. Scrivere Unit Test
  2. Code review
  3. Codice presente su VCS
  4. Eseguire il deploy sull’ambiente di stage
  5. Eseguire test di accettazione

Infine, non esiste una Definition of Done che si adatti a qualsiasi gruppo o ambiente di lavoro; essa può variare notevolmente a seconda del team, anche nell’ambito della stessa organizzazione. Inoltre, è possibile che non tutte le attività elencate nella DoD siano applicabili a tutte le user story. In tal caso, come suggerisce il buon senso, si include soltanto ciò che è applicabile.

Pubblicato da Vito Lavecchia

Lavecchia Vito Ingegnere Informatico (Politecnico di Bari) Email: [email protected] Sito Web: https://vitolavecchia.altervista.org

Lascia un commento

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