---

Certificazione Scrum Master a costi accessibili: piano passo per passo

Siamo orgogliosi di annunciare che questo articolo è stato presentato...
QUI su LinkedIn >>>

Da quando il framework Scrum è diventato uno dei modi migliori per sviluppare e consegnare software, sembra che tutti abbiano lo stesso obiettivo.

Svegliarsi al mattino, aprire il portatile e provare l’entusiasmante tranquillità di possedere qualcosa del genere:

La certificazione Scrum Master.

È questo il sogno, vero?

Consegnare ottimo software a datori di lavoro e clienti.

Avere una carriera fantastica alimentata dalle tue competenze nel processo Scrum e dalla tua certificazione Scrum Master.

Per la maggior parte delle persone, la certificazione Scrum Master è il punto di partenza con il framework.

In questo articolo voglio condividere per la prima volta una guida avanzata e dettagliata, passo per passo, per aiutarti a conseguire la certificazione Scrum Master.

In modo economico, rapido, online e senza complicazioni!

In soli quattro semplici passi puoi diventare un eccellente professionista Scrum con la tua certificazione Scrum Master.

Voglio mostrarti come Scrum possa sostenere la carriera e migliorare l’efficacia professionale, e perché dovresti sviluppare quanto prima le competenze e capacità di uno Scrum Master.

Definizione: che cos’è la certificazione Scrum Master?

Puoi trovare la migliore definizione di certificazione Scrum Master sul sito di International Scrum Institute™nel programma Scrum Master Accredited Certification™.

La certificazione Scrum Master è la testimonianza della tua competenza nel processo Scrum di sviluppo e consegna del software. La certificazione Scrum Master riconosce le conoscenze dimostrate e la tua notevole competenza nel framework dopo una valutazione formale con test a risposta multipla.

Il processo Scrum offre benefici immensi a milioni di professionisti. Non c’è quindi motivo per cui tu non debba unirti alle donne e agli uomini di successo che hanno migliorato carriera e competenze grazie al framework.

Se hai ancora dubbi, voglio assicurarti che ormai non puoi immaginare una carriera in crescita senza una certificazione Scrum Master, indipendentemente da ruolo, titolo ed esperienza nell’ecosistema dell’informatica, IT .

Non devi neppure essere un professionista informatico per comprendere Scrum, come funziona e ottenere la certificazione.

Qualunque lavoro tu svolga, nel reparto informatico o al suo esterno, c’è un fatto essenziale e incontestabile: le attività e il valore professionale offerti all’organizzazione dipendono e sono collegati all’informatica, al software e ai processi e principi Scrum agili.

Inoltre, con la trasformazione dei modelli tradizionali in attività basate sul software come servizio, SaaS , ossia il cosiddetto movimento di digitalizzazione, , ottenere la certificazione Scrum Master non è più una scelta facoltativa per alcun professionista, dentro o fuori dall’informatica. Oggi è invece una necessità.

Che tu inizi la carriera o sia un professionista informatico esperto non cambia: devi conseguire la certificazione Scrum Master.

Il tuo ruolo può comprendere o meno la gestione di persone e funzioni. Anche questo non cambia: la certificazione resta necessaria.

Puoi avere un titolo come:

• analista di business,
• architetto software,
• architetto aziendale,
• progettista software
• progettista dell’esperienza utente, UX,
• progettista dell’interfaccia utente, UI,
• sviluppatore software,
• responsabile dello sviluppo software,
• ingegnere del collaudo,
• specialista nell’automazione dei test,
• responsabile dei test,
• specialista delle operazioni dei sistemi informatici,
• amministratore Unix/Linux,
• ingegnere della sicurezza informatica, InfoSec,
• ingegnere di reti informatiche,
• amministratore di database, DBA,
• responsabile di progetto,
• responsabile di programma,
• responsabile di prodotto,
• capoteam, manager, direttore o dirigente,
• oppure qualsiasi altro titolo non elencato qui.

Dovresti imparare il framework di sviluppo Scrum e diventare oggi Scrum Master conseguendo la tua certificazione Scrum Master.

3 elementi di caos e frustrazione prima del processo Scrum agile e delle certificazioni Scrum Master

Per capire meglio l’impatto di Scrum sull’ingegneria del software e sulle aziende, osserviamo una giornata nella vita, o un progetto software nella vita professionale.

Voglio quindi parlare brevemente di un progetto precedente all’adozione di Scrum nelle nostre organizzazioni.

Pochi giorni prima di scrivere queste righe ho pranzato con un ex collega con cui lavoravo quasi 20 anni fa. Marcus ha ottenuto le certificazioni Scrum Master e Product Owner Scrum presso International Scrum Institute™.

Oggi lavora come Scrum Master in una delle principali software house nel settore dei programmi per la gestione agile dei progetti.

Sostiene un team Scrum agile con componenti distribuiti geograficamente in tutto il mondo.

Durante il pranzo, Marcus ha ammesso che i team distribuiti affrontano molte sfide tipiche. Fra i problemi specifici della configurazione del suo progetto ha citato:

• Differenze negli stili di lavoro dei componenti del team,
• Differenze di fuso orario,
• Incompatibilità culturali e
• Limiti linguistici.

Nonostante le difficoltà, ha aggiunto che gestire un progetto con Scrum agile è più divertente, produttivo e arricchente di come lavoravamo 20 anni fa. Rispetto ai tempi in cui lavoravamo senza processi Scrum di sviluppo e consegna del software.

La sua affermazione era una forte testimonianza a favore di Scrum da parte di un manager, Scrum Master e Product Owner molto affermato ed esperto.

Grazie, Marcus!

Gli ho allora raccontato un mio progetto antecedente alla conoscenza di Scrum. Sono certo che molti Scrum Master riconosceranno esperienze simili nei progetti precedenti alla certificazione.

