Programmazione Agile: i miei appunti del corso tenutosi all’Ordine degli Ingegneri di Napoli – Prima Parte.

Warning: Use of undefined constant wp_hl_message_license_content - assumed 'wp_hl_message_license_content' (this will throw an Error in a future version of PHP) in D:\inetpub\webs\inambienteit\wp-content\plugins\wp-hl-message\wp-hl-message.php on line 43

Amici di InAmbienTe, continuo questa mia divulgazione didattica condividendo con voi i miei appunti del corso di “Programmazione Agile” tenutosi il 1 e 2 Luglio 2015 presso la sede dell’Ordine degli Ingegneri di Napoli. Un interessante corso che sviluppa praticamente i punti dell’ormai famoso Manifesto Agile, che ha visto come protagonisti l’Ing. Porfirio Tramontana, Ricercatore di sistemi di elaborazione delle informazioni presso la Federico II e il Dott. Ing. Antimo Angelino Vice Coordinatore Commissione Informatica.

Di seguito gli appunti:

Prof.  Tramontano docente Federico II ingegneria del software

Sviluppo Agile: metaprocesso

La programmazione software “classicca”

• Molti progetti software falliscono
• Si parte dagli anni 2000
• Millennium  Bug
• Se il processo è ad alta qualità il software è ad alta qualità
• Ciò ha portato ad una tale rigidità che si ripercuote sul software stesso quindi spessissimo fallisce.
• Lo standard mi permette di stimare bene i costi e l’affidabilità ma è pericoloso
• Waterfall model
• Spesso siamo costretti a mettere una pezza  (challenging)
• È l’opposto dell’agile
• È la più rischiosa
• Va bene per le grandi aziende

Ciclo a cascata con validazione continua

• Verificare: il software deve dare il risultato corretto
• Validare: deve fare quello richiesto dal cliente
• Se ci sono problemi torniamo indietro di una fase

RUP

• È un processo molto preciso
• Minimizza i rischi di un fallimento
• È iterativo: rilasciamo spesso qualcosa da mostrare al cliente
• Iper burocratizzazione

Metodi Agili

• Non garantiscono la qualità
• Va bene per piccoli software
• Ad esempio software innovativi per i quali non conosciamo bene le caratteristiche
• Sviluppo di app
• Manifesto Agile
• Kent Beck
• Prima gli individui poi i tool.
• Non ci serve troppa standardizzazione
• Abbiamo il problema di non avere traccia di quanto DETTO tra le controparti. Non avendo una relazione approfondita
• Riduce i rischi di validazione
• Il software viene prima della documentazione
• Il problema è che la documentazione è importante per la manutenzione futura.
• Prima la collaborazione con il cliente che i contratti. Il cliente deve lavorare insieme agli sviluppatori: il prezzo si stabilisce a prodotto finito.
• Deve seguire i cambiamenti e non un piano preciso
• È inutile fare pianificazioni a lunghissimo tempo perché saremo sempre smentiti. Quindi Agile dice:non pianifichiamo proprio.
• Qualsiasi cosa facciamo dobbiamo valutare se l’abbiamo fatta bene
• Rapida, incrementale consegna del software
• Processo agile
• Story Card: ci scriviamo gli scenari. Deve essere piccolo. Non vogliamo affrontare troppe cose in un colpo solo. Cerchiamo di affrontare il problema un po alla volta.
• Mettiamo in salvo le piccole cose
• Ho prodotti con scarsa qualità
• Massimo orizzonte temporale: 2 settimane-3 mesi
• Funziona molto bene in ambienti non distribuiti. Idealmente sono affiatati e lavorano nella stessa stanza.
• Gruppi piccoli e tempo limitato
• Ci sono molti che hanno cercato di sviluppare i principi Agili

Principi:

