I quattro punti cardinali per un orientamento lean nell'impr... insomma.
63
I 4 punti cardinali bla bla bla Jacopo Romei
-
Upload
jacopo-romei -
Category
Business
-
view
1.921 -
download
0
description
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.
Transcript of I quattro punti cardinali per un orientamento lean nell'impr... insomma.
I 4 punti cardinali bla bla bla
Jacopo 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
Chi sono i nostri clienti?
What's in a name?
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
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
0
2
4
6
8
10
12
14
16
18
20
:-)
:-(
:-) :-)
:-(
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 di
prodotti software derivano da questa essenziale complessità e dalla sua crescita non lineare”
Fred BrooksNo silver bullet
Lo sappiamo e nonostante ciò...
I nostro software contengono tonnellate di funzionalità che rimangono inutilizzate.
La nostra più grande opportunità: smetterla di aggiungere funzionalità non strettamente
necessarie.
Complessità I
Non negoziamo mai lo scope.
Costi, scadenze, scope: negoziare quest'ultimo dovrebbe essere routine.
Complessità II
Usiamo metriche quantitative, un tanto al chilo.
Function points et similia forniscono interessanti dati relativi.
Complessità III
Abbiamo fretta di aggiungere funzionalità.
No al 'non si sa mai'. Sì al 'chissà se davvero poi'.
Complessità IV
Automatizziamo processi complessi.
Prima semplificare, poi automatizzare.
Complessità V
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.
Lo sappiamo e nonostante ciò...
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.
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'.
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.
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.
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 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.
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.
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 IV
Parliamo di 'business' come di una cosa separata dall'IT.
Il business IT è l'IT.
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.
L'industria ford-taylorista e l'industria lean hanno in comune la convinzione che le decisioni debbano
basarsi sui dati più che sulle decisioni.
Lo sappiamo e nonostante ciò...
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.
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.
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.
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?
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 un investimento altrimenti impossibile. Raggiungere un 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 è d'obbligo. Per definizione!
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.
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 V
Tardiamo ad integrare il nostro codice con quello di altri sviluppatori e quello in altri branch.
L'integrazione big bang è obsoleta.
