Caratteristiche, funzionamento e processi di Scrum

Caratteristiche, funzionamento e processi di Scrum

Le principali caratteristiche di Scrum

Le metodologie Agile si basano su processi di tipo iterativo e incrementale, ovvero il lavoro viene svolto secondo delle iterazioni di durata predefinita, chiamate Sprint, al termine delle quali sono rilasciati Incrementi del software. Il software viene sviluppato un pezzo alla volta, procedendo per iterazioni, incrementi, modifiche ed espansioni.

All’inizio del progetto, il team esegue una pianificazione semplificata, definisce dei requisiti e progetta soluzioni per avviare il progetto. Successivamente, il team è coinvolto in iterazioni sequenziali che richiedono una pianificazione più dettagliata, l’analisi dei requisiti, la progettazione, l’esecuzione, i test e, infine, la consegna ai clienti e agli stakeholder.

Caratteristiche, funzionamento e processi di Scrum

Team interfunzionali e auto-organizzati

Secondo quanto descritto nello Scrum Body of Knowledge, Scrum vede uno dei suoi punti di forza nell’utilizzo di team interfunzionali, auto-organizzati e investiti di potere.

Il team di lavoro deve essere:

  • cross-funzionale, ovvero deve essere costituito in maniera tale che le competenze siano eterogenee, affinché siano presenti tutte le persone necessarie per svolgere tutte le attività del progetto. La dimensione del team può variare da cinque a dieci persone;
  • Auto-organizzato. Scrum crede che i lavoratori debbano essere auto-motivati e debbano cercare di accettare responsabilità più grandi, realizzando un valore molto maggiore. L’auto-organizzazione porta a una maggiore adesione e a una responsabilità condivisa da parte del team e ne fa aumentare le motivazioni a cui consegue un miglioramento del livello delle prestazioni;
  • Collaborativo, ovvero deve lavorare insieme per trarre vantaggio dai reciproci contributi allo scopo di produrre qualcosa di più grande;
  • Preferibilmente co-ubicato, ovvero i membri dovrebbero essere collocati tutti nello stesso ufficio o addirittura allo stesso tavolo di valoro, per facilitare la comunicazione faccia a faccia e sfruttare così i vantaggi di un migliore coordinamento per risolvere i problemi e condividere la conoscenza.

Attenzione alla soddisfazione del cliente

Uno dei principi fondamentali di Scrum è l’attenzione nei confronti della soddisfazione dei bisogni del cliente (customer satisfaction). Ciò avviene rilasciando in modo rapido e frequente piccole e funzionanti porzioni di software, ma soprattutto tramite il ruolo del Product Owner che deve capire le esigenze e le priorità sia del team sia degli stakeholder e per questo è solitamente chiamato la Voce del Cliente (Voice of the Customer).

Accoglienza del cambiamento

Essendo che il software viene sviluppato in piccoli blocchi (batch), i cambiamenti possono essere introdotti in maniera semplice durante lo sviluppo. Lavorare a stretto contatto con gli stakeholder di progetto e mostrare loro gli incrementi prodotti alla fine di ogni sprint rende efficace gestire i cambiamenti che potrebbero essere richiesti. Inoltre, la cooperazione continua tra le persone legate al business e i membri del team fa sì che i requisiti continuino ad arrivare ad intervalli regolari e il team spesso si deve adattare al cambiamento delle circostanze.

Il funzionamento di Scrum

Nella figura seguente è riportato uno schema del flusso delle attività e dei processi della metodologia Scrum così come riportato nello Scrum Body Of Kwnoledge.

Il flusso della metodologia Scrum

