SCRUM: La guida operativa definitiva

Home » Blog » SCRUM: La guida operativa definitiva
SCRUM è il framework agile per la gestione del ciclo di sviluppo di un software che utilizziamo in Rhubbit. In questa guida pratica ti forniamo tutto quello che serve per usarlo al meglio e con il maggior profitto possibile portare al successo i tuoi progetti.
Condividi su facebook
Facebook
Condividi su twitter
Twitter
Condividi su linkedin
LinkedIn
Condividi su pinterest
Pinterest
Condividi su whatsapp
WhatsApp
Condividi su email
Email

Sommario dell'articolo

Nel precedente articolo dedicato all’agile ho fornito le basi da cui partire ed approcciare a quella che al momento è uno dei migliori framework per lo sviluppo del software: SCRUM.

Nell’articolo di oggi che è più una guida operativa a SCRUM ed ai momenti che lo governano, andrò a svelare tutti i trucchi che ci hanno permesso di guidare i clienti attraverso la giungla delle soluzioni tecnologiche ed ottenere il miglior valore possibile anche dai processi interni.

Introduzione

Negli ultimi anni l’interesse verso la filosofia AGILE e nel framework SCRUM è cresciuto molto ed ho avuto il piacere toccare con mano questo trend anche negli eventi live che ho potuto tenere prima di natale 2019 e nei webinar che ho avuto il piacere di condurre in questi mesi mesi per conto di Banca Sella.

Poiché la mia speranza è quella di diffondere il più possibile le buone pratiche di gestione del ciclo di sviluppo del software, ho realizzato col tempo questa guida che racchiude la sintesi della mia visione rispetto a questo mondo.

Completa il tutto una serie di considerazioni ed una descrizione quanto più esauriente possibile di queste importanti tematiche che ormai hanno ampiamente travalicato i limiti del mondo IT.

Agile e SCRUM sono diventati un punto di riferimento metodologico in tutti quei settori per cui è fondamentale gestire il problema relativo a complessità tecniche importanti affiancate a difficoltà di previsione ex-ante dovute a forti variabilità del contesto in cui il progetto/prodotto si evolve.

In questo articolo partirò quindi con un approfondimento sul manifesto AGILE, in quanto filosofia fondante alla base di ogni framework moderno di sviluppo iterativo, seguito da un approfondimento completo di SCRUM in quanto metodologia agile per definizione.

Nei prossimi paragrafi parleremo quindi di:

  1. SCRUM: i ruoli di Product owner e Scrum master
  2. SCRUM: eventi principali del framework
  3. Epic / Story / Task , come organizzare il lavoro in SCRUM
  4. Mindset e valori alla base di SCRUM

I ruoli di Product owner e Scrum master

In questa sezione troverai un approfondimento sui due ruoli chiave alla base di Scrum, Product OWNER e SCRUM Master, ed una riflessione su come queste figure dovrebbero collaborare al meglio per garantire il risultato atteso.

In un ambiente Agile efficiente che utilizza le metodologie Scrum, i ruoli di Product Owner e Scrum Master sono distinti ed entrambi di vitale importanza.

Sebbene le loro competenze e attività possano sovrapporsi in alcune occasioni, è importante che entrambe le persone comprendano appieno i propri ambiti e apprezzino il modo in cui possono trarre il massimo dalla reciproca collaborazione.

i ruoli nel team di scrum

Il ruolo del Product OWNER

I Product OWNER sono generalmente gli stakeholder chiave in un progetto. In quanto tali, sono responsabili della determinazione della direzione generale del progetto, delle caratteristiche che il prodotto conterrà e della priorità che verrà data a ciascuna caratteristica.

Sono responsabili di mantenere il Product BACKLOG e garantire che l’intero team Scrum comprenda la visione generale del prodotto. Tuttavia, è importante per loro trattenersi dal microgestire la squadra e cercare di determinare esattamente quanto lavoro verrà tentato in ogni sprint.

Il Product Owner funge anche da anello di congiunzione che trasporta le comunicazioni da e verso il team di scrum e funge da collegamento con la direzione superiore, con altri dipartimenti che incidono sul successo del progetto e con clienti, beta tester o utenti i cui feedback risultano vitali per il processo di evoluzione del prodotto all’interno dei cicli iterativi di Sprint che si susseguono.

In assenza di un buon Product OWNER il progetto tenderà, nella migliore delle ipotesi, ad autodeterminarsi in maniera autoreferenziale fallendo con buona probabilità nell’obiettivo finale ossia generare valore per l’utente/cliente per cui dovrebbe essere stato sviluppato.

Altra funzione critica del Product OWNER è quella di declinare le KPI definite in collaborazione con stakeholder interni ed esterni all’azienda che realizza il prodotto in modo tale che siano ampiamente comprensibili e condivise dal team di sviluppo così che possa farle proprie ed agire al meglio, in autonomia, per perseguire gli obiettivi definiti.

Vuoi 30 minuti di consulenza gratuita su SCRUM?

Il ruolo dello SCRUM Master