Alla fine degli anni 1990 facevo parte di un gruppo di ingegneria impegnato a costruire un sistema basato su smart card di sistema di infrastruttura a chiave pubblicabasato su smart card. Le carte proteggevano in sicurezza le chiavi private dei membri; le chiavi pubbliche associate e i certificati che le contenevano erano distribuiti apertamente, come suggerisce il nome.

Già allora era un progetto IT relativamente complesso, con più team hardware e software interdipendenti. Dovevamo svolgere moltissima ricerca e sviluppo (R&D) per costruire un sistema hardware e software pienamente funzionante.

Ricorda che erano i tempi precedenti al prodotto minimo funzionante (MVP) per sperimentare, creare, imparare e sperimentare di nuovo.

Se vuoi approfondire come costruire un MVP con la metodologia agile, consulta questo articolo di Cleevio, che offre una panoramica migliore del processo complesso.

Creare senza Scrum un’infrastruttura sofisticata, formata da numerosi elementi hardware e software, era una vera sfida.

Ecco tre grandi difficoltà che affrontavamo senza Scrum Master né persone certificate nei nostri team.

Il 1° elemento di caos e frustrazione senza certificazione Scrum Master: pianificare l’intero progetto prima di aver capito di che cosa si trattasse

Senza Scrum, i team costruivano e consegnavano prodotti hardware e software completamente sbagliati, che non soddisfacevano il cliente.

In alcune fasi della vita professionale, società terze ci imponevano come costruire prodotti e servizi software.

Capability Maturity Model (CMM), ISO 9001:2008 e altri derivati cercavano di aiutare le aziende ad assicurare la realizzazione del software giusto nel modo giusto.

Il loro successo non è oggetto di questo articolo. Il suo scopo è concentrarsi su Scrum e sui meriti della certificazione, non trattare gli standard di gestione della qualità e miglioramento dei processi come alternative estinte.

Devo però aggiungere che, prima di Scrum, questi framework di miglioramento venivano introdotti nei progetti con un approccio per fasi, chiamato modello di ingegneria del software a cascata.

Ogni progetto iniziava con l’analisi dei requisiti, per comprendere che cosa occorresse e volesse il cliente.

Poi progettavamo i requisiti, li implementavamo, li testavamo e verificavamo e li mantenevamo negli ambienti di produzione. Infine raggiungevamo la fine del ciclo di vita dell’ingegneria.

La realtà, però, non andava così!

Gli effetti negativi dei ritardi imprevisti in una fase si ripercuotevano inevitabilmente su quelle successive.

Era la vita prima di Scrum.

Passare il software avanti e indietro fra team diversi, senza la guida di professionisti certificati Scrum Master, rendeva il lavoro burocratico, complesso e improduttivo.

Alla fine non soffriva soltanto il prodotto: anche il morale e l’impegno dei dipendenti verso la missione organizzativa venivano completamente compromessi.

Il 2° elemento di caos e frustrazione senza certificazione Scrum Master: mancanza di impegno, gestione del cambiamento e disciplina di collaborazione fra team

La maggiore debolezza dei framework di miglioramento dei processi precedenti a Scrum era questa: Si concentravano soprattutto sulle richieste organizzative della dirigenza a proprio vantaggio.

Tra queste figuravano monitoraggio, conformità e prevedibilità. Non c’era alcuna attenzione a servire bene i clienti né a migliorare il morale dei dipendenti.

I gruppi di gestione software e gli altri stakeholder interni ed esterni cercavano quindi una scadenza fissa per le consegne e un monitoraggio semplice delle fasi ingegneristiche.

Penalizzavano le persone se qualcosa usciva dal percorso pianificato e speravano di correggere i problemi emergenti prima della data prevista di completamento.

Inoltre, silos indipendenti svolgevano fasi dell’ingegneria completamente separate. Ad esempio, gli sviluppatori erano del tutto indipendenti dal team di test e verifica. Molte persone che avrebbero dovuto perseguire la stessa missione non si conoscevano nemmeno per nome.

Sai perché nelle organizzazioni prevalesse questa mentalità a silos anziché l'attenzione alla missione e alla maturità professionale (aziendale) delle persone?

La ragione è semplicemente la gestione a matrice. È una struttura organizzativa e del personale presente nelle aziende dagli anni 1970. A prima vista, l'idea distintiva di un'organizzazione o gestione a matrice sembra intelligente.

La dirigenza costruisce una struttura riunendo dipendenti con competenze funzionali e tecniche simili negli stessi silos o, nel migliore dei casi, in silos vicini.

All’epoca erano molto diffusi i cosiddetti centri di competenza, ciascuno dei quali era un silo indipendente e autonomo.

Un silo per sviluppatori C++, uno per amministratori di database e un altro completamente separato per la garanzia della qualità oltreoceano, e così via. Prova a capirci qualcosa!

La maggiore difficoltà della struttura a matrice era che, per consegnare un progetto senza Scrum e Scrum Master, i project manager dovevano prendere temporaneamente in prestito persone dai silos.

Questi dipendenti non stavano neppure fisicamente insieme ai team di progetto: restavano nelle stanze del rispettivo centro di competenza.

Al termine dei progetti, i team temporanei si scioglievano e i partecipanti passavano ad altri incarichi.

Il valore aziendale perseguito dai progetti in corso non era quindi mai la priorità assoluta di questi silos indipendenti.

Tendevano a vedere il lavoro come caselle da spuntare per un progetto qui e un altro là.

Leadership e modello a matrice non insegnavano come impegnarsi professionalmente nell'attività per migliorare risultati economici, vendite, ricavi e profitti.

Anche un articolo di McKinsey & Company su McKinsey Quarterly ha illustrato chiaramente questa illusione di ottimizzazione dei costi oltre l'organizzazione a matrice.

L’articolo originale cita una stima di Gartner della spesa annua mondiale per spendendo 600 miliardi di USD per ripristinare i sistemi IT a causa di manutenzione non programmata e difetti.

