SCRUM in pillole #4

Scrum in pillole #4

Al termine del nostro precedente appuntamento con ‘Scrum in pillole’ ci eravamo lasciati con questa domanda: “A cosa ci si riferisce quando si parla degli aspetti di Scrum?”. Proveremo a spiegarlo brevemente nel post di oggi(1).

Cos’è un aspetto nel linguaggio di Project Management?
La definizione più appropriata di aspetto in relazione all’uso che ne fa Scrum può essere così sintetizzata: “una parte o caratteristica specifica di qualcosa che si presenta alla nostra osservazione“. Se il “qualcosa” in questione è il progetto, l’aspetto ne costituisce dunque una caratteristica specifica e al tempo stesso essenziale da gestire con attenzione e competenza per garantire il successo del progetto stesso.  Pure nella diversità della terminologia, non c’è dubbio che tutti i principali framework e standard di project management facciano riferimento a queste caratteristiche essenziali da gestire in un progetto: basti pensare alle sette tematiche di PRINCE2® o alle dieci aree di conoscenza  della PMBOK®Guide 6th Ed. (che confluiranno poi negli otto domini di performance della settima edizione di prossima pubblicazione). Per Scrum questi aspetti, e dunque queste fondamentali dimensioni di gestione, sono cinque. Vediamole un po’ più da vicino.

1. Organizzazione
Riguarda i ruoli di Scrum . Comprendere la definizione dei ruoli e delle responsabilità di un progetto Scrum è molto importante per garantire la corretta implementazione del framework. I ruoli di Scrum rientrano in due categorie generali: a. Ruoli Core – sono quelli che sono richiesti obbligatoriamente per realizzare il prodotto o servizio del progetto: Product Owner, Scrum Master e Scrum Team; b. Ruoli Non Core – sono quelli che non sono sempre obbligatoriamente richiesti per il progetto Scrum, non hanno un ruolo formale all’interno del team di progetto e possono interfacciarsi con il team, senza però essere necessariamente responsabili del successo del progetto: Stakeholder (Cliente, Sponsor, Utenti), Venditori, Scrum Guidance Body.

2. Giustificazione Commerciale
Per un’organizzazione è importante eseguire una valutazione di business appropriata prima di far partire qualsiasi progetto. Ciò aiuta gli organi decisionali chiave a comprendere l’esigenza di business di un cambiamento o di un nuovo prodotto o servizio, la giustificazione per andare avanti con un progetto e la sua fattibilità. La giustificazione commerciale in Scrum si basa sul concetto della Consegna basata sul Valore. Partendo dalla considerazione che tutti i progetti sono caratterizzati dall’incertezza degli esiti o dei risultati, Scrum tenta di iniziare a consegnare i risultati del progetto quanto prima sia possibile. Questa consegna anticipata di risultati, e perciò di valore, offre un’opportunità di reinvestimento e dimostra la pregevolezza del progetto agli stakeholder interessati.

3. Qualità
In Scrum la qualità è definita come l’abilità del prodotto o dei deliverable completati di soddisfare i Criteri di Accettazione e realizzare il valore di business atteso dal cliente. Per assicurare che un progetto soddisfi i requisiti di qualità, Scrum adotta un approccio di miglioramento continuo attraverso il quale il team apprende dall’esperienza e dal coinvolgimento degli stakeholder, in modo da tenere costantemente aggiornato il Prioritized Product Backlog con le eventuali modifiche dei requisiti. Poiché Scrum richiede che il lavoro sia completato in incrementi realizzati in ogni Sprint, gli errori o i difetti vengono notati prima grazie a test di qualità ripetitivi, piuttosto che quando il prodotto o il servizio è prossimo al completamento finale. Inoltre, importanti attività connesse alla qualità (ad esempio sviluppo, collaudo e documentazione) sono eseguite come parte del medesimo Sprint dal medesimo team; questo assicura che la qualità sia inerente a qualsiasi deliverable creato come parte di uno Sprint. Tali deliverable, potenzialmente consegnabili, scaturenti da ogni Sprint dei progetti Scrum sono detti ‘Completati’ (‘Done’).

4. Cambiamento
Tutti i progetti, indipendentemente dal metodo o framework utilizzato, sono esposti al cambiamento. È assolutamente indispensabile che i membri del team di progetto comprendano che i processi di sviluppo di Scrum sono disegnati per abbracciare il cambiamento. Un principio fondamentale di Scrum è il prendere atto che: a) gli stakeholder (ad esempio i clienti, gli utenti e gli sponsor) nel corso del progetto cambiano idea su ciò che vogliono e di cui hanno bisogno (circostanza a volte chiamata “requirements churn”, letteralmente “abbandono dei requisiti”), e b) è molto difficile, se non impossibile, che gli stakeholder definiscano tutti i requisiti all’inizio del progetto.
I progetti Scrum accolgono volentieri il cambiamento attraverso l’uso di brevi Sprint iterativi che incorporano il feedback del cliente nei deliverable di ciascuno Sprint. Ciò consente al cliente di interagire abitualmente con i membri dello Scrum Team, di visionare i deliverable non appena sono pronti e di cambiare i requisiti prima dell’inizio dello Sprint successivo, se necessario.

5. Rischio
Il rischio è definito come un evento incerto o un insieme di eventi incerti che possono impattare sugli obiettivi di un progetto, contribuendo al suo successo o fallimento. I rischi che hanno un probabile impatto positivo sul progetto vengono definiti come opportunità, mentre le minacce sono i rischi che potrebbero incidere in modo negativo sul progetto. La gestione del rischio deve essere eseguita in maniera proattiva ed è un processo iterativo che dovrà iniziare nella fase di inizio del progetto e continuare lungo tutto il suo ciclo di vita. Il processo di gestione dei rischi dovrà seguire alcuni passi standardizzati per assicurare l’identificazione del rischio, la sua valutazione, la determinazione delle azioni appropriate e la loro conseguente messa in atto. Le azioni di risposta ai rischi entrano a far parte del Prioritized Product Backlog secondo la priorità loro assegnata in rapporto a tutte le User Story presenti nel Prioritized Product Backlog, divenendo esse stesse delle User Story.

Quali responsabilità hanno nel dettaglio i ruoli core di Scrum e come si interfacciano fra di loro e con i ruoli non core?
Per avere la risposta a questa e a tante altre domande continuate a seguire le nostre pillole settimanali!

Lo Staff di PME

 

(1)I contenuti di questo articolo sono tratti dalla traduzione ufficiale in Italiano della Guida SBOK e di altri contenuti didattici, curata da PME per conto di VMEdu Inc.
Project Management Europa S.r.l. è Authorized Training Partner di VMEdu e SCRUMstudy
SCRUMstudy, SFC, SDC, SMC, SPOC, SSMC, SSPOC, ESMC, SAMC, SBOK sono marchi registrati diVMedu Inc.
L’ immagine dell’articolo è utilizzata su concessione di VMEdu Inc., che ne è la proprietaria.
Se vuoi maggiori informazioni su tutti i nostri corsi Scrum, disponibili ora anche in Italiano e sulle offerte attualmente disponibili Clicca qui.

0 Commenti

Leave a reply

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

*