<inserisci il tuo nome> Introduzione a Scrum https://www.mountaingoatsoftware.com/agile/scrum/resources/a-reusable-scrum-presentation If you'd like to provide a new translation of this agile PowerPoint presentation, please email it to hello@mountaingoatsoftware.com <inserisci il tuo nome> <data>

Introduzione a Scrum Presenta <nome> <data>

Stiamo perdendo la staffetta Hirotaka Takeuchi e Ikujiro Nonaka, “The New New Product Development Game”, Harvard Business Review, Gennaio 1986. “Lo sviluppo di un prodotto con l’approccio «a staffetta» … può entrare in contrasto con l’obiettivo di massimizzare velocità e flessibilità. Invece un approccio olistico tipo “rugby”— in cui il team cerca di avanzare come gruppo, passando la palla avanti e indietro—potrebbere essere più adatto ai requisiti competitive odierni.” would be nice to include a quote from Wicked Problems here

Scrum in 100 parole Scrum è un processo agile che permette di focalizzarci sulla consegna del massimo valore di business nel minor tempo possibile. Scrum ci permette di verificare rapidamente e ripetutamente il software funzionante (da ogni 2 settimane a ogni mese). Il business definisce le priorità. Il team si auto-organizza per trovare il modo migliore per consegnare le funzionalità a più alto valore. Ogni due settimane o un mese chiunque può vedere un vero software funzionante e decider se rilasciarlo agli utenti o continuare a migliorarlo per un altro ciclo.

Origini di Scrum Jeff Sutherland Ken Schwaber Mike Beedle Nel 1993 gestisce i primi scrums in Easel Corp IDX e 500+ persone a fare Scrum Ken Schwaber ADM Insieme a Sutherland presenta Scrum a OOPSLA 95 Autore di 3 libri su Scrum Mike Beedle Pubblicazione “Scrum patterns in PLOPD4” Ken Schwaber and Mike Cohn Co-fondatori di Scrum Alliance nel 2002, inizialmente all’interno di Agile Alliance

Chi ha usato Scrum fino ad oggi: Microsoft Yahoo Google Electronic Arts High Moon Studios Lockheed Martin Philips Siemens Nokia Capital One BBC Intuit Intuit Nielsen Media First American Real Estate BMC Software Ipswitch John Deere Lexis Nexis Sabre Salesforce.com Time Warner Turner Broadcasting Oce

Quando è stato usato Scrum: Software commerciale Sviluppo interno Sviluppo a contratto Progetti a costo fisso Applicazioni finanziarie Applicazioni c ertificate (ISO 9001) Sistemi integrati (embedded) Sistemi ad alta affidabilità (24x7 99.99% funzionamento) Avionica per caccia militari Sviluppo video giochi Sistemi salvavita (US FDA) Sistemi controllo satelliti Siti web Applicazioni mobile Formware smartphone Sistemi controllo traffic Internet Applicazioni ISV Alcune delle più grandi applicazioni oggi in uso

Caratteristiche Gruppi di lavoro auto-organizzati Prodotti il cui sviluppo è in una progressione in cicli (sprint) Requisiti sono definiti come micro-elementi in una lista (product backlog) Non ci sono particolari pratiche da seguire Si basa su un approccio adattativo per creare un ambiente agile per realizzare progetti Uno dei “framework agile””

Agile Manifesto – una serie di valori Processi e strumenti Individui e interazioni su Documentazione esaustiva Software funzionante su Negoziazione di un contratto Collaborazione col Cliente su Seguire un piano Rispondiere al cambiamento su Origine: www.agilemanifesto.org

Il “rumore” in un progetto Disaccordo Anarchia Complesso Requisiti Complicato Strategic Management and Organizational Dynamics di Ralph Stacey in Agile Software Development with Scrum di Ken Schwaber e Mike Beedle. Semplice Accordo Tecnologia Certezza Incertezza

Scrum 24 ore Sprint 2-4 sett. Resi Sprint goal Incrementi di prodotto Potenzialmente rilasciabili Sprint backlog Return Cancellati Gift wrap Buoni Cancel Regali Buoni Product backlog

Immagine disponibile www.mountaingoatsoftware.com/scrum Colleghiamo il tutto Immagine disponibile www.mountaingoatsoftware.com/scrum

Sprint Un progetto Scrum progredisce attraverso una serie di “sprint” Simile alle “iterazioni” in eXtreme Programming Durata tipica è di 2–4 settimane o al massimo un mese di calendario Una durata sempre costante porta a un miglior ritmo Il Prodotto è progettato, realizzato e testato durante lo sprint

