Blog Scrum

In questo articolo parleremo di quali siano gli elementi costitutivi di un framework Scrum tradizionale con l’aiuto della Guida a Scrum e di David West, CEO di Scrum.org.Includeremo anche esempi di come i nostri clienti personalizzano questi elementi fondamentali in base alle proprie esigenze specifiche.

Il framework

Spesso si pensa che Scrum e Agile siano la stessa cosa, perché Scrum è incentrato sul miglioramento continuo, che è un principio fondamentale di Agile. Tuttavia, Scrum è in realtà un framework che consente di eseguire il lavoro, mentre Agile è una mentalità. “Diventare Agile” non è in realtà semplice perché è necessaria la dedizione di tutto il team per cambiare il modo di fornire valore ai clienti. Tuttavia, puoi utilizzare un framework come Scrum per iniziare ad adottare questo tipo di approccio mentale e a mettere in pratica la creazione di principi Agile nella comunicazione e nel lavoro quotidiano.

Scrum è un framework euristico: si basa sull’apprendimento continuo e l’adattamento a fattori variabili. Tiene conto del fatto che il team non dispone di tutte le conoscenze all’inizio di un progetto e che si evolverà man mano che acquisisce esperienza. Scrum è strutturato per aiutare i team ad adattarsi in modo naturale alle mutevoli condizioni ed esigenze degli utenti, con una ridefinizione delle priorità integrata nel processo e cicli di rilascio brevi che consentono al team di imparare e migliorare costantemente.

Sebbene sia strutturato, il framework Scrum non è del tutto rigido. La sua esecuzione può essere adattata alle esigenze di qualsiasi organizzazione. Ci sono molte teorie sul modo esatto in cui i team Scrum devono operare per avere successo. Tuttavia, dopo oltre dieci anni in cui abbiamo aiutato i team Agile a svolgere il lavoro in Atlassian, abbiamo imparato che la comunicazione chiara, la trasparenza e la dedizione al miglioramento continuo devono sempre rimanere al centro di qualsiasi framework con cui scegli di lavorare. E il resto dipende da te.

Artefatti Scrum

Iniziamo con l’identificazione dei tre artefatti Scrum. Gli artefatti indicano qualcosa che creiamo, come uno strumento per risolvere un problema. In Scrum, questi tre artefatti sono il backlog di prodotto, il backlog dello sprint e un incremento con la definizione di “Completato”.

In un team Scrum sono le tre costanti che continuiamo a rivedere e in cui continuiamo a investire nel corso del tempo.

• Il backlog di prodotto è l’elenco principale dei lavori che devono essere eseguiti ed è mantenuto dall’owner di prodotto o dal responsabile di prodotto. Si tratta di un elenco dinamico di funzioni, requisiti, miglioramenti e correzioni che funge da input per il backlog dello sprint. È, essenzialmente, l’elenco delle cose “da fare” del team. Il backlog di prodotto è costantemente rivisto, modificato in termini di priorità e gestito dall’owner di prodotto perché, man mano che acquisiamo maggiori conoscenze o il mercato cambia, gli elementi potrebbero non essere più pertinenti o i problemi potrebbero essere risolti in altri modi.
• Il backlog dello sprint è l’elenco di elementi, storie utente o correzioni di bug selezionati dal team di sviluppo per l’implementazione nel ciclo di sprint corrente. Prima di ogni sprint, nella riunione di pianificazione dello sprint (di cui parleremo più avanti nell’articolo) il team sceglie dal backlog di prodotto gli elementi su cui lavorerà per lo sprint. Un backlog dello sprint può essere flessibile ed evolversi durante uno sprint. Tuttavia, l’obiettivo fondamentale dello sprint, cioè quello che il team desidera ottenere dallo sprint corrente, non può cambiare.
• L’incremento (o obiettivo dello sprint) è il prodotto finale utilizzabile di uno sprint. In Atlassian, di solito forniamo una dimostrazione dell’incremento durante la demo di fine sprint, in cui il team illustra quali elementi dello sprint sono stati completati. È possibile che la parola “incremento” ti risulti nuova, poiché è spesso utilizzata per indicare la definizione di “completato”, di milestone raggiunta, di obiettivo dello sprint o persino una versione completa o un epic rilasciato. Tutto dipende solo dal modo in cui i tuoi team definiscono il concetto di “completato” e da come tu definisci gli obiettivi dello sprint. Ad esempio, alcuni team scelgono di effettuare dei rilasci parziali per i propri clienti alla fine di ogni sprint. Quindi la loro definizione di “completato” sarebbe in realtà quello di “rilasciato”. Questa definizione, tuttavia, potrebbe non essere realistica per altri tipi di team. Se, ad esempio, lavori su un prodotto basato su server che può essere rilasciato ai clienti solo ogni trimestre, potresti comunque scegliere di lavorare in sprint di due settimane, ma la tua definizione di “completato” potrebbe essere la parte finale di una versione più ampia che prevedi di rilasciare in seguito. Ovviamente, maggiore è il tempo necessario per rilasciare il software, più alto è il rischio che il software manchi il bersaglio.

