Scrum

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à. La filosofia Agile è incentrata sul miglioramento continuo e incrementale attraverso rilasci piccoli e frequenti. "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.

La differenza tra Agile e Scrum e la definizione di Scrum sono illustrate nella Guida Scrum e nel Manifesto Agile. Il Manifesto Agile evidenzia quattro valori:

• Gli individui e le interazioni più che i processi e gli strumenti
• Il software funzionante più che la documentazione esaustiva
• La collaborazione col cliente più che la negoziazione dei contratti
• Rispondere al cambiamento più che seguire un piano

La definizione di Scrum si basa sull'empirismo e sul pensiero Lean. L'empirismo afferma che la conoscenza deriva dall'esperienza e che le decisioni vengono prese in base a ciò che si osserva. Il pensiero Lean riduce gli sprechi e si concentra sull'essenziale. Scrum è un framework euristico: si basa sull'apprendimento continuo e sull'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.

• Il backlog di prodotto è l'elenco principale dei lavori che devono essere eseguiti ed viene redatto 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 viene 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.

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 svolgere (ambito) durante lo sprint corrente è pianificato nel corso di questa riunione dall'intero team di sviluppo. Questo incontro è guidato dallo Scrum Master ed è il momento in cui il team decide l'obiettivo dello sprint. Le storie utente specifiche vengono quindi aggiunte allo sprint dal backlog di prodotto. Queste storie sono sempre in linea con l'obiettivo e sono anche concordate dal team Scrum per essere fattibili da implementare durante lo sprint.
   
   Al termine della riunione di pianificazione, ogni membro del team Scrum deve sapere con chiarezza cosa può essere rilasciato nello sprint e come l'incremento può essere rilasciato.

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 sull'obiettivo dello sprint e di definire un piano per le 24 ore successive.
   
   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 diffuso per condurre una riunione stand-up è di chiedere a ogni membro del team di rispondere a tre domande riguardanti il raggiungimento dell'obiettivo dello sprint:
   
   • Cosa ho fatto ieri?
   • Cosa ho intenzione di fare oggi?
   • Sto riscontrando eventuali 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.