PSM-I Certificazione Scrum Master livello 1

👨 Premessa

Uno dei benefit che più sto apprezzando e sfruttando dell’azienda in cui lavoro è la possibilità di poter scegliere un corso all’anno per la formazione continua sul lavoro. Ho a disposizione un vasto catalogo a disposizione ed una scuola interna dove poter frequentare corsi con docenti esperti.

Negli ultimi due anni ho conseguito la certificazione Cloudera developer CCA-175 e la Amazon AWS solution architect SAA-C01 . Quest’anno avevo intenzione di dedicarmi all’approfondimento di una tecnologia molto interessante in ambito cloud e non solo e cioè Docker. Peccato che per problemi organizzativi e varie pianificazioni abbia deciso di sostituire il corso con la preparazione alla certificazione PSM Professional SCRUM Master, e devo dire che per il profilo che attualmente ricopro possa essere solo un plus.

Se non vi siete già stancati di leggere vi racconto un po’ come è andata.

Introduzione

Già nel 1986 Hirotaka Takeuchi e Ikujiro Nonaka descrissero un nuovo processo di produzione industriale alternativo ai metodi di produzione di massa teorizzata da Henry Ford e Alfred Sloan basandosi sull’esperienza di Toyota nel mondo automobilistico, e introducendo il concetto di Lean Production.

A partire da queste teorie e mutuandole dal mondo manifatturiero Ken Schwaber e Jeff Sutherland presentarono per la prima volta Scrum nel 1995 come framework applicabile anche a servizi e prodotti software.

Il termine Scrum è ripreso dal mondo dello sport, infatti nel rugby lo scrum indica il pacchetto di mischia e raffigura lo sforzo di squadra nell’avanzare verso la meta condivisa.

Da allora ha preso sempre più piede questa metodologia insieme ad altre quali Extreme Programming o Crystal che sono state riunite sotto un unico cappello formalizzato dal Manifesto Agile nel 2001.

Nel 2019 è ormai assodata la conoscenza di questa metodologia e sempre più clienti la adottano come alternativa alla progettazione del PMI.

Guida ufficiale

Per iniziare a comprendere di cosa si tratti la prima lettura consigliata è la guida ufficiale che è disponibile gratuitamente dal sito ufficiale https://www.scrumguides.org/ con licenza Creative Commons SA 4.0.

E’ quindi possibile usare e modificare l’opera attribuendone la paternità agli autori e condividendo il contenuto prodotto con la stessa licenza ed è per questo oltre agli appunti che ho cercato di strutturare per prepararmi alla certificazione, qui di seguito ho riportato il copyright per questo post.

Appunti tratti dalla guida ufficiale

In a nutshell

• Scrum è un Framework
  • Leggero
  • Facile da capire
  • Difficile da padroneggiare
• L’essenza dello Scrum è
  • Team piccoli
  • Flessibilità
  • Adattabilità
• Applicabile praticamente a qualunque prodotto o servizio

Teoria

• Scrum si fonda sulla teoria del controllo dei processi empirici.
• Empirismo = la conoscenza deriva dall’esperienza e le decisioni sono basate su quello che è noto.
• 3 pilastri dell’empirismo:
  1. Trasparenza
  2. Ispezione
  3. Adattamento

Valori

1. Coinvolgimento
2. Coraggio
3. Focus
4. Apertura
5. Rispetto

Scrum Team

• I team sono auto-organizzati
• hanno tutte le competenze necessarie per portare a termine il lavoro
• consegnano in modo iterativo e incrementale
• Il modello Scrum è disegnato per ottimizzare:
  1. Flessibilità
  2. Creatività
  3. Produttività

Ruoli

Nessun ruolo è necessariamente full-time, quindi la singola persona può partecipare a più Scrum Team contemporaneamente ed in particolare Product Owner e Scrum Master possono avere anche il cappello di Develepment Team Member.

Product Owner

• Responsabile di massimizzare il valore del prodotto
• 1 Persona
• Responsabile unico del Product Backlog, la cui gestione comporta:
  1. esprimere chiaramente gli Item del Backlog
  2. ordinare gli Item che compongono il Product Backlog
  3. ottimizzare il valore del lavoro del Development Team
  4. assicura che il Product Backlog sia visibile, trasparente, chiaro a tutti

Development Team

• Costituito dai professionisti che portano avanti il lavoro da fare
• Incrementa ad ogni Sprint il lavoro in “Done”
• Solo il team crea un “Incremento”
• Caratteristiche:
  • Auto-organizzato
  • Cross-funzionale e con tutte le skill necessarie
  • Non è divisibile in sotto-team
  • Tutto il team è responsabile del lavoro
  • Non assegna titoli particolari ai componenti
• Dimensione:
  • è abbastanza piccolo da rimanere agile e abbastanza numeroso per completare in modo significativo il lavoro nello Sprint e in genere da 3 a 9 componenti
  • Il numero può variare a seconda della necessità considerando l’eventuale riduzione di produttività.

Scrum Master