La principale responsabilità dello Scrum Master è quella di garantire che il team di Scrum lavori nel miglior modo possibile nell’ambito della Scrum Framework. Lo Scrum Master deva agire come un coach ed un protettore, incoraggiando il team con riunioni stand-up quotidiane che aiutano a mantenere la visione del Product Owner in primo piano, rimuovendo gli ostacoli al loro efficiente flusso di lavoro e lavorando a stretto contatto con il Product Owner per mantenere il Product BACKLOG nel susseguirsi degli Sprint.

Laddove il Product Owner è responsabile per il prodotto creato con Scrum, lo Scrum Master è il “proprietario del processo” che mantiene il team sulla strada definita dal framework. Lavorando a stretto contatto con il Product Owner, aiuta a garantire che le richieste di funzionalità, i time box e le aspettative dei membri del team siano ragionevoli e declinate secondo principi, valori e procedure Scrum. Lo Scrum Master riporta anche informazioni a seguito di uno sprint non riuscito per contribuire a rendere più efficace lo sprint successivo.

Uno Scrum Master adeguatamente preparato è caratterizzato al contempo da adeguate competenze tecniche, necessarie per comprendere al meglio i problemi e le proposte del team di sviluppo, e quell’insieme di soft skill umane e professionali (leadership, empatia, capacità di ascoltare gli altri, capacità di comprendere le esigenze di business, …) che gli permettono di poter interagire altrettanto agilmente nel confronto continuo con Product OWNER ed altri reparti aziendali o Scrum team che lavorano al suo fianco.

Per le aziende che intendono introdurre SCRUM su progetti già avviati è inoltre importante comprendere che non sempre, per non dire raramente, è una buona idea assegnare il ruolo di Scrum Master al membro del team più senior e tecnicamente competente. Non è assolutamente detto che un tecnico molto esperto sia adatto a svolgere questo ruolo ed anzi spesso è controproducente visto che per farlo dovrà sottrarre tempo e valore dalle attività tecniche dove indubbiamente potrebbe apportare il suo massimo contributo.

Collaborazione tra Product OWNER e SCRUM Master

Come abbiamo potuto vedere questi due ruoli si sovrappongono in alcuni dei loro set di abilità, il che significa che le persone che li ricoprono dovrebbero essere in grado di collaborare al meglio. Tuttavia, il Product Owner tende ad avere una maggiore autorità all’interno dell’azienda e questo non è detto che sia un bene.

Nei layout di team più efficaci, il Product Owner e Scrum Master sono veramente partner in uno sforzo coeso e reciprocamente vantaggioso finalizzato ad ottenere i migliori risultati possibili dagli sforzi del team.

L’obiettivo che entrambi condividono è la creazione di un prodotto adeguato alle richieste del mercato attraverso l’uso di metodologie Agile. A tale scopo, il Product Owner e Scrum Master dovrebbero compiere ogni sforzo per collaborare strettamente nelle seguenti aree:

1 – Backlog Grooming

Sebbene il BACKLOG sia la principale area di competenza del Product Owner, lo Scrum Master è in una posizione eccellente per aiutare il Product Owner a prendersene cura. Con in mente i risultati di ogni retrospettiva dello sprint, lo Scrum Master può collaborare con il Product Owner per garantire che lo sprint successivo sia ancora più in linea con la realtà e preparare il team al successo.
E’ anche consigliabile lasciare libero accesso al BACKLOG per i membri del team, per quanto la definizione delle attività da fare sia ancora in una sorta di stato di bozza in questa fase un loro feedback o commento può spesso indirizzare al meglio le scelte future oltre che ridurre significativamente i tempi di Planning

2 – Migliorare la comunicazione tra i team

Lavorando a stretto contatto con lo Scrum Master, che interagisce quotidianamente con il team, il Product Owner può assicurarsi che tutte le comunicazioni necessarie riguardanti il progetto e la visione del prodotto siano chiare per il team e può riportare tutto il necessario ad altri dipartimenti, team o livelli dell’organizzazione.

3 – Migliorare il morale del team

Collaborando nel corso di un progetto, il Product Owner e Scrum Master possono mantenere il morale e la produttività di un team ai massimi livelli semplicemente mantenendo aperte le linee di comunicazione e impostando le priorità in base a ciò che è ragionevole piuttosto che su obiettivi aziendali arbitrari.

4 – Garantire dipendenze incrociate con altri team

Sia il Product Owner che lo Scrum Master probabilmente hanno stretti rapporti con altri team, ed altri loro omologhi, nonché con i membri dei team passati che potrebbero lavorare altrove nell’organizzazione. Sfruttare tali relazioni può aiutare sia a migliorare il progetto attuale sia a correggere eventuali problemi incontrati sulla strada.

5 – Chiarire la visione del prodotto

Mentre il Product Owner è responsabile della definizione e della comunicazione della visione strategica alla base del prodotto, lo Scrum Master è responsabile del coinvolgimento del team e della realizzazione di tale visione. Ha senso che entrambi siano pienamente coinvolti nella visione e siano in grado di comunicarla chiaramente in modo appropriato.

Vuoi 30 minuti di consulenza gratuita su SCRUM?

Scrum, eventi principali

Il framework SCRUM può essere visualizzato mediante una sequenza di eventi e gli artefatti corrispondenti. Gli eventi Scrum sono eventi temporizzati. Ciò significa che, in un progetto, ogni evento ha una durata massima predefinita. Questi eventi consentono la trasparenza sullo stato di avanzamento del progetto a tutti coloro che vi sono coinvolti.

