Gli "Eventi" del Processo Scrum PDF

**Gli "Eventi" del Processo Scrum** Esploriamo adesso le fasi del processo Scrum. Ci sono una serie specifica e immutabile di passaggi nel processo Scrum, che sono detti "Eventi". Gli eventi prescritti sono utilizzati in Scrum per creare regolarità e ridurre al minimo la necessità di incontri no...

**Gli "Eventi" del Processo Scrum** Esploriamo adesso le fasi del processo Scrum. Ci sono una serie specifica e immutabile di passaggi nel processo Scrum, che sono detti "Eventi". Gli eventi prescritti sono utilizzati in Scrum per creare regolarità e ridurre al minimo la necessità di incontri non definiti in Scrum. Tutti gli eventi sono a finestra temporare prefissata (time-boxed), così da avere una durata massima predefinita. Quando uno Sprint inizia, la sua durata è prefissata e non può essere né accorciata né allungata. Gli altri eventi possono invece terminare quando è raggiunto il loro scopo, assicurando che sia spesa l'appropriata quantità di tempo senza permettere sprechi all'interno del processo. Oltre allo stesso Sprint, che è un contenitore di tutti gli altri eventi, ogni evento in Scrum è una occasione formale per ispezionare e adattare qualcosa. Questi eventi sono specificamente progettati per consentire trasparenza critica e ispezione. La mancata inclusione di uno qualsiasi di questi eventi comporta una riduzione della trasparenza ed è un'occasione mancata per praticare l'ispezione e l'adattamento. **Lo Sprint** Il cuore del Framework Scrum è uno Sprint. Lo Sprint ha una durata massima di un mese o meno durante la quale viene creato un incremento di prodotto potenzialmente rilasciabile, utilizzabile e "Fatto". Gli Sprint hanno una durata costante durante il lavoro di sviluppo. Un nuovo Sprint si avvia immediatamente dopo la conclusione dello Sprint precedente. **Lo Sprint consiste e contiene:** lo Sprint Planning, il Daily Scrum, il lavoro di sviluppo, la Sprint Review e la Sprint Retrospective. Le regole dello Sprint, come abbiamo detto, sono piuttosto rigide per massimizzare l'efficienza del tempo e della collaborazione. Per questo motivo durante uno Sprint: - Non possono essere fatte modifiche che mettono a rischio lo Sprint Goal; - I Goal relativi alla qualità non devono degradarsi e, - L'Ambito (Scope) può essere chiarito e rinegoziato tra il Product Owner e il Development Team, quando si hanno maggiori elementi al riguardo. Ogni Sprint può essere considerato un progetto con un orizzonte non più lungo di un mese. Come i progetti, gli Sprint sono utilizzabili per realizzare qualcosa. Ogni Sprint ha una definizione di ciò che si va a costruire, un progetto e un piano flessibile che guideranno la costruzione, il lavoro svolto e il prodotto risultante. Gli Sprint sono limitati ad un mese di calendario. Quando uno Sprint ha un orizzonte temporale troppo lungo la definizione di ciò che viene costruito può cambiare e portare ad un aumento in termini di complessità e rischio. Gli Sprint migliorano la prevedibilità, assicurando che l'ispezione e l\'adattamento del progresso verso un obiettivo sono effettuati almeno una volta al mese. Gli Sprint inoltre limitano il rischio ad un mese di costo. **Cancellare uno Sprint** Uno Sprint può essere cancellato prima della scadenza del tempo massimo stabilito. Solo il Product Owner ha l'autorità di annullare lo Sprint, anche se può farlo anche sotto l'influenza degli stakeholder, del Team di Sviluppo o dello Scrum Master. Uno Sprint dovrebbe esser cancellato se lo Sprint Goal diventa obsoleto. Questo potrebbe verificarsi se l'organizzazione cambia direzione o se le condizioni di mercato o della tecnologia cambiano. In generale, uno Sprint deve essere annullato se non ha più senso date le circostanze. Ad ogni modo, data la breve durata dello Sprint, la sua cancellazione raramente ha senso. Quando uno Sprint è annullato, ogni elemento del Product Backlog già completato e "Fatto" è esaminato. Se parte del lavoro è potenzialmente rilasciabile il Product Owner tipicamente la accetta. Tutte le voci incomplete del Product Backlog sono nuovamente stimate e reinserite nel Product Backlog. Il lavoro svolto su di esse si deprezza rapidamente e deve essere frequentemente ristimato. Le cancellazioni degli Sprint consumano risorse, poiché tutti devono partecipare di nuovo ad un altro Sprint Planning Meeting per poterne cominciare un altro. Le cancellazioni degli Sprint sono spesso traumatiche per lo Scrum Team e sono molto rare **Sprint Planning** Il meeting di Sprint Planning è un incontro della durata massima di otto ore per uno Sprint di un mese. Per Sprint più brevi, l'evento è di solito più breve. Lo Scrum Master si assicura che l\'evento abbia luogo e che i partecipanti ne comprendano la finalità. Lo Scrum Master indica, spiega e, quando necessario, insegna allo Scrum Team come svolgerlo nel limite del tempo massimo. Il Meeting di Sprint Planning è guidato dalle seguenti domande e dalle risposte che in ogni progetto si formulano: Qual è lo Sprint Goal? Cosa può essere consegnato nell\'Incremento risultante dallo Sprint emergente? Come fare a mettere in opera il lavoro necessario a consegnare l\'Incremento? **[Primo Tema]: Cosa può essere fatto in questo Sprint?** Il Team di Sviluppo lavora per prevedere le funzionalità che saranno sviluppate durante lo Sprint. Il Product Owner discute l\'obiettivo al quale lo Sprint dovrebbe aspirare e gli elementi del Product Backlog che, se completati durante lo Sprint, permetterebbero di raggiungere lo Sprint Goal. L\'intero Scrum Team collabora per comprendere il lavoro dello Sprint. L'input per questo incontro sono il Product Backlog, l'ultimo Incremento del prodotto, la previsione di capacità del Team di Sviluppo durante lo Sprint e le performance registrate in passato del Team di Sviluppo. Il numero di elementi selezionati dal Product Backlog per lo Sprint è definito esclusivamente dal Team di Sviluppo. Soltanto il Team di Sviluppo è in grado di valutare cosa può compiere durante il prossimo Sprint. Dopo che il Team di Sviluppo ha previsto gli elementi del Product Backlog che consegnerà con lo Sprint, lo Scrum Team modella lo Sprint Goal. Lo Sprint Goal può creare quella coerenza nel lavoro del Team di Sviluppo che non sarebbe invece presente attraverso iniziative individuali senza un obiettivo comune. **[Secondo Tema:] Come si effettuerà il lavoro scelto?** Dopo aver creato lo Sprint Goal e selezionato gli elementi del Product Backlog per lo Sprint, il Team di Sviluppo decide come costruirà queste funzionalità in un Incremento "Fatto" del prodotto all'interno dello Sprint stesso. Le voci del Product Backlog selezionate per lo Sprint più il piano per la consegna definiscono lo Sprint Backlog. Il Team di Sviluppo di solito inizia con la progettazione del sistema e il lavoro necessario per convertire il Product Backlog in un incremento del prodotto. Il lavoro può essere di varia quantità o *effort* stimato. Tuttavia, una quantità sufficiente di lavoro è pianificata durante il meeting di Sprint Planning così da permettere al Team di Sviluppo di prevedere ciò che ritiene di poter fare nel prossimo Sprint. Prima della fine del meeting, il lavoro che il Team di Sviluppo ha pianificato per i primi giorni dello Sprint è suddiviso in unità della durata di un giorno o meno. Il Team di Sviluppo si autogestisce per intraprendere il lavoro contenuto nello Sprint Backlog, sia durante lo Sprint Planning Meeting che in qualunque altro momento necessario durante l'intero Sprint.