Exam: Project (80%) [they will assign the project, groups less than 9

members] + oral (20%) [one question about test driven preparation]

Lezione 1
Intro

Scrum è un metodo di lavoro agile. Il termine è stato preso dal rugby e fa riferimento a un
modo di riprendere il gioco dopo un'interruzione accidentale o quando la palla esce dal
campo.

Scrum è un approccio "a staffetta" allo sviluppo di prodotti, in cui una squadra cerca di
avanzare insieme, passandosi il "pallone" del lavoro avanti e indietro, il che può essere più
efficace per le esigenze competitive odierne rispetto a un approccio basato sulla massima
velocità e flessibilità.

Scrum inizia con la creazione di un "product backlog", una lista prioritizzata delle funzionalità
necessarie per sviluppare un prodotto di successo. Il lavoro viene eseguito in iterazioni di
breve durata, e alla fine di ogni iterazione, il team rivede le funzionalità completate con gli
stakeholder e può apportare modifiche ai piani futuri.

Scrum è adatto per affrontare domini complessi in cui gran parte delle informazioni è
sconosciuta. È basato su principi come l'esplorazione rapida di nuove idee, il rapido
apprendimento da soluzioni viable e la presentazione di risultati funzionanti ogni poche
settimane per ottenere feedback.

In conclusione, Scrum è un framework semplice ma non facile da applicare che favorisce

l'auto-organizzazione dei team, evidenzia le disfunzioni e gli sprechi, ma non offre una
soluzione preconfezionata per tutti i problemi organizzativi. È incentrato sulle persone, i
valori e i principi, e ogni organizzazione può adattarlo in modo unico alle proprie esigenze.
Scrum benefits
● Delighted customers
● Improved return on investment
● Reduced costs
● Fast results
● Confidence to succeed in a complex world
● More joy
Lezione 2
Principi Agili dello Scrum

Plan-driven development: noto anche come sviluppo tradizionale, sequenziale,

anticipatorio, predittivo o prescrittivo. Questo processo cerca di pianificare e anticipare
inizialmente tutte le funzionalità che un utente potrebbe desiderare e determinare come
costruire al meglio queste funzionalità. Un modello importante è il modello a cascata, che
prevede una sequenza completa di analisi dei requisiti, seguita da una progettazione
completa e poi dalla codifica/costruzione e dai test. Lo sviluppo pianificato funziona bene per
problemi ben definiti, prevedibili e che non subiranno cambiamenti significativi.
Scrum
Scrum è diverso. Si adatta a problemi con abbastanza incertezza da rendere difficile la
previsione. I suoi principi provengono dal Manifesto Agile e dallo sviluppo del prodotto.

Lo Scrum utilizza iterazioni adattive chiamate "sprint". Tutte le fasi sono eseguite insieme,
lavorando su una caratteristica alla volta. Alla fine di uno sprint si crea un incremento di
prodotto valido che include alcune delle funzionalità del prodotto. Questo incremento deve
essere integrato e testato con le funzionalità sviluppate in precedenza, altrimenti non è
considerato completo. Il feedback costante guida la progettazione del prodotto.
Lo Scrum abbraccia la variabilità e l'incertezza, riconoscendo che sono necessarie per
costruire qualcosa di nuovo. Promuove l'ispezione, l'adattamento e la trasparenza per
gestire la variabilità e ridurre simultaneamente tutte le forme di incertezza.
Gli altri principi chiave dello Scrum includono la validazione delle assunzioni importanti in
modo tempestivo, l'uso di molteplici cicli di apprendimento simultanei e l'organizzazione del
flusso di lavoro per ottenere un feedback rapido.
Inoltre, lo Scrum incoraggia a "andare veloce ma mai affrettarsi", a costruire la qualità in ogni
passaggio e ad adottare una cerimonia minima ma sufficiente per evitare la burocrazia
eccessiva.
Lo Scrum è ideale per progettare nuovi prodotti in un contesto complesso e in evoluzione,
promuovendo il cambiamento, l'adattamento e il feedback costante.
Lezione 3
Sprints
Le "Sprint" rappresentano un componente essenziale del framework Scrum. Si tratta di
iterazioni di lavoro con una durata massima di un mese, definite da un obiettivo che non
dovrebbe essere modificato una volta iniziato. Le Sprint sono caratterizzate da date di inizio
e fine fisse e seguono il principio del "timeboxing", una tecnica di gestione del tempo che
aiuta a organizzare il lavoro e a gestire lo scopo. Le Sprint sono di breve durata per favorire
la pianificazione e l'ispezione continua del lavoro.
È importante evitare cambiamenti significativi dopo la pianificazione della Sprint, poiché ciò
può comportare costi aggiuntivi e una perdita di fiducia nel team. Tuttavia, Scrum è anche
flessibile e consente di affrontare situazioni eccezionali, come la terminazione anticipata di
una Sprint, in modo pragmatico. La Sprint dovrebbe produrre un incremento potenzialmente
consegnabile, conforme a una definizione di "Done" concordata, che dovrebbe evolvere nel
tempo. 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.
Acceptance test: Determine if the backlog item functions as desired

Change vs clarification: Change is when we change something, clarification is when we

discuss details about that PBI.

Requirements and User Stories

In Scrum, i requisiti non vengono dettagliati inizialmente. Invece, vengono negoziati
attraverso conversazioni continue durante lo sviluppo. Vengono creati dei segnaposto per i
requisiti, chiamati Product Backlog Items (PBI), che rappresentano un valore aziendale
desiderabile. Questi PBI iniziano grandi e diventano più piccoli e raffinati nel tempo. Scrum
non ha un formato standard per PBI, spesso fornito come storie utente.
 A common template format:
