In un mercato già particolarmente competitivo, se l'acqua è poca, far galleggiare la papera diventa ancora più difficile. Reagire alla siccità economica significa asciugare le infrastrutture, ma soprattutto asciugare il modo di pensare. Focus sui clienti, potenziale sistemico dell'azienda, flusso di valore e policy sprecone sono i 4 specchi delle nostre brame per stabilire chi sia il più lean del reame.

1. I 4 punti cardinali bla bla bla
Jacopo Romei

2. Chi sono
● Coach agile dal 2005
● Coach in ideato dal 2008
● Autore di “Pro PHP Refactoring”, pubblicato da
Apress
● http://www.sviluppoagile.it/
● @jacoporomei

3. Nord
Focus sui clienti

4. What's in a name?
Chi sono i nostri clienti?

5. Clienti che pagano

6. CliUtenti che usano

7. Clienti che supportano

8. Clienti che derivano valore

9. Conosci il tuo scopo?

10. Raramente il nostro core corrisponde allo scopo.
Codice, grafica, wireframes, pubblicità...
Outside-in è tutto muda.

11. Failure demand
vs.
Value demand

12. Est
Potenzialità del sistema

13. Misurare è capire.

14. Ma bisogna capire cosa misurare.
E come.

15. La varianza è un invariante.

