Cosa sono e imporatanza degli artefatti e strumenti di Scrum

Cosa sono e imporatanza degli artefatti e strumenti di Scrum

Il metodo Scrum

Scrum è un metodo iterativo e incrementale, basato su controllo empirico del processo; è incrementale perchè il prodotto finale è il risultato di continui rilasci, ciascuno dei quali aggiunge valore a quello precedente; è iterativo perchè ogni nuovo rilascio viene adattato in base alle contingenze del momento. I suoi fondamenti sono: un processo di sviluppo con fasi ben caratterizzate, una definizione precisa dei ruoli e una serie di rituali.

Il processo Scrum

Il processo Scrum è caratterizzato da una fase iniziale di raccolta delle feature per il progetto richieste dal cliente che vengono riportate con delle User Stories: una User Story è una breve descrizione di come l’utente intende usare la feature richiesta. La scelta di quali User Stories accettare viene svolta esclusivamente dal Product Owner, che le inserisce nel Product Backlog. All’interno del Product Backlog le User Stories possono essere ulteriormente spezzetate dal team di sviluppo per creare dei requisiti più piccoli, la ratio è quella di rendere lo sforzo richiesto dall’implementazione di ogni requisito adattabile ai tempi delle iterazioni.

Successivamente il Product Owner sceglie tra i requisiti individuati nel Product Backlog quelli che si vogliono sviluppare nella successiva iterazione della fase di sviluppo, nel gergo Scrum i requisiti relativi a una singola iterazione vengono chiamati Sprint Backlog. Ogni iterazione è definita da uno Sprint: un periodo di tempo, solitamente compreso tra due e quattro settimane, durante il quale si sviluppano i requisiti che sono stati inseriti nello Sprint Backlog; ogni Sprint comprende l’implementazione di nuove feature e
i relativi test. Lo Sprint è la fase più delicata per lo sviluppo, quindi non sono ammesse modifiche allo Sprint Backlog e al Team Scrum fino al termine dello stesso.

Al termine dello Sprint segue una fase di revisione, detta Sprint Review, in cui si analizzano i risultati ottenuti e cosa è andato storto durante la fase di sviluppo. L’obiettivo è quello di migliorare il processo di sviluppo per le iterazioni future e accertarsi di aver soddisfatto le aspettative del cliente. Inoltre, comprendere quanto valore è stato aggiunto al prodotto ad ogni iterazione rende i membri dello Scrum Team più motivati e interessati al progetto. In questa fase il team verifica la qualità della release attraverso i test, in questo modo si accerta la continuità nel funzionamento generale del software e la correttezza di quanto prodotto durante lo Sprint.

Una volta completata la fase di Sprint Review si ritorna al Product Backlog e si scelgono i requisiti da implementare nello Sprint successivo. Potrebbe sembrare che in Scrum ci sia poca pianificazione, invece questa è solo un’impressione dovuta al fatto che la pianificazione non viene svolta in modo completo prima di cominciare a implementare i requisiti, ma viene diluita nello Sprint: un tipico Team Scrum spende 8 ore per pianificare l’iterazione, poi adatta la pianificazione durante i Daily Meetings (15 minuti per 30 giorni); se si considera un team di 5 persone, si scopre che la pianificazione comporta uno sforzo di 40 persone/ora per iterazione e altre 40 persone/ore di pianificazione spalmata sui successivi 30 giorni, in conclusione la quantità di tempo dedicata alla pianificazione risulta essere ben maggiore rispetto ad altri metodi, sempre considerando 30 giorni di sviluppo.

Metodologia Scrum - Come gestire i progetti con Scrum

Strumenti per implementare Scrum

Gli artefatti prodotti dalle varie fasi di sviluppo sono:

  1. Product Backlog
  2. Sprint Backlog
  3. Sprint Burndown Chart
  4. Scrum Task Board

Il Product Backlog è costituito dall’insieme di tutte le User Stories che riguardano il prodotto in sviluppo; quali requisiti possano entrare a far parte del backlog e con quale priorità è una scelta che viene effettuata esclusivamente dal Product Owner poichè è il membro dello Scrum Team più vicino al cliente e alle sue esigenze.

Lo Sprint Backlog è formato da alcune User Stories selezionate dal Product Backlog, all’inizio di ogni Sprint il Product Owner decide quali requisiti hanno priorità maggiore e devono essere, quindi, terminati entro lo Sprint; nonostante l’ultima parola spetti al Product Owner, egli fa le sue valutazioni anche sulla base di quale sia il carico di lavoro che il Development Team e lo Scrum Master ritengono adeguato per lo Sprint. In questo senso il Development Team è auto-organizzato: capisce quale sforzo è in grado di sostenere per la durata dello Sprint e come suddividere i compiti in fase di sviluppo, senza influenze esterne.