scrum il framework agile per la gestione dei progetti di sviluppo del software

Gli eventi essenziali di SCRUM sono 5:

  1. Lo Sprint
  2. Sprint Planning
  3. Daily Scrum Meetings
  4. Sprint review 
  5. Retrospettiva

Tutti hanno un’importanza cruciale a sé stante ed è per questo motivo che, ne esamineremo brevemente ciascuno qui di seguito.

1 – Lo Sprint

Durante uno Sprint, viene sviluppato un incremento di prodotto funzionante. Di solito dura due settimane (o al massimo un mese) e questa durata rimane costante per tutti gli sprint del progetto. 

Ogni Sprint è soggetto a due semplici regole:

  1. la durata di tutti gli Sprint di uno stesso progetto è costante
  2. un nuovo Sprint inizia immediatamente dopo la conclusione dello Sprint precedente

Mantenere queste semplici regole di per se in alcuni progetti è una sfida e spesso se una o l’altra delle regole viene violata la cosa è indice di una cattiva progettazione da parte di Scrum Master / Product Owner o di una debole vision aziendale che fatica nel definire esattamente quali obiettivi perseguire lasciando il team incapace di definire esattamente cosa e quando farlo.

Ogni sprint è caratterizzato da un obiettivo che fornisce una guida al team sul perché sta costruendo l’incremento e che viene formalizzato durante la riunione di Sprint Planning. L’ambito dello sprint viene chiarito e rinegoziato tra il Product Owner e il Team man mano che si apprendono ulteriori informazioni sui requisiti. Pertanto, ogni Sprint vede associato ad esso, una definizione di ciò che deve essere costruito, una progettazione e il piano flessibile che guiderà la costruzione, il lavoro di sviluppo e l’incremento del prodotto risultante.

Uno Sprint deve essere annullato se l’obiettivo Sprint diventa obsoleto. Ciò può verificarsi se l’organizzazione cambia direzione o se cambiano le condizioni del mercato o della tecnologia. Uno sprint può essere annullato solo dal Product OWNER, sebbene altri abbiano un’influenza sullo stesso.

A causa della natura di breve durata degli Sprint, la cancellazione durante uno sprint ha raramente senso portando a consumare inutilmente risorse e lasciando spesso il team impreparato al successivo sprint che deve essere riorganizzato.

Se uno Sprint viene annullato e una parte del lavoro prodotto durante lo Sprint è potenzialmente rilasciabile, il Product Owner in genere lo accetta.

Al termine di uno Sprint tutti gli elementi incompleti dello Sprint backlog vengono reinseriti nel backlog del prodotto per poi essere rimessi in produzione quando il team lo riterrà più opportuno.

2 – Sprint planning

Il lavoro da eseguire nello Sprint è pianificato durante lo Sprint Planning Meeting. Lo Sprint Planning Meeting ha solitamente una durata massima di quattro ore per gli sprint di due settimane e otto ore per gli sprint di un mese. È responsabilità dello Scrum Master assicurarsi che l’incontro abbia luogo e che tutti i partecipanti richiesti siano presenti e comprendano lo scopo dell’incontro programmato. Lo Scrum Master modera l’incontro per monitorare il completamento della discussione e la chiusura nei tempi previsti.

Durante la fase di Sprint Planning ci si concentra sulle seguenti due domande:

  1. Cosa deve essere e può essere consegnato nell’incremento di Sprint?
  2. Come saranno realizzati i lavori necessari per l’esecuzione dello Sprint?

Gli input per questo incontro sono:

  • Il Product BACKLOG
  • L’ultimo incremento del prodotto rilasciato nello sprint precedente
  • La capacità operativa prevista del team durante lo Sprint (può variare nel tempo per esigenze aziendali, rimodulazione del team, assunzione di nuovo personale, …)
  • Performance passata del team

Preso atto di ciò lo Scrum Team discute le funzionalità che possono essere sviluppate durante lo Sprint e, dove richiesto, il Product Owner fornisce chiarimenti sugli elementi del Product Backlog. Il team seleziona gli articoli dal Product Backlog per lo Sprint, in quanto i suoi membri sono i soggetti migliori per valutare ciò che è effettivamente possibile realizzare nello Sprint. Il lavoro viene svolto in modo collaborativo, riducendo così al minimo il rischio di rilavorazione.

Fatto ciò lo Scrum Team presenta quindi uno Sprint Goal. L’obiettivo di Sprint è un obiettivo che fornisce una guida al team sul perché sta costruendo l’incremento del prodotto e sul cosa effettivamente fare. Il team decide quindi in autonomica come integrare la funzionalità selezionata in un incremento del prodotto funzionante durante lo Sprint. Gli elementi del Product Backlog selezionati per questo Sprint più il piano per la consegna previsto (Sprint Goal) sono chiamati Sprint Backlog.

Il lavoro durante uno sprint è stimato durante la pianificazione dello sprint e può avere dimensioni e / o sforzi variabili. Entro la fine della riunione di Sprint Planning, il lavoro viene suddiviso in attività di durata predefinita (possibilmente inferiore ad un giorno). Questo per consentire la facilità di allocazione del lavoro e il monitoraggio del completamento. Se il team si rende conto che ha troppo o troppo poco lavoro, può rinegoziare gli articoli selezionati del Product Backlog con il Product Owner.

