Lesson 1

Principi alla base del Manifesto Agile:

● Soddisfare il cliente attraverso la consegna tempestiva e
continua di software di valore;
● Distribuisci software funzionante frequentemente;
● Conversazione faccia a faccia per trasmettere informazioni
all’interno del team;
● La semplicità è essenziale;
● Il team deve riflettere su come diventare più efficiente.

SCRUM

Definizione Scrum è un approccio agile per lo sviluppo di prodotti e servizi

innovativi

Perché ● Mostra i risultati di lavoro ogni poche settimane circa per

ottenere feedback
● Necessità di una rapida esplorazione e feedback
● I team devono essere più interfunzionali
● Sincronizza frequentemente (tutti i giorni)
● Discuti le questioni importanti in anticipo

Sintesi ➔ Un elenco prioritario delle funzionalità necessarie per sviluppare

un prodotto di successo;
➔ Lavora prima sugli elementi più importanti o con la priorità più
alta;
➔ Il lavoro viene eseguito in iterazioni brevi e cadenzate;
➔ Qualsiasi lavoro che non è stato completato avrà una priorità
inferiore rispetto al lavoro completato.
➔ Alla fine dell'iterazione dopo ogni sviluppo di una singola
funzionalità
➔ Il team esamina le funzionalità completate con le parti
interessate per ottenere il loro feedback;
➔ È possibile pianificare il lavoro successivo.

Quando ➔ SCRUM si concentra sulla fornitura di funzionalità funzionanti,

scegliere integrate, testate e di valore aziendale;
SCRUM ➔ SCRUM è buono in ambiti complessi;
 ➔ Questo non è un buon approccio per problemi semplici;
➔ SCRUM non va bene per i domini caotici che richiedono una
risposta rapida;
➔ SCRUM non è adatto per problemi guidati da interruzioni (la
programmazione guidata da interruzioni è un paradigma di
programmazione in cui l'esecuzione di un programma è
determinata da eventi esterni chiamati interruzioni).

Benefici ➔ Clienti felici;

➔ Investimenti migliorati;
➔ Costi redatti;
➔ Risultati rapidi;

SCRUM non è un processo standardizzato, non ci sono una

serie di passaggi sequenziali da seguire per produrre, nei
tempi e nel budget previsti, un prodotto di alta qualità che
soddisfi i clienti.
Esistono tre tipi di ruoli: SCRUM master (colui che gestisce il
team), team di sviluppo e product Owner

Lesson 2
Plan-driven development è un principio tradizionale, sequenziale, anticipatorio e predittivo,
dove si cercano di anticipare tutte le funzionalità che l'utente vuole per poi trovare il modo
migliore per svilupparle. Il prototipo maggiore è il waterfall model che esegue una fase alla
volta completa: analisi, design, coding, testing and operation.

In SCRUM lavoriamo su una feature alla volta, e i continui feedback dell'utente ci guidano
nello sviluppo.
SCRUM principles:
 ● Variability and uncertainty: Scrum sfrutta la variabilità ed incertezza nello sviluppo del
prodotto creando soluzioni innovative.
Scrum: is based on iterative (multiple passes to improve) and incremental
development (finish one part before all the project);
● Ridurre tutte le forme di incertezza contemporaneamente: eliminare ogni forma di
incertezza sia del cliente che dal punto di vista implementativo;
● Prediction and Adaptation: bilanciare costantemente il desiderio di predirre, e la
manterremo finchè non finiamo di sviluppare quella parte, con la necessità di
adattarsi nel caso di feedback;
● Validated Learning: organizzare il lavoro per creare un lavoro facendo delle
assunzioni che cerchiamo di validare immediatamente poichè ogni assunzione ha un
rischio che sia sbagliata;
● Work in progress (WIP): dobbiamo minimizzare i lavori iniziati e non finiti e lo
facciamo identificando lavoratori in standby, poiché lavori in ritardo hanno dei costi e
la prossima volta possiamo fare una stima migliore dei giorni necessari per
completare quel lavoro;
● Progress: misurare i progressi in base a ciò che abbiamo realizzato (che l'utente
piace) e non in base a come stiamo procedendo. Questa fase è utile per pianificare,
misurare i progressi e concentrarsi sulla consegna;
● Performance: per le performance dobbiamo andare veloci, ovvero dobbiamo fare le
nostre interazioni in modo fast per ricevere feedback subito. Dobbiamo fare un
software di qualità perché ad ogni iterazione il cliente deve utilizzare quella parte
perché è la versione finale. Produrre qualche documento minimale, non significa non
creare il manuale, ma ridurre al minimo la documentazione perché in SCRUM non è
necessaria.