• Responsabile di promuovere e supportare lo Scrum
• E’ un leader a servizio dello Scrum Team:
  1. Servizio nei confronti del Product Owner:
     • Tecniche per la gestione del Backlog
     • Aiuta a comprendere il Product Planning
     • Aiuta negli eventi dello Scrum
  2. Servizio nei confronti del Development Team:
     • Coaching
     • Rimuove gli impedimenti
     • Aiuta gli eventi dello Scrum
  3. Servizio nei confronti dell’organizzazione intesa come elementi esterni allo Scrum Team
     • Pianificare l’adozione dello Scrum
     • Lavorare con gli altri Scrum Master

Eventi

• Sono tutti Time-Boxed
• A parte lo Sprint che è un contenitore gli altri eventi sono momenti formali di Ispezione e Adattamento
• possono esserne previsti ulteriori se possono facilitare la realizzazione dello Sprint Goal.

Sprint

• 1 mese o meno nel quale si genera Incremento del prodotto. Lo sprint finisce quando termina il time boxed di un mese, la durata non può essere accorciata o allungata.
• Un nuovo sprint inizia subito dopo il termine del precedente
• Composto:
  1. Sprint Planning
  2. Daily Scrum
  3. Lavoro di sviluppo
  4. Sprint Review
  5. Sprint Retrospective
• Durante lo sprint:
  1. Non viene apportata nessuna modifica che metta in pericolo lo Sprint Goal
  2. La qualità non deve diminuire
  3. Se si cancella uno sprint va comunque fatta la review del fatto
• Cancellare uno Sprint:
  • solo il Product Owner può cancellare lo sprint
  • se lo Sprint Goal è obsoleto
  • quello che è stato completato in “Done” viene rivisto
  • se parte del lavoro è rilasciabile, viene rilasciato dal Product Owner
  • il resto viene stimato nuovamente e messo nel Product Backlog

1. Sprint Planning

• 8 ore al mese per uno Sprint di 1 mese
• Descrive tutto il lavoro da fare nello Sprint
• E’ deciso da tutto lo Scrum Team
• risponde a
  • Cosa può esser fatto in questo Sprint? Sprint Goal, che è un’obiettivo, funzionalità da raggiungere attraverso l’implementazione del Product Backlog e che guida il team sul perchè l’implementazione crei un Incremento.
  • Come si procede a fare il lavoro scelto per questo Sprint?
• Tutto il lavoro va pianificato in attività di 1 giorno
• Si possono coinvolgere esterni per eliminare gap tecnici e tecnologici
• Input:
  • Product Backlog
  • The latest product Increment
  • Projected capacity of the Development Team during the Sprint
  • Past performance of the Development Team.
• Output: Sprint Backlog costituito da:
  • Product Backlog scelto
  • Sprint Goal
  • Piano di rilascio

2. Daily Scrum

• 15 minuti al giorno (fissi a prescindere dal time-boxed dello Sprint)
• Si pianificano le attività per le successive 24 ore
• Non è un evento strutturato ma dovrebbe rispondere a questi quesiti:
  1. Cosa ho fatto ieri per arrivare allo Sprint Goal
  2. Cosa farò oggi per arrivare allo Sprint Goal
  3. Vedo impedimenti nel farlo
• successivamente all’evento è possibile ri-pianificare e adattare il restante Sprint Backlog
• il Development Team è responsabile
• Scrum Master aiuta a mantenere l’evento time-boxed

4. Sprint Review

• 4 ore al mese per uno Sprint di un mese
• si tiene alla fine dello Sprint
• adattare e rivedere il Product Backlog in modo da capire cosa possa andare allo Sprint Planning successivo.
• ispezionare l’Incremento
• Riunione informale
• include i seguenti elementi:
  • Scrum Team+ Key Stakeholder invitati dal Product Owner
  • Il Product Owner illustra il Done
  • Development Team discute
    • cosa è andato bene
    • cosa è andato male
    • come si sono risolte le cose andate amle
  • Development Team risponde dell’operato
  • Product Owner discute del Backlog + delle date di rilascio
  • Tutti discutono sulle prossime cose da fare -> input per lo Sprint Planning dello Sprint successivo.
  • Review della timeline e del budget

5. Sprint Retrospective

• 3 ore al mese
• Opportunità di fare Autoanalisi per pianificare miglioramenti nello Scrum team
• Obiettivi:
  • Ispezionare l’ultimo Sprint in termini di: persone, relazioni, processo, strumenti
  • Prioritizzare: cosa è andato bene, potenziali miglioramenti, pianificazione dei miglioramenti
• E’ un momento formale di Ispezione e Adattamento
• Il Development Team può raffinare la definizione di “Done” per aumentare la qualità del prodotto.

Artefatti

1. Product Backlog

• Lista ordinata in base al grado di chiarezza e comprensione di tutto quello che serve per il prodotto.
• Il Product Owner è responsabile
• Non è mai completo perché evolve
• Elenca
  • Caratteristiche
  • Funzionalità
  • Requisiti
  • Miglioramenti
  • Soluzioni