1. A class of users (the user role)
2. What that class of users wants to
achieve (the goal)
3. Why the users want to achieve
the goal (the benefit)

Le conversazioni svolgono un ruolo cruciale nel facilitare la comprensione condivisa e la

comunicazione dei requisiti. La raffinazione progressiva consente diversi livelli di dettaglio
nei requisiti, a seconda di quando verranno lavorati.

Le storie degli utenti sono utilizzate per esprimere i requisiti in Scrum. Sono semplici,
comprensibili sia per il business che per i team tecnici e possono essere scritte a diversi
livelli di granularità. Il formato delle storie degli utenti è descritto come "scheda,
conversazione e conferma".

Vengono introdotti i criteri "INVEST" per valutare le storie degli utenti: Indipendente,
Negoziabile, Valutabile, Stimabile, Piccola e Testabile.

Non-functional requirements: Possono essere scritti come card ma non sono ottimali, ma
devono essere inclusi nella definizione di done.
.
The product Backlog
Il Product Backlog è una lista prioritizzata delle funzionalità desiderate per un prodotto.
Serve come base per la pianificazione e lo sviluppo del prodotto.

Gli elementi del Product Backlog, chiamati anche "PBIs" (Product Backlog Items), sono
rappresentati da funzionalità che apportano valore tangibile agli utenti o ai clienti. Possono
anche includere la correzione di difetti, miglioramenti tecnici e altre attività di valore.

Un buon Product Backlog deve essere "DEEP" - Dettagliato in modo appropriato,

Emergente, Stimabile e Prioritizzato.

Il Grooming è un processo di gestione proattiva degli elementi nel Product Backlog, che
comprende la creazione e il raffinamento degli elementi, la stima dei tempi e la loro priorità.

Il Grooming è un'attività collaborativa guidata dal Product Owner, con la partecipazione di

stakeholder, ScrumMaster e il team di sviluppo. Essa può avvenire a diverse frequenze,
inclusa la pianificazione iniziale, riunioni settimanali o durante l'esecuzione dello sprint. Può
anche essere distribuito lungo lo sprint.
La definizione di "Ready" assicura che gli elementi in cima al Product Backlog siano pronti
per essere inseriti in uno sprint. È una checklist di lavoro da completare prima che un
elemento possa essere considerato pronto per lo sviluppo.

Il Grooming supporta la pianificazione continua dei rilasci, consentendo di suddividere il

backlog in "Must have" (necessari), "Nice to have" (graditi) e "Won't have" (non necessari)
per i futuri rilasci.

Di solito, si ha un Product Backlog per un singolo prodotto, ma in progetti più complessi, si

possono avere molteplici Product Backlogs, ad esempio, uno per ogni prodotto o team.

Lab 1
CI/CD
Nella progettazione tradizionale del software, l'integrazione dei sottosistemi software viene
ritardata fino alla fine del ciclo di sviluppo. Il sistema non è garantito di funzionare tra le
diverse versioni. La distribuzione di una "release" rappresenta l'unità di software rilasciabile.
I problemi emergono nelle release quando gli utenti iniziano a utilizzare il sistema e
scoprono bug, comportamenti non desiderati e funzionalità mancanti.

Consegna Continua (CD)

La Consegna Continua è una pratica di sviluppo in cui i sistemi software vengono costruiti
incrementalmente. Favorisce integrazioni frequenti e incrementalità nello sviluppo delle
funzionalità. Una volta che il sistema diventa rilasciabile, dovrebbe rimanere rilasciabile fino
all'ultima funzionalità da sviluppare. La CD richiede collaborazione, disciplina e competenze
tecniche.

Pipeline di Consegna
La pipeline di consegna è l'infrastruttura che supporta la pratica della Consegna Continua.
Contiene tutte le fasi necessarie per consegnare il software. Deve essere veloce per fornire
feedback rapido e deve rilevare i problemi in modo tempestivo. Tutto il codice che supera il
pipeline è considerato rilasciabile.

Fasi Principali del Pipeline CD

● Fase di Commit: esegue test unitari su ogni commit e produce una release
candidata;
● Repository degli Artefatti: archivia le release candidate prodotte nella fase di
commit;
● Fase di Accettazione: promuove le release candidate a release rilasciabili;
● Distribuzione: rilascia una release in un ambiente di produzione o simile.

Implementazione del Pipeline di Consegna

Il pipeline di consegna dovrebbe essere costruito incrementalmente, fase per fase.

Versionamento Semantico
Il versionamento semantico è un insieme di regole per assegnare automaticamente una
versione unica a ogni release. Ogni aumento di versione ha significati specifici: patch per
correzioni di bug, minor per bug-fix ritenuti più significativi e major per modifiche
incompatibili con le versioni precedenti.

Branch by Abstraction
Questo modello consente di sostituire un sottosistema senza interrompere la pipeline. Si
procede con lo sviluppo del nuovo sottosistema e la sostituzione del vecchio quando si è
pronti.

Github
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.

Lezione 4
Estimation and Velocity
La stima delle PBIs riguarda le stime su quanti elementi verranno completati e quale sarà il
costo associato.

La velocità rappresenta la quantità di lavoro che il team di sviluppo è solito completare in

