scrum artifacts product backlog
Introduzione agli artefatti Scrum:
Negli articoli precedenti di questa serie, ci è stato presentato agile e le diverse metodologie agili . Abbiamo anche appreso come le varie metodologie sono diverse a modo loro.
Nel nostro ultimo tutorial, siamo entrati nei dettagli di Scrum dove abbiamo discusso del Ruoli di Scrum come Product Owner, Scrum Master e il team di Scrum e hanno visto quali erano le loro responsabilità individuali.
In questo tutorial, continuiamo con Scrum e ci spostiamo ulteriormente nei dettagli sui diversi artefatti di Scrum.
Cosa imparerai:
- Diversi artefatti di Scrum
- Backlog di prodotto
- Sprint Backlog
- Incrementi di prodotto
- Conclusione
- Lettura consigliata
Diversi artefatti di Scrum
3 tipi di artefatti di mischia includono:
- Backlog di prodotto
- Sprint backlog e
- Incrementi di prodotto
Ora vedremo cosa significano questi termini e come creare questi artefatti.
Backlog di prodotto
Per dirla in termini semplici, un backlog di prodotto è un elenco di tutte le cose che sono richieste nel prodotto. È il documento finale a cui fa riferimento il team di Scrum per qualsiasi cosa relativa al prodotto. È un elenco ordinato di articoli di proprietà del Product Owner (PO).
L'OP è responsabile della creazione, del mantenimento e dell'assegnazione di priorità a questo elenco. I PO utilizzano questo backlog del prodotto per spiegare ai team di mischia i requisiti principali che devono essere soddisfatti durante lo sprint.
Gli elementi in questo elenco possono essere o meno in un linguaggio tecnico. Può anche essere un linguaggio per profani, ma dovrebbe contenere tutti i requisiti del prodotto e le relative modifiche. Inoltre, avere un backlog di prodotto non significa che il team di Scrum avrà solo questo artefatto da seguire.
Possono creare i propri artefatti dettagliati ma questi non contraddicono o sostituiscono il backlog del prodotto. Saranno piuttosto in linea con i requisiti del backlog di prodotto.
Di seguito è riportato un esempio di come può apparire un tipico backlog di prodotto:
| Storia | Stima | Priorità |
|---|---|---|
| Voglio accedere | 4 | 1 |
| Voglio disconnettermi | Due | Due |
| Voglio cambiare la password | 1 | 3 |
| Voglio aggiornare l'indirizzo | 3 | 4 |
| Voglio aggiungere un nuovo numero di telefono di casa | 1 | 5 |
Questo ci porta alla domanda, come creare un buon backlog di prodotto?
Un backlog di prodotto dovrebbe idealmente seguire le seguenti regole:
(i) Dovrebbe avere la priorità - Gli articoli nel backlog del prodotto devono essere ordinati secondo la loro priorità. Questa priorità può essere decisa insieme dal PO e dal team di mischia. I fattori di prioritizzazione possono essere un vantaggio simile al punto della storia, all'impegno richiesto nella creazione, alla complessità, alla priorità del cliente ecc.
Aiuta il team a capire cosa deve essere consegnato prima.
(ii) Dovrebbe essere stimato - Le storie dovrebbero sempre essere stimate secondo la definizione concordata, qualunque essa sia. Questo può essere utilizzato anche per la definizione delle priorità.
(iii) Dovrebbe essere di alto livello - Le storie nel backlog del prodotto devono essere di alto livello e non dovrebbero entrare nei dettagli. La creazione di user story dettagliate secondo il requisito spetta al team di Scrum e non al PO.
(iv) Dovrebbe essere dinamico - Il backlog del prodotto non è un documento statico finale. Dovrebbe essere rivisitato quando il PO riceve input dal team di Scrum e le esigenze del cliente diventano sempre più chiare. Pertanto, i requisiti del documento non vengono congelati all'inizio perché sono previste aggiunte / cancellazioni / modifiche man mano che il progetto procede.
L'ultimo punto è il più rilevante. Lo scopo di un backlog di prodotto è quello di essere una fonte attiva di requisiti. Non deve essere creato all'inizio e poi conservato in un luogo di archiviazione.
Invece, è pensato per essere condiviso ancora e ancora mentre i cambiamenti continuano a verificarsi. Man mano che si procede, potrebbero emergere nuovi requisiti e ciò potrebbe cambiare anche la priorità degli elementi del backlog. Ci saranno situazioni in cui un nuovo requisito dipende da un altro elemento nel backlog, quindi la priorità dell'articolo potrebbe dover essere rimescolata.
Oppure potrebbe esserci una user story critica che potrebbe dover essere implementata per prima perché il cliente vuole vederla prima degli altri anche se potrebbe non essere prioritaria secondo i fattori decisi dal PO e dal team di Scrum.
Pertanto, il backlog del prodotto è un elenco ordinato di requisiti aziendali di proprietà del PO e visitato più e più volte man mano che il progetto procede.
Sprint Backlog
Potresti ricordare che i team di mischia lavorano in brevi iterazioni di 2-4 settimane chiamate sprint. Durante questi sprint, il team di Scrum identifica gli elementi dal backlog del prodotto creato dal PO, che intende consegnare come parte della successiva iterazione. Gli elementi su cui il team di mischia sceglie di lavorare diventano parte dello sprint backlog.
Così decidono quali funzionalità saranno presenti nella prossima iterazione del prodotto. Il team di mischia è quello che decide cosa andrà nello sprint backlog in quanto sono loro che ci lavoreranno.
Quindi sono loro che dovrebbero valutare lo sforzo necessario per implementare quelle storie e decidere quanto possono offrire.
Il team non solo sceglie gli elementi dal backlog del prodotto su cui lavorare, ma fornisce anche una stima del tempo necessario per sviluppare quella funzionalità. Inoltre si aggiungono alle storie degli utenti di alto livello creando attività dettagliate necessarie per raggiungere l'obiettivo dello sprint.
dove guardare anime gratis online
Il team di mischia può anche continuare ad aggiornare lo sprint backlog come e quando richiesto durante lo sprint, ma è solo il team di mischia che può apportare modifiche allo sprint backlog.
Un tipico Sprint Backlog avrà l'aspetto mostrato di seguito.
Il team può idealmente aggiornarlo una volta al giorno e lo scrum master può utilizzare queste informazioni per creare un grafico di burndown dello sprint. Questo grafico di burndown aiuterà il team a vedere quanto lavoro è ancora rimasto per lo sprint e il team può pianificare il proprio lavoro di conseguenza. Possono anche aggiungere o rimuovere attività se necessario.
Alcune best practice durante la creazione di uno sprint backlog possono essere:
# 1) Prendi decisioni di gruppo - Non dovrebbe essere lo scrum master o qualsiasi altro membro del team di scrum a decidere il backlog. Piuttosto, dovrebbe essere l'intero team a decidere insieme quali elementi includere nello sprint backlog e come pianificarli.
Ogni membro di questo team interfunzionale porta le proprie capacità ed è essenziale che utilizziamo la loro esperienza per creare il miglior backlog possibile.
# 2) Non assegnare attività - Poiché è stato ripetuto più volte nella letteratura agile, non assegnare mai compiti ai membri del team. Un team di scrum dovrebbe essere autosufficiente e dovrebbe sapere come organizzare il proprio lavoro da solo.
Quindi, invece di assegnare il lavoro, dovremmo lasciare che il team scelga il lavoro da solo e decida tra loro su come procedere.
# 3) Definizione di fatto - Non dovrebbe essere solo concordato dagli stakeholder, ma anche essere reso chiaramente visibile al team in tutti i punti ogni volta che devono prendere una decisione in merito agli obiettivi dello sprint. Questo servirà come promemoria di ciò che deve essere fatto esattamente prima che possano consegnare un prodotto funzionante per la spedizione.
# 4) Continua ad aggiornare il backlog - È fondamentale che man mano che lo sprint si evolve, il team acquisisca una maggiore comprensione e quindi dovrebbe aggiornare di conseguenza lo sprint backlog per riflettere anche questa maggiore comprensione. Non dovrebbe diventare in nessun momento un documento statico.
# 5) Aggiungi qualsiasi attività - L'attività non deve essere solo correlata alla codifica, ma potrebbe essere essenziale per fornire un prodotto spedibile. Quindi menziona anche tali compiti nel backlog.
Incrementi di prodotto
Questo ci porta all'ultimo artefatto di mischia che è l'incremento del prodotto. Come definito dalla guida Scrum, un Incremento è la somma di tutti i Elementi del Product Backlog completato durante a Sprint e il valore degli incrementi di tutti gli Sprint precedenti. Come ormai sappiamo bene, Scrum è un processo iterativo.
Il risultato di ogni iterazione è questo incremento di prodotto e ogni incremento di prodotto di questo tipo aiuta il team a fare un passo avanti verso la consegna del prodotto finale.
Ciò significa che qualunque sia stato il risultato dello sprint è un incremento. Ovviamente, affinché il risultato sia considerato un incremento, dovrebbe prima soddisfare la definizione predefinita di fatto, ovvero il risultato finale dovrebbe essere un prodotto utilizzabile che è in grado di 'spedire'.
Può essere controllato, utilizzato e testato per garantire che sia effettivamente 'fatto' come da definizione e, se il Product Owner lo desidera, può anche essere rilasciato per essere pubblicato.
La cosa più importante per fornire questo incremento di prodotto è avere una comprensione condivisa della 'definizione di fatto' che è compresa da tutti.
Il team di mischia non dovrebbe mai avere dubbi sul fatto che ciò che sta facendo sarà accettato o meno. In caso di dubbio, la definizione di done dovrebbe essere sufficientemente completa da guidarli su come procedere ulteriormente. Basandosi solo su questa definizione, il team di Scrum decide quanti elementi del backlog di prodotto scegliere per lo sprint.
Questo è il minimo come ci si aspetta dallo sprint.
Conclusione
Da questo tutorial, abbiamo capito quali sono i 3 artefatti di Scrum, chi li possiede insieme ad alcune delle migliori pratiche che ci aiuterebbero a creare artefatti di migliore qualità. Nei prossimi tutorial di questa serie, discuteremo degli eventi Scrum e vedremo come eseguirli.
Nel nostro prossimo tutorial su 'Scrum Eventi , 'Discuteremo dettagliatamente ogni evento Scrum!
Tutorial PREV | PROSSIMO Tutorial
Lettura consigliata
- Eventi Scrum: Time Boxing, Sprint Planning, Daily Stand-up e Backlog Refinement
- Ruoli e responsabilità dello Scrum Team: Scrum Master e Product Owner
- Tutorial JIRA Scrum Board: Gestione di Scrum con Jira per la gestione dello Sprint
- Quiz online su Agile Scrum: prova la tua conoscenza di Agile Scrum
- Ruolo degli analisti aziendali in SCRUM e perché un QA è il migliore per questo ruolo?
- Valutazione dei difetti in Scrum: come è organizzata in un setup di Scrum
- Esempi di report di bug per applicazioni Web e di prodotto
- I 9 migliori software PLM del 2021 per gestire il ciclo di vita del prodotto