Scrum method.pptx
- 2. Le pratiche Scrum implicano la scoperta dei requisiti e lo sviluppo di soluzioni attraverso lo sforzo collaborativo di team auto-organizzati e interfunzionali e dei loro clienti / utenti finali. Sostiene la pianificazione adattiva, lo sviluppo evolutivo, la consegna precoce e il miglioramento continuo e incoraggia risposte flessibili al cambiamento. • Scrum Master • Product Owner • Scrum Team • Burndown chart • User stories • User story mapping • Story point estimation • Timeboxing • Continuous delivery • Daily Scrum • Definition of done (DoD) • Backlog refinement • Sprints SCRUM METODO SCRUM
- 3. 3 SCRU M Scrum è un framework che genera valore attraverso soluzioni adattive per problemi complessi. Il metodo Scrum richiede uno Scrum Master per promuovere un ambiente in cui: 1. Un Product Owner ordina il lavoro per un problema complesso in un Product Backlog. 2. Lo Scrum Team trasforma una selezione del lavoro in un incremento di valore durante uno Sprint. 3. Lo Scrum Team e i suoi stakeholder ispezionano i risultati e si adeguano per lo Sprint successivo. 4. Ripeti Scrum è costruito sull'intelligenza collettiva delle persone che lo utilizzano. Piuttosto che fornire alle persone istruzioni dettagliate, le regole di Scrum guidano le loro relazioni e interazioni. Scrum utilizza un approccio iterativo e incrementale per ottimizzare la prevedibilità e controllare il rischio. Il metodo coinvolge gruppi di persone che collettivamente hanno tutte le capacità e le competenze per svolgere il lavoro e condividere o acquisire tali competenze secondo necessità.
- 4. PILASTRI DEL METODO TRASPARENZA Il processo e il lavoro che ne deriva devono essere visibili a coloro che eseguono il lavoro e a coloro che ricevono il lavoro. ISPEZIONE Gli artefatti di Scrum e i progressi verso gli obiettivi concordati devono essere ispezionati frequentemente per rilevare variazioni o problemi ADATTAMENTO Se alcuni aspetti di un processo si discostano da limiti accettabili o se il prodotto risultante è inaccettabile, il processo applicato o i materiali prodotti devono essere adattati. 1/7/20XX 4
- 5. 5 Adattamento 03 • Il processo o il materiale in lavorazione devono essere regolati se un'ispezione determina che uno o più aspetti di un processo si discostano da limiti accettabili e il prodotto risultante sarà inaccettabile. • Pianificazione dello sprint • Mischia giornaliera • Revisione dello sprint • Retrospettiva Sprint Ispezione 02 • Gli utenti Scrum devono ispezionare frequentemente gli artefatti di Scrum e progredire verso un obiettivo Sprint. • Le ispezioni non dovrebbero essere così frequenti da intralciare il lavoro. • Le ispezioni sono più efficaci se eseguite diligentemente da ispettori qualificati sul luogo di lavoro. Trasparenza 01 • Gli aspetti principali del processo devono essere definiti da uno standard comune. • Un linguaggio comune che si riferisce al processo deve essere condiviso da tutti i partecipanti. • Una definizione comune di "Fatto" per coloro che eseguono il lavoro e accettano il prodotto di lavoro. PILASTRI DEL METODO
- 6. 6 ELEMENTI SCRUM Scrum Sprint è un time-box fisso ripetibile durante il quale viene creato un prodotto "Done" del più alto valore possibile. Lo Sprint è al centro della metodologia Scrum e può essere pensato come un evento che racchiude tutti gli altri eventi Scrum come Daily Scrums, Scrum Review e Sprint Retrospective. Di solito, uno Sprint dura un mese o meno. Iterazione corrente. Implementazione di un pacchetto di lavoro. Durata fissa (timeboxed). Risultati in un risultato intermedio funzionale. Sprint Elenco dei requisiti per il nuovo prodotto. Modificabile e adattabile in ogni momento. I requisiti sono classificati in ordine di priorità e suddivisi in pacchetti di lavoro. Product backlog Il team presenta il risultato intermedio al Product owner e alle parti interessate. Il feedback viene incorporato nello sprint successivo. Sprint review meeting Riunione giornaliera di 15 minuti. Incontro informativo. Ogni membro del team spiega su cosa sta lavorando al momento. Daily Scrum Meeting Suddivisione del pacchetto di lavoro in pacchetti più piccoli. Assegnandoli ai membri del team. Documentazione del lavoro rimanente per ogni pacchetto. Sprint backlog Pacchetto di lavoro che non viene modificato durante lo sprint. Risultato intermedio funzionale (incremento della funzionalità potenzialmente spedibile). Increment
- 7. 7 Product Owner Development Team Scrum Master Una persona responsabile della massimizzazione del valore del prodotto e del lavoro del team di sviluppo (Product Backlog e gestione delle priorità). Composto da professionisti che svolgono il lavoro per consegnare un prodotto potenzialmente rilasciabile "Fatto" alla fine di ogni Sprint, auto-organizzante, cross- funzionale. Una persona che si assicura che Scrum sia compreso e messo in atto, organizza riunioni e monitora tutto. SCRUM TEAM
- 8. 8 Product Owner Development Team Scrum Master Organization • Coaching nell'auto-organizzazione e nel lavoro di squadra e rimozione degli impedimenti dal team di sviluppo. • Aiuta il team di sviluppo a creare prodotti di alto valore. • Facilita l'implementazione di Scrum. • Trovare tecniche per una gestione efficace del Product Backlog. • Aiutare il team Scrum a comprendere la necessità di elementi Product Backlog chiari e concisi. • Facilita l'implementazione di Scrum. • Guidare e istruire l'organizzazione nella sua adozione di Scrum, pianificando l'implementazione di Scrum all'interno dell'organizzazione. • Aiutare i dipendenti e le parti interessate a comprendere e attuare Scrum e lo sviluppo di prodotti empirici. SCRUM TEAM
- 9. 9 Scrum Master Roles Apprendimento e scambio Supporto Scrum master roles Supervisionare Riunioni e l’applicazione dei principi Scrum Pianificazione del rilascio Attività di team building Definizione di Done (DoD) Mediare e risolvere i conflitti Aiuta il team a eliminare gli ostacoli Riparare la squadra dagli ostacoli esterni Autonomia del team Trasparenza e apertura Flessibilità Comunicazione faccia a faccia Monitoraggio e tracciamento (Grafico burndown e schede di stato) Reportistica gestionale, feedback sulle prestazioni e miglioramento dei processi Gestione dello strumento Scrum
- 10. 10 Scrum Process Update Product Backlog Sprint Planning Meeting Daily Scrum/ Work Product Increment Sprint Review Sprint Retrospective Release N Sprint Cycle Sprint 1, 2, 3, N Scrum Master Team Members Stakeholder Users Product Owner Product Backlog Sprint Backlog Burndown Product Backlog Burndown Impediment List Sprint Backlog Product Backlog Delta Report • Raccogliere e filtrare le esigenze dell’utente • Crea stories • Backlog iniziale del prodotto • Assembla il team Preparazione Scrum Artifacts Release Stockholders Product vision Project definition Contractual Agreement Initial release plan Product Owner Product Owner Scrum Roles PROCESSO SCRUM
- 11. FASE 0 Identificazione del cliente e delle esigenze il team di sviluppo si incontra con il cliente per capire le sue esigenze e i suoi requisiti. In questa fase, è importante stabilire una buona comunicazione e fare domande per capire le necessità del cliente. Creazione del Product Backlog in base alle informazioni raccolte nella fase precedente, il Product Owner crea una lista di elementi prioritari da sviluppare, chiamata Product Backlog. Il Product Owner, che rappresenta il cliente, è responsabile della definizione delle priorità dei singoli elementi. 11 Definizione del team di sviluppo in questa fase, il team di sviluppo viene formato, con l'inclusione di tutti i membri necessari per la realizzazione del progetto. Il team dovrebbe includere le competenze tecniche necessarie, ma anche competenze come la gestione del progetto e la comunicazione con il cliente. Pianificazione della Sprint il team di sviluppo si prepara per la sprint, stabilendo gli obiettivi da raggiungere durante la sprint e pianificando il lavoro da svolgere. Solo dopo aver completato queste fasi, il team di sviluppo può passare alla fase di lavoro
- 12. Product Backlog Management Stockholders Product Owner Raccogliere e filtrare le esigenze del mercato dagli stakeholder / Crea stories Release Planning Release Backlog Management Release 1 Release 2 Release N Una volta comprese le esigenze del cliente, il team di sviluppo può iniziare a creare le Epic e le User Stories. Le Epic rappresentano le funzionalità di alto livello richieste dal cliente e possono essere divise in User Stories, cioè descrizioni più specifiche e dettagliate delle funzionalità richieste. FASE 0 La creazione delle User Stories prevede generalmente i seguenti passaggi da parte del PO: 1. Identificazione utenti che utilizzeranno il prodotto e le loro esigenze specifiche. 2. Creazione schemi di flusso che descrivono come gli utenti utilizzeranno il prodotto. 3. Sulla base delle informazioni raccolte nei passaggi precedenti, il PO crea le User Stories che descrivono le funzionalità specifiche del prodotto. Le User Stories sono solitamente scritte in un formato semplice e comprensibile, ad esempio "Come utente, voglio essere in grado di effettuare un ordine online, in modo da poter acquistare i prodotti desiderati in modo rapido e semplice". In questo modo, le User Stories aiutano a razionalizzare le funzionalità dal punto di vista dell'utente finale, in modo che il team di sviluppo possa concentrarsi su ciò che è veramente importante per gli utenti e creare un prodotto che soddisfi le loro esigenze.
- 13. La priorità delle User Stories è basata sul valore che esse offrono al cliente e sull'urgenza delle loro esigenze. Il Product Owner valuta le User Stories in base alle necessità del cliente e le assegna una priorità relativa rispetto alle altre User Stories nel Product Backlog. In questo modo, il team di sviluppo può concentrarsi sulla realizzazione delle funzionalità più importanti per il cliente in primo luogo. Ogni User Story viene tradotta in uno o più elementi del Product Backlog, che definiscono i requisiti dettagliati per la loro implementazione FASE 0 Il team di sviluppo può utilizzare una tecnica chiamata "story points" per stimare il tempo e lo sforzo necessari per completare ciascuna User Story. Lo Story Point è una stima relativa dell'effort richiesto per implementare una User Story, basata su fattori come la complessità, il rischio e la conoscenza necessaria per completare la User Story. In questo aspetto entra in gioco l’esperienza passata del team. Nella metodologia Scrum, la priorità di ogni User Story viene definita dal Product Owner, che rappresenta il cliente e ha la responsabilità di definire le priorità delle User Stories nel Product Backlog.
- 14. Funzionalità 1 User Stories User Stories User Stories User Stories User Stories User Stories User Stories Funzionalità 2 User Stories User Stories User Stories User Stories User Stories Funzionalità 3 User Stories User Stories USER STORIES Sprint 1 Sprint 2 Sprint n Priorità
- 15. J F M A M J J A S O N D J F M A M J J A S O N D S1 S2 S3 S4 S5 S6 S7 S8 S9 Project #01 Project #02 Project #03 2021 2021 Agile roadmap Text Placeholder Text Placeholder Text Placeholder Text Placeholder Text Placeholder Text Placeholder Text Placeholder Text Placeholder Text Placeholder Text Placeholder Text Placeholder Text Placeholder Text Placeholder Text Placeholder Text Placeholder Text Placeholder Text Placeholder Text Placeholder Text Placeholder
- 16. # Task Responsible Start Finish Days Status Sprint I 28 Complete 1 Feature: placeholder text Anny Fry 01.02 12.02 11 Complete 2 Feature: placeholder text Max Factor 13.02 16.02 3 Complete 3 Feature: placeholder text Antony Stark 17.02 02.03 14 Complete Sprint II 19 In progress 4 Feature: placeholder text Mary Freeman 03.03 05.03 2 Complete 5 Feature: placeholder text Helen Lee 05.03 20.03 15 In progress 6 Feature: placeholder text Hu Chan 20.03 22.03 2 In progress Sprint III 25 Not started 7 Feature: placeholder text Anny Fry 22.03 01.04 10 Not started 8 Feature: placeholder text Mary Freeman 01.04 10.04 9 Not started 9 Feature: placeholder text Antony Stark 10.04 16.04 6 Not started Agile project plan table
- 17. Scrum and Agile board To Do’s Card with placeholder text Card with placeholder text Card with placeholder text Card with placeholder text Card with placeholder text Card with placeholder text Card with placeholder text Doing Card with placeholder text Card with placeholder text Card with placeholder text Card with placeholder text Card with placeholder text Card with placeholder text Card with placeholder text Card with placeholder text Done Card with placeholder text Card with placeholder text Card with placeholder text Card with placeholder text Card with placeholder text
- 18. 1.Il Product Owner (PO) si incontra con il cliente per comprendere le esigenze del prodotto e definire la visione del prodotto. 2.Il PO, in collaborazione con il cliente, definisce le Epic, ovvero grandi funzionalità o obiettivi del prodotto. 3.Il PO, in collaborazione con il cliente, identifica le User Stories, ovvero funzionalità specifiche del prodotto raccontate dal punto di vista dell'utente finale. 4.Il PO valuta le User Stories in base alle necessità del cliente e le assegna una priorità relativa rispetto alle altre User Stories nel Product Backlog. 5.Il team di sviluppo stimava il tempo e lo sforzo necessari per completare ciascuna User Story utilizzando la tecnica dei "story points". 6.Il PO, in collaborazione con il cliente e il team di sviluppo, traduce le User Stories in elementi del Product Backlog, che è una lista prioritizzata di tutte le funzionalità che il team di sviluppo dovrà implementare. 7.Il team di sviluppo, in collaborazione con il PO, seleziona un insieme di elementi del Product Backlog da implementare durante la Sprint successiva. 8.Durante la Sprint, il team di sviluppo sviluppa le funzionalità selezionate sotto la supervisione del PO. 9.Il team di sviluppo si incontra quotidianamente nel Daily Scrum per condividere informazioni sul lavoro svolto e sul lavoro previsto, individuando eventuali problemi e discutendo su come risolverli. 10.Alla fine della Sprint, il team di sviluppo presenta le funzionalità sviluppate durante la Sprint al PO e al cliente, ricevendo un feedback sul lavoro svolto durante il Sprint Review. 11.Il team di sviluppo riflette sulla Sprint appena conclusa durante la Sprint Retrospective, identificando eventuali problemi e discutendo su come migliorare per la prossima Sprint. 12.Il PO aggiorna il Product Backlog, includendo eventuali nuove User Stories o modificando le priorità esistenti, in base al feedback ricevuto dal cliente e alle riflessioni fatte dal team di sviluppo durante la Sprint Retrospective. 13.Il processo si ripete con una nuova pianificazione della Sprint, selezionando nuove User Stories dal Product Backlog e avviando la successiva
- 19. I ruoli Scrum includono: •Il Product Owner: responsabile della definizione della visione del prodotto, della gestione del Product Backlog e della priorizzazione delle User Stories. •Il team di sviluppo: responsabile dell'implementazione delle funzionalità selezionate durante la Sprint. •Il Master Scrum: responsabile di facilitare il processo Scrum, rimuovere gli eventuali impedimenti, assicurare che il team segua le regole Scrum e che le pratiche Scrum siano applicate correttamente. I prodotti Scrum includono: •Il Product Backlog: una lista prioritizzata di tutte le funzionalità che il team di sviluppo dovrà implementare. Il Sprint Backlog: la lista degli elementi del Product Backlog selezionati dal team di sviluppo per la Sprint corrente. •Incremento: il prodotto funzionante e testato alla fine di ogni Sprint.
- 20. Gli eventi Scrum includono: •Sprint Planning: il primo evento della Sprint, in cui il PO e il team di sviluppo collaborano per definire gli obiettivi della Sprint e selezionare le User Stories da implementare. •Daily Scrum: una breve riunione giornaliera durante la Sprint, in cui il team di sviluppo discute del lavoro svolto e del lavoro previsto, identifica eventuali problemi e pianifica le azioni da intraprendere per risolverli. •Sprint Review: un evento alla fine della Sprint, in cui il team di sviluppo presenta al PO e al cliente le funzionalità sviluppate durante la Sprint, ricevendo feedback e suggerimenti per migliorare. •Sprint Retrospective: un evento alla fine della Sprint, in cui il team di sviluppo riflette sul lavoro svolto durante la Sprint e identifica eventuali problemi e miglioramenti da apportare al processo Scrum. Dopo la Sprint Retrospective, il processo si ripete con una nuova pianificazione della Sprint, selezionando nuove User Stories dal Product Backlog e avviando la successiva Sprint. Il ciclo Scrum continua fino a quando il prodotto non è stato sviluppato e testato fino al punto di soddisfare le esigenze del cliente, o quando il progetto viene interrotto.