ogni sprint. Si calcola sommando la dimensione di ogni PBI completata (in accordo con la
definizione di “Done”). Le PBIs parzialmente complete non vengono conteggiate. Dopo
alcune iterazioni, si ottiene sia una velocità media che un intervallo minimo-massimo di
velocità. La velocità non aumenta nel tempo, ma migliorare il processo e fornire strumenti
migliori possono influire positivamente sulla velocità. La velocità non dovrebbe essere
utilizzata come una misura delle prestazioni del team, ma come uno strumento di
pianificazione e diagnostico.

Le stime delle PBIs fanno parte della gestione del backlog del prodotto e possono essere
espresse in punti storia o giorni ideali. Le stime delle attività sono parte della pianificazione
dello sprint e possono essere espresse in ore ideali.

La stima delle PBIs coinvolge il contributo collettivo del team di sviluppo. Il product owner
descrive le PBIs ma non guida o influenza il team, mentre lo ScrumMaster facilita il processo
di stima.

Le unità più comuni per le stime delle PBIs sono i punti storia e i giorni ideali. I punti storia
riflettono la complessità e la dimensione fisica delle PBIs, mentre i giorni ideali
rappresentano il tempo necessario per completare una PBI.

Il Planning Poker è un metodo basato sul consenso per stimare le PBIs, in cui ogni membro
del team usa carte per esprimere le loro stime.

Technical Debt
Il Technical Debt è un concetto che rappresenta il costo futuro associato a scelte di sviluppo
software rapide ma non ottimali. È come un debito che deve essere pagato
successivamente attraverso una revisione del codice.

Tipi di Technical Debt

● Unavoidable Debt: Questo tipo di debito è imprevedibile e inevitabile, come i
cambiamenti necessari a causa dell'evoluzione delle conoscenze durante lo
sviluppo;
● Strategic Technical Debt: Può essere una scelta strategica per raggiungere obiettivi
a breve termine, ad esempio, accelerare il lancio di un prodotto;

Conseguenze del Technical Debt

● Unpredictable: Il Technical Debt cresce in modo imprevedibile e può raggiungere un
punto critico in cui anche piccoli cambiamenti diventano incerti;
● Aumento del Tempo di Consegna: Accumulare Technical Debt rallenta la velocità
di sviluppo, portando a ritardi nella consegna di nuove funzionalità;
● Aumento dei Difetti: Un codice con Technical Debt diventa più complesso e
soggetto a difetti frequenti;
● Aumento dei Costi di Sviluppo e Supporto: Il Technical Debt rende costosi anche
i piccoli cambiamenti;
● Atrofia del Prodotto e Ridotta Prevedibilità: Un software con Technical Debt
diventa meno attraente e difficile da prevedere;
● Basso Soddisfacimento del Cliente: Il Technical Debt porta a prestazioni inferiori,
frustrazione universale e insoddisfazione del cliente.

Cause del Technical Debt

● Technical Debt inevitabile: Si accumula indipendentemente dalle misure
preventive;
● Technical Debt ingenuo: Deriva dall'immaturità del team, dell'organizzazione o dei
processi;
● Technical Debt strategico: Può essere una scelta deliberata per raggiungere
obiettivi specifici.

Gestione del Technical Debt

● Utilizzo di buone pratiche come il test driven development, l'integrazione continua e il
refactoring;
● Analisi economica del Technical Debt per prendere decisioni informate;
● Rendere visibile il Technical Debt al team e ai responsabili aziendali;
● Ripagare il Technical Debt in modo incrementale, concentrandosi prima su quello ad
alto rischio e alto interesse;
● Considerare se alcune forme di Technical Debt possono essere accettate o evitate.

Lezione 5
Planning
Sprint Planning, principi
Scrum promuove la creazione di artefatti in anticipo, bilanciando previsioni iniziali con
adattamenti "just in time".
Scrum evita sforzi sprecati nella creazione e nell'aggiornamento dei piani.
Scrum cerca di mantenere aperte le opzioni di pianificazione aperte fino all’ultimo momento
disponibile per evitare costi.
Scrum favorisce rilasci più piccoli e più frequenti, per un maggiore ritorno dell’investimento.

Pianificazione a Livelli Multipli

Scrum definisce diversi livelli di pianificazione (vedi immagine):
● Sprint Planning: quali funzionalità dobbiamo lavorare per il prossimo sprint; Viene
fatto da tutto il team di lavoro;
● Daily Planning: ci si domanda come completare la funzionalità in questione. Viene
fatto dallo scrum master e dal team di sviluppo;
● Portfolio Planning: si pianifica quale prodotto del portfolio di prodotti lavorare. è una
decisione che viene presa dallo stakeholders e dal product owner. I prodotti che
possono essere lavorati possono essere progetti, parti di progetto, incrementi oppure
la pianificazione di un progetto;
● Product Planning: descrive la pianificazione del prodotto. Anche questo viene
effettuato dagli stakeholders e dal product owner. si crea la tabella di marcia per la
realizzazione del prodotto, si definiscono una serie di rilasci e l’idea del prodotto;
● Release Planning: si fa un costante bilancio tra il valore del cliente e la qualità del
prodotto e ciò viene fatto attraverso vincoli, obiettivi e budget. si determina il
prossimo step per raggiungere l’obiettivo deciso, attraverso date fisse.
Confronto tra Pianificazioni a Data Fissa e a Scope Fisso
Bisogna decidere quando utilizzare un modello a scope fisso o a data fissa in base agli
obiettivi del progetto:
Modello a Scope Fisso
● Utilizzato quando si ha una chiara definizione degli obiettivi del progetto fin dall'inizio
e questi obiettivi rimarranno invariati per la durata del progetto.
● Adatto per progetti con requisiti statici, dove il cambiamento degli obiettivi è
improbabile o indesiderato.
Modello a data fissa
● Applicato quando la data di scadenza è più critica degli obiettivi specifici del progetto.
● Adatto per progetti in cui i requisiti possono evolvere nel tempo o sono difficili da
stabilire con certezza fin dall'inizio.