Come puoi immaginare, ci sono molte varianti, anche all’interno degli artefatti, che il tuo team può scegliere di definire. Ecco perché è importante rimanere aperti riguardo al modo in cui gestisci anche i tuoi stessi artefatti. Forse la tua definizione di “completato” espone il tuo team a un inutile stress; in tal caso, devi tornare indietro e scegliere una nuova definizione.SUGGERIMENTO

L’approccio che adotti verso il tuo framework dovrebbe essere altrettanto Agile di quello che adotti verso il prodotto. Prenditi il tempo necessario per capire come stanno andando le cose, apporta le modifiche necessarie e non forzare le cose solo per motivi di coerenza.

Cerimonie o eventi Scrum

Alcuni dei componenti più noti del framework Scrum sono gli eventi sequenziali, le cerimonie o le riunioni che i team Scrum eseguono regolarmente. Le cerimonie rappresentano gli eventi in cui le divergenze di opinioni dei team si manifestano in misura maggiore. Ad esempio, alcuni team ritengono che tante cerimonie siano ingombranti e ripetitive, mentre altri le usano come uno strumento di controllo necessario. Il nostro consiglio è di iniziare a utilizzare tutte le cerimonie per due sprint e valutare i risultati. Puoi quindi eseguire una retrospettiva rapida per capire quali correzioni apportare.

Di seguito è riportato un elenco di tutte le cerimonie chiave a cui un team Scrum potrebbe partecipare:

1. Organizzazione del backlog: a volte noto come backlog grooming, questo evento rientra nell’ambito delle responsabilità dell’owner di prodotto, il cui compito principale è di favorire l’attuazione della vision del prodotto e avere un quadro costante del mercato e del cliente. Pertanto, l’owner di prodotto gestisce questo elenco utilizzando il feedback degli utenti e del team di sviluppo per definire le priorità e mantenere l’elenco pulito e pronto per essere utilizzato in qualsiasi momento. Puoi leggere ulteriori informazioni su come gestire un backlog efficace qui.
2. Pianificazione dello sprint: il lavoro da eseguire (ambito) durante lo sprint corrente è pianificato durante questo incontro dall’intero team di sviluppo, che è guidato dallo Scrum Master e nell’ambito del quale il team decide l’obiettivo dello sprint. Le story d’uso specifiche vengono quindi aggiunte allo sprint dal backlog di prodotto. Queste story sono sempre allineate all’obiettivo e sono anche concordate dal team Scrum affinché possano essere implementate durante lo sprint. Al termine della riunione di pianificazione, ogni membro del team Scrum deve avere ben chiaro ciò che può essere consegnato nello sprint e in che modo può essere consegnato l’incremento.
3. Sprint: uno sprint è il periodo di tempo effettivo in cui il team Scrum collabora per completare un incremento. In genere lo sprint ha una durata di due settimane, anche se alcuni team ritengono che una settimana sia sufficiente per definire l’ambito, mentre un mese è considerato un periodo adeguato per consegnare un incremento importante. Dave West, di Scrum.org, ritiene che più il lavoro è complesso e il numero di incognite elevato, minore dovrebbe essere la durata dello sprint. In realtà la scelta dipende sostanzialmente dalle preferenze del team e se la durata scelta non funziona, non esitare a cambiarla! Durante questo periodo, l’ambito può essere nuovamente negoziato tra l’owner di prodotto e il team di sviluppo, se necessario. È questo l’aspetto cruciale della natura empirica di Scrum. Tutti gli eventi, dalla pianificazione alla retrospettiva, avvengono durante lo sprint. Una volta stabilito un certo intervallo di tempo per uno sprint, questo deve rimanere coerente per tutto il periodo di sviluppo. Ciò consente al team di imparare dalle esperienze passate e di applicare gli insegnamenti acquisiti agli sprint futuri.
4. Scrum giornaliero o riunione stand-up giornaliera: si tratta di una riunione quotidiana estremamente breve che, per praticità, avviene sempre alla stessa ora (di solito al mattino) e nello stesso luogo. Molti team cercano di completare l’incontro in 15 minuti, ma questa tempistica è solo indicativa. Questa riunione è anche definita “riunione stand-up quotidiana” per sottolineare il fatto che deve essere rapida. L’obiettivo dello Scrum quotidiano è di assicurarsi che tutti i membri del team siano allineati all’obiettivo dello sprint e di definire un piano per le prossime 24 ore La riunione stand-up rappresenta il momento in cui vengono espresse tutte le preoccupazioni riguardo al raggiungimento dell’obiettivo dello sprint o a eventuali bloccanti. Un modo comune per condurre una riunione stand-up è di chiedere a ogni membro del team di rispondere a tre domande riguardanti il raggiungimento dell’obiettivo sprint: • Cosa ho fatto ieri? • Cosa ho intenzione di fare oggi? • Ci sono ostacoli? Tuttavia, spesso la riunione si trasforma in una lettura rapida del calendario del giorno precedente e di quello successivo da parte dei membri del team. La riunione stand-up poggia su una teoria: limitare il più possibile le chiacchiere e far sì che il team possa concentrarsi sul lavoro per il resto della giornata. Pertanto, se diventa una lettura giornaliera del calendario, non esitare a cambiarla in nuovi modi creativi.
5. Revisione dello sprint: alla fine dello sprint, il team si riunisce per una sessione informale allo scopo di visualizzare una demo o ispezionare l’incremento. Il team di sviluppo mostra gli elementi del backlog con lo stato “Completato” agli stakeholder o ai membri del team con lo scopo di ricevere un feedback. L’owner di prodotto può decidere se rilasciare o meno l’incremento, anche se nella maggior parte dei casi l’incremento viene rilasciato. La riunione di revisione avviene anche quando l’owner di prodotto modifica il backlog di prodotto in base allo sprint corrente, che può essere incluso nella prossima sessione di pianificazione dello sprint. Per uno sprint di un mese, il timebox per la revisione dello sprint dovrebbe essere di massimo quattro ore.
6. Retrospettiva dello sprint: la retrospettiva è il momento in cui team si riunisce per documentare e discutere cosa ha funzionato e cosa non ha funzionato in uno sprint, in un progetto, tra le persone o nell’ambito di relazioni, strumenti o anche per determinate cerimonie. L’idea è quella di creare una situazione in cui il team possa concentrarsi sugli aspetti positivi e sulle aree di miglioramento per il futuro, mettendo in secondo piano ciò che non è andato per il verso giusto.

