Agile Project Management
Ing. Roberto Chiavaccini
Ordine degli Ingegneri di Livorno
Seminario 18/12/2014
Cos'è ?
• Un aiutino: è stato ideato nel 1902
dall'ingegnere tedesco Max Rietz
Il Regolo calcolatore
• Il Regolo calcolatore era il simbolo
degli ingegneri!
• All'Università ve l'hanno insegnato?
• Lo utilizzate?
Cos'è ?
Un aiutino ...
• ... è stato ideato nel 1917
dall'ingegnere americano H. Gantt,
collaboratore del più famoso
ingegnere F. W. Taylor
Il Gantt
• È il simbolo del metodo progettuale
classico definito, dal PMI (Project
Management Institute), Predittivo !
Il Gantt
• A Ingegneria vi hanno insegnato il
Gantt ed il Metodo Predittivo ?
• Li utilizzate ?
Il Metodo predittivo
• Di seguito alcune considerazioni sul
Metodo Predittivo basandole sul
PMBOK5 del PMI, principale referente
mondiale di Project Management
PMBOK5
• “Nei cicli di vita predittivi si
determinano (si prevedono) il prima
possibile Ambito (il perimetro del
progetto ovvero le cose da fare, chi
le farà, ..),Tempi e Costi per
realizzare il progetto” (Concept
Paper)
Metodo Predittivo
• “Questi tipi di progetto passano
attraverso una serie di fasi
sequenziali o sovrapposte ….“
Sa
lm
W
at
er
fa
ll
on
i?
Problemi
• Nella progettazione “a cascata” sono
necessari continui feedback
informativi (effetto salmone) che,
purtroppo, dilatano tempi e costi
Metodo Predittivo
• “Il lavoro svolto in una fase è
generalmente di natura diversa da
quello della fase precedente o
successiva quindi la composizione e
le capacità (le specializzazioni)
richieste al Team di progetto (di
Sviluppo) possono variare di fase in
fase”
Le Specializzazioni creano Problemi
Silos Tayloristici
Silos
Metodo Predittivo
• “Il Metodo predittivo dovrebbe essere
preferito quando il prodotto da
fornire è noto, quando esiste una
base sostanziale di prassi del settore
(delle Best Practices) o laddove un
prodotto debba essere integralmente
realizzato prima di avere Valore per i
clienti e/o per altri Stakeholders”
Dubbi
• Vi possono essere alcuni dubbi sulla
prima e sulla seconda affermazione
(presuppongono delle certezze che,
vedremo, sono oggi molto difficili)
ma è soprattutto sull'ultima che vi
invito a riflettere
Dubbi
• La realizzazione integrale “al buio”
(prima cioè di avere Valore per i
clienti – ovvero per chi pagherà)
presuppone infatti:
– O un grande azzardo proviamo
comunque a sviluppare il prodotto ed ....
io speriamo che me la cavo !
Dubbi
– O stabilire preliminarmente, magari con
un'analisi di Marketing, ciò che vogliono
i clienti “imponendo loro”, con un
Contratto, di non cambiare mai più idea
Metodo Predittivo
• Purtroppo, data l'attuale dinamica
ambientale, i Bisogni dei Clienti
evolvono molto rapidamente e non si
può impedir loro di cambiare idea
trincerandosi dietro un “Contratto”!
Gestione adattiva
• È evidente infatti che, contratto o
non contratto, se per il cliente la
colpa della sua insoddisfazione è del
fornitore in seguito non comprerà più
e magari …. renderà “difficili” gli
attuali pagamenti !
Metodo Predittivo
• Purtroppo oggi Incertezza e
Complessità regnano sovrane
Metodo Predittivo
• Il nostro (degli ingegneri “più
anziani”) bel Mondo Razional
Meccanicistico (tutto è e deve essere
noto a priori, il prima possibile) è
scomparso
Metodo Predittivo
• Ed il metodo predittivo … non è più
sufficiente!
Metodo Predittivo
• Le statistiche internazionali ce lo
confermano: nei progetti complessi
ed incerti gestiti in modo predittivo,
le previsioni di Tempo sono rispettate
solo nel 10% dei casi
Metodo Predittivo
• Ma il peggio è che anche l'Ambito ed
i Costi sono rispettati solo nel 10%
dei casi
Metodo Predittivo
• Il che vuole dire che le “previsioni”
sono rispettate …. nel 1/1000 dei
casi: è un po' poco per essere solo
sfortuna!
Metodo Predittivo
• Molti poi sono scoraggiati dal tempo
e dai costi di implementazione del
Metodo
Metodo Predittivo
• In tal caso si rinuncia e si ricorre al
classico Just do It (empirismo
manageriale)
Just Do It
• Purtroppo con l'empirismo
manageriale … le cose vanno anche
peggio !
Just Do It
• In Italia poi, per carenze di
insegnamento di Project Management
da parte delle Università, l'empirismo
la fa decisamente da padrone
Taylor & Gantt
• In fin dei conti però, Taylor e Gantt
una qualche ragione l'avevano: è il
metodo scientifico sperimentale e
non l'empirismo che dovrebbe essere
alla base del Management e, quindi,
anche del Project Management !
Taylor & Gantt
• Perché allora, se il Principio è valido,
le soluzioni del Taylor e del Gantt
oggigiorno danno risultati non troppo
brillanti ?
Taylor & Gantt
• È ovvio, i due ingegneri avevano
formulate le loro proposte 100 anni
fa in un mondo ben diverso
dall'attuale e ormai sono, ... come il
Regolo, un po' obsolete!
Ohno & Shingo
• Fortunatamente altri ingegneri (bene
o male il Management operativo ha
una grossa base “ingegneristica”), in
particolare i giapponesi Taichi Ohno e
Shigeo Shingo (ve ne hanno mai
parlato?), hanno aggiornato le
soluzioni del Taylor e del Gantt
Ohno & Shingo
• Gli ingegneri giapponesi hanno
sviluppato tali nuove soluzioni
manageriali “ancora scientifiche ma
post Taylor”, universalmente
conosciute come Lean Thinking,
applicandole alla Toyota … con ottimi
risultati sperimentali!
“Agile” Project Management
• Oggi il Lean Thinking, sulla scia di
Toyota, è applicato anche allo
Sviluppo e prende vari nomi:
• Agile Project Managerment è uno
di questi
Agile
• Generalmente con Agile ci si riferisce
allo sviluppo di prodotti SW con
specifici metodi Lean emersi a partire
dai primi anni 2000
Agile
• Tali metodi sono basati sui princìpi
del "Manifesto Agile" pubblicato
nel 2001 ad opera di 17 professionisti
dello sviluppo SW
Lean
• Oltre ad Agile altri nomi che potreste
sentire sono:
– Lean Product Development per l'industria
manifatturiera
– Lean Costruction/Last Planner per
l'edilizia
– Lean Government (per la pubblica
amministrazione)
– Lean Healthcare (per la sanità)
– ---
Agile
• Io preferisco parlare genericamente
di Lean Project Management
riferendolo così a tutte le tipologie di
progetti lasciando il termine Agile per
lo sviluppo SW
Agile
• Purtroppo per me il PMI definisce
Agile il Metodo Adattivo che
vedremo subito dopo e se lo dice il
PMI ubi maior ….
Agile
• Di recente il PMI ha addirittura
introdotto una specifica certificazione
(PMI-ACP)SM - PMI Agile Certified
Practitioner
Lean Project Management
Perchè Lean? Se ci pensate bene nella
maggior parte dei casi il problema
centrale nello Sviluppo di quasi tutti i
prodotti è, soprattutto oggi, la
mancanza di Conoscenza che hanno
sia i Clienti che i Progettisti
Lean Project Management
Oggi il mondo cambia molto
rapidamente e, quindi, per competere,
si deve puntare sempre di più
sull'Innovazione cioè su cose che, per
definizione, … né i clienti né gli
sviluppatori conoscono
Un assioma famoso
“Se fossi stato a sentire i miei clienti …
avrei prodotto una carrozza più
veloce!” H. Ford
Lean Project Management
Ed è proprio la mancanza di
Conoscenza che rende velleitario il
metodo predittivo
Lean Project Management
Se infatti manca la conoscenza è
impossibile pretendere di restare nella
comfort zone, quella zona dove siamo,
dove sappiamo cosa fare e dove
possiamo prevedere esattamente e a
priori cosa fare, magari pianificandolo
con un Gantt
Lean Project Management
In un mondo che cambia rapidamente
si deve uscire volontariamente dal
comfort per entrare nella zona
dell'apprendimento
Lean Project Management
Se infatti il rimettere sempre tutto in
discussione (il sano dubbio galileiano
… eppur si muove!) e
l'apprendimento continuo non entrano
nel nostro DNA rischiamo il fallimento
da panico in presenza delle inevitabili
situazioni nuove
Lean Project Management
Panico perché, se ci adagiamo nella
comfort zone e non impariamo a
reagire ai cambiamenti ambientali, non
solo non sapremo come risolvere i
problemi dell'Innovazione ma non
sapremo neppure come affrontarli
Conoscenza & Sviluppo
• Fortunati allora quei tecnici che
possono gestire processi ongoing
relativamente Well Structured
Conoscenza & Sviluppo
• Tali processi possono infatti essere
“mappati” e, quindi, ottimizzati (per
il Lean in ottica del Valore per il
cliente ed ilVSM – Value Stream
Mapping è una delle tecniche di base
del Lean Manufacturing)
Well Structured
• Un processo è
mappabile quando
le sue attività, la
loro sequenza ed i
processi di controllo
associati sono stabili
e possono a priori
essere descritti
(abbastanza)
accuratamente
Conoscenza & Sviluppo
• È quello che si fa anche nello
Sviluppo con il metodo Predittivo
utilizzando i reticoli di pianificazione
(ad esempio il CPM-Critical Path
Method), il Gantt e l'Earned Value
Conoscenza & Sviluppo
• La Progettazione purtroppo è oggi
(non ai tempi del Gantt) un Processo
di ricerca e apprendimento a prova
ed errore nello spazio della
Conoscenza
Conoscenza & Sviluppo
• Oltretutto, per complicare la vita, i
progetti devono avere ben definite
date di inizio e di termine: non c'è
quindi molto tempo per recuperare
gli errori
Conoscenza & Sviluppo
• La progettazione è, bene che vada,
un processo Semi-Structured (ancora
mappabile ma con molti If/Then)
Semi-Structured
Solo una parte di un
processo semi-strutturato
può essere definita in
anticipo mentre un'altra
parte non può essere
completamente specificata
sia per tipo e sequenza
delle attività che per le
modalità di controllo
Conoscenza & Sviluppo
• Più spesso è però un Processo
Knowledge-Based, assolutamente
non mappabile e, quindi, non
ottimizzabile e predicibile
Knowledge-based
I processi knowledge
based sono difficili da
definire in anticipo e non
possono avere
transazioni fisse e
strutture rigide in quanto
le loro attività nascono da
continue interazioni fra
“attori” diversi e sinergici
(a partire dai clienti)
Knowledge-based
• A priori, nei Processi Knowledge-
based, si possono solo definire i
Partecipanti e l'Elenco delle Cose
ancora da Fare (in gergo Agile il
Backlog) con l'ovvia necessità che
tempi e costi dell'Apprendimento
siano i più bassi possibile
Oltre la gestione classica
Per muoversi meglio nello Spazio
della Conoscenza, il Lean spinge a
utilizzare una gestione incrementale
ed iterativa o, meglio, adattiva
(PMBOK5 § 2.4.2.3/.4)
PMBOK5
• “I cicli di vita incrementali ed iterativi
sono quelli in cui le fasi ripetono
intenzionalmente (si ripete per capire
meglio e per migliorare) una o più
attività del progetto mentre aumenta
la comprensione del prodotto da
parte del team di progettazione”
Oltre la Cascata
• Una gestione Lean “incrementale ed
iterativa” richiede di svolgere lo
Sviluppo con modalità:
– Knowledge Based
– Front Loaded (metodo 3P della Toyota)
– Pull
Knowledge Based
• Sviluppo Knowledge Based vuol dire
che, per muoversi nello spazio ignoto
della Conoscenza, sono necessari,
come detto, adeguati e continui
(veloci) cicli di Apprendimento
convalidati da sperimentazione
Knowledge Based
• Tali cicli, basati sul “metodo
scientifico-sperimentale”, sono i
classici PDCA (Plan, Do, Check,
Act)
• Almeno il ciclo PDCA di
apprendimento ve l'hanno insegnato
(dico ai più giovani) all'Università?
Knowledge Based
• Una banale conseguenza: se per
migliorare i risultati e per ridurre i
rischi si deve Apprendere, è
necessario poter cambiare le cose e
non “scriverle a priori sulla pietra”
Knowledge Based
• È allora sbagliato scegliere da subito,
in fase Plan, la prima soluzione che si
ritiene (o che il capo per fretta e
pregiudizio ritiene) la migliore per
soddisfare le specifiche iniziali
(Point Based Engineering)
Knowledge Based
• È molto più ragionevole ipotizzare
molte soluzioni, in comune però, in
quanto più occhi …. vedono meglio di
pochi, fra tutti “gli attori del ciclo di
vita”
Knowledge Based
• Questo lo si fa utilizzando il
Brainstrorming che rende il Plan una
fase creativa a “imbuto divergente”
Knowledge Based
• Una volta trovate molte soluzioni si
devono, dopo adeguate prove
sperimentali (Do e Check),
selezionare (Act) quelle migliori!
Knowledge Based
• Tali prove, generalmente grezze e
veloci (dirty & quickly), serviranno a
scartare (metodo incrementale a
imbuto convergente) le soluzioni
peggiori
Knowledge Based
• Si manderanno avanti le soluzioni
potenzialmente migliori da sottoporre
ad analisi più accurate (metodo del
Set Based Engineering definito anche
Toyota Paradox)
Knowledge Based
• Per poi congelare le soluzioni
prescelte o, se necessario od
opportuno, cambiarle ancora, mano a
mano che migliora la conoscenza !
Front Loaded
• Front Loaded vuol dire collaborazione
fra tutti gli attori del Ciclo di vita in
tutte le fasi dello Sviluppo, per
evitare “l'effetto salmone”
Front Loaded
• Alcuni prevedono di farlo solo nella
fase del Concept Paper previsionale
ma, secondo me, questo è sbagliato
Front Loaded
• Si devono continuamente
“Coinvolgere nel Team di sviluppo”
anche gli specialisti di Marketing,
Produzione, Montaggio, …, rompendo
i tradizionali Silos Tayloristici !
Concurrent Engineering
Pull
• Pull vuol dire far pianificare il lavoro,
a ciclo breve, dagli stessi sviluppatori
delegando a loro le scelte delle
attività da svolgere (sono loro gli
Owners del Processo)
Pull
• Ed il coinvolgimento motiverà gli
sviluppatori molto meglio che non la
tradizionale “gerarchia”
Pull
• Per il Lean la ripianificazione pull
deve essere frequente (pochi giorni)
durante bervissimi “Stand up
meeting” utilizzando strumenti
visuali (Visual Project Board)
Visual Workflow Management
Per riassumere
Di seguito vi propongo uno schema
riassuntivo dello “Sviluppo
Incrementale ed Iterativo”
Steering
Committee
Gates
Business Case
Preliminary Processes
Cicli Adattivi - PMBOK5
• “I cicli di vita adattivi, noti anche
come metodologia Agile, sono volti a
rispondere agli alti livelli di modifiche
e al continuo coinvolgimento degli
Stakeholders (in particolare dei
clienti)”
Gestione adattiva
• La gestione “adattiva”, nota anche
come Scrum, è un'estremizzazione
di quella incrementale ed iterativa
Gestione adattiva
• Scrum spinge ad aggiornare ad ogni
Sprint (brevi intervalli iterativi di
tempo, da 2 a 4 settimane) anche i
Requisiti in base all'aumento della
Conoscenza che non solo gli
Sviluppatori ma che gli stessi Clienti
(e gli altri Stakeholders) avranno
durante lo Sviluppo
Gestione adattiva
• Nella gestione “adattiva” gli Sprint
devono portare a dei Risultati,
parziali ma concreti (i classici
Deliverables), che però i Clienti e gli
altri Stakeholders possano provare
e approvare, magari tramite
Deliverables ad hoc (MVP – Minimum
Viable Products)
Gestione adattiva
• In Scrum il Controllo a “maglia
stretta” viene svolto ad ogni Sprint
dal Product Owner (il PO rappresenta
i Clienti e gli altri Stakeholders), un
nuovo Ruolo, diverso dai classici
Product Manager e Project Manager
Il PO
• Il PO è lo Zar del prodotto (non del
processo che è, come detto, di
“proprietà” del team di sviluppo) in
quanto durante il ciclo di vita,
rappresentando i clienti, ha tutti i
poteri sullo stesso
Gestione adattiva
• La gestione adattiva è sicuramente
necessaria nello sviluppo del SW e
dei Servizi (generalmente i clienti si
rendono conto delle vere funzionalità
solo dopo averle effettivamente
provate)
Gestione adattiva
• Oggi è però opportuna anche nello
Sviluppo dei Prodotti manifatturieri
Gestione adattiva
• Si tenga presente oltretutto che oggi
i prodotti manifatturieri:
– possono essere simulati tramite SW per
costruire degli MVP
– la maggior parte ha una sostanziale
componente SW che ne definisce le
funzionalità
Gestione adattiva
• In sintesi la metodologia adattativa è
la successiva
Gestione adattiva
Steering
Committee
Sprint Preliminari per
Gate
valutare il Business Case
Sprint 1
Sprint i
2- 4 settimane
PO Committee PO Committee
Events
Events
Steering
Committee
Gate
Sviluppo Incrementale e Adattivo del Prodotto
Sprint n
PO Committee
Events
Sprint n+1
PO Committee
Events
PO Committee
Events
Gestione adattiva
Sprint – iterazione a periodo fisso (2-4 settimane)
Scope (Ambito)
Event:
✔ Requirements
Sprint Planning
Event
Visual Workflow
Management
(Stand-up Meeting)
✔ Attributes
✔ Configuration
✔ Risk
✔ 3P
PO Committee
Events
Design Review
& Freeze
Event
Retrospective
Event
Conclusioni
• Avendo detto che sono un po'
obsoleti, quale strumento (Lean) vi
propongo al posto del Gantt e del
Earned Value ?
Conclusioni
• Ma è ovvio lo Scrum Board con la sua
Burndown Chart !
To do
Ongoing
Done
Sprint Goal
Conclusioni
• Ma c'è uno strumento ancora più
Lean, magari utilizzabile anche
individualmente, per programmare le
proprie attività?
Conclusioni
• Ma certo: il Kanban Board !
Kanban Board
Limiti Kanban
(WiP)
Bibliografia essenziale
• PMBOK5
• Lean Thinking, J. P. Womack e D. T.
Jones, Guerini e Associati
• Essential Scrum, K. S. Rubin, AddisonWesley Series
• Agile Estimating and Planning, M. Cohn,
Prentice Hall
• Innovazione Lean, L. Attolico, Hoepli
[email protected]
[email protected]
