Pianificazione adattiva - Brewbox - 2017-03
65
-
Upload
roberto-albertini -
Category
Software
-
view
260 -
download
2
Transcript of Pianificazione adattiva - Brewbox - 2017-03
Pianificazione adattivaStrumenti per controllare lo sviluppo software
Roberto [email protected]
@robalbertini
BrewBox marzo 2017
Progetto Penelope
6 funzionalità
Progetto Penelope: happy path
Pianificate su 12 settimane
Dopo 12 settimane
Online
Sai che accadrannonon sai quando
La realtà
Cambiamenti nei requisitiAnticipo della scadenza
Tecnologie ostiliSprechiBachi
Shit happens
“
”
Lo sviluppo non è predicibile
ma è controllabile
Martin FowlerUML Distilled: A Brief Guide to the Standard Object Modeling Language
Controllare lo sviluppo
Predire è illusorio Controllare è realistico
L’obiettivo è ottenere
il miglior risultato possibile
Scaletta
I. Gli strumenti essenzialiGestione dello scope
II. Reazioni agli imprevistiCosto - Tempo - Qualità - Scope
III. Anticipare ed evitare gli imprevistiGestione del rischio, automazione, semplicità, gestione del tempo
Gli strumenti essenzialiGestione dello scope
I parte
DevelopmentChi implementa il software
BusinessChi decide cosa il software debba fare
Chi controlla lo sviluppo?
Progetto Penelope: un racconto alternativo
Dopo 7 settimaneStop al progetto
È un successoo un fallimento?
Pianificato come prima
Quanto valore viene consegnato?
24
96
Consegnato
Abbandonato
Solo le storie complete sono consegnabili
84
60
24
12
12
Negoziazione dello scope
“Avevamo quasi finito… all’80%”
Si può consegnarealmeno una parte?
Esiste una versione più semplice?
84
24
12
12
60
Negoziazione della storia non completa
Esiste! La estraggo e la consegno
36
84
Consegnato (invece di 24)
Abbandonato (invece di 96)
84
60
24
12
12
48
12
Proviamo asplittare tutte le storie
con dimensioni uniformi
Il progetto è più manovrabile
84
60
24
12
12 3 + 9
12 + 12 + 30 + 6
6 + 18
3 + 9
Pianificazione con storie piccole
9
84
6
183
39
121230
6
48
72
Consegnato (erano 36 o 24)
Abbandonato (erano 84 o 96)
Con storie tutte piccoleL’imprevisto è meno grave
Pianificazione con storie piccole
Split delle storie
Non semplicemente dividere in parti ma...
Separare le parti ad alto valoreda quelle a basso valore
Esiste una versione più semplice?È tutto indispensabile?
Split delle storie
Non semplicemente dividere in parti ma...
Aggiungere partiEsplorando le esigenze del cliente
Features implicite
Catalogo tecniche di split
The Big Picture‣ Research vs Action‣ Spike vs Implementation‣ Manual vs Automated‣ Buy vs Build‣ Build vs Buy
User Experience‣ Batch vs Online‣ Single-User vs Multi-User‣ API only vs User Interface‣ Character UI or Script UI vs GUI‣ Generic UI vs Custom UI
Ilities‣ Static vs Dynamic‣ Ignore errors vs Handle errors‣ Transient vs Persistent‣ Low fidelity vs High fidelity‣ Unreliable vs Reliable‣ Small scale vs Large scale‣ Less "ilities," e.g., slower vs More "ilities"
Features‣ Few features vs Many features‣ Main flow vs Alternate flows‣ 0 vs 1‣ 1 vs Many‣ Split condition vs Full condition‣ One level vs All levels‣ Base case vs General case
Bill Wake: http://xp123.com/articles/twenty-ways-to-split-stories/
Alcuni esempi di split
Volatile
Mono utente
CRUD
Ui generica
Script UI
Persistente
Multi utente
R-CUD
Ui custom
GUI
⇄
⇄
⇄
⇄
⇄
Catalogo tecniche di split
The Big Picture‣ Research vs Action‣ Spike vs Implementation‣ Manual vs Automated‣ Buy vs Build‣ Build vs Buy
User Experience‣ Batch vs Online‣ Single-User vs Multi-User‣ API only vs User Interface‣ Character UI or Script UI vs GUI‣ Generic UI vs Custom UI
Ilities‣ Static vs Dynamic‣ Ignore errors vs Handle errors‣ Transient vs Persistent‣ Low fidelity vs High fidelity‣ Unreliable vs Reliable‣ Small scale vs Large scale‣ Less "ilities," e.g., slower vs More "ilities"
Features‣ Few features vs Many features‣ Main flow vs Alternate flows‣ 0 vs 1‣ 1 vs Many‣ Split condition vs Full condition‣ One level vs All levels‣ Base case vs General case
Bill Wake: http://xp123.com/articles/twenty-ways-to-split-stories/
Proviamo a“incassare” presto il valore
ordinando le storie
Per primele più importanti9
84
6
183
39
121230
6
3
1212
6
43
3018
998
6
Pianificazione anticipando il valore
3
1212
6
43
3018
998
6
90
30
Consegnato (erano 48 o 36 o 24)
Abbandonato (erano 72 o 84 o 96)
Le storie abbandonate sono le meno importanti
Pianificazione anticipando il valore
Pianificazione anticipando il valore
Per essere ordinabili
devono essere
piccole
Ordinamento delle storie
Per essere ordinabili
ognuna deve avere un
valore percepibileper il business
Ordinamento delle storie
Per essere ordinabili
devono essere
indipendenti
User stories
INVEST in good storiesINVEST
– Independent– Negotiable– Valuable– Estimable– Small– Testable
Bill Wake: http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/
Efficacia della pianificazione
Dopo 7 settimaneStop al progetto
È un successoo un fallimento?
3
1212
6
43
3018
998
6
90
30
24
96
84
60
24
12
12
Lo strumento essenzialePianificare gestendo lo scope
Storie piccoleStorie verticali
Prima le più importanti
Fine I parte
Domande?
Reazioni agli imprevistiCosto - Tempo - Qualità - Scope
II parte
CostoPersone - attrezzature
TempoGestione tempo e scadenze
Come si controlla lo sviluppo?
Extreme Programming Explained: Embrace Change - Kent Beck
QualitàInterna ed esterna
ScopeLe funzionalità da implementare
Una storia è
più lunga del previsto
Tecnologie ostili Integrazioni ostili
Riduzioni di risorse9
84
30
183
39
12
12
66
Raconto alternativo: ritardo
9
84
6
183
39
121230
6
Aggiungendoprogrammatori
Aumenta il ritardoalmeno in una prima fase
84
39
12
12
9
84
183
39
66
30
12
12
9
183
30
6
6
Legge di Brooks
Reazione: controllando il costo
“
”
Aggiungere forza lavoroad un progetto software in ritardo,
lo farà ritardare ancora di più
Legge di Brooks
Frederick P. Brooks, JrThe Mythical Man-Month: Essays on Software Engineering (1975, 1995)
Legge di Brooks: cause
Tempo di inserimento (ramp up)Integrazione, Affiancamento, Apprendimento, Delega
Overhead di comunicazione (p(p − 1)/2)2 ⇒ 1 3 ⇒ 3 6 ⇒ 15 9 ⇒ 36 12 ⇒ 66
Divisibilità dei task"nine women can't make a baby in one month"
rimandare la scadenza
vincoli progettualivincoli legali
vincoli di costo
9
84
183
39
66
30
12
12
9
84
183
39
66
30
12
12
Reazione: controllando il tempo
sacrificando la qualitàcon effetto potente ed immediato
18
84
39
93
66
30
12
12
9
84
183
39
66
30
12
12
Diventa un debitorallenta lo sviluppo futuro
scontenta il cliente
Reazione: controllando la qualità
SplitNegoziazione
RiduzioneOrdinamento
Esiste una versione più semplice?È tutto indispensabile?
84
39
12
12
9
84
183
39
66
30
12
12
Reazione: controllando lo scope
5
3
3
66
9
25
15
53
SplitNegoziazione
RiduzioneOrdinamento
Consegnare le parti di maggior valoreIl miglior software possibile
3
84
66
39
9
12
12
9
84
183
39
66
30
12
12
2515
Reazione: controllando lo scope
Costo - Tempo - Qualità - Scopenon sono controllabili contemporaneamente
Inragiscono nelle variazioni
La leva più efficace è lo scope
L’obiettivo è ottenereil miglior software possibile
Fine II parte
Domande?
Anticipare ed evitare gli imprevistiGestione del rischio, automazione, semplicità, gestione del tempo
III parte
Pianifichiamo prima le storie più rischiose
Per scoprire prima gli imprevistiPer avere più tempo e più opzioni
Non tutti gli imprevisti sono “anticipabili”
12
9
98
6
183
3
41230
6
9
84
183
39
66
30
12
12
Pianificazione anticipando il rischio
Facciamo degli spikeEsplorazione “a perdere”
Per avere più tempo e più opzioni
Non tutti gli imprevisti sono “anticipabili”
0
9
84
6
183
39
121230
6
9
84
183
39
66
30
12
12
Ricerca delle difficoltà nascoste
Il rilascio
Alla 12ª settimanaè tutto pronto
9
84
6
183
39
121230
6
Mai rilasciatoIl sw esiste solo in sviluppo o test
Si scopre che il rilascio è lungo e difficile....e se fosse impossibile?
Il rilascio va fatto a t₀
9
84
6
183
39
121230
6
Bisogna rilasciare subitoanche solo un “walking skeleton”
Si costruisce una procedura di
Rilascio automatizzatoone click deployment
Alistair Cockburn: http://alistair.cockburn.us/Walking+skeleton Andrew Hunt, David Thomas: The Pragmatic Programmer: From Journeyman to Master
Implementazioni speculative
9
84
6
183
39
121230
6
9
8
4
6183
3
9
1212306
Implementazioni
utili nel futuroma non nel presente
A volte sembranouna buona idea
Implementazioni, design o framework
Implementazioni speculative: cambio di direzione
...poi il Business
Sostituisce 5 storie con5 nuove molto importanti
8
4
3
9
1212
9
6183
306
12
3018
24
9
A volte sembranouna buona idea
9
8
4
6183
3
9
1212306
Implementazioni speculative: effetti
Porto il fardellodell’implementazione speculativa
In più, sono in ritardoper le nuove features
8
4
3
9
12
6
12
3018
24
9
12
9
8
4
6183
3
9
1212306
Implementazioni speculative: meglio di no
9
84
6
183
39
121230
6
Senzainvestimentospeculativo
9
84
6
183
39
12126
612
3018
24
9
I cambi di direzione del Businessnon sono un problema
Implementa solo l’essenziale(KISS, YAGNI, definisci bene il “DONE”)
Design semplicee flessibile
Rimanda le decisioniall’ultimo momento responsabile
Come evitare gli investimenti speculativi
Le storie
sono un segnapostoper una conversazione futura
Storie vicine piccoleStorie lontane grandi
Come evitare gli investimenti speculativi di analisi
“
”
It works on my machine!
Programmatore anonimo poco prima di fare commit sull’scm
Integrazione continua dei sorgenti
Il codice va
integrato ogni poche ore
Gli sviluppatori collaborano
sull’unico branch esistente
https://trunkbaseddevelopment.com
“
”
Il lavoro si espande fino aoccupare tutto il tempo disponibile;
più è il tempo e più il lavorosembra importante e impegnativo
Legge di Parkinson
Cyril Northcote Parkinson
Ottimizzare il tempo
TimeboxingIterazioni, Tecnica del pomodoro
Tracking e analisiEsplicitare il tempo utilizzato
Definire cosa è DONEEsplicitare lo scope
Anticipare gli imprevistiper avere più margine di manovra
Controllare gli imprevistidistribuendo il rischio nel tempo
Non sprecare tempoorganizzandosi e rinunciando a predire il futuro
Fine III parte
Domande?
Ricapitolando
Alcune pratiche utili
‣ storie piccole‣ storie verticali ‣ ordinamento storie per valore‣ storie come segnaposto per conversazione‣ Solo l’essenziale (KISS, YAGNI, DONE)‣ Ultimo momento responsabile‣ Ordinamento storie per rischio‣ Spike‣ Rilasciare subito‣ Automazione‣ Continuous integration‣ Test automatizzati‣ Timebox‣ Tracking
Costo‣ Aumento del numero di persone‣ Strumenti migliori‣ Specialisti
Tempo‣ Posticipare‣ Ottimizzare l’uso del tempo
Qualità‣ Interna ed esterna‣ Debito
Scope‣ Negoziazione‣ Riduzione‣ Ordinamento
Ricapitolando
Predire è illusorio Controllare è realistico
L’obiettivo è ottenere
il miglior risultato possibile
Grazie perl’attenzione
Fine
Roberto Albertini
@robalbertini
www.linkedin.com/in/robertoalbertini
www.newgenesys.it
Credits
‣ Presentation template: Gremio by Slidescarnivalhttp://www.slidescarnival.com/gremio-free-presentation-template/1593
‣ Base color: Marsala #964F4C by Pantonehttp://www.pantone.com/color-of-the-year-2015https://www.pantone.com/color-finder/18-1438-TCX
‣ Font: Roboto by Google (Christian Robertson) https://fonts.google.com/specimen/Roboto
‣ Font: Great Vibes by TypeSETit https://fonts.google.com/specimen/Great+Vibes
‣ Icons: Font Awesome Vector Icons/Glyphshttps://goo.gl/vdQGpu, http://fontawesome.io/
Abstract
Tradizionalmente la pianificazione è vista come uno strumento per prevedere l’andamento di un progetto e congelare una promessa in un piano.
Questa promessa viene spesso smontata da cambiamenti ed imprevisti durante la vita del progetto.
Esiste un diverso approccio, che considera il cambiamento come una componente inevitabile.
Si rinuncia al desiderio di prevedere il progetto e ci si concentra su come controllarlo e adattarlo per ottenere il miglior risultato possibile.
Nel talk, tramite simulazioni di progetti dove accadono i tipici imprevisti, verranno presentati gli strumenti e le pratiche che permettono di controllare al meglio il progetto.
http://agilemanifesto.org 2001
