• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
I quattro punti cardinali per un orientamento lean nell'impr... insomma.
 

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

on

  • 2,030 views

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 ...

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.

Statistics

Views

Total Views
2,030
Views on SlideShare
2,020
Embed Views
10

Actions

Likes
8
Downloads
18
Comments
0

3 Embeds 10

http://paper.li 4
http://twitter.com 3
http://www.geekagenda.it 3

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

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

  • 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● http://www.sviluppoagile.it/● @jacoporomei
  • 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 muda.
  • 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 :-( 6 7 8 9 10 11 12 13 14 15 :-(
  • 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
  • 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 nella loro capacità di innovare. Le sfide descrivono una strategia orientata al futuro, abilitando le persone ad agire in modo indipendente.
  • 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 illusorio● Debito tecnico
  • “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
  • Lo sappiamo e nonostante ciò...
  • Complessità I I nostro software contengono tonnellate di funzionalità che rimangono inutilizzate.La nostra più grande opportunità: smetterla di aggiungere funzionalità non strettamente necessarie.
  • Complessità II Non negoziamo mai lo scope.Costi, scadenze, scope: negoziare questultimo dovrebbe essere routine.
  • Complessità IIIUsiamo metriche quantitative, un tanto al chilo.Function points et similia forniscono interessanti dati relativi.
  • 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 molto megliodelleconomia di scala. Nellindustria IT più che mai.
  • Lo sappiamo e nonostante ciò...
  • Economie di scala INon abbandoniamo la mentalità da “lotti e coda”cercando la massima occupazione delle risorse. Così non riusciamo ad assorbire linevitabile varianza.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 lavoro che gestiscono.In un approccio lean i manager possono non avere tutte le risposte, ma è decisivo che facciano le giuste domande.
  • 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.
  • 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.
  • Separazione tra decisione e lavoro IVParliamo di business come di una cosa separata dallIT. Il business IT è lIT.
  • 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.
  • Lindustria ford-taylorista e lindustria lean hannoin comune la convinzione che le decisioni debbano basarsi sui dati più che sulle decisioni.
  • Lo sappiamo e nonostante ciò...
  • 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.
  • 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.
  • 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.
  • 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?
  • 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.
  • 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.
  • Lo sappiamo e nonostante ciò...
  • Debito tecnico I Tolleriamo codice oscuro.I junior dovrebbero essere educati al clean code. I senior dovrebbero dare il buon esempio.
  • Debito tecnico II Non facciamo refactoring.Se vogliamo essere incrementali non cè scelta: il refactoring è dobbligo. Per definizione!
  • 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.
  • 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.
  • Debito tecnico VTardiamo ad integrare il nostro codice con quello di altri sviluppatori e quello in altri branch. Lintegrazione big bang è obsoleta.
  • Jacopo Romei jr@ideato.itvia Quinto Bucci 205 47023 Cesena (FC) info AT ideato.it www.ideato.it