Close

Che cos'è Scrum e come iniziare

Guida Scrum - Che cos'è, come funziona e come iniziare

Esplora argomenti
Freccia agile

Inizia gratuitamente con il modello Scrum di Jira

Semplifica il progetto e pianifica, monitora e gestisci facilmente il lavoro tra uno sprint e l'altro. Il modello Scrum di Jira include board, backlog, roadmap, report e molto altro ancora!

Usa modello

Che cos'è Scrum?

Scrum è un framework di gestione dei progetti Agile che aiuta i team a organizzare e gestire il proprio lavoro utilizzando una serie di valori, principi e pratiche. Proprio come una squadra di rugby (da cui proviene il nome Scrum, mischia) che si allena per un grande evento sportivo, il framework Scrum incoraggia i team a imparare attraverso l'esperienza, a organizzarsi in modo autonomo mentre lavorano su un problema e a riflettere sui risultati conseguiti e sugli insuccessi per migliorare continuamente.

Sebbene il framework Scrum sia utilizzato più frequentemente dai team di sviluppo software, i suoi principi e insegnamenti possono essere applicati a tutti i tipi di lavoro in team. Questo è uno dei motivi per cui è così diffuso. Spesso considerato come un framework di gestione dei progetti Agile, Scrum descrive in realtà una serie di riunioni, strumenti e ruoli che lavorano di concerto per aiutare i team a strutturare e gestire il loro lavoro.

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.A tale scopo, Megan Cook, Group Product Manager per Jira Software ed ex coach Agile, fornirà consigli e trucchi nella nostra serie di video Il Coach Agile:

Articoli Scrum

[CONTINUA]

Agile e Scrum a confronto

Le persone spesso pensano che Scrum e Agile siano la stessa cosa perché Scrum è incentrato sul miglioramento continuo, che è un principio fondamentale di Agile. Tuttavia, Scrum è un framework per portare a termine il lavoro, mentre Agile è una filosofia. La filosofia Agile è incentrata sul miglioramento incrementale continuo attraverso rilasci piccoli e frequenti. Non puoi davvero «diventare Agile», poiché ci vuole la dedizione di tutto il team per cambiare il modo in cui pensano a come offrire valore ai clienti. Puoi, però, usare un framework come Scrum per iniziare a pensare in modo Agile ed esercitarti a integrare i principi Agile nei flussi di comunicazione e di lavoro quotidiani.

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.

Un diagramma del framework di Scrum

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 framework di Scrum

Il framework Scrum delinea una serie di valori, principi e pratiche che i team Scrum seguono per fornire un prodotto o un servizio. Descrive i membri del team e le loro responsabilità, gli "artefatti" che definiscono e contribuiscono a creare il prodotto, nonché le cerimonie Scrum che guidano il team nel lavoro.

I membri di un team Scrum

Un team Scrum è una squadra snella e agile che si occupa di fornire incrementi di prodotto mirati. Le dimensioni del team Scrum sono in genere ridotte, circa 10 persone, ma sufficienti per completare una notevole quantità di lavoro in un solo sprint. 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 è il product manager. Gli owner di prodotto si concentrano sul garantire che il team di sviluppo offra il massimo valore all'azienda. Inoltre, è importante che l'owner di prodotto sia una persona fisica. Nessun team di sviluppo desidera una guida mista 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 nel 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 cui per sfamare un qualsiasi team 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 essere d'ostacolo 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.

Artefatti Scrum

Gli artefatti Scrum sono informazioni importanti utilizzate dal team Scrum che aiutano a definire il prodotto e il lavoro da svolgere per crearlo. I tre artefatti Scrum sono il backlog di prodotto, il backlog dello sprint e l'incremento rispetto alla definizione di "completato", e rappresentano i concetti cardine sui quali un team Scrum dovrebbe riflettere durante gli sprint e nel tempo.

  • 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.

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