Visualizziamo ora brevemente come funzionavano la gestione dei cambiamenti e degli impedimenti nei progetti. Come funzionavano con il modello a cascata, l’organizzazione a matrice e senza Scrum.

Sì, hai ragione. Dirigenza e dipendenti trattavano la gestione del cambiamento, degli impedimenti e degli errori come anomalie negative che non avrebbero mai dovuto verificarsi.

I cambiamenti erano quindi sinonimo di ritardi, spesso con un effetto domino. I team cercavano qualcuno da incolpare per difetti e impedimenti.

Infine, poiché i silos non avevano meccanismi per elaborare, correggere e imparare dagli errori, continuavano a ripeterli.

Inoltre continuavano ad aumentare la quantità di debito tecnico mentre affrontavano passivamente i problemi.

Il 3° elemento di caos e frustrazione senza certificazione Scrum Master: le decisioni autocratiche prevalevano su quelle democratiche

Steve Jobs disse una volta:

«Non ha senso assumere persone intelligenti e dire loro che cosa fare. Assumiamo persone intelligenti perché dicano a noi che cosa fare».

Era però l’esatto contrario del modo in cui molti dirigenti prendevano decisioni prima dell’era Scrum.

Prima di Scrum, le decisioni autocratiche dei responsabili prevalevano sull’intelligenza collettiva dei team.

Annullavano la capacità decisionale democratica dei gruppi che svolgevano il lavoro effettivo che copriva l'intero ciclo software, dalla concezione alle operazioni.

Più una decisione veniva allontanata dai centri di lavoro, ossia dai team interessati, più era difficile prendere correttamente una decisione critica.

Le valutazioni dei leader erano solitamente impulsive, poco approfondite, spesso tardive e incerte, ma talvolta persino premature.

Queste decisioni autocratiche imposte dall'alto facevano sentire sottovalutati i dipendenti. Ostacolavano completamente la capacità organizzativa di trovare soluzioni creative e innovative per affrontare difficoltà competitive aziendali e software.

Inoltre scoraggiavano i team a offrire contributi quando venivano chiamati a partecipare alle decisioni.

Questa era una breve panoramica di come sviluppavamo e consegnavamo software e servizi prima dell’adozione di Scrum. Vediamo ora come ne abbiamo risolto gli elementi di caos e frustrazione.

Che cos’è Scrum?

Anzitutto non intendevo scrivere questa sezione come riferimento capace di rispondere a tutte le domande su Scrum. Offre però una base approfondita per la maggior parte dei professionisti principianti e intermedi.

Per chi cerca una guida più avanzata ma pratica per imparare rapidamente, abbiamo anche altro. Ti suggerisco di scaricare la nostra guida al framework Scrum dal link qui.

Che cos’è Scrum? Senza complicare troppo, possiamo definirlo così:

Scrum è un framework leggero per generare valore attraverso soluzioni adattive a problemi complessi. Lo sviluppo software iterativo e incrementale ne è un’importante applicazione.

Benché il software sia il principale ambito di Scrum, il processo agile e iterativo può essere ed è già applicato anche al di fuori del settore.

Molti nel settore informatico credono che il termine "Scrum" sia nato nei primi anni 2000 parallelamente alle tendenze emergenti dello sviluppo e della consegna agili. È un’informazione errata!

L’articolo di Harvard Business Review del gennaio 1986 descriveva un approccio allo sviluppo del prodotto precedente al successivo framework Scrum. Hirotaka Takeuchi e Ikujiro Nonaka scrissero The New New Product Development Game. Sì, New compare due volte.

Dovresti leggere "The New New Product Development Game" per scoprire come è iniziato tutto!

Parlando di Scrum, sentiamo spesso il termine "Agile Scrum" accanto a "Scrum". Questo ha spinto alcuni a cercare differenze fra i due termini.

Una buona notizia: "Agile Scrum" e "Scrum" indicano la stessa cosa, il processo di ingegneria del software Scrum. Perché allora a volte mettiamo "Agile" davanti a "Scrum"?

Perché il framework ha accolto e incorporato pienamente il Manifesto per lo sviluppo agile del software, o Manifesto Agile nel processo centrale, nei principi e nella filosofia. Comprendiamo quindi meglio il Manifesto Agile e i valori Scrum prima di approfondirne gli aspetti tecnici.

Il Manifesto per lo sviluppo agile del software, o Manifesto Agile

I valori del Manifesto Agile:

• Gli individui e le interazioni più dei processi e degli strumenti,
• Il software funzionante più della documentazione esaustiva,
• La collaborazione con il cliente più della negoziazione dei contratti,
• Rispondere al cambiamento più che seguire un piano.

Pur attribuendo un valore significativo agli elementi a destra, il Manifesto Agile apprezza e privilegia maggiormente quelli a sinistra.

Gli elementi privilegiati sono stati attentamente collaudati nel tempo e scelti per:

• Servire meglio clienti e parti interessate e creare valore con il software,
• Migliorare la professione dell’ingegneria del software, qualunque sia il tuo ruolo, titolo o livello di carriera.

I valori del framework Scrum

Ho già spiegato che Scrum non è soltanto un processo di ingegneria del software: possiede anche un solido insieme di principi di base.

La maggior parte degli ambiti professionali può infatti applicare e utilizzare questi principi.

La certificazione Scrum Master non basta per avere grande successo. Devi comprendere saldamente anche i valori Scrum.

così da svolgere un ottimo lavoro e realizzare software fantastico, apprezzato dai tuoi clienti e datori di lavoro. Approfondiamo ora questi principi.

Coraggio

Fare la cosa giusta per offrire ai clienti il massimo valore non è sempre la scelta più semplice. In questi momenti Scrum Master, Product Owner e componenti del team devono ricordare il proprio dovere e la propria responsabilità.

