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