Pianificazione adattivaStrumenti per controllare lo sviluppo software

Roberto Albertinir.albertini@newgenesys.it

@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

r.albertini@newgenesys.it

@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