Costruire i migliori prodotti e servizi possibili nel proprio ambito aziendale e informatico. Per andare oltre la mediocrità, prima o poi il team dovrà prendere decisioni difficili che non renderanno tutti felici nel proprio insieme di parti interessate.

Per affrontarle, tutti dovrebbero ricordare ciò che hanno imparato nella formazione per la certificazione Scrum Master.

Devono ricordare di essere coraggiosi e imparare a decidere e agire con coraggio.

Concentrazione

Quando senti parlare del valore della concentrazione in Scrum, dovresti pensare a due cose:

• Individuare il lavoro giusto: Quali attività servono per raggiungere gli obiettivi del mio Sprint? Che cosa è essenziale per realizzare i migliori prodotti e servizi per i clienti, affinché siano soddisfatti del mio lavoro?
• Definire le priorità: A quali attività devo dedicarmi adesso?

In ogni momento esiste una domanda fondamentale a cui l’intero team, compresi Scrum Master e Product Owner, deve rispondere. È questa: "Quali sono le cose più importanti da fare ora per soddisfare i motivi per cui il datore di lavoro ci ha assunti?"

Scrum comprende vari eventi e rituali per assicurare priorità ragionevoli a storie e attività. Dare priorità alle storie utente e ai relativi compiti deve essere un’attenzione continua.

Assicuriamo così che il team lavori alle cose giuste nell’ordine corretto. Gli eventi formali e le pratiche di perfezionamento collegate aiutano a esaminare la concentrazione e adattare il lavoro:

• Riunione di perfezionamento Scrum: Il perfezionamento chiarisce, scompone e dimensiona i prossimi elementi del Product Backlog, aiutando anche a ordinarli. Una riunione è una possibilità per svolgere questa attività continua.
• Sprint Planning Meeting, riunione di pianificazione dello Sprint: Queste riunioni ci aiutano a vedere dipendenze e ordine corretto del lavoro per consegnare le nostre user story.
• Daily Scrum Meeting, riunione Scrum quotidiana: I Daily Scrum, o stand-up quotidiani, aiutano a impostare la giornata. Dobbiamo indirizzare l’attenzione dove è più necessaria.
• Sprint Review Meeting, riunione di revisione dello Sprint: La revisione dello Sprint mostra indirettamente dove concentrare gli sforzi per revisioni future più soddisfacenti.
• Sprint Retrospective Meeting, riunione retrospettiva dello Sprint: Queste riunioni aiutano a dare priorità agli aspetti del processo di ingegneria da migliorare per primi.

Qui ho trattato i rituali soltanto dal punto di vista della concentrazione. Trovi una spiegazione più dettagliata delle cerimonie Scrum più avanti nell’articolo.

Ora dovrebbe essere evidente quanto priorità e concentrazione siano essenziali per Scrum.

Impegno

Senza l’impegno di Scrum Master, Product Owner e team non è possibile ottenere risultati software eccellenti.

Molti interpretano il valore dell’impegno come accordo e vincolo sugli obiettivi dei risultati da consegnare in uno Sprint.

Sebbene sia del tutto sensato, questa interpretazione non è perfetta. Nel contesto dei valori Scrum, l’autore usa "ossessione" per sottolineare la dedizione. Nella definizione Scrum, l’impegno riguarda gli obiettivi del team e il sostegno reciproco; non richiede lavoro eccessivo né certezza su ogni elemento previsto.

Per avere successo nell’ingegneria del software, nella vita e negli affari, devi essere ossessionato dai tuoi obiettivi. Quindi nel contesto Scrum, devi quindi dedicarti con assoluta determinazione a creare software meraviglioso che risolva i problemi dei tuoi clienti.

Perché impegno e relativa ossessione per gli obiettivi sono così importanti? Senza questa dedizione alla missione di costruire e consegnare software straordinario, ogni impedimento non banale rallenta e blocca il lavoro.

Scrum Master e team inizieranno allora a creare spiegazioni per giustificare al Product Owner perché non riescano a raggiungere gli obiettivi dello Sprint. Le scuse non dovrebbero più trovare spazio se vuoi un team superiore alla media.

Soltanto con un’enorme dedizione diventa relativamente più semplice e gratificante risolvere i problemi dei clienti e creare valore con il software.

Rispetto

Indipendentemente da età, genere, origine, convinzioni, esperienza, competenza, opinioni e prestazioni, ogni componente deve rispettare gli altri e poter contare su di loro.

Il rispetto non si limita al team: ogni parte interessata aziendale o informatica, interna o esterna, viene pienamente rispettata e accolta.

I più esperti devono evitare di scoraggiare il contributo dei meno esperti.

È particolarmente importante accogliere e affrontare correttamente opinioni opposte a quelle della maggioranza.

Apertura

Il valore dell’"apertura" distingue spesso un team medio da uno eccellente. Puoi paragonarlo alle grandi capacità di un gruppo di persone dalla mente aperta.

Sono creative, innovative, riflessive, sincere, dirette e umili. Nello sviluppo e nella consegna Scrum, le persone devono poter discutere apertamente sfide e prospettive diverse. Questo non rende però appropriata ogni decisione o azione: rispetto, qualità e obiettivi restano importanti.

L’unica condizione è essere trasparenti e mirare a contribuire alla missione comune.

Non significa che ogni decisione e azione debba necessariamente accelerare i risultati e produrre grandi successi.

Grazie ad apertura e coraggio, il gruppo non teme di sbagliare. Considera errori e risultati non ottimali come opportunità fondamentali per migliorare significativamente produttività complessiva e qualità del lavoro.

Componenti principali del framework Scrum

Il team Scrum comprende un Product Owner, uno Scrum Master e gli sviluppatori, con tre responsabilità distinte. La precedente espressione “componente del team Scrum” nell’articolo indica il gruppo di sviluppo, non una quarta responsabilità né un intero team separato.

Oltre agli altri programmi offerti agli studenti di tutto il mondo, International Scrum Institute™ offre tre programmi principali di formazione e certificazione per questi tre ruoli.

