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

Programmazione Agile

Programmazione Agile

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

Lascia un commento