Tre ruoli essenziali per il successo del team Scrum

Un team Scrum ha bisogno di tre ruoli specifici: owner di prodotto, Scrum Master e team di sviluppo. Inoltre, poiché i team Scrum sono interfunzionali, il team di sviluppo include non solo sviluppatori ma anche tester, progettisti, esperti in interfaccia utente e tecnici operativi.

L’owner di prodotto Scrum

Gli owner di prodotto sono i promotori dei loro prodotti. Sono concentrati sulla comprensione delle esigenze aziendali, dei clienti e del mercato, quindi definiscono le priorità del lavoro che deve essere svolto dal team di progettazione. Gli owner di prodotto efficaci:

• Creano e gestiscono il backlog di prodotto.
• Collaborano a stretto contatto con l’azienda e il team per garantire che tutti comprendano gli elementi del lavoro nel backlog di prodotto.
• Forniscono al team indicazioni chiare su quali funzionalità fornire in futuro.
• Decidono quando rilasciare il prodotto, con una predisposizione verso una distribuzione più frequente.

L’owner di prodotto non sempre coincide con il responsabile di prodotto. Gli owner di prodotto hanno principalmente il compito di garantire che il team di sviluppo offra il massimo valore all’azienda. Inoltre, è importante che l’owner di prodotto sia una sola persona. A nessun team di sviluppo piace avere indicazioni contrastanti da parte di più owner di prodotto.

Lo Scrum Master

Gli Scrum Master sono i promotori delle attività Scrum nell’ambito dei propri team. Affiancano i team, gli owner di prodotto e l’azienda sul processo Scrum e si adoperano per perfezionarne le prassi.

Uno Scrum Master efficace ha una comprensione profonda del lavoro svolto dal team e può aiutarlo a ottimizzare la trasparenza e il flusso di consegna. In qualità di capo facilitatore, pianifica le risorse necessarie (sia umane che logistiche) per la pianificazione dello sprint, la riunione stand-up, la revisione dello sprint e la retrospettiva dello sprint.

Il team di sviluppo Scrum