Questi programmi sono Scrum Master Accredited Certification™ (SMAC™), Scrum Product Owner Accredited Certification™ (SPOAC™), e Scrum Team Member Accredited Certification™ (STMAC™).

Una buona organizzazione deve possedere adeguatamente tutte e tre queste competenze. È essenziale per riuscire con Scrum.

Ogni responsabilità Scrum deve essere svolta e restare distinta. Un Product Owner o Scrum Master può contribuire anche come sviluppatore al lavoro dello Sprint Backlog, mantenendo però le responsabilità dell’altro ruolo.

Più team sullo stesso prodotto condividono un Product Owner, un obiettivo di prodotto e un Product Backlog. Ogni team ha la responsabilità di Scrum Master e richiede sostegno efficace; Scrum non prescrive che una persona possa sostenere un solo team.

Non sottovalutare l’importanza di comprendere scopo e funzione dei ruoli e affidarli a persone adeguate. Abbiamo spesso osservato che le difficoltà nascono dal non comprenderli o dall’assegnarli alle persone sbagliate.

Parliamo ora dei tre ruoli.

Tre ruoli Scrum: il Product Owner

Il Product Owner Scrum ordina il backlog per massimizzare il valore e collabora con le parti interessate sulle decisioni di prodotto e rilascio. Gli sviluppatori selezionano il lavoro previsto per uno Sprint; le modalità di rilascio dipendono dal contesto. Rappresenta le richieste funzionali e non funzionali degli utenti finali.

Il ruolo è molto più ampio di quelli tradizionali di Project Manager, Program Manager o Product Manager.

Il ruolo unifica attività di gestione del prodotto e del progetto ed è strettamente integrato con sviluppo e consegna del software.

I compiti essenziali del Product Owner sono:

• Gestire e chiarire i requisiti,
• Guidare i rilasci e assicurare il ritorno sull'investimento (ROI),
• Collaborare strettamente con il team,
• Gestire le parti interessate.

Tre ruoli Scrum: il componente del team

Il team Scrum implementa il software. Gli sviluppatori scelgono quanto lavoro prevedono di completare durante uno Sprint. Lo Sprint è un evento a durata fissa; il risultato di prodotto utilizzabile creato al suo interno è un Incremento che soddisfa la definizione di completato.

Un team eccellente dispone generalmente della maggior parte delle competenze di ingegneria del software. Sviluppatori, architetti, tester, amministratori di database e persone di tutti gli altri ruoli lavorano insieme.

Insieme costruiscono e consegnano software eccellente per il quale il cliente paga.

I componenti non appartengono più a silos funzionali di una struttura a matrice. Gli sviluppatori non appartengono più ai centri di competenza dello sviluppo, i tester a quelli dei test e così via.

Qualunque fosse la collocazione precedente, appartengono al proprio progetto Scrum. Il loro compito è costruire il miglior software possibile per soddisfare i requisiti del Product Owner.

Le caratteristiche dei team Scrum sono:

• Responsabilizzati,
• Autonomi,
• Interfunzionali,
• Auto-organizzati,
• Piccoli,
• Partecipanti sufficientemente disponibili: il tempo pieno è una scelta organizzativa comune,
• Capaci di collaborare strettamente, nella stessa sede o distribuiti,
• Uno per tutti, tutti per uno.

Tre ruoli Scrum: lo Scrum Master

Lo Scrum Master aiuta tutti i partecipanti al progetto e le parti interessate esterne a comprendere e applicare correttamente il framework. Sostiene il team nell’esecuzione del processo e nel miglioramento continuo di produttività e prestazioni.

Il suo ruolo è introdurre Scrum e un nuovo modo di pensare e agire.

Agisce anche come promotore del cambiamento e guida il team a sviluppare nuove norme e standard. Resta accessibile: la vicinanza fisica può aiutare, ma non è un obbligo Scrum.

Le responsabilità essenziali comprendono:

• Introdurre Scrum nell’ecosistema aziendale e informatico,
• Guidare il team a comprendere e vivere i valori Scrum,
• Assicurare una stretta collaborazione tra Product Owner e team,
• Rimuovere gli impedimenti,
• Guidare mettendosi al servizio,
• Sostenere eventi Scrum efficaci e facilitare quando serve, preservando la responsabilità degli sviluppatori sul Daily Scrum.

Product Backlog, o backlog Scrum

Il Product Backlog (Scrum Backlog), o Scrum Product Backlog, è l’elemento centrale per gestire tutti i requisiti noti di un progetto Scrum.

Comprende i requisiti del cliente e gli elementi di lavoro necessari a svolgere e completare con successo il progetto. I requisiti includono aspetti funzionali e non funzionali e altre caratteristiche legate alla progettazione dell’ esperienza utente e interfaccia utente .

Il backlog contiene le richieste di funzionalità e le relative user story. Può includere anche prerequisiti o requisiti complementari, come creare ambienti di test e sviluppo, e storie necessarie a correggere difetti noti, ridurre il debito tecnico o migliorare funzionalità.

Ogni prodotto ha un proprio Product Backlog. Il Product Owner ne è responsabile per creazione, manutenzione e perfezionamento. Il backlog non risponde, né dovrebbe rispondere, a come sviluppare e consegnare i requisiti.

È compito del team Scrum, che decide e documenta negli Sprint Backlog le attività necessarie. Product Backlog e Sprint Backlog sono artefatti distinti, non necessariamente documenti o strumenti fisicamente separati, anche se gli elementi del primo determinano il contenuto del secondo.

Il Product Backlog è un documento vivo. Come il software migliora incrementalmente, il backlog cambia con l’apprendimento del team, attraverso aggiunte, rimozioni e riordinamenti. Scrum non richiede di per sé un processo separato di gestione delle modifiche. Il Product Owner crea le prime versioni del backlog secondo la migliore comprensione iniziale del prodotto.