Lo Sprint Burndown Chart e lo Scrum Task Board sono degli strumenti fondamentali per il Development Team poichè facilitano la comunicazione tra gli sviluppatori: la Scrum Task Board risulta utile per capire quale membro del team stia lavorando a una feature e a quale fase dello sviluppo sia giunto, invece lo Sprint Burndown Chart illustra qual’è lo stato di avanzamento dello Sprint e può essere utile per capire quali task sono rimasti bloccati e hanno bisogno di uno sforzo maggiore per essere terminati rispetto alle promesse iniziali. Entrambi questi due strumenti uniti ai Daily Meeting completano la comunicazione tra i membri del team perchè questi elementi permettono una comunicazione visiva, mentre il Daily Meeting aggiunge la comunicazione verbale.

Lo Sprint Burndown Chart è un grafico che illustra l’andamento dello Sprint: sull’asse delle ascisse vengono indicati i giorni dedicati allo Sprint, sull’asse delle ordinate viene misurato il numero di requisiti che non sono ancora stati completati; la retta che viene disegnata su questo grafico parte dal numero di requisiti dello Sprint sull’asse delle ordinate per procedere in diagonale verso il basso. Risulta quindi evidente per chiunque, con un semplice colpo d’occhio capire, se lo sviluppo prosegue come nelle previsioni o se gli sviluppatori sono bloccati (in questo caso troveremo una linea costante, in alcuni casi addirittura crescente).

Lo Sprint Burndown Chart può essere costruita automaticamente tramite l’uso di software, ma molti team preferiscono mantenerla in versione fisica vicino alla Task Board per lasciare agli sviluppatori maggiore soddisfazione nel vedere che il risultato del loro lavoro aiuta il team a raggiungere l’obiettivo; inoltre un elemento fisico presente nella stessa stanza dove lavora il Development Team permette a tutti di mantenere sempre sotto controllo l’avanzamento dello sviluppo.

La Scrum Task Board è una lavagna divisa in colonne: To-Do, In-Progress, Done. Inizialmente vengono poste nella colonna To-Do tutte le User Stories che dovranno essere implementate durante lo Sprint, vicino a ogni User Story vengono collocati tutti i requisiti, sempre tra quelli scelti per lo Sprint, che la riguardano. Ogni sviluppatore decide durante il Daily Scrum quali requisiti sviluppare nel corso della giornata, quindi appena comincia a lavorare su un requisito lo sposta dalla colonna To-Do a In-Progress e scrive il suo nome sul task scelto, infine, quando ha terminato l’implementazione lo sposta in Done. Solitamente uno sviluppatore lavora su un solo requisito alla volta per mantenere la sua concentrazione sul task più alta possibile.

A volte capita che gli sviluppatori individuino dei requisiti aggiuntivi che sono necessari per completare una User Story, ma che non erano stati considerati inizialmente; in questi casi è sufficiente che lo sviluppatore informi i suoi colleghi al Daily Meeting in modo che anche gli altri possano valutare l’inserimento del nuovo task e capire se entra in conflitto con quanto è stato fatto o si era programmato di fare. Al termine dello Sprint, tutti i requisiti che si trovano nella colonna Done possono essere eliminati, se una User Story è stata completata, poichè non ha più task aperti, può essere eliminata; invece, tutte le User Stories e i requisiti che si trovano in To-Do e In-Progress vengono reinseriti nel Product Backlog per continuare il loro sviluppo in un nuovo Sprint.

Cosa sono e imporatanza degli artefatti e strumenti di Scrum

Oltre agli strumenti che abbiamo già analizzato ne esistono altri che non farebbero parte del metodo Scrum per come era stato pensato inizialmente, ma che con il tempo sono entrati a far parte della collezione degli strumenti di Scrum: sono i cosiddetti Generally Accepted Scrum Practices (GASPs). Questi strumenti possono comprendere piccole variazioni a come era stato pensato Scrum, per esempio il Daily Scrum viene svolto in piedi da alcuni team e viene chiamato Stand-up Meeting, oppure possono consistere nell’inserimento di metodi aggiuntivi, un esempio per tutti è un metodo per la stima dello sforzo di un requisito noto con il nome di Planning Poker. Quest’ultimo consiste nello stabilire una stima dello sforzo per un requisito tramite un metodo di votazione tra gli sviluppatori: ogni votante ha un mazzo di carte, ognuna con un valore diverso (i valori sono arbitrari, il loro significato è quello di indicare dei livelli di complessità), e sceglie una carta per il requisito in esame; capita spesso che i valori scelti dagli sviluppatori siano molto discordanti tra loro poichè ognuno di essi fa valutazioni con criteri propri, un confronto tra i votanti è utile per chiarire la corretta comprensione del requisito e quindi stabilire una valutazione soddisfacente per tutti gli sviluppatori.

“A intervalli regolari, il team riflette su come diventare più efficiente, poi modifica e aggiusta il suo metodo operativo di conseguenza”.

Adattare le procedure e gli strumenti di un metodo agile alle esigenze del proprio team è una pratica che viene incoraggiata nel mondo Agile; infatti, quando al termine dello Sprint si fa una retrospettiva di cosa ha funzionato e di cosa è andato storto è utile pensare a come rendere il team più produttivo, per raggiungere questo fine la metodologia agile non fornisce linee guida e lascia, quindi, spazio alla fantasia e alla capacità dei membri del team nel trovare una soluzione efficace.

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 *