Sviluppo sequenziale vs parallelo Requisiti Progettazione Codifica Test Piuttosto che completare una cosa alla volta… ... Con Scrum si fa un po’ di tutto a ogni ciclo. “The New New Product Development Game” di Takeuchi and Nonaka. Harvard Business Review, Gennaio 1986.

Nessun cambiamento durante lo sprint Richiesta CR Pianificare la durata dello sprint in funzione di quanto tempo è possibile “rifiutare” la richiesta di un cambiamento

Il framework di Scrum Ruoli Cerimonie Strumenti Product owner ScrumMaster Team Ruoli Sprint planning Sprint review Sprint retrospective Daily scrum meeting Cerimonie Strumenti as translation of Artifacts is not really correct but this is how we use Product backlog Sprint backlog Burndown charts Strumenti

Scrum framework Ruoli Cerimonie Strumenti Product owner ScrumMaster Team Ruoli Sprint planning Sprint review Sprint retrospective Daily scrum meeting Cerimonie Strumenti Product backlog Sprint backlog Burndown charts

Product Owner Definisce le funzioniltà del prodotto Decide le date di rilascio e il contenuto E’ responsabile della profittabilità (ROI) del prodotto Definisce le priorità tra le funzioni in base al valore di mercato delle stesse Adatta le funzionalità dopo ogni ciclo Accetto o rifiuta i risultati del lavoro del team

ScrumMaster La funzione gestionale nel progetto Responsabile per la esecuzione e il miglioramento di pratiche e valori di Scrum Rimuove eventuali blocchi Assicura che il team si pianamente funzionante e operativo Facilita la collaborazione tra ruoli e funzioni Protegge il team dale interferenze esterne

Team Tipicamente 5-9 persone Interfunzionale: Programmatri, tester, UX designer, etc. Partecipanti devono essere full-time Alcune eccezioni (p.e. database administrator)

Team Team è auto-organizzato Idealmente, nessun titolo Cambiamenti tra I partecipanti solo tra uno sprint e un altro (no interno a sprint)

Il framework Scrum Ruoli Cerimonie Strumenti Product owner ScrumMaster Team Ruoli Sprint planning Sprint review Sprint retrospective Daily scrum meeting Cerimonie Product backlog Sprint backlog Burndown charts Strumenti

Sprint goal Sprint backlog Sprint planning Gestione priorità Sprint Capacità del Team Gestione priorità Sprint Analizza e valuta Product Backlog Definisce l’obiettivo dello sprint Sprint goal Product backlog Condizioni dal Business Sprint planning Definisce come raggiungere l’obiettivo di sprint (progettazione) Crea sprint backlog (tasks) partendo dagli elementi nel product backlog (user stories / funzioni) Stima sprint backlog Estimation in hour is not a best practice Stato attuale del Prodotto Sprint backlog Tecnologia

Sprint planning Team seleziona elementi del product backlog che si impegna a completare nello sprint Si crea lo sprint backlog Ogni task è definite e stimato Tutti insieme, non solo lo ScrumMaster Considerare una progettazione ad alto livello Estimation in hour is not a best practice As a travel planner, I want to see photos of the hotels. Middleware(8 ore) UX(4 ore) Test (4 ore) Casi di esempio (6 ore) Test prestazione (4 ore)

Daily scrum Come farlo Non è la sede dove si risolvono i problemi Ogni giorno 15-minuti In piedi Non è la sede dove si risolvono i problemi Tutti possono partecipare Solo i membri del team, ScrumMaster e Product owner possono parlare Riduce riunioni non necessarie

Rispondere a tre domande Cosa hai fatto ieri? 1 Cosa farai oggi? 2 Qualche impedimento? 3 Non è per allineare per lo Scrum Master Sono prese in carico di ognuno di fronte al team

Sprint review Team presenta al Product Owner cosa ha realizzato durante lo sprint Tipicamente assume la forma di una demo delle funzionalità o della architettura della applicazione Informale 2 ore No slide ma demo Partecipa tutto il team Chiunque può essere invitato

Sprint retrospective Periodicamente bisogna analizzare cosa non ha funzionato Tipicamente 15–30 minuti Eseguita alla fine di ogni sprint Partecipa tutto il team ScrumMaster Product owner Team Eventualmente client e altri

Questo è solo uno dei tanti modi per eseguire una Rettrospective Start / Stop / Continue Tutto il team riunito discute di cosa preferirebbero Cominciare a fare Smettere di fare Questo è solo uno dei tanti modi per eseguire una Rettrospective Continuare a fare