Riassunto
SCRUM è buono per creare prodotti dove il contesto è in continua evoluzione, dove sono
previsti cambiamenti, ci sono numerosi feedback e con un contesto temporale iterativo.

Plan-drive sequential é buono per creare progetti prevedibili e dove non sono previsti
cambiamenti.

Lesson 3
Sprint è lo scheletro del framework SCRUM, ovvero l'iterazione dello SCRUM. Esso deve
avere un goal che una volta iniziato non dev'essere alterato. Il tempo è anche fissato, sia
l'inizio che la fine. Fissare il tempo comporta dei benefici come prioritizzazione e
performance, lavoro di team migliore. La durata degli spring dev'essere breve in modo tale
che abbiamo un miglior rapporto con il cliente ed è migliore per il team. La pianificazione
delle scadenze porta una migliore coordinazione, sincronizzazione del lavoro.
Il cambiamento in SCRUM non è consentito, mentre la chiarificazione si, basta che non sia
una nuova feature.
Se il goal dello spring diventa invalido possiamo decidere se continuare a lavorare su quella
feature per vendere il software ad un'altra azienda oppure possiamo stopparci e prendere
una feature piccola per i restanti giorni e lavorarci per la restante parte in modo tale da
essere sincronizzati.
Done è una sorta di checklist di ciò che dobbiamo realizzare nello spring, secondo il lato del
cliente e non il nostro punto di vista. Se la checklist è finita, abbiamo finito lo spring. Si
possono aggiungere dei criteri per la valutazione di done.

Riassunto
Spring provede lo scheletro di scrum. Esso é piccolo, con tempo e consistente nel tempo.
L'obiettivo non può cambiare. Dev'essere conforme con la definizione di done.

Requiremwnts and User Stories

Nella produzione sequenziale i requisiti non sono negoziabili. In SCRUM i dettagli sono
negoziabili attraverso le conversazioni che succedono nei continui sviluppi.
Per ogni requisito dobbiamo creare un PBI (placeholder), ovvero un product backlog item
che é un singolo elemento di lavoro con il prodotto backlog. Include qualsiasi task per
migliorare il progetto. SCRUM non ha un formato per il placeholder ma é conveniente
utilizzare una struttura semplice come una conversazione. Un template comune é la card
(un postit) che contiene l'user role, il goal e il beneficio; non deve avere tutti i dettagli del
goal ma alcune frasi essenziali.

Le user stories catturano cosa l'utente e il cliente ha bisogno in diversi livelli di astrazione.
Se abbiamo una piccola storia siamo obbligati a definire tutti i requisiti di livello basso. Le
labels di convenienza sono epic (months size), features (weeks size), sprintable stories
(days size).
I criteri per una buona storia sono: indipendente, negoziabile, valutabile, estimabile, piccolo
e testabile.
I requisiti non funzionali devono essere inclusi nella definizione di done.

I requisiti in SRUM sono definiti come stories, le storie sono delle cards, conversazioni e
conferme.

The Product Backlog

É una lista prioritizzata di funzionalità desiderate. É una coniscenza condibisa di ciò che
dobbiamo costruire ordinata. Non troviamo soltanto le funzionalità ma anche fixare qualcosa,
tecnical work come aggiornare il sistema o acquisizione di conoscenza ovvero creare
prototipi e testarli per vedere quali dei due performa meglio.

Grooming é composto da tre attività: creare e definire i PBI, estimarli e prioretizzarli.

Grooming é uno sforzo collaborativo tra clienti e team. Alla fine del grooming ognuno devw
avere chiaro e condiviso il backlog del prodotto.

Ready: una checklist dei lavori da completare prima che il prodotto prima che esso sia
considerato ok, ovvero springable.

Grooming è il flusso delle features dentro la release. Il backlog può essere partizionato in tre
aree che possono essere implementate o meno: da avere, nice to have, won't have.

