SCRUM

Principi Agile

• individui ed interazioni invece che tools
• software funzionante invece di documentazione
• collaborazione invece di contrattazione con il cliente
• rispondere al cambiamento mentre si segue un piano

Metodologia SCRUM

• trasparenza - gli aspetti del processo significativi devono essere visibili a coloro responsabili per l’esito finale
• ispezione - i documenti Scrum sono tenuti d’occhio per controllare progressi e variazioni
• adattamento - quando ci sono variazioni rispetto al desiderata sono necessarie modifiche al flusso

Di cosa parliamo?

• ruoli
• documenti (artifacts)
• riti
• controlli

Ruoli

• Product Owner
• Scrum Master
• Dev team

Product Owner - skills

1. Domain/Business Knowledge
2. Comunicazioni
3. Organizzazione
4. Negoziazione
5. Analisi

Product Owner - tratti

1. Decisivo
2. Visionario
3. Resilient
4. Leader
5. Responsabile

Product Owner - focus

1. Costruire il prodotto nel modo giusto
2. Realizzare i bisogni e la "felicita’" del cliente
3. Creare una visione di prodotto
4. Bilanciare priorita’, rischi, valore, opportunita’ e le dipendenze necessarie alla costruzione del prodotto nel giusto ordine
5. Massimizzare fatturazione e ritorno sugli investimenti
6. Usare le metriche di progetto
7. Rilasciare frequentemente parti di prodotto per ottenere feedback velocemente

Scrum Master

1. Lo Scrum Master (SM) e’ responsabile per l’efficacia del Scrum Team
2. E’ un leader
   1. serve lo Scrum Team - rimuove gli impedimenti, si assicura che gli eventi dello Scrum abbiano luogo e nei tempi giusti
   2. serve il Product Owner - aiuta il PO a trovare soluzioni per realizzare il prodotto ed a costruire il backlog
   3. serve l’organizzazione - insegna lo Scrum agli altri
3. E’ il coach del team. Amministra i processi, NON le persone.
   1. E’ l’ "Autorita’ di processo", si assicura che tutti comprendano ed applichino le teorie, i valori, le regole e le pratiche Scum
4. Lo scrum master NON e’ un Project Manager - che non esiste in Scrum
5. Puo’ lavorare al progetto anche "part-time"
6. Lo scrum master puo’ anche sviluppare ma e’ sconsigliato

Dev Team

Dimensione del team - 5-9 persone

Scalabilita’ nello Scrum

Artifacts

• Backlog - traguardo di prodotto. Il Product Owner ne e’ responsabile
• Sprint backlog - traguardo dello sprint. Lo scrum team ne e’ responsabile
• Incremento - definito nella definizione di finito. Lo scrum team ne e’ responsabile

Backlog

• Redatto dal PO che ne e’ responsabile
• E’ una lista di elementi, di cose da fare, di User Stories
• E’ la sola sorgente di lavoro
• Deve massimizzare il valore dei delivers
• Non e’ mai completo
• Rappresenta uno stato futuro del prodotto ed e’ parte di una product vision piu’ grande
• Si possono avere piu’ Scrum team ma un solo backlog

Sprint

Uno sprint e’ un lasso di tempo predefinito utile a completare un set di User Stories. In Scum generalmente la durata e’ tra le 1 e le 4 settimane, tipicamente 1 o 2. La durata degli sprint rimane fissa durante tutto il progetto.

1. Lo Sprint Backlog e’ composto da 3 elementi:
   1. lo Sprint Goal (perche’ facciamo lo sprint)
   2. le User Stories selezionate (che cosa facciamo nello sprint)
   3. il Piano per consegnare gli incrementi (come lo eseguiamo)
2. E’ un piano fatto da e per gli sviluppatori
3. Ha altissima visibilita’
4. Puo’ cambiare durante lo sprint, anche se e’ sconsigliato
5. PO e Devs possono negoziare cosa rientri nello sprint ma questo non dovrebbe modificare il traguardo dello sprint
6. Gli elementi incompleti della lista vengono riportati nel Backlog di prodotto per future considerazioni.

Increments - User Story

Sono scritte dal punto di vista del cliente finale. Rispondono a WHO - WHAT - WHY

Template:

as a user type I want to action so that effect

Acceptance Criteria

• arricchisce la user story rendendola testabile ed assicura che la storia sia pronta per la demo
• sono decisi dal Product Owner che il discute con il team
• devono essere definiti in modo che possano "passare" o "fallire"
• devono essere chiari e concisi
• devono essere 3-7 per storia, se ne servono di piu’ la storia va divisa in due

Esempio di User Story

As a new student,
I want to be able to create and account,
so that I can enroll into a course.

Acceptance criteria:

• The user should be able to create an account with the email
• The user should be able to create an account from google

Increments - Task

Il task e’ un elemento del backlog che non e’ una User Story. Generalmente si tratta di un compito di sviluppo necessario al completamento di una o piu’ User Stores

Riti

Lo Scrum Master e’ responsabile per l’organizzazione e la gestione di questi eventi

1. daily scrum
2. backlog refining
3. sprint planning
4. sprint review
5. sprint retrospective

Daily scrum - 15 minuti

E’ responsabilita’ dello Scrum Master

Non e’ un meeting riguardante lo stato del progetto ma un momento per applicare il principio inspect and adapt.

Dura massimo 15 minuti

Tutti rispondono a 3 domande:

• che cosa hai fatto ieri per raggiungere il traguardo dello sprint?
• che cosa farai oggi per raggiungere il traguardo dello sprint?
• hai qualche impedimento per il raggiungimento del traguardo dello sprint?

Daily scrum #2