Comunicazione dello Stato del Progetto

Si utilizzano due tipi di grafi:
● Burnout: si comunicano le caratteristiche che vogliamo completare ed il nostro
progresso sprint dopo sprint. Questo grafo mostra il totale del lavoro incompiuto,
ovvero quello che rimane dopo ogni sprint. Il lavoro rimanente alla fine dello sprint
rappresenta la velocità dello sprint;
● Burnup: si usa questo grafo per comunicare lo stato del progetto e l'avanzamento
verso gli obiettivi.

Pianificazione dello Sprint e Pianificazione Giornaliera

Concordare gli specifici elementi del product backlog su cui il team Scrum lavorerà nel
prossimo sprint:
● Si verifica all'inizio di ogni sprint;
● Una descrizione del lavoro a livello di attività.

Il livello di pianificazione più dettagliato

● Si verifica durante la riunione di mischia quotidiana del team;
● I membri del team descrivono collettivamente il piano generale per quel giorno.

Planning Each Sprint

Lo "Sprint Planning" è una fase del processo di sviluppo agile Scrum in cui il team stabilisce
un obiettivo per lo sprint e decide cosa consegnare. Essa viene fatta all’inizio dello sprint.

Principali caratteristiche sprint planning

● Durante la pianificazione, l'intero team collabora.
● Il Product Owner condivide l'obiettivo iniziale dello sprint e presenta il Product
Backlog prioritizzato.
● Il team di sviluppo determina cosa può consegnare e fa un impegno realistico.
● Il responsabile Scrum osserva l'attività e fa domande per garantire un risultato di
successo.

Input per la Pianificazione

Il Product Owner ha una chiara idea di ciò che vuole (gli elementi del PBIs) ma non influisce
sull'impegno del team.
Il team di sviluppo collabora e negozia con il Product Owner, tenendo conto delle capacità
del team, della velocità e dei vincoli.

In termini di approcci alla pianificazione dello sprint, ci sono due metodi principali:
● Pianificazione a Due Parti: Questo approccio è più flessibile ed è stato introdotto
per consentire una migliore gestione delle incertezze e delle emergenze durante
l'Sprint. Questo approccio consente al team di adattarsi meglio alle mutevoli
esigenze del progetto durante l'Sprint.
● Pianificazione a Una Parte: Durante la pianificazione dell'Sprint, il team si
concentra sulla selezione degli elementi di lavoro (elementi di backlog) che verranno
completati durante l'Sprint. Il team stima la quantità di lavoro che può essere
affrontata nell'Sprint, basandosi sulla sua velocità passata o su altre metriche
rilevanti.

In sintesi, la principale differenza tra i due approcci sta nella flessibilità. La pianificazione a
due stati consente al team di essere più adattabile alle modifiche delle priorità durante
l'Sprint, mentre la pianificazione a uno stato è più vincolante e richiede che il team mantenga
la stessa selezione di lavoro durante l'Sprint.

Per determinare la capacità del team, si considera la capacità del team di lavorare al PBI
rimuovendo il tempo dedicato ad altre attività Scrum, il lavoro al di fuori dello sprint
(grooming) e il tempo personale.

La selezione degli elementi del PBIs può avvenire in vari modi, come allineare gli elementi
con l'obiettivo dello sprint o selezionare gli elementi in cima al backlog. È importante non
iniziare ciò che non si può terminare per evitare sprechi.

La fiducia nell'impegno del team viene acquisita suddividendo gli elementi del Product
Backlog in compiti necessari per completare seguendo la definizione di "done" concordata
dal team. Questo processo aiuta a creare il "Sprint Backlog" che serve a verificare l'impegno
del team.

Lab 2
Test Doubles
Il software testing è il processo utilizzato per acquisire fiducia che il software sviluppato
funzioni come previsto e secondo i requisiti. La profondità del testing può variare in base al
tipo di software e alle esigenze regolamentari ed etiche.

L'Agile Manifesto promuove il valore del software funzionante rispetto alla documentazione
dettagliata e incoraggia la consegna frequente di software funzionante come misura di
progresso.

Il TDD è una pratica di sviluppo che integra lo sviluppo di funzionalità con lo sviluppo di test
automatizzati. Si basa su due regole fondamentali: scrivere nuovo codice solo se un test
automatizzato fallisce ed eliminare la duplicazione.
Benefici del TDD: la garanzia che tutti i requisiti siano testati, una buona copertura di test e il
focus sulla progettazione di interfacce.
Il TDD è importante nella Continuous Integration poiché aiuta a rilevare e correggere errori
precocemente, facilita il refactoring e migliora la qualità del codice.