Il team può anche invitare altri (non facenti parte del team Scrum) a partecipare alla riunione Sprint Planning per ottenere consulenze tecniche o di dominio che aiutino nella stima.

Lo Sprint Backlog può quindi agilmente essere condiviso con altri stakeholder (interni o esterni all’azienda) che possono ragionevolmente aspettarsi che a fine Sprint quanto previsto venga rilasciato organizzando il loro lavoro di conseguenza.

 

3 – Daily Scrum Meetings

Il Daily Scrum Meeting è un incontro di 15 minuti, condotto quotidianamente per comprendere rapidamente l’avanzamento dall’ultimo Daily Scrum Meeting e creare un piano per le prossime 24 ore. Questa riunione viene anche definita Stand up Meeting giornaliero.

Il Daily Scrum Meeting si tiene ogni giorno alla stessa ora e nello stesso luogo per ridurre la complessità. Durante l’incontro, ogni membro del team spiega:

  • Che cosa ha fatto il giorno precedente che ha aiutato a raggiungere lo Sprint Goal
  • Cosa farà nella giornata in corso per aiutare a raggiungere lo Sprint Goal
  • Quali impedimenti vede che ostacolino a lui o il team nel raggiungimento dello Sprint Goal

Questo incontro giornaliero viene erroneamente considerato un evento di monitoraggio dello stato, sebbene, in realtà, sia un evento di micro-pianificazione.

L’input alla riunione dovrebbe essere ciò che il team sta facendo per raggiungere lo Sprint Goal e l’output dovrebbe essere un piano nuovo o rivisto che ottimizzi gli sforzi della squadra nel raggiungerlo davvero entro i tempi previsti.

Sebbene lo Scrum Master coordini il Daily Scrum Meeting e assicuri che gli obiettivi dell’incontro siano raggiunti, l’incontro è di responsabilità del Team.

Se necessario, tutto o parti del team possono incontrarsi immediatamente dopo il Daily Scrum Meeting, per eventuali discussioni dettagliate o per riprogrammare il resto del lavoro da fare.

Di seguito sono riportati i vantaggi di Daily Scrum Meetings:

  • migliora la comunicazione all’interno del team
  • Aiuta ad Individuare eventuali impedimenti o colli di bottiglia, al fine di facilitare una rimozione anticipata degli stessi, in modo da ridurne al minimo l’impatto sullo Sprint
  • evidenzia e promuove un rapido processo decisionale
  • permette, nei casi peggiori, di essere consapevoli di ritardi o constraints imprevisti ed aiuta l’azienda a reagire ad essi il più efficientemente possibile
  • migliora il livello di conoscenza del team.

 

4 – Sprint review

Una Sprint Review si tiene alla fine di ogni Sprint. Durante la Sprint Review, viene esaminata una presentazione dell’incremento che sta per essere rilasciato. In questo incontro, lo Scrum Team e le parti interessate collaborano per capire cosa è stato fatto nello Sprint. Sulla base di ciò, e di eventuali modifiche al Product Backlog durante lo Sprint, i partecipanti arrivano ai passaggi successivi necessari per ottimizzare il valore generato. Pertanto, l’obiettivo della Sprint Review è ottenere feedback e suggerimenti utili oltre che allineare soggetti esterni al team con lo stato di avanzamento effettivo del prodotto.

Lo Sprint Review dura mediamente due ore per gli sprint di due settimane e quattro ore per gli sprint di un mese.

Durante la review lo Scrum Master garantisce che:

  • l’incontro abbia effettivamente luogo
  • i partecipanti ne comprendono lo scopo
  • l’incontro resti focalizzato sull’agenda richiesta e completato entro la durata prevista

La Sprint Review include i seguenti aspetti:

  1. i partecipanti includono lo Scrum Team e le principali parti interessate, parti selezionate dal Product Owner
  2. il Product Owner spiega quali elementi del Product Backlog sono stati completati durante lo sprint e cosa non è stato completato
  3. il Team discute su cosa è andato bene durante lo Sprint, su quali problemi ha incontrato e come sono stati risolti
  4. il team dimostra con slide, video o live demo il lavoro che ha completato e risponde alle eventuali domande sull’incremento rilasciato
  5. l’intero gruppo discute quindi su cosa fare dopo pertanto, la Sprint Review fornisce un valido contributo alla pianificazione dello Sprint successivo
  6. lo Scrum Team rivede quindi la cronologia, il budget, le potenziali capacità e il mercato per la prossima versione anticipata dell’incremento del prodotto.

L’obiettivo della Sprint Review è quello di generare un Product Backlog aggiornato, che definisca i probabili articoli del Product Backlog per il prossimo Sprint ed allinei le parti coinvolte con lo stato di avanzamento del prodotto.

 

5 – Retrospettiva

La Sprint Retrospective si verifica dopo la Sprint Review e prima del successivo Sprint Planning. Di solito si tratta di un incontro di un’ora per gli sprint di durata di due settimane e di un incontro di tre ore per gli sprint di durata di un mese.

