Lean anche io!
No tu no!
#IAD13@andreascavolini
@SimoneVannicola
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
Agenda
Il contesto: grandi clienti - fornitore
ICONSULTING IS AN INDEPENDENT CONSULTINGCOMPANY SPECIALIZED IN DWH,BI & PM
Strong expertise on all the market leading technologies
WHO
WE ARE
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
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
25% of our time invested in R&D
SPECIALIZEDDEVELOPING
SKILLSVENDOR
INDEPENDENT
2 3 41
THE EXPERT MOOD
INNOVATIVE
Fornitore: ICONSULTING (1/2)
R&D: OUR DNAWE BRING INNOVATION TO YOU
WHAT
WE DO
Fornitore: ICONSULTING (2/2)
Our
CUSTOMERS
MANUFACTURINGALFA WASSERMANNAMPLIFONARISTON THERMOCAMAR SMACANTIERI SANLORENZOCASE NEW HOLLANDDUCATI MOTOR HOLDINGFEDRIGONIFONTANOTG.DGGP ITALYCISA (Ingersoll-Rand) GRUPPO COESIAGRUPPO FABBRIICF - LA FAENZAIGUZZINII.M.A. INDUSTRIA MACCHINE AUTOMATICHE INTERTABA - PHILIP MORRISKME KOMATSU UTILITY EUROPELOWARAMAGNETI MARELLIMALAVOLTA CORPORATEMARAZZIMARPOSSNEGRI BOSSIOTISOVA BARGELLINIPHILIP MORRIS ITALIAPM GROUPPOZZI GINORIROSETTI MARINOSACMISECISONY EUROPATEUCO GUZZINI UNO A ERRE
MEDIA & PUBLISHINGGRUPPO INDUSTRIALE L’ESPRESSOFOX INTERNATIONAL CHANNELPANINI GROUPSKY ITALIAVODAFONEZANICHELLI EDITORE
GOVERNMENT & PUBLIC SECTORARCEAAGREA ARPA ARPATAVEPACESIACOMUNE DI BOLOGNA COMUNE DI REGGIO EMILIAERVETINVITALIAI.S.P.R.A. AMBIENTEISTITUTO NAZIONALE FISICA NUCLEARELEPIDAMINISTERO DELL’INTERNOMINISTERO DEL LAVORO E DELLE POLITICHE
SOCIALIPROV. AUTONOMA DI BOLZANOPROV. AUTONOMA DI TRENTOPROVINCIA DI RIMINIREGIONE EMILIA ROMAGNA UNIVERSITA’ DI BOLOGNA
SERVICESCRIFDAY RISTOSERVICEENIGRUPPO SOCIETA’ GAS RIMINIMANUTENCOOP FACILITY MANAGEMENTMOBYRINASIENAMBIENTESISAL
FASHIONCALZEDONIADIESELGEOXIMAXLOTTOMILAR
FINANCIAL SERVICESCREDIT SUISSEDEXIA CREDIOPEUROGROUPFGA CAPITAL (GRUPPO FIAT)INA ASSITALIAUNIPOL BANCA
FOODBARILLABIRRA PERONIERIDANIA SADAMGRANDI SALUMIFICI ITALIANIMASSIMO ZANETTI BEVERAGE GROUPMONTENEGROSALUMIFICIO FRATELLI BERETTASEGAFREDO
LARGE SCALE RETAILCONAD ADRIATICOCOOP ITALIALA RINASCENTESMA (SIMPLY MARKET)VIP CATERING
Grandi clienti
Le nostre prime esperienze…
ClienteMedia
Come tutto ebbe inizio…
ID Funzionalità Stato Stima Release
0801 Snow Flake indicatori Coffee Shop 100% 1Release1
0502 Calcolo del numero di coffee shop 100% 1Release1
1005 Universo in Business Object XI 100% 2Release2
0600 Controllo errori cambio valuta 100% 1Release2
1015 Dashboard Coffee Shop 70% 16Release2
0124 Documentazione: VAR - Trader 20% 3Release2
Partenzadi Ilias
Ilias inizia a parlare di
metodologie Agili
Cliente Caffè
Caso cliente
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
Il giorno prima del kick-off
Release 1
Release 2
Release 3
Release 4
Release 5
Verifichiamo il gantt? Ehm… il gantt? Sì il piano…
Ma questo non è un gantt!
Release 1
Release 2
Release 3
Release 4
Release 5
Ehm… aspetta…Allora?
Ma è la stessa cosa!
Ok… ci lavoriamo!
Ecco il Release Plan
Il kick-off: gantt-ification
Il progetto parallelo
Il nostro piano
Dicembre Febbraio Aprile GiugnoOttobre
Budget e Rolling
Business Blue Print
Recupero Storico
Budget
1°Rilascio Esercizio
Chiusure Amm
Simulazione
Reporting CdG e Amm
Titoli e Contratti
Verifica Fatture e Workflow
Chiusure e Reportistica
Ammortamenti Fissi e Variabili
Recupero Storico
Approvazione BBP
UAT e
Integration Test
Rilascio
finale
Parallelo
Release 1
Release 2
Release 3
Release 4
Release 5
Release 6
Release 7
Release 8
Release 9
Release 10
Proponiamo al cliente continui rilasci incrementali
La prima release…
La seconda release…
La sprint demo mostra i risultati e rende felice il cliente
Il cliente era contento…
…ma eravamo esausti!
Alla prima retrospettiva decidiamo di rialzarci
Cosa è andato bene?Cosa è andato male?Cosa abbiamo imparato?Cosa possiamo fare meglio?
Capiamo che occorre fare ordine
Creiamo uno Sprint Backlog
Funzionalità Stima (g) SIVA GAGA EDGNPerc Attività completata
Giornate mancanti
Maschera Inserimento Titoli 5 1 4 100% -
Maschera Curve Run 24 mese 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 2 100% -
SF: reporting; Chiusura Amm 6 2 4 60% 2,4
Specifiche di Interfaccia HYP<->SAP 2 2 50% 1
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
Rilascio in collaudo dei nuovi sviluppi e bugfix 1,5 1 0,5 0% 1,5
Sapevamo cosa fare ma non se ce l’avremmo fatta
…e finiviamo sempre con l’acqua alla gola
0
5
10
15
20
25
30
35
40
45
23-n
ov
24-n
ov
25-n
ov
26-n
ov
27-n
ov
28-n
ov
29-n
ov
30-n
ov
01-d
ic
02-d
ic
03-d
ic
04-d
ic
05-d
ic
06-d
ic
07-d
ic
08-d
ic
09-d
ic
10-d
ic
11-d
ic
12-d
ic
13-d
ic
14-d
ic
15-d
ic
16-d
ic
17-d
ic
18-d
ic
19-d
ic
20-d
ic
21-d
ic
Eff
Est
Quindi introduciamo il Burndown Chart
Burndown ChartRappresentazione 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.
Week 0 - Inizio Iterazione n
Cash Cost Minumum Garantee
Logica Actual/Actual Revised
Import dati IBMS
Verificare Ammortamento Lineare su Hiatus fuori dal range di validità
Calcolo Passaggi Run Stimati
Calcolo Ammortamento Run
Maschera Input Rendicontazione
Excel con Ammortamento Run
Sprint Planning Meeting
Week 1 Week 2 Week 3 – Fine iterazione n
Sprint BackLog
Sviluppo
Analisi funzionalità iterazione n+1
SAL settimanaleUAT
Rilascio
01020304050
23-n
ov
30-n
ov
07-d
ic
14-d
ic
21-d
ic
SAL settimanale
Burndown chart
Approvazione utente specifica funzionale iterazione n+1
Retrospettiva
Alla fine il nostro processo era così
Sprint incrementali della durata di circa tre settimane ciascuno.
0
5
10
15
20
25
30
35
40
03-g
en
05-g
en
07-g
en
09-g
en
11-g
en
13-g
en
15-g
en
17-g
en
19-g
en
21-g
en
23-g
en
25-g
en
Eff
Est
Sprint 4
0
5
10
15
20
25
30
35
40
45
23-n
ov
25-n
ov
27-n
ov
29-n
ov
01-d
ic
03-d
ic
05-d
ic
07-d
ic
09-d
ic
11-d
ic
13-d
ic
15-d
ic
17-d
ic
19-d
ic
21-d
ic
Eff
Est
Sprint 3
0
5
10
15
20
25
30
35
40
45
Eff
Est
Sprint 6
Burndown Chart di tre diversi Sprint
BE-LEAN
BE-LEAN Framework
Metodologia
Design Simple Design
Pianificazione Piano dei deliverables
Misurazione delle velocità
Piccole e frequenti
release (mensili)
Coinvolgimento del cliente Sviluppo Definire gli standard
DONE Definition
Testing Test Driven Development
Organizzazione Scrum Team (self organizing)
Sit Together
Controllo critica periodica, revisione
della metodologia
Miglioramento continuo
Pratiche
Design Spike Solutions
Set-Based Design
Pianificazione User stories (funzionalità)
Backlog
Planning poker
Sviluppo Tecnica del pomodoro
Pair programming
Refactoring
Testing Unit Test First
Organizzazione Stand-up meeting
Sprint demo
Utilizzo della carta nei dettagli
Wall-based Taskboard
Controllo Burn-down chart
Retrospective
Le chiavi di successo
Persone e interazioni:
rapporti vis-a-vis
Funzionalità (no attività)
come cuore dei progetti
Semplificazione,
auto-organizzazione,
ritmo nella gestione
Riduzione dell’uso della
tecnologia nei dettagli
Frequenti release,
feedback continuo
Coinvolgimento del cliente
Qualità
Motivazione
delle persone
Flessibilità
Risk Management
Miglioramento
continuo
Dove siamo oggi?
ClienteMedia
Ci accorgiamo che abbiam lavorato tantissimo sul
processo (Scrum style) e sulla cultura (Lean style) ma
troppo poco sull’automatizzazione (XP
style)
Arriva PierG: un boostalla diffusione delle metodologie agili in
azienda
Tanti tavoli di ricerca e innovazione avviati:• Automatizzazione
degli sviluppi• Automatizzazione del
deploy• Suite di testing
Crescita e diffusione in azienda. Sviluppo di
strumenti di gestione e controllo dei progetti
che agevolino un approccio agile.
Altri Clienti…
I Trade-off
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
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.
Progetti a pacchetto Vs Agilità
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.
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
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:
ReleaseGg
Budget
Gg
Stima
%
Compl.Gg Utili
Stima
Gg a
Finire
BudgetValore
RilasciatoEfficienza
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
Release6 53 53 0% 53 5.300 - -
Totale 387 350 82% 334 65 38.700 31.861 -1539
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.
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.
Ritmo Vs disponibilità degli utenti
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.
Essere agili non è il fine ma il mezzo per il miglioramento continuo
Top Related