Experience report, adozione di approcci Lean a Agile nello sviluppo software in F1

1. Sistemi Informativi Ges 1
AgileDay 2006 - Essere agili nel diventare
agili
Maranello, Dicembre 2006
Luca Minudel lminudel@ferrari.it
Nicola Canalini ncanalini@ferrari.it
Piergiorgio Grossi pgrossi@ferrari.it

2. Sistemi Informativi Ges 2
Contesto: il cliente
Le attività di sviluppo software hanno come cliente tutti i dipartimenti della
Gestione Sportiva.
Ogni dipartimento viene trattato come fosse una piccola azienda servita dai Sistemi
Ges sia dal punto di vista economico che gestionale.
In particolare sono ‘attivi’ 50 centri di costo.
Il numero di dipartimenti/azienda (50) da servire è maggiore del numero di
developer (20).
I dipartimenti hanno esigenze molto diversificate e coprono le competenze di n
business (pianificazione, lifing, telemetria, ERP, Enterprise Application
Integration, magazzini, simulazione ...).
Da qui la classificazione in 2 suite dei nostri prodotti software : TrackSuite
(afferiscono alle attività di pista) e ProductioneSuite (utili alla progettazione,
costruzione e gestione delle parti della macchina).

3. Sistemi Informativi Ges 3
Contesto: le attività e il Team
Ogni dipartimento richiede n attività suddivise in:
– nuovi progetti
– attività di change su progetti attivi (sia esso change evolutivo o change correttivo)
Il numero di progetti (~ 100) è molto maggiore del numero dei developer (20).
Il numero di richieste (~ 10 al gg) di change è comparabile con il numero dei
developer.
Il Team ha 3 location separate in contatto via intranet, telefono, instant messaging.

4. Sistemi Informativi Ges 4
Il metodo: i problemi da affrontare
La prorompente innovazione tecnologica, la esasperata necessità di time to market e
le caratteristiche di competitività e variabilità della F1 richiedono che si abbia
una forte capacità di reazione.
In un ambiente ideale, il cambiamento è identificato come il male. Lo sforzo è
concentrato sul definire ex ante le esigenze dell’utente per poter cristallizzare i
requisiti. Da quel momento in poi (momento spesso controfirmato dal cliente) il
cambiamento è visto come una turbativa per i progettisti e una cosa ‘che si
paga’ per il cliente.
Il nostro contesto è caratterizzato da
• alta velocità, grandi variabilità, grandi rischi.
• un altissimo numero di richieste e progetti fortemente integrati tra di loro
Insomma il cambiamento è la norma !

5. Sistemi Informativi Ges 5
Il metodo: gli obiettivi che vogliamo raggiungere
Noi vogliamo scrivere outstanding software e cioè software di qualità.
Questo vuol dire scrivere software:
– estendibile: e cioè aperto alle evoluzioni e modifiche qualunque esse siano
– integrato: e cioè facente parte del ‘sistema’ Ferrari
– robusto: e cioè resistente alle sollecitazioni dell’utente e all’ambiente (tipicamente non
controllato) in cui esso gira

6. Sistemi Informativi Ges 6
Standup
30 minuti ogni mattina alle 9.
Una volta alla settimana facciamo un weekly meeting che e’ uguale a quello
giornaliero e si parla dell’intera settimana:
Rispondiamo a queste domande:
• Cosa ho fatto ieri ?
• Sono in anticipo/ritardo ?
• Qual’è la data di consegna?
• Cosa farò oggi ?
• Di cosa ho bisogno ?
• Comunicazioni (info di interesse generale, assenze, etc.)
La regola e’ NO FEEDBACK, e solo domande retoriche.

7. Sistemi Informativi Ges 7
Collective Ownership (and Coding standards)
Non per tutti i progetti, solo per quelli ad alta varianza cioe’ per cui abbiamo piu’ di
due richieste di modifica al mese.
Per noi significa:
* Leggibilita’
* Pattern comune di approccio alle soluzioni
* No branch
* Standard sintattico light (e’ determinante il consenso del team, la scelta
tecnica e’ secondaria)

8. Sistemi Informativi Ges 8
Planning Game
Non abbiamo formalizzato un momento per questa pratica.
Lavorando con team virtuali che si aggregano e disgregano ad ogni iterazione su
progetti diversi il planning game e’ indispensabile all’inizio di ogni iterazione.
Per team piu’ “stabili” nel tempo c’e’ piu’ regolarita’.
Durante il planning game non riusciamo a fare design, ma spesso facciamo scelte
architetturali.
Scriviamo storie della durata di una iterazione in linguaggio utente
Cerchiamo di darci un orizzonte di 2 mesi

9. Sistemi Informativi Ges 9
Continuous Integration
Il sistema di Continuous integration e’ basato su uno strumento propietario che in automatico
ogni notte:
– build dei sorgenti
– calcolo delle metriche
– verifica dei test automatici
– setup-kit
– invio di mail e di report
Check-In
– del codice rilasciabile
– frequente
Progetti raggruppati in solution (compile-time) e in Test Suite (night-build).
Il team conosce & condivide le conseguenze della una modifica di un componente condiviso.
Small releases e stiamo sperimentando il time boxing.