Lo scopo della Sprint Retrospective è di:

  • rielaborare ciò che è stato appreso dell’ultimo Sprint, per quanto riguarda le persone, le relazioni, i processi e gli strumenti
  • individuare gli elementi principali che sono andati bene e i potenziali miglioramenti
  • creare un piano per l’implementazione di miglioramenti per aumentare la qualità del prodotto.

La Sprint Retrospective è in realtà uno dei momenti più importanti per la crescita del team costituendo un’opportunità di introspezione e miglioramento incrementali nel quadro del processo di Scrum così da da renderne più efficace la prossima iterazione.

Vuoi 30 minuti di consulenza gratuita su SCRUM?

5 – Come organizzare il lavoro (EPIC/STORY/TASK)

Tre i concetti più importanti alla base del framework SCRUM ci sono quelli di EpicUser Story e Task. È importante comprendere appieno cosa sono in modo che il team possa adoperarli adeguatamente per superare grandi o piccole sfide nel fornire il prodotto che soddisfi le aspettative dei clienti per cui è progettato.

SCRUM: Come organizzare il lavoro

Epic

Un Epic è una grande story, un macro obiettivo che semplicemente non può essere raggiunto in un singolo sprint. Di solito, ci vogliono mesi per realizzare completamente un Epic e raggiungere l’obiettivo per cui è stata definita. Un Epic si riferisce in genere a una serie di requisiti che non sono stati ancora razionalizzati nelle storie degli utenti. Va immaginata come un grande obiettivo che deve ancora essere semplificato e diviso in diversi compiti affinché il team agile possa lavorarci.

Le Epic sono generalmente di ampia portata, prive di dettagli e devono essere suddivise in User story più piccole prima di poter essere elaborate. Epic è generalmente considerato il “livello più alto” o una gerarchia del lavoro da suddividere in attività quotidiane più piccole e specifiche, chiamate appunto User Story così da aiutare l’organizzazione a raggiungere i suoi obiettivi aziendali.

Per definire adeguatamente un Epic occorre:

  • definire un obiettivo di cui i manager e gli esecutori vorrebbero tenere traccia
  • identificare una caratteristica del prodotto, una richiesta del cliente o un requisito aziendale
  • limitare il contesto che la caratterizza affinché non richieda troppo o troppo poco tempo per essere completata

Di seguito alcuni esempi di EPIC:

  • Come banca, vogliamo estendere i nostri servizi offrendo assicurazioni sulla vita e sulla salute.
  • Vogliamo aggiungere un riconoscimento biometrico per aumentare la sicurezza senza problemi.
  • Come reparto marketing, vogliamo creare un’app interattiva che comunichi al meglio le funzionalità del prodotto per soddisfare al meglio i clienti premium.

User Story

Le User Story definisco semplicemente l’elenco degli elementi che devono essere realizzati all’interno di un progetto. Vanno pensate come un elenco di cose da fare, elenco gestito dal Product Owner che definisce di fatto i perimetri effettivi del prodotto. Lo Scrum Master, le parti interessate e il team di Scrum contribuiscono al completamento degli elementi così definiti. 

L’idea alla base di questa entità è di scomporre un prodotto in pezzi spendibili in modo che il grande progetto possa essere realizzato con successo un pezzo alla volta. 

Se una EPIC può coinvolgere più team e più progetti e possono essere monitorate su più livelli una User Story è una definizione di altissimo livello dei requisiti del progetto. Contiene informazioni sufficienti per fornire al team Scrum un contesto adeguato su come dovrebbe essere il prodotto finale e per consentire di calcolare una stima effettiva dell’effort necessario per il suo completamento. È uno strumento fortemente legato all’approccio agile che aiuta a spostare l’attenzione dalla documentazione al ragionamento ed alla libertà di implementazione in tempo reale.

Le linee guida fondamentali quando si scrive una User Story sono:

  • le storie degli utenti devono essere brevi e di semplice e coerente descrizione in tutto il progetto agile
  • sebbene di principale dominio del Product Owner, chiunque può aggiungere o quantomeno proporre user story se pensa che possano effettivamente contribuire all’effettivo raggiungimento del macro obiettivo definito dal Epic di riferimento
  • vanno espresse in un linguaggio semplice in modo che il cliente possa capire di cosa tratta il prodotto finale (nel caso del software, cosa verrà realizzato)
  • costituiscono la risposta al “chi”, al “cosa” e al “perché” di una parte del progetto espresse con un linguaggio semplice e non tecnico.

Le User Story sono considerate il “cuore di Scrum” perché fungono da “blocchi” dello sprint e da punto di contatto tra la visione più astratta e trasversale dei vari reparti aziendali e quella più tecnica ed operativa del team che le deve realizzare.

User Story TEMPLATE

Al fine di massimizzare la leggibilità delle User Story all’interno di ogni reparto dell’azienda e di lasciare al contempo il massimo grado di libertà esecutiva possibile ai membri del team e contemporaneamente ridurre al minimo il tempo necessario alla loro definizione SCRUM definisce un pattern standard per la la loro definizione:

COME

VOGLIO

IN MODE CHE

Esempi di User Story:

  • COME utente loggato, VOGLIO migrare tutti i miei dati di backup in un sistema cloud IN MODE CHE possa liberare memoria sul mio dispositivo.
  • COME studente, VOGLIO poter ordinare trascrizioni ufficiali delle lezioni online IN MODE CHE possa risparmiare tempo durante lo studio.
  • COME compratore in un supermercato, VOGLIO pagare gli articoli messi nel mio carrello da un’app mobile IN MODE CHE possa saltare la fila in negozio e guadagnare tempo.

 