• In teoria sono ammessi anche i Product managers e gli stakeholders ma non possono interrompere lo scrum team.
• Lo Scrum Master non deve permettere divagazioni e perdite di tempo.
• I membri del team potrebbero rivolgersi allo Scrum Master come se gli dessero lo status del proprio lavoro ma non e’ cosi’: i membri del team devono aggiornarsi principalmente tra di loro

Sprint planning

Inizializza lo sprint individuand che cosa verra’ implementato durante lo stesso. E’ un piano risultante dalla collaborazione di tutto il team:

Il PO si assicura che siano chiari gli elementi del backlog che vengono scelti. Il team puo’ invitare anche altre figure per avere piu’ chiaro possibile che cosa deve fare.

Sprint planning - Story points

Quando si fanno stime non si possono "dare i numeri" ma il numero che viene comunicato dovrebbe essere il piu’ possibile una ipotesi plausibile.

Il cervello umano non e’ in grado di quantificare il lavoro (ed altre cose) in termini assoluti, si deve quindi ragionare in termini relativi.

Gli Story points sono una unita’ di misura relativa che ci devono dire quanto un incremento sia piccolo o grande (e quindi quale sia la sua complessita’).

Dopo i primi 2-3 sprint e’ possibile calcolare approssimativamente a quante ore corrisponda un punto.

Sprint planning - Planning poker

La tecnica piu’ usata e’ quella del Planning Poker:

I membri del team contemporaneamente svelano la loro stima, fatta di numeri appartenenti alla sequenza di Fibonacci

Se la differenza tra il numero minimo e quello massimo e’ piu’ grande di n allora si discute, altrimenti si trova una via intermedia (sempre sulla scala di Fibonacci)

Sprint review - 1-2 ore

E’ responsabilita’ dello Scrum Master

• Non e’ solo una demo o una presentazione degli incrementi: durante questo evento di guarda al risultato dello sprint e si decidono gli adattamenti futuri al piano di lavoro.
• E’ un meeting informale durante il quale il team (tutti, anche il PO) presenta il risultato dello sprint agli stakeholders.
• Idealmente c’e’ anche il cliente e si discutono con lui gli sviluppi futuri. Se quella settimana non si presenta niente, comunque si parla dello sprint successivo.

Sprint retrospective - 30 minuti per ogni settimana di sprint

E’ responsabilita’ dello Scrum Master

• lo scopo principale e’ quello di migliorare la qualita’ e l’efficacia del team
• si parla di individui, interazioni, process e tools
• e’ l’opportunita’ di applicare l’ inspect and adapt al processo che il team sta utilizzando per lavorare
• e’ presente l’intero team
• deve essere un "luogo sicuro" per dire la propria opinione
• si parla dei principi generali, piu’ che di singoli episodi
• NON si danno colpe o addossano responsabilita’, ma si impara come team da cio’ che e’ accaduto

Sprint retrospective - template

• Cosa e’ andato bene?
• Cosa e’ andato male?
• Che cosa potremmo cambiare?

Visione d’insieme

Controlli

• velocity
• burndown chart
• cono di incertezza
• debito tecnico
• refactoring del codice

Velocity

• E’ la somma dei punti che si erano stimati per gli incrementi effettivamente completati
• La velocity ci da un’idea di quanti punti stimati si possono lavorare ogni sprint
• Non si comparano mai i punti lavorati da 2 team diversi - non ha alcun senso
• le velocity calcolate sui primi 2-3 sprint non sono ancora molto attendibili

Burndown chart

Mostra la quantita’ di lavoro che rimane per completare un dato sprint.

Cono di incertezza

• E’ la rappresentazione del fatto che all’inizio del progetto l’incertezza e’ al massimo. Piu’ facciamo e piu’ riduciamo l’incertezza.
• Piu’ lunga, lontana e’ la previsione, tanto meno sara’ accurata.
• Nel waterfall la stima si fa nella prima parte del cono, proprio dove la possibilita’ di errore e’ massima.
• Le conseguenze sul progetto sono devastanti dal punto di vista delle tempistiche ed anche del ritorno economico.

Debito tecnico

E’ un concetto nel campo dello sviluppo software che esprime il costo implicito di rework addizionali causati dalla scelta di una soluzione veloce invece di utilizzare un approccio piu’ preciso ma che richiederebbe piu’ tempo.

Refactoring del codice

E’ una diretta conseguenza del debito tecnico.

E’ il miglioramento di una parte di codice che non cambia il comportamento del software. Per esempio possiamo semplificare una parte di codice in modo che sia piu’ semplice da manutenere, o che sia piu’ facile aggiungere feature in futuro.

Se ne occupa il team di sviluppo direttamente durante lo Sprint.

Contratti e budget

Un contratto con un prezzo prefissato ed un perimetro di lavoro pre-definito e tutto deve essere pianificato con largo anticipo. E’ senza alcun dubbio il contratto peggiore che ci possa capitare perche’ va contro i principi dell’agile, va contro gli interessi della nostra azienda e va contro gli interessi del cliente. (Fixed-Price contract type)

Con il contratto a prezzo fisso molte variabili sono bloccate, nonostante questo e’ possibile ed auspicabile usare la metodologia Scrum.

Il contratto migliore e’ quello con formula simile al rimborso spese o, al limite, un contratto che prevede l’acquisto di giornate da parte del cliente. (Time-and-Material contract type)

Il Product Owner rivede il budget almeno una volta alla fine di ogni sprint e si assicura che un valore proporzionale venga consegnato al cliente.

I nostri tool

• github
• notion
• jira

Github.com

• codice
• issues
• documentazione tecnica
• release

Notion.so

• documentazione di alto livello
• manuali
• documenti condivisi con il cliente
• minute
• note

Jira

• timeline
• backlog
• sprint