Test Pattern
Esistono diverse tecniche di test patterns. Queste tecniche migliorano il flusso di lavoro nel
Test-driven development e si suddividono in quattro categorie principali:
● Red Bar Patterns: dove e quando scrivere i test e quando fermarsi. Fasi:
○ Starter test: Il primo test che scrivete dovrebbe essere qualcosa di cui siete
sicuri di poter implementare.
○ Explanation test: Includere discussioni o suggerimenti con i colleghi nei test
nel codice.
○ Regression test: Una volta trovato un bug, aggiungere un test nella suite che
lo copra.
● Green Bar Patterns: come rendere i test eseguibili più velocemente possibile
○ Fake it: È accettabile restituire costanti per far passare un test inizialmente.
○ Triangulate: Ritardare l'introduzione di astrazioni finché non siete certi che
siano necessarie.
○ Obvious Implementation: Se qualcosa è ovvio, implementatelo.
○ One-to-many: Se dovete lavorare con strutture dati, iniziate con uno o due
elementi e generalizzate a n elementi (quando applicabile).
● Refactoring Patterns: tecnica per scrivere i test;
○ Durante il refactoring, cercate di mantenere sempre i test verdi.
○ Factor out duplication: Eliminare la duplicazione di codice.
● Testing Patterns:
○ Child test: Se un test è troppo grande e fallisce costantemente, suddividerlo
in test più piccoli e farli funzionare
○ Mock objects: Simulare le dipendenze costose o ingombranti con "oggetti
finti" che restituiscono costanti.
○ Isolated tests: I test non dovrebbero influenzarsi a vicenda e non dovrebbero
dipendere dall'ordine di esecuzione.
○ Test list: Tenere traccia dei test eseguiti e dei test da eseguire (funzionalità
mancanti).
○ Test Data, Realistic Data: Entrambi hanno il loro valore nei test.

Lezione 6
Sprint Execution
Durante uno sprint della durata di due settimane, l'esecuzione dello sprint rappresenta circa
otto dei dieci giorni totali. I partecipanti e i loro ruoli includono:
● Il team di sviluppo: Si auto-organizza per raggiungere l'obiettivo dello sprint senza
che venga loro assegnato il lavoro o venga detto come farlo.
● Il Master Scrum: Funge da coach, facilitatore e rimuove gli ostacoli. Non assegna il
lavoro al team e non dice loro come farlo.
● Il Product Owner: Deve essere disponibile per rispondere a domande di
chiarimento, revisionare il lavoro intermedio, fornire feedback al team e discutere
 eventuali modifiche all'obiettivo dello sprint. Deve anche verificare che i criteri di
accettazione siano stati soddisfatti.

Il processo di esecuzione dello sprint coinvolge pianificazione, gestione, esecuzione e

comunicazione del lavoro, creando funzionalità funzionanti e testate, pianificando come
raggiungere l'obiettivo, lavorando parallelamente e collaborando, evitando mini-waterfall e
applicando intelligentemente il multitasking.

È importante trovare un equilibrio e lavorare sul numero di elementi che il team può gestire
senza sovraccaricarlo, riducendo il tempo necessario per completare ciascun elemento e
massimizzando il valore complessivo consegnato durante lo sprint.

Buone pratiche per migliorare le prestazioni includono il test-driven development (scrivere i

test prima della logica di business), refactoring (miglioramenti di codice), simple design (la
progettazione semplice è la soluzione migliore per codice sicuro e di qualità), pair
programming (lavorare a coppie risulta più produttivo), continuous integration (continuare
ad integrare il software man mano che si lavora, come la pipeline di consegna), collective
code ownership (le persone devono poter lavorare anche su altre parti di codici, altrimenti
se perdiamo il team members che si occupa di quella parte avremmo un grande buco),
coding standard (standard sulla formattazione del codice), metaphor (non lo ricorda Ricca)
l'organizzazione della bacheca e una comunicazione efficace. È anche importante tenere
traccia del lavoro da completare e comprendere come leggere un grafico burndown per
visualizzare il progresso. Inoltre, è consigliabile utilizzare anche grafici burnup per evitare di
gestire troppi elementi nel backlog del prodotto contemporaneamente.

Sprint significa organizzare il lavoro in maniera democratica. Lavorare in maniera continua

ottimizzando le nostre prestazioni con ciò che abbiamo visto prima.

Sprint Review
Dopo abbiamo fatto la pianificazione e l’esecuzione c’è la revisione.
Durante la revisione Sprint, si ispeziona e si adatta l'incremento potenzialmente
consegnabile del prodotto. Questo offre una visione trasparente dello stato attuale del
prodotto, incluso qualsiasi dato scomodo. Gli intervenuti possono porre domande, fare
osservazioni e suggerimenti, nonché discutere su come procedere date le attuali condizioni.

La revisione Sprint si svolge subito dopo l'esecuzione dello Sprint e poco prima della
retrospettiva Sprint.

La revisione Sprint è importante perché aiuta a garantire la creazione di un prodotto di

successo. Consente frequenti correzioni di rotta per mantenere lo sviluppo del prodotto nella
giusta direzione.

La partecipazione alla revisione Sprint dovrebbe coinvolgere un gruppo ampio e interessato

di persone. È una delle riunioni più difficili da pianificare e coinvolge spesso persone al di
fuori del team Scrum. Di solito, la riunione non supera le quattro ore. Nella riunione c’è lo
scrum master (il quale ascolta ascolta i feedback) gli stakeholders (i quali possono suggerire
correzioni), figure esterne stakeholder (i quali possono fornire il loro punto di vista).
La preparazione per la revisione Sprint dovrebbe essere informale ma di alto valore. Si
consiglia di dedicare da 30 minuti a un'ora per ogni settimana di durata dello Sprint per
prepararsi. Durante la revisione, vengono mostrati gli artefatti prodotti per raggiungere
l'obiettivo dello Sprint.

Di solito la conduzione della revisione Sprint è il master Scrum, mentre i membri del team si
alternano per presentare il lavoro svolto.

Durante la revisione Sprint, vengono mostrati i progressi realizzati sull'incremento del

prodotto, viene discussa la situazione attuale del prodotto e si fornisce un riepilogo di cosa è
stato realizzato rispetto all'obiettivo dello Sprint. Inoltre, si confronta con l'obiettivo dello
Sprint e si adatta la direzione futura del prodotto.