• Il cliente partecipa attivamente
• Definisce le priorità perché metto in conto di non riuscire a finire il progetto
• Consegna incrementale
• Lo devo evitare se devo fare software di altissima qualità
• Le persone devono fare i processi
• Devo limitate al massimo le imposizioni
• Accettiamo i cambiamenti
• DOBBIAMO ESSERE SEMPLICI: il software lo devono capire tutti e deve essere semplice da modificare
• Per Agile il software DEVE FUNZIONARE, per gli schemi classici deve essere QUALITATIVAMENTE VALIDO

Agilità e Modellazione

• Modellazione: è un gradino oltre la progettazione. Serve ad individuare gli attori e stiamo già pensando in dettaglio al problema.
• Modello dei casi d’uso
• Modello concettuale
• Nel modello NON DEVE ESSERCI LA SOLUZIONE
• Nell’agile c’è il rischio di non fare la modellazione perché non ci interessa conoscere interamente il problema
• Spesso il cliente non riesce a spiegarci bene qual è il problema

Processo:

• Identifichiamo le funzionalità che vogliamo rilasciare
• L’interazione va da 2 a 13 settimane: sviluppo e testo insieme al cliente
• Quando finisce l’interazione lo diamo al cliente finale e lo supportiamo
• Nel caso in cui c’è bisogno di fare delle modifiche bisogna capire se interrompere il progetto o prendere una risorsa e dedicata alle modifiche
• Quando definisco un requisito devo anche definire le metodologie di verifica
• Man mano che si sviluppa si scrivono i test
• Conviene fare test automatico:

1. Scrittura
2. Esecuzione
3. Risultati

• Per gestire al meglio i test utilizzo Junit  (un framework con classi e metodi)
• Nel sistema agile il testing dovrebbe essere più semplice
• Con Junit posso rendere automatico anche la gestione dei risultati
• Dobbiamo fare test continui non accumulare troppo da testare. NON SI SALTANO I TEST
• Sarebbe opportuno che i test li faccia chi non ha creato la funzione
• Nell’agile si propone di alternare sviluppatori e testing
• TDD: prima scriviamo il test poi facciamo il programma
• Il test di sistema lo faccio da solo
• Il test di accettazione lo faccio con il cliente
• Ogni volta che aggiungiamo un pezzo rifacciamo tutti i test. Se sono automatici non abbiamo problemi. Magari li facciamo fare di notte.
• Junit è punto fondante della metodologia Agile

VANTAGGI

• So quando posso consegnare il pezzetto
• Con pagamenti giorno per giorno ho una migliore monetizzazione
• Si evolve working progress
• Testiamo in continuazione
• Il cliente è soddisfatto

EXTREME PROGRAMMING (XP)

• È la prima metodologia 1999
• Concetto di storie: il cliente mi dice cosa vuole
• Creo degli scenari (requisiti) non ambigui, verificabili, coerenti e completi le ultime due sono spesso trascurate
• Se modifico qualcosa se ne creava una nuova versione di questo qualcosa. Inoltre faccio il test di queste versioni (controllo di versione)
• Si fonda su strumenti ben precisi come Junit
• Ho rilasci molto frequenti. Massimo un mese

PRATICHE XP

1. Pianificazione: la facciamo tutti insieme sotto forma di GAME. Deve durare poco.
2. Small releases: piccoli rilasci quindi riesco meglio a gestire tutto
3. Metaphor: tutti devono sapere tutto dei progetti. Anche i nomi delle variabili e dei metodi devono essere comprensibili a tutti. Magari con metafore.
4. Simple Design: la semplicità porta facilità di gestione ma sono di bassa qualità. (Design Pattern)
5. Testing: mai evitare ed automatizzare
6. Refactoring: modifiche al codice del programma per migliorare la qualità. Questo perché il codice di XP è già di scarsa qualità. Ce lo dobbiamo imporre
7. Pair programming: programmazione a coppia. Si controllano a vicenda.
8. Collective ownership: tutti devono sapere tutto.

Scarica il file degli appunti il formato PDF – Programmazione Agile 1