AgileDay 2006 - Essere agili nel diventare agili

19
Sistemi Informativi Ges 1 AgileDay 2006 - Essere agili nel diventare agili Maranello, Dicembre 2006 Luca Minudel [email protected] Nicola Canalini [email protected] Piergiorgio Grossi [email protected]

description

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

Transcript of AgileDay 2006 - Essere agili nel diventare agili

Page 1: AgileDay 2006 - Essere agili nel diventare agili

Sistemi Informativi Ges 1

AgileDay 2006 - Essere agili nel diventare agili

Maranello, Dicembre 2006

Luca Minudel [email protected] Canalini [email protected]

Piergiorgio Grossi [email protected]

Page 2: AgileDay 2006 - Essere agili nel diventare agili

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

Page 3: AgileDay 2006 - Essere agili nel diventare agili

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.

Page 4: AgileDay 2006 - Essere agili nel diventare agili

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 loroInsomma il cambiamento è la norma !

Page 5: AgileDay 2006 - Essere agili nel diventare agili

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

Page 6: AgileDay 2006 - Essere agili nel diventare agili

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.

Page 7: AgileDay 2006 - Essere agili nel diventare agili

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)

Page 8: AgileDay 2006 - Essere agili nel diventare agili

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

Page 9: AgileDay 2006 - Essere agili nel diventare agili

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.

Page 10: AgileDay 2006 - Essere agili nel diventare agili

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

Page 11: AgileDay 2006 - Essere agili nel diventare agili

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

Page 12: AgileDay 2006 - Essere agili nel diventare agili

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

Page 13: AgileDay 2006 - Essere agili nel diventare agili

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.

Page 14: AgileDay 2006 - Essere agili nel diventare agili

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.

Page 15: AgileDay 2006 - Essere agili nel diventare agili

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.

Page 16: AgileDay 2006 - Essere agili nel diventare agili

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 …

Page 17: AgileDay 2006 - Essere agili nel diventare agili

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!

Page 18: AgileDay 2006 - Essere agili nel diventare agili

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

Page 19: AgileDay 2006 - Essere agili nel diventare agili

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 [email protected] Nicola Canalini [email protected]

Piergiorgio Grossi [email protected]