Ingegneria del Software Processi di Sviluppo Agile Origini dello Sviluppo Agile Proposta di un gruppo di sviluppatori che rilevava una serie di criticità degli approcci convenzionali: Troppa rigidità dei processi Elevata quantità di prodotti intermedi Scarsa attenzione ai team di sviluppo Incapacità di risposta veloce ai cambiamenti
Manifesto per Lo Sviluppo Agile We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. Kent Beck et. al Cosa si intende per l agilità? Caratteristica dei moderni processi di sviluppo software per la quale si ha una risposta efficacie (rapida ed adattabile) ai cambiamenti (I. Jackobson) Comunicazioni efficaci fra tutti gli stakeholders coinvolti nel progetto Coinvolgimento del cliente nel team di sviluppo Auto-gestione del team di sviluppo Realizzazione rapida di incrementi del sistema
Un Processo Agile Si adatta al team di sviluppo valorizzando le risorse umane Non è fortemente vincolante E guidato dalle descrizioni delle necessità del cliente Si basa su azioni a breve termine Da forte enfasi alla costruzione piuttosto che all analisi e modellazione Sviluppa incrementi software iterativamente Si adatta ai cambiamenti Un Processo Agile: Extreme Programming L extreme programming (XP) è il più diffuso processo agile Non è una tecnica di programmazione ma un vero e proprio processo composto da quattro attività strutturali Planning Design Coding Test
Extreme Programming (2) user stories values acceptance test criteria iteration plan simple design CRC cards spike solutions prototypes refactoring pair programming Release software increment project velocity computed unit test continuous integration acceptance testing XP - Planning Ha inizio con la descrizione di user stories che descrivono funzionalità desiderate Il cliente ad ogni user story assegna una priorità Il team di sviluppo valuta le user stories, fa una pianificazione ed assegna un costo Ogni user story per la quale si prevede un tempo di sviluppo elevato viene suddivisa in più user stories Il team di sviluppo definisce i criteri per il testing di accettazione Il team di sviluppo stima la velocità del progetto
XP - Design E una fase molto leggera rispetto agli approcci convenzionali E orientata agli oggetti Gli unici prodotti di questa attività sono: Class Responsibility Collaborations Card Schede di assegnazione delle responsabilità alle classi Spike solutions Soluzioni di punta (prototipi) per funzionalità critiche E un prodotto opzionale XP - Coding Incoraggia il pair programming Due sviluppatori per ogni terminale ( due teste sono meglio di una ) I due sviluppatori si possono concentrare su aspetti differenti Ad esempio: uno sulla implementazione delle funzionalità in senso stretto e l altro sull interfacciamento e sull integrazione con le altre user stories
XP - Test Esecuzione delle unità di test e dei test di accettazione del cliente Valori di XP XP si basa su 4 valori chiave: Comunicazione Semplicità Feedback Coraggio Ran Jaffries
Altri modelli di sviluppo agile ASD Adaptive Software Development DSDM Dynamic Systems Development Method Scrum FDD Feature Driven Development Modelli Agili vs Approcci Convenzionali
Modelli Agili vs Approcci Convenzionali (2) Boehm s curve!" #!" # Modelli Agili vs Approcci Convenzionali Quando sono da preferire i modelli agili? Nel caso di team di sviluppo piccoli, molto coesi e con elevata esperienza Quando si deve garantire la consegna di un prodotto in tempi estremamente rapidi Le dimensioni del sistema da realizzare possono precludere l applicazione dei modelli agili La realizzazione di sistemi di grandi dimensioni difficilmente può prescindere da una corretta documentazione di tutte le sue parti realizzate e da realizzare