Durante la revisione Sprint, il team può fare e rispondere a domande cruciali riguardo al
prodotto e alle preferenze degli stakeholder. Questo feedback è utilizzato per adattare il
backlog del prodotto e i piani di rilascio.

La revisione Sprint non è il luogo per ottenere l'approvazione definitiva del lavoro. Le
questioni di approvazione sono gestite successivamente dal Product Owner. La revisione
mira a raccogliere feedback e adattare il prodotto. La partecipazione sporadica potrebbe
essere un segnale di priorità sbagliate o grandi sforzi di sviluppo potrebbero richiedere più di
una revisione.

In breve, la revisione Sprint è una parte cruciale del processo Scrum in cui il team esamina il
lavoro fatto durante lo Sprint, raccoglie feedback dagli stakeholder e adatta la direzione
futura del prodotto.

Sprint Retrospective
La Sprint Retrospective è un momento in cui il team Scrum esamina il processo utilizzato
per sviluppare il prodotto. È un'opportunità per riflettere sul lavoro svolto, identificare punti di
forza e debolezza e pianificare miglioramenti. Durante questa fase, il team può esaminare
qualsiasi aspetto che influisce sulla creazione del prodotto, inclusi processi, pratiche,
comunicazioni, ambiente, strumenti, ecc.

La Sprint Retrospective è una pratica fondamentale ma spesso sottovalutata all'interno di

Scrum. Durante questa fase, vengono affrontate domande come cosa ha funzionato bene
durante lo sprint da continuare a fare, cosa non ha funzionato bene da evitare e cosa
dovrebbe essere iniziato o migliorato. I partecipanti includono il team Scrum completo, il
master Scrum, il proprietario del prodotto e, se invitati dal team, gli stakeholder o i manager.

La preparazione per la Sprint Retrospective coinvolge la revisione di tutti gli aspetti rilevanti
del processo, l'identificazione di esercizi che possono aiutare i partecipanti a esplorare e
decidere insieme, la raccolta di dati oggettivi (non opinioni) sugli eventi e la strutturazione
del tempo, solitamente circa 1,5 ore per uno sprint di due settimane.
Le attività principali includono la creazione di un ambiente sicuro in cui i partecipanti
possano esprimere le proprie opinioni, la condivisione del contesto per allineare le
prospettive individuali, l'identificazione di insight e la definizione di azioni di miglioramento da
intraprendere. È essenziale che le azioni stabilite vengano effettivamente attuate.

è importante assicurarsi che quanto emerso dalla Sprint Retrospective venga effettivamente
implementato. Inoltre, viene menzionato il concetto di un "insight backlog", ovvero una lista
di problemi identificati che non possono essere affrontati immediatamente ma che possono
essere ripresi in una futura Sprint Retrospective.

In sintesi, la Sprint Retrospective è un momento cruciale per il miglioramento continuo nel

processo di sviluppo Agile, in cui il team Scrum riflette sul proprio lavoro e identifica modi per
fare meglio nel prossimo sprint.

Lab 3
Test Double
Key terms:
● SUT: System under test;
● DOC: Depended-on component, il componente testato;
● Verifica basata sullo stato: ottenere input, calcolare output, asserzioni sugli input-
output;
● Verifica basata sul comportamento: ottenere input, calcolare output, asserzioni su
come il SUT interagisce con i DOC.

I "Test Doubles" sono oggetti che sostituiscono i DOC durante i test:

Dummy: un semplice segnaposto;
Stub: fornisce un modo per iniettare comportamenti costanti nel SUT;
Spy: registra le chiamate che il SUT scatena in un oggetto, talvolta è un oggetto reale;
Fake: una versione semplificata di un componente reale;
Mock: simile a uno Spy, ma è in grado di asserire il proprio comportamento.

Ci sono diversi casi d'uso dei Test Doubles tra cui la riproducibilità, l'evitare fixture
complesse, la gestione della casualità, la manipolazione di variabili d'ambiente e la rottura
delle dipendenze.

Utilizzare i mock objects o meno?

● La verifica basata sul comportamento può rivelare dettagli di implementazione delle
classi, rendendo i test fragili.
● La verifica basata sullo stato tratta il SUT come una scatola nera e non fa
supposizioni sull'implementazione interna.
● I mock objects possono rendere i test dipendenti dai dettagli di implementazione del
SUT, quindi la loro scelta è controversa.

Usi dei Test Doubles

● Reperibilità: I Test Doubles possono essere utilizzati per riprodurre situazioni
specifiche durante i test, al fine di ottenere risultati ripetibili.
 ● Evitare fixture complesse: Aiutano ad evitare la creazione di fixture complesse o
costose durante i test.
● Randomicità: Possono essere utilizzati per gestire situazioni in cui la casualità è
coinvolta nei test.
● Variabili d'ambiente: Servono per gestire le variabili d'ambiente durante i test.
● Rompere le dipendenze: I Test Doubles possono essere utilizzati per separare le
dipendenze tra gli oggetti durante i test.
● Lavorare su un'interfaccia non ancora disponibile: Consentono di lavorare su
un'interfaccia di sistema che non è ancora disponibile.
● Lavorare in parallelo con interfacce concordate: Possono essere utilizzati per testare
componenti che devono operare in parallelo, seguendo specifiche interfacce
concordate.
● Mantenere test isolati e veloci: Aiutano a mantenere i test isolati e veloci, senza
dover attendere risorse esterne.
● Sostituire dipendenze costose in termini di tempo: Consentono di sostituire
dipendenze costose in termini di tempo durante i test.
● Sostituire dipendenze non disponibili: I Test Doubles possono essere utilizzati per
sostituire le dipendenze che non sono al momento disponibili.
● Spostare test lenti in test di accettazione/integrazione: Possono essere utilizzati per
spostare i test lenti nei test di accettazione o integrazione, mantenendo i test unitari
veloci.
● Controllo completo sul contesto del Sistema Sotto Test (SUT): I Test Doubles offrono
controllo completo sul contesto del SUT che altrimenti non sarebbe possibile
ottenere.
● Testare qualcosa che non produce un output diretto: Possono essere utilizzati per
testare situazioni in cui non c'è un output diretto, ma ci aspettiamo un
comportamento specifico.

