Lo Scrum Framework PDF

**Lo Scrum Framework** Ora che abbiamo capito il \"perché\" di Agile, esploriamo come funziona in pratica attraverso i suoi Framework di base. I Framework più popolari di cui sentirete parlare sono Scrum, Kanban e Lean Agile ed Experience Programming (XP). **Partiamo da Scrum** Scrum è un sottoi...

**Lo Scrum Framework** Ora che abbiamo capito il \"perché\" di Agile, esploriamo come funziona in pratica attraverso i suoi Framework di base. I Framework più popolari di cui sentirete parlare sono Scrum, Kanban e Lean Agile ed Experience Programming (XP). **Partiamo da Scrum** Scrum è un sottoinsieme di Agile e uno dei framework di processo più popolari per l\'implementazione di Agile. Jeff Sutherland ha creato il processo Scrum nel 1993, prendendo il termine \"Scrum\" da un\'analogia in uno studio del 1986 di Takeuchi e Nonaka pubblicato su Harvard Business Review. Nello studio, Takeuchi e Nonaka confrontano team multifunzionali ad alte prestazioni con la formazione Scrum utilizzata dalle squadre di rugby. Il contesto originale per questo era la produzione, ma Sutherland, insieme a John Scumniotales e Jeff McKenna, ha adattato il modello per lo sviluppo software. **La Teoria di Scrum** Scrum si basa sulla teoria del controllo empirico dei processi, o empirismo. L'empirismo afferma che la conoscenza deriva dall'esperienza e che le decisioni si basano su ciò che si conosce. Scrum utilizza un metodo iterativo ed un approccio incrementale per ottimizzare la prevedibilità ed il controllo del rischio. I pilastri che sostengono ogni implementazione del controllo empirico di processo sono: trasparenza, ispezione e adattamento. Scrum è: - Leggero - Semplice da comprendere - Molto difficile da padroneggiare È un modello di sviluppo software iterativo che sfrutta i processi incrementali inclusi in un framework più ampio che utilizza team interfunzionali per raggiungere gli obiettivi e adattarsi ai cambiamenti. Scrum mira a stabilire piccole parti di una release più velocemente in iterazioni di lunghezza fissa, chiamate sprint, che durano da una a due settimane. Ciò consente al team di distribuire il software con cadenza regolare. Alla fine di ogni sprint, le parti interessate e i membri del team si incontrano per pianificare i passaggi successivi. Possiamo quindi dire che Scrum è un framework di processo utilizzato dai primi anni novanta per gestire lo sviluppo di prodotti complessi. Dobbiamo tenere sempre a mente che Scrum non è un processo o una tecnica per costruire prodotti ma piuttosto è un framework all'interno del quale è possibile utilizzare vari processi e tecniche. Scrum rende chiara l'efficacia relativa del proprio product management e delle proprie pratiche di sviluppo così da poterle migliorare. Il framework Scrum è costituito dagli Scrum Team e dai ruoli, eventi, artefatti e regole a essi associati. Ogni parte del framework serve a uno specifico scopo ed è essenziale per il successo e l'utilizzo di Scrum. Strategie specifiche per l'utilizzo del framework Scrum sono varie e descritte più avanti. Le regole di Scrum legano insieme gli eventi, i ruoli, di riunioni e gli artefatti governando le relazioni e le interazioni tra essi. Ad esempio, Scrum richiede quattro cerimonie che forniscono struttura a ogni Sprint: - **Pianificazione dello Sprint,** - **Stand-up giornaliero,** - **Demo dello Sprint,** - **e Retrospettiva dello Sprint.** Durante ogni Sprint, il team utilizzerà artefatti visivi come bacheche delle attività o grafici burndown per mostrare i progressi e ricevere feedback incrementali. Questo tipo di gestione dei progetti si traduce in una maggiore reattività ai clienti, minori costi di sviluppo, soddisfazione sul lavoro e rendimenti più immediati. Scrum non è un processo lineare, ma piuttosto una pratica fluida che prende in considerazione molte parti mobili, team e obiettivi man mano che procede. I pilastri che sostengono ogni implementazione del controllo empirico di processo sono: trasparenza, ispezione e adattamento. **Trasparenza** Gli aspetti significativi del processo devono essere visibili ai responsabili del risultato finale (Outcome). La trasparenza richiede che quegli aspetti siano definiti da uno standard comune in modo tale che gli osservatori condividano una comune comprensione di ciò̀ che viene visto. Ad esempio: - Un linguaggio comune di riferimento al processo deve essere condiviso da tutti i partecipanti; e - Una definizione comune della parola "Fatto" deve essere condivisa da chi esegue e chi deve accettare il lavoro. **Ispezione** Chi utilizza Scrum deve ispezionare frequentemente gli artefatti di Scrum e l'avanzamento verso un obiettivo con lo scopo di rilevare le eventuali deviazioni indesiderate. Tali ispezioni non dovrebbero essere tanto frequenti da intralciare il lavoro stesso. Le ispezioni sono più utili quando eseguite diligentemente da chi ha l'abilità e la competenza necessaria a effettuarle rispetto ad un particolare stadio del lavoro. **Adattamento** Se chi ispeziona verifica che uno o più aspetti del processo sono al di fuori dei limiti accettabili e che il prodotto finale non potrà essere accettato, deve adattare il processo o il materiale ad esso relativo. L'adattamento deve essere portato a termine il più rapidamente possibile per ridurre al minimo l'ulteriore deviazione. \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ **Vantaggi di Scrum** Scrum è un framework altamente prescrittivo con ruoli e cerimonie specifici. Sebbene possa essere molto da imparare, queste regole hanno molti vantaggi. I vantaggi di Scrum includono: **Maggiore trasparenza e visibilità del progetto:** con riunioni quotidiane, l\'intero team sa chi sta facendo cosa, eliminando molti malintesi e confusione. I problemi vengono identificati in anticipo, consentendo al team di risolverli prima che sfuggano di mano. **Maggiore responsabilità del team:** non c\'è un project manager che dice allo Scrum Team cosa fare e quando. Invece, il team decide collettivamente quale lavoro può completare in ogni sprint. Lavorano tutti insieme e si aiutano a vicenda, migliorando la collaborazione e consentendo a ogni membro del team di essere indipendente. **Facile da adattare ai cambiamenti:** con sprint brevi e feedback costanti, è più facile gestire e adattare i cambiamenti. Ad esempio, se il team scopre una nuova user story durante uno sprint, può facilmente aggiungere quella funzionalità allo sprint successivo durante la riunione di perfezionamento del backlog. **Maggiori risparmi sui costi:** la comunicazione costante assicura che il team sia a conoscenza di tutti i problemi e dei cambiamenti non appena si presentano, contribuendo ad abbassare le spese e ad aumentare la qualità. Codificando e testando le funzionalità in blocchi più piccoli, si ottiene un feedback continuo e gli errori possono essere corretti in anticipo, prima che diventino troppo costosi da risolvere. \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ **Svantaggi di Scrum** Sebbene Scrum offra alcuni vantaggi concreti, ha anche alcuni svantaggi. Scrum richiede un alto livello di esperienza e impegno da parte del team e i progetti possono essere a rischio di Scope Creep. Ecco gli svantaggi di Scrum: **Rischio di Scope Creep**: alcuni progetti Scrum possono subire Scope Creep a causa della mancanza di una data di fine specifica. Senza una data di completamento, gli stakeholder potrebbero essere tentati di continuare a richiedere funzionalità aggiuntive. **Il team richiede esperienza e impegno:** con ruoli e responsabilità definiti, il team deve avere familiarità con i principi Scrum per avere successo. Poiché non ci sono ruoli definiti nello Scrum Team (tutti fanno tutto), richiede membri del team con esperienza tecnica. Il team deve anche impegnarsi nelle riunioni Scrum quotidiane e rimanere nel team per tutta la durata del progetto. **Lo Scrum Master sbagliato può rovinare tutto:** lo Scrum Master è molto diverso da un project manager. Lo Scrum Master non ha autorità sul team; lui o lei deve fidarsi del team che sta gestendo e non dirgli mai cosa fare. Se lo Scrum Master cerca di controllare il team, il progetto fallirà. **Le attività mal definite possono portare a imprecisioni:** i costi e le tempistiche del progetto non saranno accurati se le attività non sono ben definite. Se gli obiettivi iniziali non sono chiari, la pianificazione diventa difficile e gli sprint possono richiedere più tempo di quanto inizialmente stimato.