Tutorial Scrum
In questo tutorial ti forniremo istruzioni dettagliate su come condurre un progetto Scrum, assegnare priorità e organizzare il backlog in sprint, eseguire le cerimonie Scrum e altro ancora, il tutto all'interno di Jira.
Durata lettura:
Tempo di lettura: 10 minuti. Da completare nel corso di 2 settimane
Destinatari:
Nuovi utenti di Scrum, dello sviluppo software Agile o di Jira
Prerequisito:
Aver creato un account Jira
Scrum è uno dei framework più popolari per l'implementazione di Agile. Con Scrum, un prodotto viene creato con una serie di iterazioni di lunghezza fissa chiamate sprint, che offrono ai team Agile un framework per rilasci eseguiti a cadenza regolare.
Passaggio 1. Creazione di un progetto Scrum
Dopo aver creato un account in Jira e aver effettuato l'accesso, puoi selezionare un modello dalla raccolta. Seleziona Scrum (puoi vedere in anteprima il modello Scrum gratuito qui oppure puoi scoprire come creare un progetto Kanban qui).
Successivamente, ti verrà chiesto di scegliere un tipo di progetto. Se il tuo team lavora in modo indipendente e desidera controllare i tuoi processi e le tue pratiche di lavoro in uno spazio autonomo, prova il nostro modello Scrum gestito dal team. Per ulteriori informazioni, consulta la Guida introduttiva ai progetti gestiti dal team nella Atlassian Community.
Una volta creato il progetto, visualizzerai un backlog vuoto. Il backlog è noto anche come backlog di prodotto e contiene un elenco in corso dei potenziali elementi di lavoro del team per il progetto.
Passaggio 2. Creazione di storie utente o task nel backlog
In Jira, gli elementi di lavoro come storie utente, task e bug sono definiti "ticket". Crea alcune storie utente con l'opzione di creazione rapida nel backlog. Se non hai idee per delle storie utente, crea storie di esempio per iniziare e vedere come funziona il processo.
Le storie utente vengono utilizzate per descrivere gli elementi di lavoro in un linguaggio non tecnico e dal punto di vista dell'utente. Come {tipo di utente}, voglio {obiettivo} in modo da {vantaggio}.
Usiamo un sito web come semplice esempio per creare una storia utente.
Come cliente, voglio poter creare un account in modo da poter vedere i miei acquisti precedenti.
Le storie utente vengono generalmente delineate e classificate in ordine di priorità dall'owner di prodotto; successivamente, il team di sviluppo determina i task dettagliati che sono necessari per completare la story in uno sprint imminente. Il team di sviluppo è anche responsabile della stima dell'impegno relativo necessario per completare il lavoro della story.
Dopo aver creato alcune storie utente, puoi iniziare a definirne la priorità nel backlog. In Jira, è possibile classificare o assegnare priorità alle story trascinandole e rilasciandole nell'ordine in cui dovrebbero essere elaborate.
Queste sono solo le story di partenza per il progetto. Continuerai a creare story per tutta la durata del progetto. Questo perché l'agilità implica l'apprendimento e l'adattamento continui.
Passaggio 3. Creazione di uno sprint
Crea il tuo primo sprint nel backlog in modo da poter iniziare a pianificare lo sprint.
In Scrum, i team prevedono di completare una serie di storie utente o altri elementi di lavoro durante un periodo di tempo prestabilito, noto come sprint. In generale, gli sprint durano una, due o quattro settimane. Spetta al team stabilire la durata di uno sprint: consigliamo di iniziare con due settimane. È un periodo sufficiente per ottenere dei risultati, ma non così lungo da impedire al team di ricevere un feedback regolare. Una volta determinata la cadenza dello sprint, il team lavora perennemente in base a tale cadenza. Gli sprint a lunghezza fissa rafforzano le competenze di stima e prevedono la velocity futura del team nella conduzione delle attività del backlog.
Passaggio 4. Conduzione della riunione di pianificazione dello sprint
All'inizio di uno sprint, dovresti condurre la relativa riunione di pianificazione con gli altri membri del team. La riunione di pianificazione dello sprint è una cerimonia che consente a tutto il team di prepararsi per ottenere risultati positivi durante lo sprint. In questa riunione, l'intero team discute l'obiettivo dello sprint e le story nel backlog di prodotto prioritario. Il team di sviluppo crea task e stime dettagliate per le story con priorità elevata. Il team di sviluppo si impegna quindi a completare un certo numero di story nello sprint. Queste story e il piano per completarle diventano ciò che è noto come backlog dello sprint.
Aggiungi le stime degli Story Point alle story aggiungendo un numero nel campo Stima degli Story Point. Puoi anche aggiungere ulteriori dettagli alle story o cliccare sull'icona Crea sottotask per suddividere ulteriormente il lavoro della story.
Quando sei pronto, trascina nello sprint che hai appena creato le story concordate nella riunione di pianificazione dello sprint. Questo è il backlog dello sprint.
Partecipanti obbligatori: team di sviluppo, Scrum Master, owner di prodotto
Quando: all'inizio di uno sprint.
Durata: di solito due ore a settimana di iterazione; ad esempio, uno sprint di due settimane inizia con una riunione di pianificazione di quattro ore. La riunione termina quando il suo scopo è stato raggiunto.
Scopo: pianificare il lavoro dello sprint. Il team concorda con l'obiettivo dello sprint e il backlog dello sprint.
Quando si crea uno sprint, l'owner di prodotto di solito identifica un obiettivo dello sprint, che fornisce un tema per il lavoro da completare nello sprint. Un obiettivo dello sprint offre anche una certa flessibilità nel numero di story completate in uno sprint. Uno sprint è considerato riuscito se il suo obiettivo viene raggiunto.
I team software tradizionali forniscono stime in un formato temporale costituito da giorni, settimane, mesi.
Molti team Agile, tuttavia, sono passati agli Story Point. Gli Story Point valutano l'impegno relativo del lavoro, spesso in un formato simile alla successione di Fibonacci: 0, 0,5, 1, 2, 3, 5, 8, 13, 20, 40, 100.
Le stime ti aiutano a valutare la quantità di lavoro che dovresti aggiungere allo sprint successivo in base al numero di membri del team di cui disponi. Dopo alcuni sprint, il tuo team migliorerà la propria capacità di comprendere quanto lavoro può compiere in ogni sprint e quest'informazione sarà utile per evitare di assumere impegni eccessivi.
Passaggio 5. Avvio dello sprint in Jira
Assegna un nome allo sprint. Alcuni team assegnano allo sprint un nome corrispondente all'obiettivo dello sprint. Se è presente un tema comune tra i ticket nello sprint, assegna un nome che richiami quel tema. Diversamente, assegna allo sprint il nome che preferisci.
Aggiungi la durata dello sprint e le date di inizio e di fine. Le date di inizio e di fine devono essere allineate alla programmazione del team. Ad esempio, alcuni team iniziano gli sprint di lunedì e li terminano il venerdì mattina della settimana successiva. Altri team decidono di iniziare e terminare gli sprint a metà settimana. Sta a te decidere! Se hai dei dubbi su quale dovrebbe essere la durata degli sprint, ti consigliamo di provare con un periodo di due settimane.
Aggiungi l'obiettivo dello sprint come concordato nella riunione di pianificazione dello sprint.
Una volta iniziato lo sprint, verrai indirizzato alla scheda Sprint attivi nel progetto.
È qui che il team sposterà gli elementi di lavoro dalla colonna Da completare alla colonna In corso e, infine, alla colonna Completato!
Se utilizzi il modello Scrum gestito dal team, questo verrà chiamato Board.
Passaggio 6. Conduzione delle riunioni stand-up giornaliere
Dopo l'inizio dello sprint, chiedi al team di riunirsi quotidianamente, di preferenza al mattino, per esaminare ciò su cui ogni persona sta lavorando. Lo scopo è capire se ci sono persone nel team che stanno incontrando ostacoli al completamento dei task dello sprint.
Partecipanti (principalmente): team di sviluppo
Quando: una volta al giorno, in genere al mattino
Durata: non più di 15 minuti. Non prenotare una sala conferenze e conduci la riunione in piedi. Stare in piedi è utile per non allungare la riunione!
Scopo: la riunione stand-up giornaliera è pensata per informare rapidamente tutti riguardo a ciò che sta accadendo a livello di team e pianificare il lavoro della giornata. Non si tratta di una riunione completa sullo stato. Il tono dovrebbe essere leggero e divertente, ma informativo. Chiedi a ogni membro del team di rispondere alle seguenti domande:
- Cosa ho completato ieri?
- Su cosa lavorerò oggi?
- Sono bloccato da qualcosa?
C'è una responsabilità implicita nel rendere conto del lavoro completato il giorno precedente davanti ai colleghi. Nessuno vuole essere il membro del team che fa costantemente la stessa cosa senza fare progressi.
Suggerimento: alcuni team utilizzano dei timer per tenere tutti in linea con i tempi. Altri si lanciano a vicenda una palla per assicurarsi che tutti prestino attenzione. Molti team distribuiti utilizzano videoconferenze o chat di gruppo per ridurre le distanze. Il tuo team è unico e dovrebbe esserlo anche la tua riunione stand-up!
Puoi utilizzare gli sprint attivi della board Scrum durante la riunione stand-up giornaliera, in modo che ogni membro possa vedere le attività su cui sta lavorando.
Passaggio 7. Visualizzazione del grafico burn-down
Durante uno sprint è utile controllare il grafico burn-down. In Jira, questo grafico mostra la quantità di lavoro effettiva e stimata da svolgere in uno sprint. Il grafico burn-down viene aggiornato automaticamente da Jira man mano che completi gli elementi di lavoro. Per visualizzare questo grafico, clicca su Report nella barra laterale, quindi seleziona Grafico burn-down dall'elenco a discesa dei report.
Il grafico burn-down epic mostra la quantità effettiva e stimata di lavoro da svolgere in uno sprint o epic. L'asse delle x orizzontale del grafico burn-down indica il tempo, mentre l'asse delle y verticale indica gli Story Point.
Utilizza un grafico burn-down per tenere traccia del lavoro totale rimanente e per fare una previsione sulla probabilità di raggiungere l'obiettivo dello sprint. Monitorando il lavoro rimanente durante l'iterazione, il team può gestire l'avanzamento e agire di conseguenza.
- Il team conclude ogni sprint in anticipo perché non si impegna abbastanza nel lavoro.
- Il team non rispetta la previsione di ogni sprint perché si impegna troppo nel lavoro.
- La linea di burn-down fa cali ripidi piuttosto che un burn-down più graduale perché il lavoro non è stato scomposto in porzioni granulari.
- L'owner di prodotto aggiunge o modifica l'ambito a metà sprint.
Passaggio 8. Visualizzazione del report sprint
In qualsiasi momento durante o dopo lo sprint, puoi visualizzare il report sprint per monitorare lo sprint.
Il report sprint include il grafico burn-down ed elenca il lavoro completato, il lavoro non completato e l'eventuale lavoro aggiunto dopo l'inizio dello sprint.
Passaggio 9. Conduzione della riunione di revisione dello sprint
The sprint review, or sprint demo, is a sharing meeting where the team shows what they've shipped in that sprint. Each sprint usually produces a working part of the product called an increment.
Questa è una riunione con molti feedback sul progetto e include una sessione di brainstorming per decidere cosa fare dopo.
Partecipanti (principalmente): team di sviluppo, Scrum Master, owner di prodotto.
Partecipazione facoltativa per: stakeholder
Quando: in genere l'ultimo giorno dello sprint
Durata: in genere due ore per uno sprint di due settimane
Scopo: ispezionare l'incremento e aggiornare in modo collaborativo il backlog di prodotto.
Domande da porsi:
- Il team ha rispettato la previsione dello sprint?
- A metà sprint è stato aggiunto o rimosso del lavoro?
- Ci sono dei lavori che non sono stati completati nel periodo dello sprint?
- In tal caso, per quali motivi?
Passaggio 10. Conduzione della riunione retrospettiva sprint
Dopo aver completato lo sprint, chiedi al team di condurre una retrospettiva e documentala in una posizione di tua scelta. Noi ti consigliamo di utilizzare Confluence.
Partecipanti: team di sviluppo, Scrum Master, owner di prodotto.
Quando: al termine di un'iterazione.
Durata: in genere 90 minuti per uno sprint di due settimane.
Scopo: il team effettua un'ispezione su se stesso e sui propri processi, strumenti e interazioni. I ticket di miglioramento vengono spesso aggiunti al backlog dello sprint successivo.
Le retrospettive non rappresentano solo l'occasione per esporre le proprie lamentele senza agire. Usale per scoprire cosa funziona in modo che il team possa continuare a concentrarsi su quelle aree, ma anche per scoprire cosa non funziona e usare il tempo a disposizione per trovare soluzioni creative e sviluppare un piano d'azione. Il miglioramento continuo è ciò che sostiene e guida lo sviluppo all'interno di un team Agile e le retrospettive ne sono una parte fondamentale.
Domande da porsi:
- Cosa è andato bene durante lo sprint?
- Cosa poteva andare meglio?
- Quali aree cercheremo di migliorare la prossima volta?
Suggerimento: anche se le cose stanno andando bene a livello di intero team, continua a condurre le retrospettive, perché forniscono al team una guida continua per continuare a far andare bene le cose.
Passaggio 11. Completamento dello sprint in Jira
Quando lo sprint termina, devi completarlo.
Se lo sprint presenta ticket non completati,m puoi:
- Spostare i ticket nel backlog.
- Spostare i ticket in uno sprint futuro.
- Sposta i ticket in un nuovo sprint, che Jira creerà per te.
Passaggio 12. Ripetizione dal passaggio 2
A questo punto, hai le basi che ti servono per creare il backlog con le storie utente, organizzare le storie utente in sprint, iniziare lo sprint e organizzare cerimonie Scrum. Puoi decidere se questi contenuti vanno bene per il tuo team o se preferisci passare ad alcuni argomenti più avanzati.
Dopo aver completato i passaggi precedenti insieme al tuo team, passa all'articolo avanzato: Apprendimento delle pratiche di Scrum avanzato con Jira.