Task

Differentemente dalle User Story, che definiscono esigenze individuate dall’alto e quindi tipicamente codificate dal Product Owner che si relaziona con gli altri stakeholder, i task sono delle esigenze evidenziate dal basso, tipicamente da membri del team o dallo Scrum Master, che identificano problematiche tecniche o un prevedibile collo di bottiglia o blocco all’orizzonte.

Come per le User Story anche in questo caso Scrum Master e membri del team sono liberi di inserire questi task nel Product Backlog, task che in fase di Sprint planning verranno poi adeguatamente stimati e prioritizzati così da poter essere inseriti all’interno di uno dei futuri rilasci.

Nonostante i membri del team che le segnalino saranno fortemente motivati a lavorare immediatamente su queste problematiche è severamente sconsigliato mettere in lavorazione uno di questi task durante una iterazione di Sprint già in corso, si rischia di non raggiungere lo Sprint Goal, di compromettere le stime fatte o di mettere in secondo piano funzionalità che possono generare valore effettivo sul mercato.

E’ però altrettanto importante non abbandonare indefinitamente questo tipo di attività nel backlog perchè, se effettivamente indispensabili, prima o poi la loro criticità emergerà risultando bloccante e sicuramente in quel momento non si disporrà del tempo adeguato per gestire come si dovrebbe questo tipo di problematiche.

Alcuni esempi di Task:

  • Occorre aggiornare il framework utilizzato per realizzare l’applicazione perchè il precedente non è più supportato e quindi esposto a bug di sicurezza.
  • Va modificata la struttura del database perché alcune query risultano lente e richiedono eccessiva potenza di calcolo oltre a generare una eccessiva latenza nel sistema
  • Dobbiamo modificare l’architettura del progetto perchè occorre scalare più rapidamente

Mindset e valori di SCRUM

Come tutti voi ormai sapete SCRUM è un framework molto popolare e noto per lo sviluppo di software secondo la metodologia AGILE. Alcuni anni fa all’interno di Scrum furono aggiunti 5 valori al framework che ogni membro di un team che segue questa metodologia dovrebbe utilizzare come guida per il suo processo decisionale. 

Non molte persone conoscono e comprendono questi valori, ma personalmente credo che siano fondamentali per un’implementazione di successo della metodologia e quindi di seguito li elencheremo ed analizzeremo in dettaglio.

I 5 Valori di SCRUM

1 – CORAGGIO

I membri del team devono avere il coraggio di fare la cosa giusta e lavorare concentrandosi sui problemi da risolvere

I membri dello Scrum Team dovranno essere caratterizzate e/o invogliati oltre che supportati nell’avere il coraggio di fare la cosa giusta e lavorare su problemi complessi sentendosi liberi di prendere delle decisioni ed assumendosi di conseguenza la responsabilità su di esse. I membri del team così motivati si supporteranno l’un l’altro nel fare la cosa giusta e nell’assumersi rischi informati in modo che possamo imparare e migliorare lungo il percorso verso la realizzazione del prodotto.

Bisognerà quindi:

  • ammettere che nessuno è perfetto
  • essere pronti ad affermare che alcune cose non vanno fatte nel prodotto
  • condividere tutte le informazioni possibili per aiutare il team e l’organizzazione a fare o motivare le scelte più coraggiose
  • ammettere che non ci sono requisiti perfetti per acquisire e affrontare cambiamenti rapidi è la realtà

2 – FOCUS

Tutti devono essere concentrati sul lavoro pianificato e sugli obiettivi del TEAM

Tutti si devono concentrare sul lavoro dello Sprint e sugli obiettivi dello Scrum Team. Quando si ha a che fare con complessità e imprevedibilità, l’attenzione è essenziale per ottenere qualcosa di significativo. Poiché ci si concentra solo su poche cose alla volta, è possibile rilasciare prima le funzionalità più importanti. 

Il framework Scrum include elementi che aiutano a promuovere la concentrazione:

  • il team dovrebbe concentrarsi sull’avere un “incremento fatto” almeno entro la fine di ogni Sprint
  • ogni ruolo nel team ha una distinta responsabilità che aiuta le persone a sapere su cosa concentrarsi come priorità. Ciò contribuisce in definitiva ai risultati della squadra
  • il team di Scrum si concentra su un obiettivo e lo Sprint aiuta a guidare il team nell’individuare cosa e come consegnare
  • il backlog di prodotto è gestito secondo un ordine prioritario condiviso e ciò mette a fuoco ciò che è la cosa più importante da fare
  • gli eventi sprint a tempo determinato creano un senso di urgenza e misurabilità e ci aiutano a concentrarci sullo scopo dell’evento
  • gli eventi e gli artefatti Scrum aiutano a concentrarsi sull’ispezione dei progressi e sulle nuove informazioni, in modo che il team possa adattarsi a intervalli abbastanza frequenti.

3 – COMMITMENT

I membri del team si devono impegnare personalmente al raggiungimento degli obiettivi del progetto