Lab 4
Benefici TDD:
● Impone standard di base per la qualità del software durante lo sviluppo.
● I test completi proteggono dai regressi del software.
● Può rallentare lo sviluppo, ma è utile nello sviluppo basato sul trunk.
● I test agiscono come specifiche.
● I test possono essere automatizzati.
● Fornisce significato formale.
● Richiede conoscenze tecniche per contribuire ai test.
● Solitamente copre molti dettagli a basso livello; i "test di accettazione" (quelli utili
come specifiche) vengono scritti per ultimi.

Sviluppo basato sul comportamento (BDD)

BDD è un insieme di pratiche che mira a coinvolgere sia le persone del business che quelle
tecniche nei progetti software. Si lavora in piccole iterazioni per massimizzare il valore per gli
stakeholder. Si produce una "documentazione del sistema" che può essere "verificata
automaticamente" in base al comportamento implementato (specifiche/test di accettazione).

Pratiche di BDD
BDD assume che si stia già lavorando in un contesto agile. Essa si concentra sull'effort di
sviluppo su incrementi piccoli (user story). Risponde prontamente ai feedback degli utenti,
facendo il minimo necessario per soddisfare le richieste. Si basa su iterazioni di sviluppo
veloci. Si richiede la disponibilità quotidiana di persone con conoscenze di dominio.

Workflow BDD
La sequenza BDD si suddivide in scoperta (discovery), formulazione (formulation) e
automazione (automation). Nella scoperta si creano esempi concreti del comportamento del
sistema desiderato. Nella formulazione si producono documenti che fungono da "specifiche
eseguibili" per le funzionalità da implementare. Si utilizza il linguaggio specifico del dominio
Gherkin per definire specifiche in modo leggibile sia per gli esseri umani che per i computer.

Linguaggio Gherkin
Gherkin è un linguaggio specifico del dominio che consente di definire documentazione
strutturata che si legge quasi come il linguaggio naturale. È uno strumento prezioso poiché
consente alle persone senza formazione in programmazione di contribuire alla definizione
del comportamento (e quindi ai test) del software.

Automazione
Una volta disponibili specifiche eseguibili, queste possono essere tradotte in test per guidare
l'implementazione del sistema. Si crea un ciclo "a doppio loop" in cui i test di accettazione ad
alto livello guidano l'implementazione del comportamento e, all'interno, si seguono le
pratiche standard di sviluppo iterativo. Esistono strumenti, come Cucumber, che mappano
automaticamente il linguaggio Gherkin in "scheletri di test" disponibili in molteplici linguaggi.

Requisiti del Progetto (Informali)

Adozione della continuous integration e continuous delivery.
Il codice dovrebbe essere ben testato, indipendentemente dal fatto che si sviluppi con il TDD
o meno.
Coinvolgimento di tutti nello sviluppo dei propri test.
Definizione dei criteri di accettazione in Gherkin.
Opzionale l'uso di strumenti BDD per l'esecuzione dei test.
Libertà nella scelta dello stack software da utilizzare.
Deve essere impostato un ciclo di integrazione continua (CI/CD) entro il primo sprint e
"approvato" durante la prima revisione dello sprint.

Lezione X
TODO
TODO

Lab X
TODO
TODO

ALTRO
Useful Notions
Concetti di base sulle annotazioni Java
Le annotazioni forniscono informazioni aggiuntive sui pacchetti, le classi, i metodi, i campi, le
variabili e altro ancora nel codice Java. Le annotazioni sono utilizzate per aggiungere
informazioni aggiuntive alle classi e per sviluppare strumenti di elaborazione.
Le annotazioni consentono di ispezionare proprietà aggiuntive durante l'esecuzione del
programma.
Le annotazioni sono diverse dai commenti e sono sopravvissute ai compilatori.
Prima di Java 5, i metodi deprecati venivano annotati sfruttando i javadoc e le capacità delle
classi venivano annotate con interfacce speciali.
Soluzioni più pulite:

Le annotazioni possono essere utilizzate per specificare informazioni ovunque ci si aspetti

un modificatore.
Le annotazioni vengono definite utilizzando l'annotazione @interface.
Riflessione in Java:

La riflessione in Java consente a un programma di analizzare le classi e le proprietà degli

oggetti durante l'esecuzione.
Le classi, i campi, gli oggetti e i metodi sono visti come oggetti Java.
Java fornisce il pacchetto java.lang.reflect per la riflessione.
È possibile ottenere informazioni sulle classi, creare nuove istanze, chiamare metodi,
accedere a campi privati e altro ancora utilizzando la riflessione.
Design Pattern:

Un design pattern è una soluzione comprovata e ricorrente a un problema di progettazione

