Metodologie Agile Scrum

in Informatica

Metodologie Agile – Scrum

Questo post non vuole essere una guida all’utilizzo delle metodologie Agile e, in particolare, di Scrum. Semplicemente, dovendo impostare alcune demo su Azure DevOps, ho evidenziato alcuni punti fondamentali sulla sua applicazione e sulla terminologia.

Scrum è una metodologia Agile basata sull’ “esperienza”. Per poterlo utilizzare correttamente è necessario garantire la “trasparenza” ai responsabili del progetto, in modo da poter garantire l’ispezione del prodotto che si sta sviluppando. Questo approccio consente di adattare molto velocemente lo sviluppo in caso di nuove esigenze o eventuali mutamenti rispetto all’analisi iniziale.

Sprint

Tutte le metodologie Agile basato il loro funzionamento sulla divisione del progetto finale in fasi, che prendono il nome di sprint. Ad ogni sprint, il team di sviluppo aggiunge nuove funzionalità al progetto finale, interagendo con il cliente. L’iterazione che si viene a generare consente di avanzare molto velocemente e soprattutto frequentemente verso il prodotto finale. La frequenza con cui vengono effettuati revisione/rilascio permette di ottenere un monitoraggio dell’andamento complessivo e la soddisfazione del cliente finale. Gli sprint sono il core di Scrum e hanno durata compresa tra 2 e 4 settimane.

Ruoli

I ruoli coinvolti in Scrum sono tre:

  • Product Owner: è colui che  definisce il lavoro da svolgere e l’ordine con cui viene completato. Si interfaccia con gli stakeholder individuando le necessità del cliente finale e definendo le priorità con cui dovranno essere sviluppate le funzionalità .
  • Scrum Master: può essere considerato come il responsabile del progetto. Applica le regole della metodologia agile e si assicura che l’intero ciclo di sviluppo abbia successo. Organizza meeting, e risolve eventuali impedimenti. Si assicura che ciascun sviluppatore sia impegnato sui propri task al 100%, senza distrazioni.
  • Team di Sviluppo: solitamente il team di sviluppo è composto da un numero variabile di sviluppatori (da 3 a 9), e lo stesso Scrum Master può far parte del team. Si tratta di coloro che portano a buon fine ogni singolo sprint.

Artefatti

Gli artefatti sono tre:

  • Product Backlog: è una lista contenente tutti i requesiti che dovrà avere l’applicazione finale. Viene creato dal Product Owner che è responsabile di ciascun item ( Product Backlog Items) e del loro ordinamento. L’ordinamento stabilisce la priorità con cui verranno implementate le funzionalità. In pratica è un elenco contente: caratteristiche, funzioni, requisiti, miglioramenti e correzioni. Il product Backlog è in continua evoluzione e asseconda i feedback degli utenti finali. Le voci presenti all’interno del Backlog prendono il nome di User Story, la funzionalità descritta dall’utente finale o da cliente. Se la User Story rappresenta funzionalità complesse (suddividibili in ulteriori User Story) prendono il nome di Epic.
  • Sprint Backlog: l’insieme degli elementi del Product Backlog che sono stati selezionati per essere completati in un’iterazione. Può essere considerata come una previsione di quanto verrà prodotto al termine dell’iterazione. Tiene traccia del lavoro che è stato effettuato, di quanto dovrà essere ancora effettuato e delle attività completate. Tipicamente solo il Team di Sviluppo è abilitato all’inserimento di nuovi task.
  • Incremento: è la somma di tutte le funzionalità completate in uno Sprint alle quali devono essere sommate quelle degli sprint precedenti.

Eventi

Gli eventi associati agli sprint sono:

  • Sprint Planning: l’inizio di uno sprint. E’ una riunione in cui viene concordato l’obiettivo dello sprint. Il team di sviluppo seleziona i Product Backlog Items e li associa allo sprint, pianificando come portarli a termine (impostazione dello Sprint Backlog )
  • Daily Scrum: è un evento giornaliero di circa 15 minuti in cui il team di sviluppo viene programmata la giornata di lavoro. In pratica vengono descritte le funzionalità realizzate nella giornata precedente, cosa verrà sviluppato nella giornata corrente e degli eventuali ostacoli che sono stati trovati.
  • Sprint Review: si tratta di una riunione tra il Scrum Team e la il cliente, per analizzare l’avanzamento raggiunto. In questa fase vengono raccolti gli input per le successive riunioni di planning.
  • Sprint Retrospective: è un momento in cui il team di sviluppo analizza lo sprint appena concluso, analizzando ciò che è andato bene e ciò che potrebbe essere effettuato per migliorare lo sviluppo nel prossimo sprint.

Al termine dello Sprint Retrospective si ricomincia con un nuovo sprint, quindi da un nuovo sprint planning.