[23-03-2023]

Agile Unified Process

La cosa più importante è il coinvolgimento di tutto quanto il team con competenze sicuramente trasversali. Le persone sarebbe bene che lavorassero senza stare a leggere centinaia di pagine di documentazione, ma è molto più comodo una formazione specifica su che cosa si deve fare. Non deve sparire la documentazione, ma questa non diventa più il focus principale, ma la si va a vedere solamente quando serve.

Cerchiamo di essere semplici e fare tutto quello che dobbiamo fare in poche pagine; siate sintetici e semplici, anche per arrivare a sodo e non perdere tempo. C’è anche un discorso di agilità che viene definita come agility. Focus su attività che contano, definite “ad alto valore”. Nel Waterfall si parte molto facilmente per la tangente. Indipendenza dagli strumenti. Non ci si leghi agli strumenti di sviluppo ma lascia che i dev scelgano quello con cui si trovano meglio, magari vai verso open source se riesci. Il prodotto deve essere facilmente personalizzabile in modo molto semplice.

In ogni ciclo alla fine abbiamo 4 micro fasi che si ripetono in loop:

1. Inception → vediamo i requisiti e li mettiamo in priorità praticamente. Quali sono le cose che vogliamo andare ad affrontare per primi?
2. Elaboration → fase in cui diamo peso alla progettazione e definiamo l’architettura e selezioniamo i requisiti da implementare in base alla priorità.
3. Construction (1/2 time) → implementazione sw
4. Transition (1/8) → qui scriviamo la documentazione, facciamo la release e poi acceptance test con il cliente per vedere che effettivamente sia andato tutto okay e il cliente si aspettavano prodotto del genere

Molto spesso è importante fare time boxing e stare sempre nei tempi, poi se ci scappa qualcosa lo si fa nella iterazione successiva

SCRUM

Slide 11 c’è un po’ di storia sul metodo SCRUM Funny fact: la Microsoft crede tantissimo nel metodo scrum.

Ogni iterazione si chiama sprint, come il ciclo dello Unified Process, e alla fine abbiamo sempre un prototipo di software da fare vedere al cliente. Possiamo andare ad usare tecniche come:

• user stories
• pair programming

Un aspetto fondamentale è l’interazione face to face → parlarsi di persona sia tra dev che tra dev e clienti una forte interazione. Ci sono vari ruoli:

• Product Owner: parla coi clienti per capire che cosa deve essere sviluppato e produce una serie di requisiti che devono essere inserite e li mette in un prodcut backlog (le cose da fare) in ordine di priorità.
• Team di sviluppo: di tutti i requisiti del product backlog se ne scelgono alcuni e si mettono all’interno dello sprint backlog. Uno sprint può durare da 1 a 4 settimane, è importante avere sempre una data finale dello sprint. Se decido che dura 4 settimane, dopo 4 settimane esatte mi fermo → time boxing assoluto. In questo tempo si lavora sodo. Sono previsti dei daily scrum ogni giorno in cui si fa il punto della situazione giornaliera e dire come si sta andando. Tutto supportato da un burndown chart. Alla fine del ciclo di 4 settimane ho la sprint review col review in cui faccio vedere un software demo al cliente. Cosa molto interessante: alla fine della sprint review si fa anche lo sprint retrospective del team che si auto analizza e si cerca di andare a migliorare lo sprint successivo. Tutto questo fino all’acceptance test.
• Scrum Master: che gestisce il team dal punto di vista gestionale e dei rapporti