software.
I design pattern forniscono un modo per affrontare problemi comuni in modo efficace.
Sono radicati nell'esperienza pratica e forniscono un vocabolario comune per gli sviluppatori
e gli architetti del software.
Esempi di design pattern includono Singleton, Prototype, Abstract Factory, Proxy,
Command, ecc.
Tieni presente che questo è solo un riassunto dei concetti principali presenti nel testo. Se hai
domande specifiche o hai bisogno di ulteriori dettagli su un particolare argomento, sentiti
libero di chiedere.

Scrum Framework
Il framework Scrum è incentrato su pratiche, ruoli, attività e artefatti specifici. Non è un
processo standardizzato con passi sequenziali da seguire, ma piuttosto un framework per
organizzare e gestire il lavoro. Gli elementi chiave di Scrum includono:

Ruoli Scrum: Ci sono tre ruoli principali in Scrum: il Product Owner, lo ScrumMaster e il
Development Team. Questi ruoli sono obbligatori, ma possono esserci anche altri ruoli.
Product Owner: Questa figura è responsabile di cosa verrà sviluppato, in quale ordine e
imposta gli obiettivi. Si assicura che le funzionalità siano sviluppate nell'ordine più
vantaggioso per il successo del prodotto.

ScrumMaster: Il ruolo di ScrumMaster è quello di guidare il team nel seguire Scrum, agire da
coach e facilitatore, proteggere il team dalle interferenze esterne e rimuovere gli ostacoli che
possono ostacolare il progresso.

Development Team: Questo team è responsabile di determinare come consegnare il

prodotto, si auto-organizza per trovare il modo migliore per raggiungere gli obiettivi e deve
avere tutte le competenze necessarie per farlo.

Pratiche Scrum: Scrum prevede una serie di pratiche tra cui lo sprint planning, lo sprint
backlog, le sprint review e sprint retrospective.

Product Backlog: È una lista prioritizzata delle attività da svolgere, costantemente in

evoluzione, gestita dal Product Owner. È importante concentrarsi sul lavoro più valutabile.

Sprint: Si tratta di iterazioni con una durata fissata, durante le quali si crea qualcosa di valore
tangibile per il cliente o l'utente. Non sono ammesse modifiche di scopo o personale durante
uno sprint, tranne rare eccezioni.

Sprint Planning: Durante questa attività, il Product Owner e il Development Team decidono
quali elementi del Product Backlog verranno sviluppati nello sprint in corso e fissano gli
obiettivi.

Sprint Backlog: È una lista di compiti necessari per completare gli elementi selezionati
durante lo sprint planning.

Daily Scrum: Ogni giorno durante uno sprint, i membri del Development Team conducono
una breve riunione per condividere cosa è stato fatto, cosa verrà fatto e per discutere
eventuali ostacoli.

Definition of Done: Il team definisce uno standard di qualità che deve essere soddisfatto
prima che un'attività sia considerata completata.

Sprint Review: Alla fine dello sprint, si tiene una revisione per esaminare ciò che è stato
realizzato e ottenere feedback dagli stakeholder.

Sprint Retrospective: Dopo la revisione, il team tiene una retrospettiva per discutere ciò che
ha funzionato bene e cosa può essere migliorato nel processo.

Scrum è un framework flessibile che promuove la trasparenza, l'ispezione e l'adattamento,

consentendo alle squadre di lavorare in modo più efficace e di consegnare valore in modo
continuo.

Enterprise Applications
Definizione di Enterprise Application: L'articolo inizia discutendo cosa siano le applicazioni
enterprise. Sottolinea che un'idea sbagliata è definirle semplicemente come "software per
aziende", ma le applicazioni enterprise coinvolgono la visualizzazione, la manipolazione e
l'archiviazione di grandi quantità di dati complessi e il supporto o l'automazione dei processi
aziendali.

Esempi di Enterprise Applications: Vengono forniti esempi di applicazioni enterprise, tra cui
sistemi di prenotazione, sistemi finanziari, sistemi di gestione della catena di
approvvigionamento e altri utilizzati nelle moderne imprese. Si sottolinea la differenza tra
queste applicazioni e sistemi embedded, sistemi di controllo, telecomunicazioni o software
desktop.

Terminologia: L'articolo spiega che le applicazioni enterprise possono essere chiamate

anche "sistemi informativi" o "elaborazione dati" e include una varietà di applicazioni come
gestione delle paghe, record dei pazienti, tracciamento delle spedizioni, analisi dei costi,
scoring del credito, assicurazioni, contabilità e assistenza clienti.

Performance delle Applicazioni Enterprise: L'articolo affronta l'importanza delle prestazioni

delle applicazioni enterprise, considerando aspetti come il tempo di risposta, la reattività, la
latenza, la capacità di carico e la scalabilità.

Architetture Tipiche: Viene discusso il concetto di architetture a livelli e la loro importanza

nelle applicazioni enterprise.

Persistenza dei Dati: Si spiega il concetto di persistenza dei dati e come sia fondamentale
nelle applicazioni. La discussione si concentra sulla conservazione dei dati in database
relazionali.

Database Relazionali: Vengono affrontati i vantaggi dei database relazionali nelle

applicazioni enterprise, inclusa la loro flessibilità, robustezza e capacità di garantire
l'integrità dei dati.

Object-Relational Mapping (ORM): Si introduce il concetto di ORM come un modo per

gestire la persistenza degli oggetti nelle applicazioni enterprise e come soluzione per
superare le differenze tra il modello orientato agli oggetti e i database relazionali.

Vantaggi dell'ORM: L'articolo menziona i vantaggi dell'ORM, tra cui un aumento della
produttività, una maggiore manutenibilità e una migliore performance.