Osservandone l’evoluzione da uno Sprint all’altro e ampliando le conoscenze dei requisiti, aggiunge, rimuove e perfeziona gli elementi.

Il Product Owner assegna le priorità ai requisiti nel backlog. Più alta è la priorità di un elemento, più dettagli dovrebbe contenere, affinché il team comprenda facilmente i requisiti e crei le attività necessarie.

Inoltre, usando un approccio di stima come gli story point, il team stima regolarmente i requisiti. Le stime delle storie più prioritarie devono essere perfezionate per prepararle alla pianificazione dello Sprint.

Sprint

Tutte le attività per implementare i requisiti avvengono durante gli Sprint. Gli Sprint sono cicli di attività lavorative per sviluppare incrementi rilasciabili di un prodotto software o di un servizio. A volte gli Sprint vengono chiamati iterazioni.

Puoi considerarli piccoli progetti. Come suggerisce il termine "Sprint", non durano a lungo: un mese o meno. Gli Sprint di quattro settimane sono un esempio comune, non l’esatto limite massimo di calendario del framework.

A differenza di una corsa, alla fine dello Sprint il team non dovrebbe essere senza fiato e senza energie: dovrebbe sentirsi fresco e iniziare con slancio quello successivo.

Scrum non mira a creare pressione e stress. È noto che le persone lavorano meglio quando sono concentrate, tranquille e senza distrazioni. Applicati correttamente, gli Sprint ci aiutano a ottenere proprio questo.

Ogni Sprint inizia con una Sprint Planning. Durante la pianificazione il team decide quali e quanti requisiti implementare nello Sprint, poi avvia le attività necessarie a consegnarli.

Daily Scrum, o riunione Scrum quotidiana si svolge ogni giorno lavorativo dello Sprint, alla stessa ora e nello stesso luogo. Gli sviluppatori lo usano per verificare l’avanzamento verso l’obiettivo dello Sprint e adattare il piano della giornata successiva. Possono anche chiedere aiuto allo Scrum Master per rimuovere impedimenti che rallentino o blocchino l’avanzamento.

Il team conclude lo Sprint con revisione e retrospettiva. La riunione di revisione dello Sprint permette a team e principali parti interessate di esaminare risultati e avanzamento verso l’obiettivo di prodotto e discutere adattamenti futuri. È una sessione di lavoro, non una fase di approvazione del Product Owner.

Durante lo Riunione di retrospettiva dello Sprint, il team riflette su come collabora, applica Scrum e può migliorare.

Tiene quindi conto insieme di questi feedback e opportunità di miglioramento nella pianificazione successiva. Gli Sprint consentono questi cicli di feedback in periodi brevi e con piccoli lotti di lavoro. È uno dei motivi principali per cui e del modo in cui il framework Scrum aiuta team e organizzazioni a migliorare continuamente.

Ispezione e adattamento in Scrum

Ispezionare e adattare è un concetto semplice da capire, ma molto difficile da applicare e padroneggiare correttamente.

Le aziende hanno infine riconosciuto che nessun project manager può prevedere completamente il quadro dei sistemi complessi né pianificare in modo affidabile dall’inizio alla fine. Era evidente la necessità di provare qualcosa di diverso.

Insieme alla produzione snella (nota anche come movimento lean), le aziende dovevano sviluppare un processo che le rafforzasse strategicamente. Occorreva una procedura operativa standard per imparare e correggere la rotta durante i progetti e le operazioni.

Nacque così il Toyota Improvement Kata, utile termine di confronto con ispezione e adattamento in Scrum. Gli approcci hanno scopi collegati, ma Toyota Improvement Kata non è semplicemente un altro nome dei pilastri empirici Scrum. Secondo il modello di ispezione e adattamento:

• Passo 1. Ispezionare: Facciamo del nostro meglio per comprendere lo stato del progetto con il livello attuale di conoscenze e comprensione.
• Passo 2. Adattare: Definiamo direzione e visione dei passi successivi, poi elaboriamo la strategia e la realizziamo.
• Passo 3. Apprendere: Osserviamo attentamente, impariamo e ci insegniamo a vicenda mentre lavoriamo. Registriamo continuamente ciò che funziona e ciò che non funziona.
• Passo 4. Ricominciare: Ripartire nuovamente dal passo 1.

I quattro passi seguenti sono un’analogia didattica, non una corrispondenza esatta con gli eventi Scrum. Ispezione, adattamento e apprendimento avvengono durante tutto lo Sprint.

• Passo 1. Ispezionare è analogo alle revisioni e alle retrospettive dello Sprint.
• Passo 2. Adattare è analogo alla pianificazione dello Sprint.
• Passo 3. Apprendere è analogo ai Daily Scrum.
• Passo 4. Ricominciare è analogo alla conclusione di uno Sprint e all’avvio di quello successivo.

Auto-organizzazione

Il team si organizza da solo. I componenti decidono per consenso le attività necessarie a raggiungere gli obiettivi dello Sprint. Un team auto-organizzato non richiede un manager né un capoteam.

L’auto-organizzazione in Scrum è molto disciplinata.

Sprint Backlog e Riunioni Daily Scrum sostengono l’autogestione. Un grafico di burndown dello Sprint è una modalità facoltativa per rendere visibili i progressi.

Per la maggior parte dei team, organizzare autonomamente il lavoro richiede una fase di apprendimento. Scrum Master competenti e certificati li aiutano a eccellere rapidamente.

L’auto-organizzazione comprende anche la collaborazione nonostante opinioni diverse e possibili conflitti. Richiede rispetto e fiducia nei processi decisionali condivisi.

Questi processi comprendono, fra l’altro, pianificazione, stima, implementazione, rendicontazione e revisione del lavoro di cui il team è responsabile congiuntamente.

Eventi Scrum e perfezionamento continuo del backlog

Evento Scrum 1. Pianificazione dello Sprint: perché, che cosa e come