I team Scrum sono sempre operativi. Sono i promotori delle pratiche di sviluppo sostenibile. I team Scrum più efficaci sono affiatati, ubicati nello stesso luogo e in genere includono da cinque a sette membri. Per stabilire le dimensioni ottimali del team un metodo utile è quello della famosa “regola delle due pizze” coniata da Jeff Bezos, CEO di Amazon, secondo la quale per sfamare un qualsiasi team in azienda non dovrebbero essere necessarie più di due pizze.

I membri del team hanno competenze diverse, ma condividono le proprie conoscenze in modo che nessuno possa diventare un collo di bottiglia nella consegna del lavoro. I team Scrum solidi si organizzano in modo autonomo e affrontano i progetti con un evidente spirito collaborativo. Tutti i membri del team si aiutano a vicenda per garantire il completamento efficace dello sprint.

Il team Scrum guida il piano per ogni sprint. Prevede la quantità di lavoro che ritiene di poter completare nel corso dell’iterazione utilizzando come linea guida la propria velocity storica. Mantenere una durata fissa dell’iterazione offre al team di sviluppo un feedback importante sul processo di stima e consegna, il che a sua volta rende le previsioni sempre più accurate nel corso del tempo.

Scrum, Kanban e Agile

Scrum è un framework Agile talmente diffuso che le due metodologie sono spesso erroneamente considerate uguali. Tuttavia, esistono altri framework, come Kanban, che è un’alternativa molto diffusa. Alcune aziende scelgono persino di seguire un modello ibrido Scrum e Kanban, che ha acquisito il nome di “Scrumban” o di “Kanplan”, che è Kanban con un backlog. Sia Scrum che Kanban utilizzano metodi visivi come la board Scrum o la board Kanban per monitorare lo stato di avanzamento del lavoro. Entrambi mettono in primo piano l’efficienza e suddividono task complessi in elementi di lavoro di minori dimensioni e più gestibili, ma gli approcci adottati verso il raggiungimento di tale obiettivo sono diversi. Scrum si focalizza su iterazioni più piccole di durata fissa. Una volta definito il periodo di tempo per uno sprint, vengono quindi determinate le story o gli elementi del backlog di prodotto che possono essere implementati durante questo ciclo di sprint. In Kanban, invece, il numero di task o il lavoro in corso (limite WIP) da implementare nel ciclo corrente è fissato all’inizio. Il tempo necessario per implementare queste funzioni viene quindi calcolato in modo retrospettivo. Kanban non è così strutturato come Scrum. Fatta eccezione per il limite WIP, è abbastanza aperto all’interpretazione. Scrum, tuttavia, presenta diversi concetti categorici applicati nell’ambito della sua implementazione, come la revisione degli sprint, la retrospettiva, lo Scrum quotidiano e così via. Inoltre, insiste sull’aspetto dell’interfunzionalità, che è la capacità di un team Scrum di non dipendere da membri esterni per raggiungere i propri obiettivi. Creare un team interfunzionale non è semplice. In questo senso, Kanban è più facile da adattare, mentre il framework Scrum può essere considerato come un cambiamento fondamentale nel processo di pensiero e nel funzionamento di un team di sviluppo.

Perché utilizzare il framework Scrum?

In sé il framework Scrum è semplice. Le regole, gli artefatti, gli eventi e i ruoli sono facili da capire. Il suo approccio semiprescrittivo contribuisce realmente a eliminare le ambiguità nel processo di sviluppo, offrendo allo stesso alle aziende un tempo sufficiente per le personalizzazioni.

La possibilità di organizzare task complessi in storie utente gestibili lo rende ideale per i progetti difficili. Inoltre, la demarcazione chiara dei ruoli e degli eventi pianificati garantisce trasparenza e ownership collettiva nel corso dell’intero ciclo di sviluppo. Grazie alla rapidità dei rilasci, che permette di vedere in poco tempo i progressi compiuti, il team è sempre motivato e gli utenti sono soddisfatti.

Tuttavia, la comprensione del framework Scrum in tutti i suoi aspetti potrebbe richiedere del tempo, soprattutto se il team di sviluppo è abituato a un tipico modello a cascata. I concetti di iterazioni più piccole, riunioni Scrum quotidiane, revisioni di sprint e identificazione di uno Scrum Master potrebbero comportare un cambiamento culturale impegnativo per un nuovo team.

Tuttavia, i vantaggi a lungo termine hanno un peso notevolmente maggiore rispetto alla curva iniziale di apprendimento. I risultati offerti da Scrum nello sviluppo di prodotti hardware e software complessi in diversi settori e verticali lo rendono un framework di grande interesse per la tua organizzazione.