Sei sulla pagina 1di 60

Dal Waterfall allo Scrum

Scopo del Project Management

➢ Definire gli obiettivi (gestione dello scopo)


➢ Dare una visione realistica del progetto
durante tutto il ciclo di vita (gestione
integrata)
➢ Creare una tempistica ed un piano dei
costi (gestione del tempo e dei costi)
➢ Identificare e prevenire i rischi (gestione
del rischio)
➢ Controllare e valutare gli scostamenti
(gestione della qualità)
L’approccio tradizionale
Definizione esecuzione

● Fattibilità
● Definizione ● Rilevazione
obiettivi ○ Tempi Effettivi
● Project ○ Costi Effettivi chiusura
Charts
● Consegna
controllo ● Esame
critico dei
Pianificazione risultati
● Verifica ● Apprendimen
● W.B.S ○ Analisi degli scostamenti to
● Gant ○ Analisi delle cause
● …. ● Ripianificazione
○ Attuazione dei correttivi
○ Nuove stime a finire

t inizio t fine tempo


Il Gantt
Il modello Waterfall

Waterfall model CC BY 3.0


Peter Kemp / Paul Smith - Adapted from Paul Smith's work at
Sviluppo di un sito Internet
Design/UX
UML

Struttura del Database


Programmazione del Backend
(Ex. Python, Perl, Java)

Programmazione Middleware
(Ex. PHP, ASP, JSP)

Editing/Javascript
Approccio Push e Pull

1 2 3 4
Catena di Montaggio
● Flusso da monte a valle
● Il centro decisionale è a monte
● Sovraproduzione
● Trasporti e manutenzione inutili
● Stoccaggio eccessivo
● Manodopera eccessivamente
specializzata
● Difficoltà a cambiare le linee di
produzione per prodotti
differenti

1 2 3 4
Toyota Production System
● Just in Time
○ Flusso da monte a valle
○ Si produce solo quello che
serve
○ Facilità a produrre prodotti
differenti
● Autoattivazione
○ Centro decisionale
distribuito
○ Manodopera
adibita a più
mansioni

1 2 3 4
Muda: Spreco di Beni
Muri: Spreco di Risorse
Mura: Livellamento
Kaizen
Adapt

Inspect
Il Kanban
Codice Articolo A47652

Descrizione 1.2.3.4

Numero di pezzi da Fabbricare 50

Numero del pezzo A20

Origine Isola1

Destinazione Isola3

Punto di riordino 20

Tipo di imballaggio 15

1 2 3 4
Benefici del Kanban

● Visualizzare il flusso di lavoro


● Limitare il Work-in-Progress
● Misurare e gestire il flusso

● Facililità di integrazione sull’


attuale struttura organizzativa
● Funzionante da subito
Realizzare Kanban.1
Image by Giulio Roggero “Agile in 45minuti”

Iniziamo dalla lista delle nostre attività


Realizzare Kanban.2
Image by Giulio Roggero “Agile in 45minuti”

Dividiamo la board per status


Realizzare Kanban.3
Image by Giulio Roggero “Agile in 45minuti”

Dettagliamo ulteriormente la board aggiungendo


tutti gli step del processo
Realizzare Kanban.4
Image by Giulio Roggero “Agile in 45minuti”

Aggiungiamo le code per ogni status


Realizzare Kanban.5
Image by Giulio Roggero “Agile in 45minuti”

Aggiungiamo il numero di WIP per ogni status


Realizzare Kanban.6
Image by Giulio Roggero “Agile in 45minuti”

Aseegniamo infini ogni task ai membri del team


Kanban passo passo..
Image by Giulio Roggero “Agile in 45minuti”
Kanban passo passo..
Image by Giulio Roggero “Agile in 45minuti”
Kanban passo passo..
Image by Giulio Roggero “Agile in 45minuti”
Kanban passo passo..
Image by Giulio Roggero “Agile in 45minuti”
Kanban passo passo..
Image by Giulio Roggero “Agile in 45minuti”
Kanban passo passo..
Image by Giulio Roggero “Agile in 45minuti”
Kanban passo passo..
Image by Giulio Roggero “Agile in 45minuti”
Kanban passo passo..
Image by Giulio Roggero “Agile in 45minuti”
Kanban passo passo..
Image by Giulio Roggero “Agile in 45minuti”
Kanban passo passo..
Image by Giulio Roggero “Agile in 45minuti”
Kanban passo passo..
Image by Giulio Roggero “Agile in 45minuti”
I colli di bottiglia..
Image by Giulio Roggero “Agile in 45minuti”
I colli di bottiglia..
Image by Giulio Roggero “Agile in 45minuti”
I colli di bottiglia..
Image by Giulio Roggero “Agile in 45minuti”
I colli di bottiglia..
Image by Giulio Roggero “Agile in 45minuti”
I colli di bottiglia..
Image by Giulio Roggero “Agile in 45minuti”
I colli di bottiglia..
Image by Giulio Roggero “Agile in 45minuti”
I colli di bottiglia..
Image by Giulio Roggero “Agile in 45minuti”
Le attese..
Image by Giulio Roggero “Agile in 45minuti”
Le attese..
Image by Giulio Roggero “Agile in 45minuti”
Agile Manifesto