Lab 1
Il Continuous Delivery (CD) è uno sviluppo pratico dove il software è incrementalmente
costruito. Si preferiscono piccole integrazioni rispetto alle grandi. CD non è un insieme di
tools ma richiede teamwork e collaborazione.

La pipeline di distribuzione è un’infrastruttura che consente la distribuzione continua, veloce

ma nonostante ciò sicuro ed esatto.
Le fasi principali di una pipeline di distribuzione sono:
▸ Fase di commit: fornisce un feedback rapido agli sviluppatori sul loro lavoro; La fase di
commit consiste nell'eseguire automaticamente unit test su ogni commit prodotto dagli
sviluppatori.
▸ Repository degli artefatti: archivia l'output della fase di commit; Ogni versione candidata (o
artefatto) dovrebbe essere caratterizzata da un identificatore univoco per poter essere
archiviata nell'Artifact Repository. L'Artifact Repository più semplice è una cartella semplice,
dotata di alcuni script per identificare la versione candidata più recente.
▸ Fase di accettazione: elimina le liberatorie dei candidati; La fase di commit testa il software
dal punto di vista dello sviluppatore, utilizzando principalmente test unitari, mentre la fase di
accettazione testa il software dal punto di vista degli utenti finali.
▸ Distribuzione: distribuisce una versione in un ambiente di produzione o simile alla
produzione. Il principio fondamentale del CD è che tutto il software che sopravvive alla
pipeline è rilasciabile e dovrebbe essere possibile rilasciare ogni versione.
Tutte le fasi, tranne eventualmente l'ultima, dovrebbero essere automatizzate, per garantire
riproducibilità e coerenza durante lo sviluppo.
Una pipeline di distribuzione è un oggetto complesso che è meglio creare in modo
incrementale, fase per fase. Una buona pratica è quella di “far crescere” la pipeline sopra
uno scheletro ambulante. Uno scheletro ambulante è un piccolo sistema che svolge una
funzione end-to-end e può essere implementato, magari sviluppando una singola
caratteristica dell'intero sistema. Una volta disponibile lo scheletro ambulante, dobbiamo
rispondere alle seguenti domande:
▸ Come eseguire i test unitari per questo?
▸ Come eseguire i test di accettazione?
▸ Come implementarlo in un ambiente di tipo produttivo?

Git non è stato progettato per piccoli progressi, però è possibile lavorare sul main (trunk-
based development) e rimanere i branch molto piccoli scaled trunk-based development). È
molto importante non pushare qualcosa di errato nel branch master. Ci sono alcuni tool
come Branch Protection (che offrono delle coperture per i branch), code review (possiamo
usare github actions per verificare che i branch che vogliamo mergiare non rompono i test
unitari) e development's discipline (ovvero una serie di regole da seguire per evitare futuri
problemi).

Nell'ambiente CD dobbiamo sempre stare in uno stato di rilascio e dobbiamo aggiungere

piccole feature costantemente.

GitHub actions è una funzionalità di GitHub che permette l'esecuzione di flussi di lavoro. Un
flusso di lavoro è una sequenza di lavori eseguiti dai runner. Un lavoro è composto da steps
che possono essere comandi shell o funzionalità terze dette actions.
Un runner è una macchina virtuale che esegue flussi di lavoro. Uno step è uno script shell o
un'azione. I jobs sono una sequenza di steps da eseguire in ordine.
Lesson 4
Estimation and velocity
La stima è importante capire i tempi necessari per implementare ed anche i costi. In media
possiamo fare 18-20 storie in a sprint. Per la velocità riusciamo a capirla dopo qualche sprint
con precisione. L'estimazione è fatta in diversi livelli di granularità.

PBI estimation
Estimate as team: occorre scegliere come un team;
Estimate non sono commissioni: è importante essere accurati e non precisi;
L'estimazione non ha una size. Le piú comuni unità di misura sono gli story point e gli ideal
days oppure 70% per gli story points e 30% per gli ideal days.
Per stimare usiamo una specie di poker dove il team si mette d'accordo sullo stesso
numero.

La velocità è calcolata per ogni lavoro completato, ovvero che è done. È necessario
calcolare un range di velocità al fine perché qualche volta andiamo veloci altre volte lenti. La
velocità è qualcosa che non può aumentare nel tempo, anche se lavoriamo di piú.

Technical Debt
Ci sono dei debiti

Lesson 5
TODO