Scrum è una metodologia Agile di sviluppo software che viene ora adottata da molte aziende e aziende come parte di iniziative di trasformazione digitale.
Sommario:
A proposito di Scrum
Il ruolo della metodologia Scrum è fornire un framework per lo sviluppo software Agile che consenta ai team di lavorare in modo collaborativo ed efficiente per fornire prodotti software di alta qualità.
È un framework in cui i team possono lavorare insieme per sviluppare prodotti complessi. Invece di rilasciare un prodotto dopo lunghe fasi di pianificazione, progettazione, sviluppo e test, la mischia mira a fornire prodotti pronti per l’uso fin dall’inizio in piccoli incrementi.
I principi fondamentali di Scrum sono la comunicazione trasparente del team, la regolare verifica della qualità e la capacità di adattarsi al cambiamento. Se adottato e utilizzato nel modo giusto, i team possono fornire prodotti software di alta qualità in modo tempestivo ed efficiente.
Principali vantaggi di Scrum
Fonte: scrum.org
- Puoi ottenere una maggiore produttività. Essere un team Scrum significa che il team sta scomponendo problemi complessi in piccoli pezzi. Quindi quei piccoli pezzi vengono consegnati all’interno degli sprint come incrementi di sprint. I membri del team possono concentrarsi su attività specifiche all’interno di uno Sprint (periodo di tempo definito in cui vengono sviluppati gli incrementi, ad esempio due settimane).
- Scrum incoraggia la comunicazione regolare tra l’intero team. Ciò garantisce quindi che tutti siano chiari sulla portata e sulle aspettative. Riduce una quantità piuttosto significativa di incomprensioni che potrebbero altrimenti verificarsi. Soprattutto se si vuole procedere a ritmo sostenuto di volata in volata, tutta la squadra deve lavorare giorno dopo giorno per lo stesso obiettivo.
- Scrum è progettato per essere flessibile, in modo che i team possano adattarsi alle mutevoli esigenze e priorità. Ciò consente ai team di rispondere rapidamente ai cambiamenti nell’ambito del progetto o alle esigenze dei clienti. Invece di aspettare fino al termine dell’intero ciclo di vita dello sviluppo, puoi semplicemente modificare il contenuto tra gli sprint.
- Scrum sottolinea l’importanza dei test e della garanzia della qualità, idealmente in modo automatizzato. L’obiettivo finale è aumentare la qualità del prodotto finale. Ciò riduce il rischio di difetti e garantisce che il prodotto soddisfi i requisiti del cliente.
- Scrum è progettato per essere incentrato sul cliente, il che significa che il cliente è coinvolto nel processo di sviluppo dall’inizio alla fine, di solito nel ruolo di proprietario del prodotto o con una connessione diretta con il proprietario del prodotto (ne parleremo più avanti). Ciò garantisce che il prodotto finale soddisfi le esigenze del cliente e con la giusta priorità.
Successivamente, discuteremo il ruolo della metodologia di mischia.
Ruolo della metodologia di Scrum
Fonte: hangoutagile.com
Lo scopo della metodologia Scrum è fornire un framework per lo sviluppo software Agile che consenta ai team di lavorare in modo collaborativo. Costruisci un team Scrum che si riunisce quotidianamente e regolarmente e ha discussioni programmate (cerimonie) all’interno di uno sprint che ripete ogni sprint. In genere, le seguenti cerimonie fanno parte della configurazione di base di un team di mischia:
- Standup giornalieri: un momento e un luogo in cui tutti i membri del team si incontreranno e discuteranno di ciò che è stato fatto il giorno scorso, quale sarà il lavoro il giorno successivo e quali sono gli eventuali ostacoli attuali.
- Perfezionamento delle storie: è qui che vengono discussi e finalizzati i nuovi contenuti (per i prossimi sprint).
- Pianificazione dello sprint: durante questa cerimonia, il team stima i contenuti pronti per l’uso (definiti all’interno delle storie) e quindi si impegna in un sottoinsieme specifico da essi, principalmente sulla base di stime di priorità e impegno.
- Revisione dello sprint: qui il team incontra gli stakeholder e presenta loro ciò che il team ha ottenuto nell’ultimo sprint.
- Retrospettiva dello sprint: un dialogo dedicato al team solo per discutere di cosa può essere migliorato o di ciò che il team ritiene debba essere cambiato in futuro.
Il significato della metodologia Scrum risiede nella sua capacità di aiutare i team a lavorare in modo più efficace. I principi fondamentali della metodologia Scrum si basano sul Manifesto Agile e sono i seguenti.
Controllo di processo empirico
Scrum si basa sull’idea che il progresso si ottiene meglio attraverso un processo empirico di ispezione e adattamento continui. Ciò significa che i team dovrebbero ispezionare regolarmente il proprio lavoro e adattare i propri processi per migliorare le proprie prestazioni.
Team auto-organizzati
I team Scrum sono auto-organizzati, il che significa che sono responsabili della gestione del proprio lavoro e delle decisioni relative al raggiungimento dei propri obiettivi. Questo aiuta a promuovere la collaborazione e la responsabilità all’interno del team.
Iterazioni a tempo
Puoi suddividere i progetti Scrum in iterazioni a tempo, chiamate sprint, che in genere durano da una a quattro settimane. Ciò garantisce che il team lavori per un obiettivo specifico e proceda regolarmente.
Backlog di prodotto prioritario
Il product backlog è un elenco prioritario di funzionalità e requisiti su cui il team lavorerà durante il progetto. Il product owner è responsabile del mantenimento del product backlog e di garantire che rifletta le esigenze e le priorità del cliente.
Miglioramento continuo
Scrum sottolinea l’importanza del miglioramento continuo. Sia in termini di prodotto in fase di sviluppo che di processi utilizzati per svilupparlo. Ciò significa che i team dovrebbero riflettere regolarmente sul proprio lavoro e cercare modi per migliorare le proprie prestazioni.
Sfide
Fonte: scrum.org
Mentre la metodologia Scrum può essere molto efficace nello sviluppo del software, ci sono anche alcune sfide che i team possono affrontare quando la implementano.
Resistenza al cambiamento
Scrum richiede un cambiamento significativo nella mentalità e nella cultura, che può essere difficile da accettare per alcuni membri del team. Alcuni membri del team possono essere resistenti al cambiamento, il che può rendere difficile implementare Scrum in modo efficace. In altre parole, devi “prenderlo”. Finché non lo fai, non ci sei.
Mancanza di esperienza
È necessario un certo livello di esperienza e competenza per implementare in modo efficace. Se i membri del team non hanno familiarità con le metodologie Scrum o Agile, rappresenta una sfida da superare.
Mancanza di impegno
Scrum richiede un elevato impegno da parte di tutti i membri del team, inclusi il product owner, lo Scrum master e il team di sviluppo. Se i membri del team non sono completamente impegnati nel processo, può essere difficile ottenere i risultati desiderati.
Povera comunicazione
Scrum fa molto affidamento sulla comunicazione e sulla collaborazione tra i membri del team. Se i membri del team non comunicano spesso ed efficacemente, può essere difficile per loro.
Enfasi eccessiva sul processo
Sebbene Scrum fornisca un framework per lo sviluppo software Agile, è importante ricordare che si tratta solo di un framework. Se i membri del team si concentrano troppo sul seguire il processo, potrebbero perdere di vista l’obiettivo finale di fornire prodotti software di alta qualità.
Ruoli di uno Scrum Team
Ogni team di mischia, per essere efficace, deve essere composto da pochi ruoli concreti. Se quei ruoli non sono dedicati alla squadra o nel conteggio sbagliato, la formazione di successo di un tale team di mischia potrebbe essere in pericolo.
#1. Team di sviluppo
Questa è la parte esecutiva del team, quindi dal punto di vista della consegna del prodotto, forse la parte più importante del team. Un tipico team di sviluppo di Scrum è composto da specialisti di sviluppo/test/architettura/analisti per un totale di 4-10 persone. Se è inferiore, è discutibile se puoi ancora chiamarlo squadra. Se è di più, tutte le cerimonie e la gestione delle discussioni del team diventeranno eccessivamente complesse e non vale davvero la pena di mantenerle.
Il team di sviluppo prende le storie dal backlog, le stima e le implementa all’interno degli sprint. Il team è responsabile dello sviluppo e del test della storia e, una volta terminato, anche della distribuzione alla produzione.
#2. Maestro di mischia
Uno scrum master funge da orchestratore per il team di sviluppo. Pianifica riunioni regolari, assicura che il team di sviluppo sia chiaro nei contenuti e organizza le attività durante uno sprint con l’obiettivo di raggiungere il piano e gli obiettivi dello sprint.
Questo non è davvero un ruolo di contenuto. In effetti, lo scrum master non ha bisogno di capire tecnicamente nulla dal contenuto delle storie che il team di sviluppo sta risolvendo (anche se sicuramente aiuta). Tuttavia, lo scrum master serve il team di sviluppo e lo protegge dall’ambiente esterno. Per protezione intendo consentire al team di lavorare sulla base di principi agili. Sii qui l’oratore per il team e non permettere di modificare il piano di sprint attualmente concordato con richieste non pianificate.
#3. Proprietario del prodotto
Server Product Owner (PO) per la connessione tra il team di sviluppo e gli utenti aziendali (stakeholder) esterni al team. PO discute il contenuto con tutte le parti interessate e porta il contenuto concordato allo scrum team.
Quindi PO crea storie per il team con descrizioni e aspettative chiare. PO deve assicurarsi che il team di sviluppo comprenda questo contenuto in modo che il team possa stimare ogni storia. In quanto tale, PO possiede le discussioni sul perfezionamento delle storie all’interno del team.
Oltre al contenuto e alla gestione dell’intero arretrato, PO è anche responsabile dell’impostazione delle priorità per ogni storia all’interno dell’arretrato. PO, tuttavia, non è responsabile della selezione di storie concrete nello sprint. Che solo il team di sviluppo può fare impegnandosi nell’ambito, il team sceglierà per il prossimo sprint. L’OP può influenzare tale selezione solo impostando e comunicando correttamente le priorità.
Interazioni di ruoli all’interno di uno Scrum Team
Fonte: scrum.org
Anche con tutte le persone e i ruoli gestiti, la comunicazione è davvero la chiave del successo. Ancora più importante, la giusta comunicazione perché ci sono tanti modi per sbagliare. E questo è in realtà il motivo principale per cui molti team di mischia non hanno successo. Semplicemente non lo sistemano bene.
Ad esempio, i proprietari dei prodotti spesso chiedono al team di sviluppo di elaborare nuove storie di contenuti. Ma non è scopo del team di sviluppo creare l’arretrato. Certo, possono aiutare a definire le storie, renderle dettagliate e suddividerle per poterle eseguire all’interno degli sprint. Ma il proprietario del prodotto è responsabile dell’arretrato. L’OP idealmente non dovrebbe chiedere al team di sviluppo di entrare in contatto con gli stakeholder aziendali.
In un’altra nota, né lo scrum master né il product owner definiranno quale sarà esattamente l’ambito del prossimo sprint. Questo accade molto spesso comunque, poiché i ruoli di scrum master e product owner sono una sorta di ruoli di leader naturali all’interno del team di scrum. Ma in realtà, non sono in grado di decidere cosa il team di sviluppo deve o non deve portare nello sprint. Il team di sviluppo è l’unico che può eseguirlo, quindi spetta al team di sviluppo decidere. Ciò significa che PO sta fornendo informazioni su quanto sia importante quale storia sia dal punto di vista aziendale; PO può persino ordinare l’arretrato di storie dal più importante al meno importante. In questo modo il team di sviluppo ha un’idea di quali storie prendere per prime.
Il proprietario del prodotto deve fare uno sforzo per discutere regolarmente con il team di nuovi contenuti che l’ordine di acquisto desidera che il team fornisca. PO è qui per discutere a fondo di ogni storia che crea o porta in arretrato. Tutti nel team di sviluppo devono capire la storia e per loro è chiaro quali sono i criteri di accettazione.
Lo Scrum master non è solo l’orchestratore del team; in qualche modo, SM protegge il team dal proprietario del prodotto, dalla leadership o da altri stakeholder esterni. SM mantiene in esecuzione i processi interni di scrum e conduce la maggior parte delle cerimonie per il team. Nelle chiamate giornaliere sullo stato, SM si assicura che tutti comunichino solo gli aggiornamenti importanti della giornata, in modo che la riunione non richieda più tempo del previsto. Questo vale in realtà per tutte le chiamate.
SM organizza anche chiamate retrospettive periodiche per il team, in cui aiuta il team a riflettere sul lavoro svolto nello sprint precedente e ad identificare le aree in cui il team può migliorare.
Parole finali
La creazione di un team di mischia di successo è solitamente una lunga strada. Devi costruire esperienza all’interno del team, anche se i membri concreti del team hanno già qualche esperienza precedente. Ogni team di mischia è unico e trovare un modo per lavorare e collaborare insieme come una squadra su argomenti comuni richiede sempre tempo.
La cosa più importante è mantenere stabile la squadra una volta che l’hai già formata. Solo allora la squadra può iniziare a migliorare ad ogni sprint successivo. L’obiettivo finale è convertirsi in una squadra auto-organizzante, dove anche la presenza di un maestro della feccia non è più obbligatoria per la maggior parte del tempo. Se non riesci a tenere unita la squadra, sarai ancora nella fase di apprendimento.
Successivamente, dai un’occhiata ai migliori strumenti di mischia per una startup o una media impresa.