Gli individui e le interazioni più che i processi e gli strumenti


Il prodotto funzionante più che la documentazione esaustiva
La collaborazione col cliente più che la negoziazione dei contratti
Rispondere al cambiamento più che seguire un piano

Ovvero, fermo restando il valore delle voci a


destra, consideriamo più importanti le voci a
sinistra.
Focus
Se ci concentriamo
su un ristretto
numero di attività
abbiamo più
possibilità che
queste vengano
svolte al tempo
stabilito.
Raggiungere l’obiettivo
Scrum

Scrum è un termine inglese che


alla lettera indica «un mucchio
ristretto e disordinato di persone».
Nel rugby tale termine è noto come
mischia chiusa oppure mischia
ordinata.
Il processo Scrum
Lo Scrum Team
Il Product Owner

● Ha la responsabilità di
massimizzare il ritorno di
investimento.
● Trasmette la Vision e i
requirements.
● Collabora sul
prodotto.
● Gestisce il Backlog e pianifica i Fonte Web

rilasci di prodotto.
Lo Scrum Master
● È un facilitatore, aiutando il team a
collaborare insieme.
● Aiuta il team nella corretta
applicazione dello
Scrum.
● Facilita l’auto-organizzazione e
rimuove gli impedimenti.
● Stimola il team a superare i propri
limiti.
Il Team di Sviluppo

● Cross funzionale e auto


organizzato.
● Collabora con il PO per definire
gli obiettivi di Sprint.
● Si impegna a completare gli
elementi del Backlog scelti per lo
Sprint.
● È responsabile della qualità.
Gli artefatti
Product Backlog
● Lista ordinata di User Stories in base
al valore di business, dipendenze
tecniche, due date..
● Product Owner è il responsabile
ultimo della sua gestione e
delle priorità da dare alle storie
nel backlog per il Team di
sviluppo.
● Il product backlog può contenere
delle stime approssimative sia del
valore di business che dello sforzo
necessario a svilupparle.
Sprint Backlog
● Lo sprint Backlog è l’insieme
delle User Story che il
development team si è
preso in carico di svolgere
durante lo Sprint.
● Esso a sua volta è suddiviso
in task che verranno svolti
e che comporranno un
avanzamente di prodotto.
● Lo sprint backlog è di
proprietà del Team di
sviluppo, e tutte le stime
incluse sono effettuate dal
team stesso.
BurnDown Chart
● Un burn down chart è una
rappresentazione grafica
del lavoro da fare su un
progetto nel tempo.
● Il lavoro rimanente è
indicato sull'asse verticale
e il tempo sull'asse
orizzontale.
● È per dare un quadro del
progetto e fare previsioni.
Le cerimonie Scrum

● Backlog Refining
● Sprint Planning
● Daily Scrum
● Sprint Review
● Retrospective
Backlog Refining
Il Team (o parte del team) si vede
regolarmente per:
● Rimuovere le user story che
non appaiono
rilevanti
● Aggiungere nuove storie in base alle
ultime esigenze
● Ridefinire le priorità
● Specificare ulteriormente le user story che
sono ad alta priorità ma ancora troppo
vaghe
Durata: 1 ora per uno sprint di 2 settimane
Sprint Planning
All’inizio di ogni sprint tutto il team si vede per:
● Il product owner presenta e descrive le
user story a priorità più alta.
● Il team di sviluppo prende in consegna le
attività fino al raggiungimento della sua
capacità.
● Il product owner resta a disposizione per
rispondere alle domande.
● Il team di sviluppo inizia a valutare le
storie e a dividerle in attività.
Durata: Max 4ore per uno sprint di 2
settimane
Daily Scrum
Riunione giornaliera del team di sviluppo
nello stesso posto e alla stessa ora:
● Si risponde a tre domande:
○ Quali task hai completato ieri
○ Quali blocchi hai trovato
○ Quali task farai per domani
● Favorire il dialogo tra i membri del
team e non verso lo SM
●No Problem Solving
Durata: 15 Minuti
Sprint Review

Alla fine di ogni sprint il team si vede per:


● Verifica che tutte le US prese in carico
siano state completate.
● Si organizzano delle piccole Demo per le
nuove Feature
Durata: 2 ore per uno sprint di due
settimane
La retrospettiva
Tutto il team è atteso per:
● Esaminare come l’ultimo Sprint è
andato per quanto riguarda le
persone, le relazioni, i processi e
gli strumenti;
● Identificare e ordinare i maggiori
elementi che son andati bene e il
potenziale di miglioramento;
● Creare un piano per attuare i
miglioramenti al modo di lavorare
dello Scrum Team
Durata: 1 ora per uno sprint di 2
settimane