Inizio

  1. Creare la vision del progetto. In questo processo viene analizzato il business case del progetto per creare un documento ufficiale che dichiara quale sia la vision (Project Vision Statement) che verrà seguita durante tutto il ciclo di vita del progetto. In questa fase viene identificato il Product Owner;
  2. Identificare lo Scrum Master e gli stakeholder. In questa fase viene identificato lo Scrum Master sulla base di alcuni criteri di selezione;
  3. Creare lo Scrum Team. In questo processo il Product Owner e lo Scrum Master identificano i membri del team;
  4. Scrivere le Epic. In questo processo, servendosi del Project Vision Statement vengono scritte delle User Story 13 di alto livello. Queste User Story sono chiamate Epic. Le Epic sono troppo ampie per essere completate dal team in un solo Sprint e per questo vengono scomposte in User Story più piccole;
  5. Creare il Prioritized Product Backlog. In questo processo le Epic vengono raffinate e ordinate secondo un ordine di priorità per creare il Prioritized Product Backlog del progetto. Inoltre, vengono anche stabiliti i criteri del cosiddetto “Fatto”14;
  6. Stilare il Release Planning. In questo processo vengono revisionate le User Story contenute nel Prioritized Product Backlog per realizzare il Release Plan (piano di pianificazione dei rilasci), che è una schedulazione che può essere condivisa con gli stakeholder. In questa fase viene anche determinata la lunghezza degli Sprint.

Pianificazione e stime

  1. Scrivere le User Story. In questo processo il Product Owner, con l’aiuto del team, scrive le User Story e ne definisce i criteri di accettazione. Esse devono essere progettate garantendo che i requisiti dei clienti siano rappresentati e compresi da tutti gli stakeholder. Le User Story vengono poi inserite nel Prioritized Product Backlog;
  2. Approvare, stimare e affidare le User Story. In questo processo le User Story per uno Sprint vengono approvate dal Product Owner e successivamente lo Scrum Master e il team effettuano una stima dello sforzo necessario per sviluppare le funzionalità descritte nelle User Story;
  3. Creare la lista delle attività. Durante il Task Planning Meeting le User Story
    approvate e stimate sono suddivise in attività;
  4. Stimare le attività. Durante il Task Estimation Meetings il team effettua una stima dello sforzo richiesto per realizzare le attività presenti nella lista (Effort Estimated Task List);
  5. Creare lo Sprint Backlog. In questa fase il team conduce lo Sprint Planning Meeting, in cui viene creato lo Sprint Backlog, ovvero la lista delle attività da realizzare durate lo Sprint.

Implementazione

  1. Creare i deliverable. In questa fase il team lavora alle attività presenti nello Sprint Backlog per creare i deliverable dello Sprint. Per mantenere sotto controllo il lavoro svolto e quello ancora da fare si utilizza una Scrum board15 e i problemi risolti o da affrontare sono registrati su un diario chiamato Impediment Log;
  2. Condurre i Daily Standup Meeting. Ogni giorno sono condotti dei meeting di durata stabilita (es. 15 minuti) che sono utili per i membri del team perché in questa occasione possono aggiornarsi sui loro progressi e impedimenti;
  3. Portare avanti il Prioritized Product Backlog. In questo processo il Prioritized Product Backlog viene continuamente aggiornato e mantenuto. Inoltre, si può tenere un Prioritized Product Backlog Review Meeting, in cui eventuali modifiche o aggiornamenti al Backlog sono discussi ed eventualmente incorporati.

Revisione e retrospettiva

  1. Convocare lo Scrum of Scrums. Solo per i progetti di grandi dimensioni in cui sono coinvolti più Scrum Team, i rappresentanti del team convocano gli Scrum of Scrums Meeting, a intervalli prestabiliti o quando richiesto, per collaborare e tenere traccia dei rispettivi progressi, impedimenti e delle dipendenze tra i team;
  2. Dimostrare e validare lo Sprint. In questo processo, durante lo Sprint Review Meeting il team dà dimostrazione dei deliverable prodotti durante lo Sprint al Product Owner e agli stakeholder più rilevanti, al fine di garantire l’approvazione e l’accettazione da parte del Product Owner;
  3. Condurre la retrospettiva dello Sprint. In questo processo il team e lo Scrum Master si incontrano per discutere delle lezioni imparate durante lo Sprint.

Rilascio

  1. Consegnare i deliverable. In questo processo i deliverable accettati sono consegnati agli stakeholder. Un documento formale di consegna dei deliverable funzionanti documenta che lo Sprint si è concluso con successo;
  2. Condurre una retrospettiva del progetto. In questo processo, che conclude il progetto, gli stakeholder e lo Scrum Team si incontrano per discutere di come è andato il progetto e delle lezioni apprese.

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 *