Il framework Scrum Ruoli Cerimonie Strumenti Product owner ScrumMaster Team Ruoli Sprint planning Sprint review Sprint retrospective Daily scrum meeting Cerimonie Product backlog Sprint backlog Burndown charts Strumenti

Questo product backlog Requisiti La lista di tutte le funzioni desiderate Idealmente costruito in modo che ogni element abbia un valore per I Clienti del prodotto Priorità gestita dal Product Owner Priorità verificata all’inizio di ogni sprint Questo product backlog

Un esempio di product backlog Elemento del backlog Stima Come ospite, voglio prenotare una camera 3 Come ospite, voglio cancellare una precendente prenotazione 5 Come ospite, voglio modificare le date di una precendente prenotazione Come impiegato dell’hotel, voglio eseguire un report RevPAR reports (revenue-per-available-room) 8 Migliorare la gestione delle eccezioni ... 30 50

Sprint goal Una frase che indica su cosa ci si deve focalizzare durante lo sprint Biologia Funzioni di support per permettere studi di generica. Applicazione Database Una applicazione che può eseguire comandi SQL su un DB Oracle. Servizi finanziari Integrare indicatori real time sulla compagnia ABC.

Gestire sprint backlog Ognuno sceglie il lavoro da realizzare Il lavoro NON viene assegnato Stima del lavoro rimanente viene aggiornata quotidianamente

Gestire sprint backlog Ogni membro può migliorare I requisiti presenti in sprint backlog Il lavoro sulle storie dello sprint “emerge” Se un requisito non è chiaro all’inizio dello sprint utilizzare il lavoro nello sprint per chiarirlo Aggiornare il lavoro restante mano a mano che I requisiti diventano più chiari

Un esempio di sprint backlog Tasks Lun Mar Mer Gio Ven Realizzare interfaccia UI Tracciare errori sul log 8 10 16 8 16 12 4 12 16 8 4 11 8 8 Realizzare Middleware Testare middleware Scrivere help online Scrivere classi di esempio

Un esempio di sprint burndown chart Ore

Attività Lun Mar Mer Gio Ven Realizzare Middleware Testare Middleware Realizzare interfaccia UI 8 4 12 16 8 10 16 7 11 8 Realizzare Middleware 16 Testare Middleware 8 Scrivere help online 12 50 40 30 Ore 20 10 Lun Mar Mer Gio Ven

Scalabilità di Scrum Tipica dimension del team è 7 (± 2) persone Scalabilità gestita come “team di team” Fattori collegata alla scalabilità Tipo di applicazione Dimensione del team Distribuzione del team Durata del progetto Scrum è già stato utilizzato per progetti 500+ persone (Scrum of scrums)

Scalabilità con Scrum of scrums

Scrum of scrums of scrums

Riferimenti sul web www.mountaingoatsoftware.com/scrum www.scrumalliance.org www.controlchaos.com scrumdevelopment@yahoogroups.com

Libri suggeriti Agile and Iterative Development: A Manager’s Guide by Craig Larman Agile Estimating and Planning by Mike Cohn Agile Project Management with Scrum by Ken Schwaber Agile Retrospectives by Esther Derby and Diana Larsen

Libri suggeriti su Scrum Agile Software Development Ecosystems by Jim Highsmith Agile Software Development with Scrum by Ken Schwaber and Mike Beedle Scrum and The Enterprise by Ken Schwaber Succeeding with Agile by Mike Cohn User Stories Applied for Agile Software Development by Mike Cohn

Copyright Sei libero di : sotto le seguenti condizioni Condividere/copiare, distribuire o inviare questo documento Riutilizzare/adattare questo documento sotto le seguenti condizioni Attribuzione. Devi indicare in maniera specifica l’autore o il licenziatario di questo document (ma non in modo che emerge che tu abbia ricevuto la loro approvazione per l’uso). Niente in questa licenza può vincolare rendere moralmente responsabile l’autore. Per maggiori dettagli http://creativecommons.org/licenses/by/3.0/

Contact information Presentazione di: Mike Cohn mike@mountaingoatsoftware.co m www.mountaingoatsoftware.com (720) 890-6110 (office) Tradotta da: Corrado De Sanctis Puoi eliminare questa slide o qualsiasi altra, ma è necessario indicare l’origine nella versione che tu realizzerai. Puoi usare il logo e il nome dell’azienda (vd in basso a sinistra) o includere una slide dedicata per dare creadito a questo documento. Grazie.