I 4 punti cardinali bla bla blaJacopo Romei
Chi sono●   Coach agile dal 2005●   Coach in ideato dal 2008●   Autore di “Pro PHP Refactoring”, pubblicato da    Apress● ...
NordFocus sui clienti
Whats in a name?Chi sono i nostri clienti?
Clienti che pagano
CliUtenti che usano
Clienti che supportano
Clienti che derivano valore
Conosci il tuo scopo?
Raramente il nostro core corrisponde allo scopo.   Codice, grafica, wireframes, pubblicità...          Outside-in è tutto ...
Failure demand     vs.Value demand
EstPotenzialità del sistema
Misurare è capire.
Ma bisogna capire cosa misurare.            E come.
La varianza è un invariante.
Un esempio                 :-)                                         :-)20181614121086420     1   2   3    4    5   :-( ...
Stabilire obiettivi●   Il sistema è stabile    ●   Stabilire obiettivi è inutile    ●   Un obiettivo troppo ambizioso non ...
Obiettivi assoluti         vs.Obiettivi relativi(usare con moderazione)
Sfide, non obiettivi.
Le sfide sono a lungo termine e sollecitano              passione e orgoglio.Le sfide comunicano fiducia nelle persone e n...
SudFlusso end-to-end
Eliminare il failure demand
Mappare il value demand
Value stream map
Cogliere le migliori opportunità di miglioramento
OvestSprechi da politiche aziendali
Sprechi da politiche aziendali●   Complessità●   Economie di scala●   Separazione tra decisioni e lavoro●   Pensiero illus...
“I software, rispetto alla loro estensione, sono i più complessi fra tutti gli artefatti umani. […]  Molti dei classici pr...
Lo sappiamo e nonostante ciò...
Complessità I  I nostro software contengono tonnellate di    funzionalità che rimangono inutilizzate.La nostra più grande ...
Complessità II        Non negoziamo mai lo scope.Costi, scadenze, scope: negoziare questultimo           dovrebbe essere r...
Complessità IIIUsiamo metriche quantitative, un tanto al chilo.Function points et similia forniscono interessanti         ...
Complessità IV   Abbiamo fretta di aggiungere funzionalità.No al non si sa mai. Sì al chissà se davvero poi.
Complessità V Automatizziamo processi complessi.Prima semplificare, poi automatizzare.
La nostra forma mentis è radicata nelleconomia  di scala, ma nei sistemi con grande varianza    leconomia di flusso rende ...
Lo sappiamo e nonostante ciò...
Economie di scala INon abbandoniamo la mentalità da “lotti e coda”cercando la massima occupazione delle risorse.  Così non...
Economie di scala IITalmente assorbiti dalla mentalità “lotti e coda”       che non vediamo le vere code.Procrastiniamo le...
Economie di scala III  Lavoriamo in continuo multi-tasking e nonvediamo gli sprechi inerenti al continuo context          ...
Economie di scala IVQuando riusciamo a fare una cosa per volta ci preoccupiamo di raggiungere la massima              occu...
Economie di scala V Lavoriamo su budget annuali e piani a lungo   termine, promettendo consegne enormi.Poi la realtà inter...
I grandi sistemi IT nascono dalla grande       competenza delle persone.
Lo sappiamo e nonostante ciò...
Separazione tra decisione e lavoro ICè la diffusa presunzione che i manager possano   non capire gli aspetti tecnici del l...
Separazione tra decisione e lavoro II    La cosa migliore che possa accadere ad ungrafico/sviluppatore/creativo è quella d...
Separazione tra decisione e lavoro                III   Continui passamano separano responsabilità(cosa fare), conoscenza ...
Separazione tra decisione e lavoro               IVParliamo di business come di una cosa separata                    dallI...
Separazione tra decisione e lavoro V   Separiamo i team di sviluppo dai team di                  supporto.Chi fa dovrebbe ...
Lindustria ford-taylorista e lindustria lean hannoin comune la convinzione che le decisioni debbano      basarsi sui dati ...
Lo sappiamo e nonostante ciò...
Pensiero illusorio IInseguiamo metodi e strumenti di moda senza  sottoporli al vaglio della sequenza ipotesi-          esp...
Pensiero illusorio IIGestiamo i progetti sulla base di dati puntuali e     non su serie di dati contestualizzati.  Una cer...
Pensiero illusorio IIINon ci piace lincertezza, è scomoda e cerchiamo  di rimuoverla presto, cercando di sfoltire la      ...
Pensiero illusorio IVGestiamo un sacco di conoscenza, ma ancora nonè chiaro come preservarla nei gruppi. I documenti      ...
Pensiero illusorio V    Il mero funzionamento non equivale al               completamento.Il nostro sistema, la nostra cam...
Posso indebitarmi per permettermi uninvestimento altrimenti impossibile. Raggiungereun obiettivo indebitandosi non lo rend...
Lo sappiamo e nonostante ciò...
Debito tecnico I            Tolleriamo codice oscuro.I junior dovrebbero essere educati al clean code. I     senior dovreb...
Debito tecnico II           Non facciamo refactoring.Se vogliamo essere incrementali non cè scelta: il    refactoring è do...
Debito tecnico IIILasciamo che i test di regressione diventino lenti. Man mano che il deficit cresce, diminuiamo la       ...
Debito tecnico IV Esitiamo a rimpiazzare sistemi obsoleti zeppi di  dipendenze con nuove e migliori architetture.Bisogna m...
Debito tecnico VTardiamo ad integrare il nostro codice con quello  di altri sviluppatori e quello in altri branch.       L...
Jacopo Romei jr@ideato.itvia Quinto Bucci 205 47023 Cesena (FC)  info AT ideato.it   www.ideato.it
Upcoming SlideShare
Loading in …5
×

I quattro punti cardinali per un orientamento lean nell'impr... insomma.

2,291 views

Published on

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.

Published in: Business

I quattro punti cardinali per un orientamento lean nell'impr... insomma.

  1. 1. I 4 punti cardinali bla bla blaJacopo Romei
  2. 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. 3. NordFocus sui clienti
  4. 4. Whats in a name?Chi sono i nostri clienti?
  5. 5. Clienti che pagano
  6. 6. CliUtenti che usano
  7. 7. Clienti che supportano
  8. 8. Clienti che derivano valore
  9. 9. Conosci il tuo scopo?
  10. 10. Raramente il nostro core corrisponde allo scopo. Codice, grafica, wireframes, pubblicità... Outside-in è tutto muda.
  11. 11. Failure demand vs.Value demand
  12. 12. EstPotenzialità del sistema
  13. 13. Misurare è capire.
  14. 14. Ma bisogna capire cosa misurare. E come.
  15. 15. La varianza è un invariante.
  16. 16. Un esempio :-) :-)20181614121086420 1 2 3 4 5 :-( 6 7 8 9 10 11 12 13 14 15 :-(
  17. 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. 18. Obiettivi assoluti vs.Obiettivi relativi(usare con moderazione)
  19. 19. Sfide, non obiettivi.
  20. 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. 21. SudFlusso end-to-end
  22. 22. Eliminare il failure demand
  23. 23. Mappare il value demand
  24. 24. Value stream map
  25. 25. Cogliere le migliori opportunità di miglioramento
  26. 26. OvestSprechi da politiche aziendali
  27. 27. Sprechi da politiche aziendali● Complessità● Economie di scala● Separazione tra decisioni e lavoro● Pensiero illusorio● Debito tecnico
  28. 28. “I software, rispetto alla loro estensione, sono i più complessi fra tutti gli artefatti umani. […] Molti dei classici problemi dello sviluppo diprodotti software derivano da questa essenziale complessità e dalla sua crescita non lineare” Fred Brooks No silver bullet
  29. 29. Lo sappiamo e nonostante ciò...
  30. 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. 31. Complessità II Non negoziamo mai lo scope.Costi, scadenze, scope: negoziare questultimo dovrebbe essere routine.
  32. 32. Complessità IIIUsiamo metriche quantitative, un tanto al chilo.Function points et similia forniscono interessanti dati relativi.
  33. 33. Complessità IV Abbiamo fretta di aggiungere funzionalità.No al non si sa mai. Sì al chissà se davvero poi.
  34. 34. Complessità V Automatizziamo processi complessi.Prima semplificare, poi automatizzare.
  35. 35. La nostra forma mentis è radicata nelleconomia di scala, ma nei sistemi con grande varianza leconomia di flusso rende molto megliodelleconomia di scala. Nellindustria IT più che mai.
  36. 36. Lo sappiamo e nonostante ciò...
  37. 37. Economie di scala INon abbandoniamo la mentalità da “lotti e coda”cercando la massima occupazione delle risorse. Così non riusciamo ad assorbire linevitabile varianza.
  38. 38. Economie di scala IITalmente assorbiti dalla mentalità “lotti e coda” che non vediamo le vere code.Procrastiniamo le richieste dei clienti invece di dire un semplice no.
  39. 39. Economie di scala III Lavoriamo in continuo multi-tasking e nonvediamo gli sprechi inerenti al continuo context switching.Fare una cosa per volta permette di consegnare valore prima.
  40. 40. Economie di scala IVQuando riusciamo a fare una cosa per volta ci preoccupiamo di raggiungere la massima occupazione.Così non riusciamo – di nuovo - ad assorbire linevitabile varianza.
  41. 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. 42. I grandi sistemi IT nascono dalla grande competenza delle persone.
  43. 43. Lo sappiamo e nonostante ciò...
  44. 44. Separazione tra decisione e lavoro ICè 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. 45. Separazione tra decisione e lavoro II La cosa migliore che possa accadere ad ungrafico/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. 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. 47. Separazione tra decisione e lavoro IVParliamo di business come di una cosa separata dallIT. Il business IT è lIT.
  48. 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. 49. Lindustria ford-taylorista e lindustria lean hannoin comune la convinzione che le decisioni debbano basarsi sui dati più che sulle decisioni.
  50. 50. Lo sappiamo e nonostante ciò...
  51. 51. Pensiero illusorio IInseguiamo metodi e strumenti di moda senza sottoporli al vaglio della sequenza ipotesi- esperimento-conclusione. Adottiamo nuovi approcci senza valutarne laproprietà nel nostro contesto e poi siamo delusi dai risultati.
  52. 52. Pensiero illusorio IIGestiamo 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. 53. Pensiero illusorio IIINon ci piace lincertezza, è 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. 54. Pensiero illusorio IVGestiamo un sacco di conoscenza, ma ancora nonè chiaro come preservarla nei gruppi. I documenti enormi che non legge nessuno. Forse lopen source può insegnarci qualcosa?
  55. 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. 56. Posso indebitarmi per permettermi uninvestimento altrimenti impossibile. Raggiungereun obiettivo indebitandosi non lo rende gratuito e prima o poi quel debito va saldato o falliremo comunque.
  57. 57. Lo sappiamo e nonostante ciò...
  58. 58. Debito tecnico I Tolleriamo codice oscuro.I junior dovrebbero essere educati al clean code. I senior dovrebbero dare il buon esempio.
  59. 59. Debito tecnico II Non facciamo refactoring.Se vogliamo essere incrementali non cè scelta: il refactoring è dobbligo. Per definizione!
  60. 60. Debito tecnico IIILasciamo 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. 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. 62. Debito tecnico VTardiamo ad integrare il nostro codice con quello di altri sviluppatori e quello in altri branch. Lintegrazione big bang è obsoleta.
  63. 63. Jacopo Romei jr@ideato.itvia Quinto Bucci 205 47023 Cesena (FC) info AT ideato.it www.ideato.it

×