Il framework Scrum include le prassi, le cerimonie o le riunioni che i team Scrum eseguono regolarmente. Le cerimonie Agile 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 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 analizzare l'incremento. Il team di sviluppo mostra gli elementi di backlog completati alle parti interessate e ai membri del team per ottenere un feedback. L'owner di prodotto può decidere se rilasciare o meno l'incremento, sebbene nella maggior parte dei casi venga rilasciato.

    Questa riunione di revisione è anche il momento in cui l'owner di prodotto rielabora il backlog di prodotto in base allo sprint corrente, che può alimentare la prossima sessione di pianificazione dello sprint. Per uno sprint di un mese, valuta la possibilità di prolungare la tua revisione dello sprint a un massimo di 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.

Freccia agile

Inizia gratuitamente con il modello Scrum di Jira

Semplifica il progetto e pianifica, monitora e gestisci facilmente il lavoro tra uno sprint e l'altro. Il modello Scrum di Jira include board, backlog, roadmap, report e molto altro ancora!

Valori Scrum

Nel 2016, abbiamo aggiunto cinque valori Scrum alla Guida Scrum. Questi valori forniscono indicazioni per il lavoro, le azioni e il comportamento del team Scrum e sono fondamentali per il successo del team.

Impegno preso

Poiché i team Scrum sono di ridotte dimensioni, ogni membro del team svolge un ruolo significativo per il conseguimento degli obiettivi. Pertanto, ciascun membro del team deve farsi carico soltanto dei task che sa di poter completare e comunicare con frequenza le informazioni sull'avanzamento del lavoro, ad esempio durante le riunioni stand-up.

Coraggio

Un team Scrum deve avere il coraggio di mettere in discussione lo status quo o tutto ciò che ostacola il successo. I membri del team Scrum non devono temere di sperimentare nuove soluzioni, e devono essere messi nelle condizioni di farlo. È necessario che si sentano liberi di essere trasparenti in merito a ostacoli, avanzamento dei progetti, ritardi e così via.

Focus

Il fulcro del flusso di lavoro è lo sprint, un periodo di tempo mirato e specifico in cui il team Scrum deve completare una determinata quantità di lavoro. Lo sprint crea una certa struttura e agevola la concentrazione necessaria per completare la mole di lavoro pianificata.

Apertura

La riunione stand-up quotidiana promuove un ambiente aperto che consente ai team di discutere liberamente del lavoro in corso e degli ostacoli. I team Scrum di Atlassian rispondono spesso a queste domande:

  • Su cosa ho lavorato ieri?
  • Su cosa lavorerò oggi?
  • Quali problemi stanno bloccando il mio lavoro?

Questo approccio aiuta a mettere in evidenza i progressi, identificare i bloccanti e creare un momento di condivisione che rafforza il team.

Rispetto

La forza di un team Agile risiede nella collaborazione e nel riconoscere che ogni membro del team contribuisce allo sprint. Tutti i partecipanti si congratulano per i risultati altrui e rispettano i colleghi, l'owner di prodotto, gli stakeholder e lo Scrum Master.

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.

Iniziare a utilizzare 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.

Per imparare a usare Scrum con Jira Software, dai un'occhiata a questo tutorial.

Claire Drumond
Claire Drumond

Claire Drumond è una marketing strategist, relatrice e scrittrice per Atlassian. Inoltre, è autrice di numerosi articoli pubblicati sui blog di Trello e Atlassian e una contributrice attiva di varie pubblicazioni su Medium, tra cui HackerNoon, Art+Marketing e PoetsUnlimited. Partecipa come relatrice a conferenze tecnologiche in tutto il mondo su agile, analisi dei silos e sviluppo dell'empatia.

Freccia agile

Inizia gratuitamente con il modello Scrum di Jira

Semplifica il progetto e pianifica, monitora e gestisci facilmente il lavoro tra uno sprint e l'altro. Il modello Scrum di Jira include board, backlog, roadmap, report e molto altro ancora!

Usa modello
Prossimo contenuto
Sprint