• Gli Items hanno:
  • Descrizione
  • Ordine
  • Stima
  • Valore
  • Definizione di “Done” (se diverso da quello organizzativo)

a. Product Backlog Refinement

• E’ l’azione di dettagliare, stimare, ordinare gli Item
• Consuma Max 10% del Team
• gli Item che possono essere messi in Done in uno Sprint sono i candidati “Ready” dello Sprint Planning
• Il Development Team è responsabile di tutte le stime

b. Monitoraggio del progresso

• In ogni momento è disponibile il lavoro totale rimanente, almeno al termine di ogni Sprint Review. (Si può utilizzare il Burn-down Chart)
• Tale informazione è trasparente agli Stakeholder.
• Responsabilità del Product Owner

2. Sprint Backlog

• Sottoinsieme del Product Backlog + Pianificazione di rilascio
• Per assicurare un miglioramento continuo + 1 elemento della Retrospective
• Eventuali variazioni sono gestite nel Daily Scrum
• solo il Development Team lo può cambiare durante uno Sprint

a. Monitoraggio del progresso

• In ogni momento è disponibile il lavoro totale rimanente, almeno al termine di ogni Daily Scrum.
• Responsabilità del Development Team

3. Incremento

E’ la somma di tutti gli Item del Product Backlog completati durante uno Sprint + valore di tutti gli Incrementi precedenti.

a. Trasparenza dell’artefatto

Lo Scrum Master deve aiutare a mantenere la completa trasparenza degli artefatti. La mancata completa trasparenza si verifica quando il risultato ottenuto è diverso da quello atteso.

Definizione di Done

• L’obiettivo di ogni Sprint è di rilasciare Incrementi di funzionalità che aderiscono alla definizione aziendale, organizzativa di Done
• I Development Team rilasciano 1 Incremento per ogni Sprint
• Il Product Owner può decidere di rilasciare immediatamente l’Incremento
• Done è parte di una convenzione standard o linea guida di tutti i Development Team che lavorano allo stesso Product, ciò però non implica che la stessa definizione venga usata da tutti i team che lavorano allo stesso prodotto. In particolare la definizione viene data dall’organizzazione e se non aderente dal team di sviluppo.
• Ogni Incremento è additivo nei confronti di tutti i suoi precedenti quindi si integra naturalmente con gli altri incrementi
• Con l’esperienza la definizione di Done si espande per includere criteri sempre più stringenti che determinano una qualità superiore del prodotto. Questo avviene nella Sprint Retrospective.
• Assicura la trasparenza dell’artefatto, a scegliere cosa può essere fatto in fase di planning, capire quando una parte dell’Incremento è completato.

Certificazione PSM-I (Professional Scrum Master I)

• La certificazione viene somministrata attraverso un test online di 80 domande per 1 ora di durata.
• Per passare il test è necessario totalizzare almeno 85% di risposte corrette.
• La lingua di riferimento è l’inglese ed è bene leggere la guida più volte per appropriarsi delle parole chiavi che si possono trovare nelle domande del test.
• Come tutti i test a crocette una strategia valida è quella di leggere bene tutta la domanda e le risposte. Se la si sa subito bene, altrimenti ragionare escludendo le risposte sicuramente false può portare ridurre od addirittura trovare quella giusta.
• E’ bene leggere più volte la guida ufficiale.
• Qui sotto lascio un link valido e gratuito per potersi esercitare con delle domande simili (ma non uguali) a quelle che si possono trovare durante il test.
• Il corso che ho seguito è durato 3 giorni lavorativi ma per la preparazione non occupandomi più di 30 minuti a sera ho impiegato 1 mese circa.
• Oltre alla guida ufficiale è necessario recuperare informazioni sullo scaled Scrum ed in particolare su Nexus dalla Scrum.org

Link di preparazione

1. Sito ufficiale per certificazione PSM-I
2. Guida ufficiale. Meglio scegliere la versione originale in inglese visto che l’esame sarà in inglese.
3. Mikail Lapshin nel suo blog propone un test online di preparazione.

Considerazioni

Ultimamente è sempre più richiesta l’esperienza in questo ambito. I recruiter spesso chiedono la conoscenza del metodo SCRUM soprattutto se lavorate nello sviluppo software. La guida è coincisa per essere in inglese. Solitamente i libri di testo di inglesi e americani sono prolissi e spesso più pragmatici che teorici. Questo invece è una guida di 20 pagine che nella sua brevità rispecchia quanto detto subito dagli autori: il framework è facile da comprendere ma difficile da padroneggiare. E se vi state chiedendo se ho completato la certificazione… ecco qui la mia licenza: https://www.scrum.org/certificates/482916

Copyright

©2017 Ken Schwaber and Jeff Sutherland. Offered for license under the Attribution Share-Alike license of Creative Commons and also described in summary form. By utilizing this Scrum Guide, you acknowledge and agree that you have read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.

Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. (The Scrum Guide)