I membri del team di scrum devono impegnarsi per il successo del progetto ed essere co-autori della creazione di obiettivi realistici e rispettabili. Ogni ruolo di scrum si impegna per il successo del team, non solo per la cura di risultati individuali, ciò crea un ambiente di fiducia, proattivo e pronto alla risoluzione dei problemi portando a produttiva ed elevati standard qualitativi del team se:

  • il Product Owner dimostra impegno prendendo le migliori decisioni per ottimizzare il valore del prodotto, non semplicemente cercando di soddisfare ogni stakeholder
  • lo Scrum Master dimostra impegno sostenendo lo Scrum Framework, il che significa che non si prolungano inopportunamente sprint o altri intervalli di tempo sotto pressione per arrivare a rilasci sotto pressioni errate che spingerebbero il team a scelte meno consapevoli ed alla deresponsabilizzazione
  • Scrum Master dimostra l’impegno rimuovendo gli impedimenti che lo Scrum Team non può risolvere da sé, piuttosto che tollerando lo status quo nell’organizzazione
  • il team di sviluppo dimostra impegno creando un incremento che soddisfa la loro definizione di “Fatto”, non qualcosa che è quasi fatto.

4 – RISPETTO

I membri del team si devono rispettare reciprocamente in quanto persone competenti in grado di prendere decisioni autonomamente

Come team auto-organizzanti, non è possibile fare a meno del rispetto reciproco così da coltivare un ambiente proattivo, produttivo e umano per tutti. Il framework Scrum include elementi che aiutano a promuovere il rispetto ai massimi livelli:

  • l’intero Scrum Team partecipa a Sprint Planning, Sprint Review e Sprint Retrospective. Ciò promuove il rispetto per ciascun ruolo, le responsabilità e le diverse prospettive
  • il team di sviluppo è interfunzionale, il che significa che nel suo insieme ha tutte le competenze necessarie per fornire un incremento del prodotto “Fatto”. Ciò promuove il rispetto per le esperienze, le capacità e le idee di tutti. Ciò promuove anche l’apprendimento e la crescita collettivi
  • lo Sprint Backlog è di proprietà del team di sviluppo. Dato che sono loro a fare il lavoro, decidono quanto possono fare in uno Sprint e come fare il lavoro. Ciò dimostra rispetto per le loro conoscenze e competenze, nonché rispetto per il lavoro a un ritmo sostenibile ma porta al tempo stesso i membri del team ad assumersi la responsabilità delle stime fatte e decisioni prese
  • esaminando solo il prodotto “Fatto” in una Sprint Review, portiamo trasparenza ai nostri veri progressi. Ciò dimostra rispetto per i nostri stakeholder
  • un Product Owner richiede informazioni, collabora e stabilisce aspettative realistiche per gli stakeholder. Questa è un’altra dimostrazione di rispetto per gli stakeholder ed al contempo per il team
  • il focus dello Scrum Master è sulla salute dello Scrum Team e sull’uso efficace di Scrum. Avere un ruolo incentrato sull’insegnamento, la facilitazione e il coaching dimostra il rispetto per le persone e le squadre ed influisce sulla loro capacità di crescita
  • l’attenzione di Scrum sulla creazione di valore mostra rispetto per l’organizzazione all’interno della quale agisce il team facendo in modo di non spendere denaro per funzionalità di basso valore o cose che non potrebbero mai essere utilizzate
  • avere un Incremento potenzialmente rilasciabile entro la fine dello Sprint dimostra rispetto per l’organizzazione in cui si agisce offrendole la flessibilità necessaria per prendere decisioni critiche in fase di investimento delle risorse disponibili.

5 – APERTURA AL CAMBIAMENTO

Il TEAM e gli Stakeholder devono essere pronti ad accettare tutto il lavoro fatto e tutti i cambiamenti necessari affinché questo avvenga

L’approccio empirico alla base di Scrum (come di altre metodologie agili) richiede trasparenza ed apertura mentale, i progressi, la crescita ed i problemi del team sono fondamentali per guidare il cambiamente dentro e fuori il prodotto. Il team dovrebbe aprirsi per condividere discipline e competenze, per collaborare con le parti interessate e l’ambiente esterno, per condividere feedback e imparare gli uni dagli altri. 

Il framework Scrum include elementi che aiutano a promuovere l’apertura al cambiamento:

  • limitare uno Sprint a 30 giorni o meno promuove l’apertura a cambiare direzione in base a nuove informazioni
  • l’obiettivo dello Sprint è fisso e fornisce una guida, ma il piano per raggiungere l’obiettivo Sprint è aperto al cambiamento in base a ciò che il team di sviluppo sta imparando
  • un backlog di prodotto trasparente dimostra apertura con i nostri stakeholder su ciò che è pianificato per il prodotto (e ciò che non è pianificato) e su ciò che probabilmente sarà contenuto nel prossimo rilascio
  • la focalizzazione della Sprint Retrospective sul miglioramento continuo delle interazioni, dei processi e degli strumenti del nostro team invita ad un’apertura al feedback, alla riflessione e al cambiamento del modo in cui lavoriamo
  • la Sprint Review dimostra apertura alla condivisione dei progressi con i nostri stakeholder, nonché apertura al feedback e alla collaborazione con loro.

Le 3 Regole d’oro