10. Sistemi Informativi Ges 10
Pair Programming
1) C’era gia’
2) Piace molto al team
3) Lo facciamo poco e in particolare sulle parti critiche o quando un capita di
dover lavorare su una storia su cui si ha poca esperienza
4) Fa veramente la differenza in termini di tempo di sviluppo, la velocita’ e’ molto
alta perche’ in due si evitano gli sprechi
5) Serve alla condivisione della conoscenza
6) Quando le coppie ruotano spinge alla chiarezza del disegno
7) Permette di programmare senza Ego
8) Nel pair la diversità è un plus

11. Sistemi Informativi Ges 11
Refactoring (Incremental Design)
A parte i big refactoring che vengono pianificati …
Siamo pronti a rifattorizzare ogni volta che apriamo un sorgente.
Nella nostra esperienza ogni scelta di design, anche la piu’ piccola, necessita di
refactoring.
Stiamo affrontando il tema del refactoring della suite di test
L’utente chiede la feature, il team decide quanto e quale refactoring fare
Il codice di cui si fa il Check-In vogliamo non sia più degradato di quello che
abbiamo estratto

12. Sistemi Informativi Ges 12
Simple design
• Simple, per noi, significa anche standard
• L’alternativa e’ il fallimento certo
• Simple per noi significa anche eliminare complessità inutili e soluzioni parziali
che lasciano il problema irrisolto e casi speciali da gestire

13. Sistemi Informativi Ges 13
Miglioramento continuo
Ci chiediamo come migliorare.
E’ un progetto vero e proprio, sviluppiamo attivita’ dedicate al team di sviluppo. Da
qui nascono principalmente le idee di evoluzione della metodologia.
Il progetto e’ gestito come tutti gli altri progetti con date di scadenza e storie
assegnate ai developer.
Il team e’ il cliente di questo progetto… abbiamo il customer on site 100% ;-)
Mettiamo alla prova la capacità di auto-organizzarci
Scegliamo attentamente dove dirigere gli sforzi per avere un beneficio visibile
subito e maggiore possibile.

14. Sistemi Informativi Ges 14
Programmers Test
Abbiamo una suite di test automatici che gira ad ogni build
Tutti i software critici hanno la build notturna che lancia la suite di test. Se un test
fallisce fallisce anche la build
Monitoriamo il numero di test che scriviamo ad ogni iterazione e seguiamo il trend.
Questo perche’ l’obiettivo e’ che scrivere test e scrivere codice sfumino nella
stessa cosa.
Circa 10.000 Unit Test, 100.000 Assert, 100 nuovi test a settimana.

15. Sistemi Informativi Ges 15
Customers Test
Eseguiamo a mano una lista di SmokeTest che verificano le funzionalita’ di ogni
software prima di ogni rilascio.
Stiamo automatizzando questi smoke test.
Abbiamo alcuni test di accettazione e alcuni test funzionali che lanciamo e che
mettiamo a disposizione di altri gruppi di Sistemi Informativi che erogano
supporto ai nostri utenti.

16. Sistemi Informativi Ges 16
No overtime
Non ci capita di fare Overtime se non in periodi legati alla particolarita’ del
business.
Ci sono week end in cui a causa del Gran Premio e’ chiesta la presenza di developer
in ufficio …

17. Sistemi Informativi Ges 17
No overtime
Non ci capita di fare Overtime se non in periodi legati alla particolarita’ del
business.
Ci sono week end in cui a causa del Gran Premio e’ chiesta la presenza di developer
in ufficio o in pista!

18. Sistemi Informativi Ges 18
In che modo diventiamo Agili ... Agilmente?
• Ci facciamo guidare dal valore che consegnamo all’utente
• Senza fretta (...) e senza sosta procediamo a piccoli passi migliorativi
• Qualità: subito ci costa meno, mai ci costa troppo
– quando subito non si può, presto piuttosto che mai
– quanto è “sufficientemente buono”?
– il peso delle date di consegna, quando dopo diventa mai
• Reagiamo senza improvvisare, agiamo prima dell’ultimo momento responsabile,
lo facciamo con competenza tecnica
• Scegliamo dove intervenire per avere il massimo beneficio

19. Sistemi Informativi Ges 19
Whole Team
Non riusciamo.
Questa carenza ci crea diversi problemi:
- Qualita’
- Dobbiamo continuamente distinguere quella interna da quella esterna
- Testing
- Alcuni clienti non ne capiscono l’utilita’
- Requirements
- E’ difficile capire veramente cosa vuole l’utente
- E’ facile cadere nella trappola “so io cosa intende …”
Come può la community italiana aiutarci ad ottenerlo ?
Luca Minudel lminudel@ferrari.it
Nicola Canalini ncanalini@ferrari.it
Piergiorgio Grossi pgrossi@ferrari.it