Durante lo Sprint Planning, il team costruisce uno Sprint Backlog realizzabile che stabilisce i requisiti da implementare.

I compiti dei diversi ruoli durante la pianificazione sono:

• Il Product Owner propone perché lo Sprint potrebbe creare valore. L’intero team collabora a un obiettivo e gli sviluppatori selezionano gli elementi del backlog che prevedono di completare.
• Il team individua le attività necessarie e le stima. Gli sviluppatori decidono quali e quanti elementi prevedono di completare, considerando prestazioni passate, capacità e definizione di completato.
• Lo Scrum Master modera la riunione e assicura che auto-organizzazione e autonomia decisionale restino intatte.

La presenza del Product Owner è obbligatoria durante la pianificazione. Può così rispondere alle domande e chiarire requisiti e criteri di accettazione.

Il team può invitare altre persone, come utenti finali o manager, a fornire consigli. Gli invitati danno consigli senza sostituirsi agli sviluppatori nelle decisioni su come lavorare.

Evento Scrum 2. Daily Scrum, o stand-up quotidiano

Il Daily Scrum è una riunione di massimo 15 minuti che si svolge ogni giorno lavorativo alla stessa ora e nello stesso luogo. È meglio avere accesso diretto allo Sprint Backlog e al grafico di burndown. Lo Scrum Team può così orientare il Daily Scrum sulla base dei fatti e dell'avanzamento visibili a tutti i suoi membri.

Il Daily Scrum mira a sostenere l'auto-organizzazione dello Scrum Team e a individuare sistematicamente gli impedimenti.

Il Daily Scrum è per gli sviluppatori. Product Owner o Scrum Master che lavorano su elementi dello Sprint Backlog partecipano come sviluppatori. Ogni altra modalità di partecipazione deve preservarne concentrazione e autogestione: Scrum non impone la presenza di ogni ruolo o parte interessata.

Gli sviluppatori scelgono una struttura utile centrata sull’obiettivo dello Sprint e su un piano attuabile. Le tre domande seguenti sono un formato facoltativo familiare, non domande prescritte dallo Scrum attuale.

• Daily Scrum: domanda #1. Quali attività ho svolto dall'ultimo Daily Scrum?
• Daily Scrum: domanda #2. Quali attività intendo svolgere prima del prossimo Daily Scrum? Qual è il mio piano d'azione?
• Daily Scrum: domanda #3. Ho incontrato o prevedo impedimenti che possano rallentare o bloccare l'avanzamento del mio lavoro?

I Developer conducono il proprio Daily Scrum. Quando serve, lo Scrum Master aiuta a comprenderne scopo ed efficacia. L’evento resta di 15 minuti; il formato a tre domande è facoltativo.

Lo scopo del Daily Scrum non comprende prendere decisioni lunghe né risolvere problemi. Per allineare decisioni e risolvere problemi, il team può organizzare incontri separati su richiesta, generalmente subito dopo il Daily Scrum.

Lo Scrum Master documenta gli impedimenti e le relative date in un registro, lavagna a fogli mobili o rapporto accessibile al team. Trovo molto utile aggiornare rapidamente lo stato degli impedimenti aperti al termine del Daily Scrum.

Evento Scrum 3. Revisione dello Sprint

Il Sprint Review si svolge alla fine dello Sprint. Una revisione di una o due ore può essere adatta ad alcuni team; il massimo formale è di quattro ore per uno Sprint di un mese, con eventi generalmente più brevi per Sprint più corti. Secondo software e infrastruttura, può svolgersi in sala riunioni, laboratorio o nella stanza del team.

Lo scopo è esaminare l’incremento rilasciabile costruito nello Sprint e rendere trasparente lo sviluppo del prodotto.

Il team dimostra i risultati. Insieme alle parti interessate discute ciò che è stato realizzato e che cosa è cambiato nell’ambiente. Esamina risultati e passi successivi: non è un controllo di conformità a un elenco fisso di attività promesse.

La revisione permette a team e parti interessate di esaminare il prodotto e adattare il backlog. Successivamente l’intero team collabora al prossimo obiettivo dello Sprint. Quindi, le revisioni sono un’applicazione formale e pratica di "ispezionare e adattare".

Partecipano team, Product Owner e Scrum Master. Possono unirsi anche altri interessati come utenti finali, clienti e rappresentanti aziendali.

Possono fornire feedback sull’incremento dimostrato. Il team può così ricevere contributi diretti e non filtrati dalle persone per cui costruisce software.

Evento Scrum 4. Retrospettiva dello Sprint

Il Riunione di retrospettiva dello Sprint segue la revisione e conclude lo Sprint. Dura al massimo tre ore per uno Sprint di un mese; per quelli più corti è generalmente più breve.

Lo scopo è migliorare la collaborazione del team e l’applicazione del processo Scrum.

Le retrospettive portano quindi a maggiore produttività, migliori prestazioni dei componenti e qualità del software.

Sono brevi analisi retrospettive per individuare miglioramenti ed eliminare ostacoli del processo. Alcuni esempi frequenti nei nostri progetti sono:

• Adozione di pratiche di sviluppo software agile come extreme programming (XP) oppure sviluppo guidato dai test (TDD).
• Individuare nuove norme e principi del team oppure
• Maggiore disponibilità dello Scrum Product Owner.

Il team svolge una retrospettiva alla fine di ogni Sprint, senza eccezioni. Soltanto così può adattare e migliorare sistematicamente l’uso di Scrum secondo le caratteristiche del progetto.

Pratica collegata: perfezionamento del Product Backlog, o grooming

Scrum Le riunioni di perfezionamento del backlog mirano a mantenerlo aggiornato. Il Product Backlog riflette così le migliori conoscenze e la comprensione dello Scrum Team sul progetto in corso.