16. Un esempio
:-) :-)
20
18
16
14
12
10
8
6
4
2
0
1 2 3 4 5 :-(
6 7 8 9 10 11 12 13 14 15
:-(

17. Stabilire obiettivi
● Il sistema è stabile
● Stabilire obiettivi è inutile
● Un obiettivo troppo ambizioso non verrà raggiunto
● Il sistema è instabile
● Stabilire obiettivi è inutile
● Non c'è predittibilità, tantomeno controllo

18. Obiettivi assoluti
vs.
Obiettivi relativi
(usare con moderazione)

19. Sfide, non obiettivi.

20. Le sfide sono a lungo termine e sollecitano
passione e orgoglio.
Le sfide comunicano fiducia nelle persone e nella
loro capacità di innovare.
Le sfide descrivono una strategia orientata al
futuro, abilitando le persone ad agire in modo
indipendente.

21. Sud
Flusso end-to-end

22. Eliminare il failure demand

23. Mappare il value demand

24. Value stream map

25. Cogliere le migliori opportunità di miglioramento

26. Ovest
Sprechi da politiche aziendali

27. Sprechi da politiche aziendali
● Complessità
● Economie di scala
● Separazione tra decisioni e lavoro
● Pensiero illusorio
● Debito tecnico

28. “I software, rispetto alla loro estensione, sono i
più complessi fra tutti gli artefatti umani. […]
Molti dei classici problemi dello sviluppo di
prodotti software derivano da questa essenziale
complessità e dalla sua crescita non lineare”
Fred Brooks
No silver bullet

29. Lo sappiamo e nonostante ciò...

30. Complessità I
I nostro software contengono tonnellate di
funzionalità che rimangono inutilizzate.
La nostra più grande opportunità: smetterla di
aggiungere funzionalità non strettamente
necessarie.

31. Complessità II
Non negoziamo mai lo scope.
Costi, scadenze, scope: negoziare quest'ultimo
dovrebbe essere routine.

32. Complessità III
Usiamo metriche quantitative, un tanto al chilo.
Function points et similia forniscono interessanti
dati relativi.

33. Complessità IV
Abbiamo fretta di aggiungere funzionalità.
No al 'non si sa mai'. Sì al 'chissà se davvero poi'.

34. Complessità V
Automatizziamo processi complessi.
Prima semplificare, poi automatizzare.

35. La nostra forma mentis è radicata nell'economia
di scala, ma nei sistemi con grande varianza
l'economia di flusso rende molto meglio
dell'economia di scala. Nell'industria IT più che
mai.

36. Lo sappiamo e nonostante ciò...

37. Economie di scala I
Non abbandoniamo la mentalità da “lotti e coda”
cercando la massima occupazione delle risorse.
Così non riusciamo ad assorbire l'inevitabile
varianza.

38. Economie di scala II
Talmente assorbiti dalla mentalità “lotti e coda”
che non vediamo le vere code.
Procrastiniamo le richieste dei clienti invece di
dire un semplice 'no'.

39. Economie di scala III
Lavoriamo in continuo multi-tasking e non
vediamo gli sprechi inerenti al continuo context
switching.
Fare una cosa per volta permette di consegnare
valore prima.

40. Economie di scala IV
Quando riusciamo a fare una cosa per volta ci
preoccupiamo di raggiungere la massima
occupazione.
Così non riusciamo – di nuovo - ad assorbire
l'inevitabile varianza.

41. Economie di scala V
Lavoriamo su budget annuali e piani a lungo
termine, promettendo consegne enormi.
Poi la realtà interviene, i requisiti cambiano, ci
rendiamo conto che qualcosa non va e non
sappiamo come fuggire al meccanismo delle
promesse enormi.

42. I grandi sistemi IT nascono dalla grande
competenza delle persone.

43. Lo sappiamo e nonostante ciò...

44. Separazione tra decisione e lavoro I
C'è la diffusa presunzione che i manager possano
non capire gli aspetti tecnici del lavoro che
gestiscono.
In un approccio lean i manager possono non avere
tutte le risposte, ma è decisivo che facciano le
giuste domande.

45. Separazione tra decisione e lavoro II
La cosa migliore che possa accadere ad un
grafico/sviluppatore/creativo è quella di smettere
di fare il proprio lavoro, elevato al rango di
manager.
Se la miglior carriera possibile ti fa lasciare la tua
competenza alle spalle, non avremo mai
competenza dove serve.

46. Separazione tra decisione e lavoro
III
Continui passamano separano responsabilità
(cosa fare), conoscenza (come fare), azione (fare) e
feedback (apprendere).
Nella pratica, tonnellate di decisioni sono prese
sulla base di conoscenza tacita, implicita.

47. Separazione tra decisione e lavoro
IV
Parliamo di 'business' come di una cosa separata
dall'IT.
Il business IT è l'IT.

48. Separazione tra decisione e lavoro V
Separiamo i team di sviluppo dai team di
supporto.
Chi fa dovrebbe vivere le conseguenze di ciò che
ha fatto.

49. L'industria ford-taylorista e l'industria lean hanno
in comune la convinzione che le decisioni debbano
basarsi sui dati più che sulle decisioni.

50. Lo sappiamo e nonostante ciò...

51. Pensiero illusorio I
Inseguiamo metodi e strumenti di moda senza
sottoporli al vaglio della sequenza ipotesi-
esperimento-conclusione.
Adottiamo nuovi approcci senza valutarne la
proprietà nel nostro contesto e poi siamo delusi
dai risultati.

52. Pensiero illusorio II
Gestiamo i progetti sulla base di dati puntuali e
non su serie di dati contestualizzati.
Una certa varianza è fisiologica. Tentare di
rimuoverla aggraverà i problemi.

53. Pensiero illusorio III
Non ci piace l'incertezza, è scomoda e cerchiamo
di rimuoverla presto, cercando di sfoltire la
gamma di alternative.
Di solito, avendo a che fare con problemi
complessi, non funziona così: sviluppare più
alternative costa meno che anticipare la
scrematura.

54. Pensiero illusorio IV
Gestiamo un sacco di conoscenza, ma ancora non
è chiaro come preservarla nei gruppi. I documenti
enormi che non legge nessuno.
Forse l'open source può insegnarci qualcosa?

55. Pensiero illusorio V
Il mero funzionamento non equivale al
completamento.
Il nostro sistema, la nostra campagna, il nostro
layout va osservato là fuori, fra gli utenti, nel
mondo vero.

56. Posso indebitarmi per permettermi un
investimento altrimenti impossibile. Raggiungere
un obiettivo indebitandosi non lo rende gratuito e
prima o poi quel debito va saldato o falliremo
comunque.

57. Lo sappiamo e nonostante ciò...

58. Debito tecnico I
Tolleriamo codice oscuro.
I junior dovrebbero essere educati al clean code. I
senior dovrebbero dare il buon esempio.

59. Debito tecnico II
Non facciamo refactoring.
Se vogliamo essere incrementali non c'è scelta: il
refactoring è d'obbligo. Per definizione!

60. Debito tecnico III
Lasciamo che i test di regressione diventino lenti.
Man mano che il deficit cresce, diminuiamo la
frequenza dei test.
Dobbiamo mantenere i test scattanti come nei
primi giorni del nostro progetto.

61. Debito tecnico IV
Esitiamo a rimpiazzare sistemi obsoleti zeppi di
dipendenze con nuove e migliori architetture.
Bisogna minimizzare le dipendenze. Sono decenni
che sappiamo come fare: information hiding e
separation of concerns.

62. Debito tecnico V
Tardiamo ad integrare il nostro codice con quello
di altri sviluppatori e quello in altri branch.
L'integrazione big bang è obsoleta.

63. Jacopo Romei
jr@ideato.it
via Quinto Bucci 205
47023 Cesena (FC)
info AT ideato.it
www.ideato.it