Un po' di background sui processi agili

1. Un po' di background sui processi agili Fabio Vitali

2. Modelli di progettazione software • Totale mancanza di regole, o processi ad hoc, o hack casuali e senza regole di qualcosa mai realmente progettato. Questa è la situazione standard in molte realtà aziendali. • Tecniche heavy weight Gestione sistematica del processo attraverso l'uso di management delle attività di sviluppo, in una sequenza rigorosa e controllata di step successivi dalle interfacce chiare e dalle responsabilità ben definite. Ad esempio, Unified Process (UML) • Techniche light weight: manipolazione controllata di soluzioni già funzionanti, in evoluzione continua e senza burocrazia di nessun tipo. Ad esempio, Extreme Programming. Fabio Vitali - IUM 1999/2000

3. I processi heavy weight • Step controllati e in sequenza • Interfacce controllate e rigorose tra step diversi • Chiara suddivisione di ruoli (progettisti, implementatori e tester) • Scambio di informazioni attraverso documentazione rigorosa, estesa, controllata. • Grande enfasi sulla documentazione di progetto • Gestione del progetto controllata e predicibile. Fabio Vitali - IUM 1999/2000

4. I processi light weight • Soluzione people-oriented piuttosto che process-oriented. • Enfasi su flessibilità e adattabilità piuttosto che su descrizioni sistematiche e rigorose. • Processi per piccoli passi (evoluzioni successive) da un sistema funzionante ad un sistema funzionante • Voluta commistione di fasi tra design, implementazione e testing. • Team di programmatori snello, con pieno potere sul codice, si occupano della progettazione, dell'implementazione e del testing tutti insieme • XP: Team di due persone davanti ad UNA tastiera: uno programma, l'altro suggerisce, critica, sta attento agli errori, pensa. Fabio Vitali - IUM 1999/2000

5. Ancora sui processi light-weight • Cicli di rilascio molto corti (settimane o giorni) • Implementazioni minimali senza abbellimenti • Nessuno spreco di tempo per analisi e design, si inizia subito a programmare (analisi e design li si fanno per strada) • Descrizione dei problemi in termini di piccoli pezzi distinti implementati in iterazioni successive • Sviluppo di sistemi affidabili iniziando dal piccolo e procedendo per incrementi piccoli. • Stretta comunicazione tra implementatori e clienti • Test continuo e sistematico del risultato prodotto Fabio Vitali - IUM 1999/2000

6. Vantaggi dei sistemi light-weight • Poca zavorra, poca tara: tutto il tempo di lavoro è dedicato alla realizzazione della soluzione (uso sistematico di lavagne, post-it e cartoncini invece che voluminosi documenti di design) • Risultati immediati: qualcosa di funzionante lo si vede fin dall'inizio del lavoro). Ogni iterazione produce un sistema funzionante. • Ottima qualità del codice: riduzione radicale di bug di prima generazione e di ritorno • Sorprendentemente di successo: le storie dell'orrore su XP sono di gran lunga minori di quelle di altri sistemi più pesanti. Fabio Vitali - IUM 1999/2000

7. Svantaggi dei sistemi light-weight • Tutt'altro che nuovi (già negli anni sessanta esisteva la metodologia chiamata chief programmer team, usata con successo prima, e poi abbandonata, da IBM) • Dipende fortemente dall'abilità del team (richiede buoni programmatori) e dalla capacità dei manager di entusiasmarli • Non può scalare all'infinito come dimensioni di team (UP ha gestito progetti di centinaia di programmatori, XP si ferma a 12-15) • … e dunque neanche come dimensioni del progetto (UP: decine di milioni di righe di codice, XP: centomila, massimo duecentomila righe). • Non tutti gli sviluppi possono essere soddisfacentemente divisi in blocchi di release da 15-30 giorni. Fabio Vitali - IUM 1999/2000

8. Infine • Processi light-weight (o agili) sono molti, diversi e variegati • Hanno pregi in comune: poca burocrazia, velocità, interesse al risultato funzionante e solido • Hanno difetti: non è scalabile, richiede ottimi programmatori ben disciplinati e motivati, non è usabile in tutti i progetti. • Infine: non esistono metodi light-weight che si occupano della realizzazione di sistemi usabili. Le interfacce sono aspetti completamente ignorati in tutti i metodi light.weight. Fabio Vitali - IUM 1999/2000

9. Conclusioni del corso

10. Il corso • Non è fatto per imparare a pappagallo concetti o tecniche, ma per avere una visibilità sui problemi e le soluzioni cercate. • Non siete pronti per gestire un progetto di usabilità (manca la conoscenza dettagliata e l'uso sistematico delle tecniche viste), ma sapete della loro esistenza. • Sperabilmente, un giorno che vi doveste trovare nella situazione di organizzare la progettazione dell'interazione di un sistema, andrete a rileggervi (con diversa attenzione) questi testi e li userete in maniera appropriata e non affrettata. Fabio Vitali - IUM 1999/2000

11. Le mie valutazioni • Io sono soddisfatto della vostra partecipazione al corso, sia nelle lezioni, sia nei progetti. • Ovviamente, ho opinioni diverse su ciascuno di voi, che si rifletteranno nei voti. • Ma saranno tutti alti (≥ 27). • Ci vediamo il 15 gennaio 2003 alle ore 14:30 qui per la registrazione dei voti. • Un voto in meno a chi arriva senza statino. Fabio Vitali - IUM 1999/2000