Il perfezionamento può avvenire su richiesta o in discussioni programmate. Due sessioni di 30 minuti alla settimana sono un esempio pratico, non una frequenza obbligatoria né un limite massimo. Product Owner e sviluppatori collaborano, coinvolgendo Scrum Master e altri contributori quando utile.

Durante queste riunioni, i partecipanti perfezionano il Product Backlog con le azioni seguenti:

• Aggiungere nuove user story in base ai requisiti appena scoperti.
• Rimuovere le user story non più necessarie al prodotto.
• Affinare le stime delle user story.
• Aggiornare le priorità delle user story.
• Dividere storie enormi in storie più piccole e gestibili, assegnando le priorità appropriate.

Quattro semplici passi per conseguire la certificazione Scrum Master

Conseguirla è semplice, rapido e interamente online.

Grazie a International Scrum Institute™, oggi puoi certificarti più rapidamente e a costi inferiori che mai.

I quattro semplici passi per ottenere la tua certificazione Scrum Master senza sprecare tempo e denaro e senza complicazioni sono i seguenti.

• Passo #1. Iscriviti online

  Iscriviti alla certificazione Scrum Master online attraverso la tua pagina di iscrizione alla Scrum Master Accredited Certification™.

  Dopo l’iscrizione, International Scrum Institute™ invia immediatamente online il codice di accesso all’esame.

  Dal link seguente puoi iscriverti al programma di certificazione Scrum Master.

• Apri immagine a grandezza naturale ↗

  Passo #2. Studia online

  Preparati online usando la tua guida di studio Scrum, The Scrum Framework™.

  The Scrum Framework™ è progettato per essere interamente orientato alla pratica. I contenuti aiutano ad affrontare le sfide quotidiane del lavoro e della carriera di uno Scrum Master di talento. È ricco di casi di studio ed esempi pratici che mostrano una giornata nella vita degli Scrum Master di maggior successo.

  Dal link seguente puoi Richiedi la copia gratuita di The Scrum Framework™.

• Passo #3. Sostieni online il test di certificazione Scrum Master

  Dopo aver letto, studiato e assimilato attentamente The Scrum Framework™, sei pronto! Dovresti sentirti pienamente sicuro di superare l’esame.

  Dal link seguente puoi Accedi all’esame di certificazione Scrum Master.

• Passo #4. Ottieni la certificazione Scrum Master

  Una volta superato l’esame, ti inviamo immediatamente la certificazione.

  Datori di lavoro e clienti possono verificarne l’autenticità usando lo strumento di convalida delle certificazioni Scrum per i datori di lavoro. Dal link seguente puoi accedere allo strumento di convalida delle certificazioni Scrum per i datori di lavoro.

Le mie conclusioni sulla certificazione Scrum Master

È il momento di riepilogare. Se non hai letto ogni parola della guida passo per passo, ecco le mie riflessioni su vantaggi e svantaggi della certificazione.

I vantaggi

Vantaggi per dipendenti, liberi professionisti, coach e formatori

• La certificazione riconosce la tua competenza e le conoscenze aggiornate nell’ambito Scrum.
• Ti aiuta a distinguerti dai colleghi che non si sviluppano più e a ottenere il lavoro dei tuoi sogni come Scrum Master certificato e competente.
• Amplia la prospettiva e apre ulteriormente la mente all’apprendimento continuo, aiutandoti a ottenere più responsabilità e ottime opportunità di carriera.
• Offre nuovi strumenti per consegnare prodotti e servizi eccellenti che clienti e datori di lavoro apprezzeranno.

Vantaggi per organizzazioni e datori di lavoro

• Le certificazioni riducono i costi migliorando l’efficienza di team, attività e processi.
• Aiutano a ottenere progetti che altrimenti non vinceresti, grazie a dipendenti formati e competenti.
• Migliorano soddisfazione e impegno dei dipendenti incoraggiando formazione e sviluppo delle competenze.
• Migliorano qualità dei risultati, soddisfazione dei clienti e infine successo e redditività dell’organizzazione.

Gli svantaggi

• La certificazione non dovrebbe fermare l’apprendimento. Ricorda che conseguirla è soltanto il primo passo.

  Nello spirito di "ispezionare e adattare" appreso con Scrum, resta tuo dovere sperimentare, osservare e imparare continuamente.

• Non esiste una soluzione universale per tutte le organizzazioni del mondo. Scrum non fa eccezione.

  Abbiamo osservato che molte organizzazioni incapaci di ottenere le migliori prestazioni da Scrum hanno una caratteristica comune: non l’hanno adattato al proprio ecosistema aziendale e informatico.

  Sempre nello spirito di "ispezionare e adattare", non considerare Scrum una ricetta di successo garantita al 100%. Non sottovalutare la tua capacità di adattarlo alle dinamiche dell’azienda e dell’informatica. Come professionista retribuito, è proprio ciò che devi fare per ottenere il miglior flusso di risultati e i migliori esiti aziendali.

• Scrum non ha risolto tutti i problemi dei nostri reparti IT. Non smettere di svilupparti con nuovi processi emergenti di sviluppo e consegna software come DevOps.

  Per comprendere meglio i limiti noti di Scrum e come li affronta DevOps, leggi in seguito questo importante articolo: Quali sono le 6 principali differenze fra DevOps e Scrum?

In conclusione, la certificazione Scrum Master è un ottimo punto di partenza per le pratiche agili di sviluppo e consegna del software.

Secondo uno studio Gartner «Diventare uno Scrum Master migliore» pubblicato nel 2019, l’articolo prevedeva per il 2023 che il 92% delle aziende mondiali e il 96% di quelle statunitensi avrebbe adottato pratiche Scrum agili. È la previsione riportata nell’articolo originale, non un tasso di adozione attuale misurato.

Non ci sarà quindi un momento migliore di adesso per

• Inizia a imparare gratuitamente il framework Scrum e
• Consegui la certificazione Scrum Master con le tariffe molto accessibili di International Scrum Institute™.

Resta soltanto una domanda: quando inizierai?