Lean anche io! No tu no! - Italian Agile Days 2013

3,455 views

Published on

Slide presentate a Italian Agile Day(s) 2013 di Reggio Emilia:
Lean anche io!
No tu no!

Sessione incentrata sulla condivisione dell'esperienza di transizione verso un modello Lean in progetti reali di consulenza per grandi aziende dove spesso molte delle pratiche e delle metodologie proposte in ambito agile sono difficilmente applicabili. L’obiettivo è mostrare i successi ottenuti (sia per il team di sviluppo che per gli utenti), condividere i nostri fallimenti, i problemi incontrati e le sfide aperte per offrire un punto di vista su come può essere affrontata la transizione ad un modello agile in contesto di relazione grande cliente-fornitore.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,455
On SlideShare
0
From Embeds
0
Number of Embeds
2,573
Actions
Shares
0
Downloads
10
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Lean anche io! No tu no! - Italian Agile Days 2013

  1. 1. Lean anche io! No tu no! #IAD13 @andreascavolini @SimoneVannicola
  2. 2. Agenda      Il contesto: grande cliente - fornitore – il fornitore – i grandi clienti La storia delle nostre esperienze – gli albori: la curiosità – gli esperimenti con i primi clienti: l'entusiasmo – i primi fallimenti: la delusione – i primi successi: la speranza Un caso cliente Dove siamo oggi I trade-off – Progetti a pacchetto vs agilità – Release Planning vs Gantt – Story Point vs Man-Days – Big Design Up Front vs Incremental Design – Ritmo vs disponibilità degli utenti
  3. 3. Il contesto: grandi clienti - fornitore
  4. 4. Fornitore: ICONSULTING (1/2) THE EXPERT MOOD WHO WE ARE ICONSULTING IS AN INDEPENDENT CONSULTING COMPANY SPECIALIZED IN DWH,BI & PM Research in our DNA: Iconsulting was born from a spin-off of a prestigious Research University Consortium group focused on Data Warehouse & Business Intelligence with the mission of delivering best in class BI & PM projects Strong expertise on all the market leading technologies 25% of our time invested in R&D Over 300 projects delivered to more than 100 customers Professorship in prestigious Italian Universities and Business Schools In-house Knowledge Factory School providing education services to professionals who need to develop their skills 1 2 INNOVATIVE SPECIALIZED 3 VENDOR INDEPENDENT 4 DEVELOPING SKILLS
  5. 5. Fornitore: ICONSULTING (2/2) R&D: OUR DNA WE BRING INNOVATION TO YOU WHAT WE DO
  6. 6. Grandi clienti MANUFACTURING Our CUSTOMERS FASHION CALZEDONIA DIESEL GEOX IMAX LOTTO MILAR FINANCIAL SERVICES CREDIT SUISSE DEXIA CREDIOP EUROGROUP FGA CAPITAL (GRUPPO FIAT) INA ASSITALIA UNIPOL BANCA FOOD BARILLA BIRRA PERONI ERIDANIA SADAM GRANDI SALUMIFICI ITALIANI MASSIMO ZANETTI BEVERAGE GROUP MONTENEGRO SALUMIFICIO FRATELLI BERETTA SEGAFREDO LARGE SCALE RETAIL CONAD ADRIATICO COOP ITALIA LA RINASCENTE SMA (SIMPLY MARKET) VIP CATERING MEDIA & PUBLISHING ALFA WASSERMANN AMPLIFON ARISTON THERMO CAMAR SMA CANTIERI SANLORENZO CASE NEW HOLLAND DUCATI MOTOR HOLDING FEDRIGONI FONTANOT G.D GGP ITALY CISA (Ingersoll-Rand) GRUPPO COESIA GRUPPO FABBRI ICF - LA FAENZA IGUZZINI I.M.A. INDUSTRIA MACCHINE AUTOMATICHE INTERTABA - PHILIP MORRIS KME KOMATSU UTILITY EUROPE LOWARA MAGNETI MARELLI MALAVOLTA CORPORATE MARAZZI MARPOSS NEGRI BOSSI OTIS OVA BARGELLINI PHILIP MORRIS ITALIA PM GROUP POZZI GINORI ROSETTI MARINO SACMI SECI SONY EUROPA TEUCO GUZZINI UNO A ERRE GRUPPO INDUSTRIALE L’ESPRESSO FOX INTERNATIONAL CHANNEL PANINI GROUP SKY ITALIA VODAFONE ZANICHELLI EDITORE GOVERNMENT & PUBLIC SECTOR ARCEA AGREA ARPA ARPAT AVEPA CESIA COMUNE DI BOLOGNA COMUNE DI REGGIO EMILIA ERVET INVITALIA I.S.P.R.A. AMBIENTE ISTITUTO NAZIONALE FISICA NUCLEARE LEPIDA MINISTERO DELL’INTERNO MINISTERO DEL LAVORO E DELLE POLITICHE SOCIALI PROV. AUTONOMA DI BOLZANO PROV. AUTONOMA DI TRENTO PROVINCIA DI RIMINI REGIONE EMILIA ROMAGNA UNIVERSITA’ DI BOLOGNA SERVICES CRIF DAY RISTOSERVICE ENI GRUPPO SOCIETA’ GAS RIMINI MANUTENCOOP FACILITY MANAGEMENT MOBY RINA SIENAMBIENTE SISAL
  7. 7. Le nostre prime esperienze…
  8. 8. Come tutto ebbe inizio… Cliente Caffè Cliente Media Ilias inizia a parlare di metodologie Agili Partenza di Ilias ID Funzionalità 0801 0502 1005 0600 1015 0124 Snow Flake indicatori Coffee Shop Calcolo del numero di coffee shop Universo in Business Object XI Controllo errori cambio valuta Dashboard Coffee Shop Documentazione: VAR - Trader Stato Stima Release 100% 100% 100% 100% 70% 20% 1Release1 1Release1 2Release2 1Release2 16Release2 3Release2
  9. 9. Caso cliente
  10. 10. Il contesto Progettuale  Key User: Controllo di gestione e Amministrazione  3 diverse sorgenti informative: sistemi gestionali  Doppia anima del progetto:  Nostro Progetto: Motore di calcolo, reporting, budgeting, simulazioni  Progetto Parallelo: Contabilizzazione e gestione fatture  Forti aspettative dal Top Management
  11. 11. Il giorno prima del kick-off Verifichiamo il gantt? Ehm… il gantt? Ecco il Release Plan Sì il piano… Release 1 Ma questo non è un gantt! Ma è la stessa cosa! Releas e1 Ehm… aspetta… Allora? Release 2 Releas e2 Releas e3 Releas e4 Releas e5 Release 3 Release 4 Release 5 Ok… ci lavoriamo!
  12. 12. Il kick-off: gantt-ification Release 1 Release 2 Release 3 Ottobre Release 4 Release 5 Dicembre Release 6 Release 7 Release 8 Febbraio Release 9 Release 10 Aprile Giugno Il nostro piano Budget e Rolling Chiusure Amm Reporting CdG e Amm Simulazione Recupero Storico 1°Rilascio Esercizio Budget Rilascio finale Parallelo Business Blue Print Il progetto parallelo Approvazione BBP Titoli e Contratti Verifica Fatture e Workflow Ammortamenti Fissi e Variabili Chiusure e Reportistica Recupero Storico UAT e Integration Test
  13. 13. Proponiamo al cliente continui rilasci incrementali
  14. 14. La prima release…
  15. 15. La seconda release…
  16. 16. La sprint demo mostra i risultati e rende felice il cliente
  17. 17. Il cliente era contento… …ma eravamo esausti!
  18. 18. Alla prima retrospettiva decidiamo di rialzarci Cosa è andato bene? Cosa è andato male? Cosa abbiamo imparato? Cosa possiamo fare meglio?
  19. 19. Capiamo che occorre fare ordine
  20. 20. Creiamo uno Sprint Backlog EDGN Perc Attività completata 1 4 100% - 2 0,5 1,5 100% - Calcolo Ammortamento Run 9 2 7 100% - Calcolo Cash Cost 7 2 4 100% - Maschera titolo: Inserire la lookup su Investiment Obligation 1 1 100% - Maschera verifica ammortamento in valuta 2 100% - SF: reporting; Chiusura Amm 6 Specifiche di Interfaccia HYP<->SAP 2 Produzione estrazione contabilizzazioni SAP 1 1 100% Automatizzazione estrazione Hyp->SAP 2 2 0% 2 Inserire Il Trim nel'XLST del client 1 1 0% 1 1,5 1 0% 1,5 Funzionalità Stima (g) SIVA Maschera Inserimento Titoli 5 Maschera Curve Run 24 mese Rilascio in collaudo dei nuovi sviluppi e bugfix GAGA 2 2 Giornate mancanti 4 60% 2,4 2 50% 1 0,5 -
  21. 21. Sapevamo cosa fare ma non se ce l’avremmo fatta …e finiviamo sempre con l’acqua alla gola
  22. 22. Quindi introduciamo il Burndown Chart Burndown Chart Rappresentazione grafica del lavoro rimasto rispetto al tempo. Nell’asse X è rappresentato il tempo, nell’asse Y il lavoro (giornate/uomo). Si aggiorna automaticamente in funzione delle percentuali di avanzamento aggiornate quotidianamente nello sprint backlog. 45 40 35 30 25 Eff 20 Est 15 10 5 21-dic 20-dic 19-dic 18-dic 17-dic 16-dic 15-dic 14-dic 13-dic 12-dic 11-dic 10-dic 09-dic 08-dic 07-dic 06-dic 05-dic 04-dic 03-dic 02-dic 01-dic 30-nov 29-nov 28-nov 27-nov 26-nov 25-nov 24-nov 23-nov 0
  23. 23. Alla fine il nostro processo era così Sprint incrementali della durata di circa tre settimane ciascuno. Sprint BackLog Calcolo Ammortamento Run Maschera Input Rendicontazione Rilascio SAL settimanale 23-nov Sprint Planning Meeting Calcolo Passaggi Run Stimati Excel con Ammortamento Run UAT 21-dic Verificare Ammortamento Lineare su Hiatus fuori dal range di validità 50 40 30 20 SAL settimanale 10 0 14-dic Import dati IBMS 07-dic Logica Actual/Actual Revised 30-nov Cash Cost Minumum Garantee Burndown chart Retrospettiva Approvazione utente specifica funzionale iterazione n+1 Sviluppo Analisi funzionalità iterazione n+1 Week 0 - Inizio Iterazione n Week 1 Week 2 Week 3 – Fine iterazione n
  24. 24. Sprint 6 10 5 0 45 40 35 30 25 20 Eff 15 Est 25-gen 0 23-gen 5 20 Est 21-gen 10 19-gen 15 Eff 17-gen 20 15-gen 25 13-gen 30 11-gen 35 09-gen 40 40 07-gen 45 05-gen Sprint 3 03-gen 21-dic 19-dic 17-dic 15-dic 13-dic 11-dic 09-dic 07-dic 05-dic 03-dic 01-dic 29-nov 27-nov 25-nov 23-nov Burndown Chart di tre diversi Sprint Sprint 4 35 30 25 15 Eff 10 Est 5 0
  25. 25. BE-LEAN
  26. 26. BE-LEAN Framework
  27. 27. Metodologia Pianificazione  Piano dei deliverables  Misurazione delle velocità  Piccole e frequenti release (mensili)  Coinvolgimento del cliente Design  Simple Design Sviluppo  Definire gli standard  DONE Definition Organizzazione  Scrum Team (self organizing)  Sit Together Testing Controllo  critica periodica, revisione della metodologia  Miglioramento continuo  Test Driven Development
  28. 28. Pratiche Pianificazione  User stories (funzionalità)  Backlog  Planning poker Design  Spike Solutions  Set-Based Design Sviluppo Organizzazione     Stand-up meeting Sprint demo Utilizzo della carta nei dettagli Wall-based Taskboard  Tecnica del pomodoro  Pair programming  Refactoring Testing Controllo  Burn-down chart  Retrospective  Unit Test First
  29. 29. Le chiavi di successo  Persone e interazioni:  Qualità rapporti vis-a-vis  Funzionalità (no attività) come cuore dei progetti  Motivazione delle persone  Semplificazione, auto-organizzazione, ritmo nella gestione  Flessibilità  Riduzione dell’uso della tecnologia nei dettagli  Risk Management  Frequenti release, feedback continuo  Miglioramento  Coinvolgimento del cliente continuo
  30. 30. Dove siamo oggi? Cliente Media Arriva PierG: un boost alla diffusione delle metodologie agili in azienda Altri Clienti… Crescita e diffusione in azienda. Sviluppo di strumenti di gestione e controllo dei progetti che agevolino un approccio agile. Ci accorgiamo che abbiam lavorato tantissimo sul processo (Scrum style) e sulla cultura (Lean style) ma troppo poco sull’automatizzazione (XP style) Tanti tavoli di ricerca e innovazione avviati: • Automatizzazione degli sviluppi • Automatizzazione del deploy • Suite di testing
  31. 31. I Trade-off
  32. 32. Intro  Causa problemi logistici con la sala, non ci è stato possibile condividere alcuni concetti durante la sessione.  Condividiamo nelle slide che seguono alcune parti più discorsive in modo da condividere comunque in maniera rapida e semplice alcuni concetti.  Se siete interessati ad approfondimenti contattateci:  Twitter:  @andreascavolini  @SimoneVannicola  Oppure ci trovate su LinkedIn
  33. 33. Progetti a pacchetto Vs Agilità  Progetto a pacchetto: budget predefinito su un perimetro non modificabile  In un modello waterfall la «sotenibilità» del progetto deriva da una chiara definizione dei requisiti e del perimetro progettuale  Nella realtà, nel corso del progetto, scope e requisiti cambiano anche significativamente.  Molto spesso ci troviamo di fronte a proposte «agiliste» che spingono per riportare alla ribalta i progetti «time and material». Tale proposta non è accettata dalla maggior parte delle grandi aziende.  La nostra esperienza ci porta a dire che è più semplice lavorare su progetti a pacchetto con una metodologia agile che waterfall! E quindi why not?  Occorre solo avere l’accortezza di definire alcune regole del gioco con i clienti come:  Si deve sensibilizzare il cliente sul fatto che un UAT chiude il ciclo di sviluppo delle funzionalità validate. Occorre mostrare flessibilità sì, ma soprattutto sul futuro e non infiniti ricicli su quanto già realizzato.  È importante tenere fermo lo scope della sprint in corso e posticipare gli sviluppi delle richieste spot dell’utente nelle sprint successive, in quanto distraggono il team, creano stress e generano bug.
  34. 34. Release Planning vs Gantt  I vantaggi di utilizzare un gantt per il controllo del progetto sono: ̵ Intuitiva visione dell’insieme ̵ Se la sequenza e il piano vengono rispettati è “facile” individuare ritardi e ripianificare il piano “slittandolo”  I limiti di utilizzare un gantt sono: ̵ Il piano è una rappresentazione rigida della realtà e non è possibile seguirlo passo passo. ̵ Ogni task tenderà ad essere iniziato all’ultimo (aumento dei rischi) e ad essere finito alla data prestabilita perfino quando si è in anticipo (aumento dei costi). ̵ Si utilizza una struttura per attività (Work Breakdown Structure) che non rispecchia il valore per il cliente di ogni funzionalità (Feature Breakdown Structure) ̵ Molto spesso le dipendenze individuate non sono reali! Occorre cercare di rompere tutte le dipendenze ogni volta che è possibile!  Approccio Lean: ̵ Utilizza un gantt di alto livello allo scopo di definire delle milestones interne ed essere comunicativi con il cliente. ̵ Gestisci il progetto utilizzando un backlog e strumenti come burndown chart
  35. 35. Story Point vs Man-Days  Multiple team membership! Team formati con risorse non completamente dedicate su un singolo progetto.  Non riusciamo ad avere una misura oggettiva della velocità ossia degli Story Point rilasciabili in ogni singola iterazione  Stima di ciascuna funzionalità per Man Days  Si effettua una stima della velocità e delle giornate «nette» che il team può dedicare al progetto.  Planning Poker e valutazione della stima in funzione della complessità di ogni singola funzionalità e non in base a «io quanto ci metterei»  Molti feedback derivanti dalle metriche che riusciamo a derivare tramite Timesheet integrato: Release Gg Gg % Budget Stima Compl. Stima Gg a Finire Gg Utili Budget Valore Efficienza Rilasciato Release1 64 64 100% 84 0 6.400 6.400 -2000 Release2 58 50 100% 56 0 5.800 5.800 200 Release3 74 73 100% 72 0 7.400 7.400 200 Release4 79 64 100% 74 0 7.900 7.900 500 Release5 59 46 74% 48 12 5.900 4.361 -439
  36. 36. Big Design Up Front vs Incremental Design  In generale nei progetti complessi per grandi clienti viene richiesto di definire un design a priori  Nel nostro caso lavoriamo anche su architetture applicative a cascata fortemente interdipendenti  La tentazione è di effettuare un Big Design Up Front (BDUF)  Lavorando su architetture a flusso siamo comunque costretti dare un design della macro soluzione. Tale attività viene fatta anche con una macro-analisi effettuata con gli utenti con lo scopo di coprire il livello giusto di design o Just Enough Design Up Front (JEDUF)  Man mano che il progetto procede viene effettuata l’analisi dell’iterazione successiva e viene incrementalmente evoluto il design della soluzione.
  37. 37. Ritmo Vs disponibilità degli utenti  In un contesto ideale l’utente è parte del team e fornisce i requirement «just in time»  In contesti meno ideali il Product Owner sopperisce a eventuali assenze degli utenti  In contesti paradossali il Demand scrive un documento e lo passa al team.  In ogni caso, release frequenti necessitano frequenti incontri con gli utenti per l’analisi delle funzionalità da realizzare e gli User Acceptance Test (UAT) sulle funzionalità rilasciate.  Nelle grandi aziende la disponibilità degli utenti è un fattore critico.  Nella nostra esperienza il miglior metodo è stato bilanciare il just in time con un anticipo delle specifiche in modo di avere un cuscinetto di funzionalità già analizzate (almeno sufficiente alla successiva release o superiore prima di periodi che vedono gli utenti impegnati in altre attività).  Per quanto riguarda i rilasci in produzione, il team deve cercare di lavorare mantenendo iterazioni a ritmo costante senza necessariamente rilasciare in produzione ogni release. Quando gli utenti tornano disponibili si svolge UAT sulle funzionalità di più iterazioni e si rilascia in esercizio.
  38. 38. Essere agili non è il fine ma il mezzo per il miglioramento continuo

×