Extreme Programming Genova, 29 Ottobre 2002

22/06/20152 Cosa è XP? È una delle metodologie cosiddette agili per lo sviluppo di software. Le metodologie agili nascono per svincolarsi da metodologie troppo rigide mantenendo però un approccio disciplinato.

22/06/20153 Cenni storici Nasce nella primavera del 1996 grazie a Kent Beck. Viene applicata in un progetto di gestione paghe alla Chrysler.

22/06/20154 XP si basa su quattro valori Comunicazione Feedback Semplicità Coraggio

22/06/20155 Comunicazione Tra sviluppatori Tra sviluppatori e utenti finali Tra manager, sviluppatori e utenti finali

22/06/20156 Feedback Rilasci frequenti Test di accettazione da parte dell’utente Azioni immediate in risposta ai risultati del test di accettazione

22/06/20157 Semplicità Nella progettazione: –Scomposizione del progetto in unità piccole Nel codice realizzato Nella realizzazione dei test e quindi nel debug

22/06/20158 Coraggio Nell’affrontare cambiamenti di requisiti. Nell’affrontare nuove tecnologie. Nel migliorare continuamente il codice.

22/06/20159 XP è facilmente applicabile Non è niente di completamente nuovo. È fatta per essere adattabile. È composta da un insieme piccolo di regole/pratiche.

22/06/ Un progetto XP

22/06/ Descrizione delle iterazioni

22/06/ Ciclo di sviluppo in XP

22/06/ Condivisione del codice

22/06/ Regole e pratiche di XP - Pianificazione “User stories” –Scritte dal cliente –Massimo di 3 settimane di lavoro “Release Planning” –Combina esigenze di manager e clienti con le esigenze di sviluppo “Small releases” –È più facile intervenire in caso di problemi “Iteration planning” –Suddivisione in “tasks” delle “user stories”

22/06/ Regole e pratiche di XP - Codifica “Customer always on site” -Per definire le “user stories”, per concordare i rilasci, per provare e collaudare il software il prima possibile. Progettare il test prima –Facilita la scrittura del codice –“Costringe” a rispettare i requisiti definiti dalle “user stories”. “Pair Programming” –Migliora la qualità del software.

22/06/ Regole e pratiche di XP - Codifica “Collective Code Ownership” –Chiunque può modificare o correggere qualsiasi modulo software. –Responsabilità più distribuite. “No overtime” –Riduce il numero di errori. –Migliora la soddisfazione degli sviluppatori. –Neanche aggiungere persone ad un progetto migliora situazioni critiche.

22/06/ Regole e pratiche di XP – Progettazione “Simplicity” –Contenere sempre le singole unità di lavoro entro certi limiti aiuta la pianificazione, il test e lo sviluppo. “Spike solutions” –Quando ci sono incertezze nelle stime dovute ad incognite tecnologiche, sviluppare piccoli prototipi con l’obiettivo di ridurre il rischio. “Refactor” –Non appena possibile modificare parti di codice complesso per semplificare.

22/06/ Regole e pratiche di XP – Testing “Unit tests” –Il test deve essere creato prima della stesura del codice tramite appropriati strumenti per l’automazione che fanno parte degli strumenti di sviluppo. –Devono essere trattati alla stessa stregua del codice. –I moduli software modificati successivamente devono superare i test scritti precedentemente. –Alla scoperta di un baco la prima azione da intraprendere è la riscrittura del test.

22/06/ Regole e pratiche di XP - Testing “Acceptance tests” –Verificano che le “user stories” siano rispettate –Vanno scritti con i clienti subito dopo aver sviluppato le “user stories” –Solo il superamento di “acceptance tests” modifica lo stato di avanzamento del progetto.

22/06/ Bibliografia www-106.ibm.com/developerworks/library/j-xp0813/