I 4 punti cardinali bla bla bla. Jacopo Romei

Transcript

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

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 :-) :-)

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 ipotesiesperimento-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 via Quinto Bucci Cesena (FC) info AT ideato.it