Dopo questa lunga cavalcata su SCRUM, se sei arrivato fin qui direi che ti sei meritato un piccolo extra.

Quelle che troverai di seguito sono 3 regole d’oro che, a prescindere da come deciderai di declinare il tuo approccio a SCRUM, ti saranno sicuramente utili.

1 – Prioritizzare

E’ fondamentale stabilire la priorità delle User Story nel Product BACKLOG altrimenti il team si troverà in serie difficoltà nel valutare il lavoro da fare

Pensa sempre al Backlog come ad un repository di conoscenza condivisa all’interno del quale Scrum Master, Product Owner e Team members concorrono nella creazione di contenuti di valore e poi domandati: cosa ci può essere di maggior valore se non la prioritizzazione delle attività in un framework time boxed come SCRUM?

La domanda è retorica, ma sappi che spesso la capacità di stabilire le giuste priorità fa la differenza tra il successo ed il fallimento di un progetto.

2 – GOAL Definito

Non modificare lo SPRINT Goal durante il ciclo di SPRINT: si introdurranno bug e l’andamento dello sprint non sarà misurabile (causa mancanza di stime adeguate) 

Come avrai capito il tempo è una variabile fondamentale all’interno di SCRUM fa quindi qualsiasi cosa in tuo potere pur di non aggiungere attività non previste in fase di planning ad uno sprint in corso e, qualora non fosse possibile evitarlo, sarà sempre preferibile inserire queste attività nel backlog assegnando loro alta priorità e puntando magari a rimandare attività attualmente inserite nel planning così da concludere al più presto lo sprint in corso e passare ad un nuovo ciclo di iterazione in cui inserire sensatamente e logicamente questi nuovi task.

Lo so, ci sono alcuni casi in cui è proprio impossibile rispettare questa regola (un bug bloccante in produzione, una richiesta assolutamente improrogabile di un superiore, …). E’ però responsabilità di Scrum Master e Product owner mediare con gli altri stakeholder di progetto per ridurre al minimo possibile queste anomalie.

3 – TEAM Stabile

Non alterare il TEAM durante il ciclo di SPRINT, nuove risorse vanno affiancate ai membri del team perchè ne acquisiscono know how e convenzioni

Anche questa, se pure non ne abbia l’apparenza, è un regola finalizzata come tutto ad ottimizzare la gestione del tempo in SCRUM, introdurre nuove risorse durante uno sprint in corso può infatti rallentare il lavoro del resto del team o portare alla creazione di bug o malfunzionamenti dovuti alla scarsa esperienza del nuovo collaboratore rispetto al dominio di progetto.

Può sembrare assurdo ma la cosa più intelligente da fare in questi casi è lasciare uno o due sprint al nuovo arrivato per ambientarsi, facendolo lavorare in affiancamento ai membri più esperti del team così che abbia il tempo di formarsi autonomamente sul progetto diventando adeguatamente produttivo prima di essere effettivamente inserito nel ciclo di iterazioni dei successivi sprint.

Direi che è tutto, concludo citando un grande dell’imprenditoria e dell’innovazione come Henry Ford:

Ritrovarsi insieme è un inizio, restare insieme è un progresso, ma riuscire a lavorare insieme è un successo.“

– Henry Ford

bene, SCRUM non è altro che un ottimo metodo per lavorare bene insieme! 

Hai dubbi o vuoi dei chiarimenti? Lascia pure un commento o contattami senza problemi 🙂

Se ti è piaciuto l’articolo e pensi che possa interessare a un tuo collaboratore o a un tuo conoscente, condividilo pure senza alcuna remora

Condividi su facebook
Facebook
Condividi su twitter
Twitter
Condividi su linkedin
LinkedIn
Condividi su pinterest
Pinterest
Condividi su whatsapp
WhatsApp
Condividi su email
Email
Prenota ora 30 minuti di consulenza gratuita
Compila il modulo e scegli tu come e quando essere ricontattato

Lascia un commento

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

Cosa dicono i nostri clienti

Sede Legale
Via Giuseppe Orlandi n° 58, 70010, Turi (BA)

Sede Operativa – Torino
Via Abate Vassalli – Eandi, 26, 10138 Torino TO

© 2014 Rhubbit Srl | Tutti i diritti riservati | Privacy Policy
P.IVA/CF: 07616040726 | Capitale sociale 10.000 € n.i.v. | R.E.A. BA 570190

Prenota la consulenza gratuita

Invia Messaggio

Qual è tuo più grande problema aziendale che stai cercando di risolvere?

Ti invieremo una proposta commerciale volta alla sua risoluzione.
Non hai nulla da perdere

OFFERTA SPECIALE

Devi realizzare un'app di catalogo?

Approfitta dell’offerta speciale che abbiamo in serbo per te!
L’App nativa per Apple e Android al 50%!

Iscriviti ora all'unico corso gratuito in Italia sul mobile marketing

Riceverai le lezioni comodamente nella tua casella di posta elettronica e potrai contattare il docente in qualsiasi momento.

Iscriviti al corso gratuito di SCRUM!

Iscriviti ora all’unico corso gratuito esistente in rete su SCRUM.
Ricevi le lezioni comodamente in mail e se necessario fruisci del supporto del docente.

Avvia conversazione
Serve aiuto?
Ciao,
come posso esserti utile?