È 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.
Code and fix può funzionare solo in progetti piccoli.
Affermarzione di strumenti di sviluppo “visuali” e RAD lascia molta, troppa libertà.
Molti sviluppatori conoscono strumenti RAD, pochi conoscono ambienti tipo C, C++.
Una metodologia dovrebbe rimettere ordine in queste situazioni.
CASE: resti schiavo tutta la vita
Cenni storici
Nasce nella primavera del 1996 grazie a Kent Beck.
Viene applicata in un progetto di gestione paghe alla Chrysler.
Il programma in questione è ancora in uso e gestisce 10000 dipendenti.
XP si basa su quattro valori
Comunicazione
Feedback
Semplicità
Coraggio
Comunicazione
Tra sviluppatori
Tra sviluppatori e utenti finali
Tra manager, sviluppatori e utenti finali
Obiettivi vari: formazione continua, standard uniformi a tutto il team, proprietà del codice collettiva, soddisfazione massima dell’utente, rispetto delle scadenze e scadenze rispettose della qualità del prodotto.
Release planning, move people around, customer always available, standards, pair, collective code ownership, stand-up meeting
Feedback
Rilasci frequenti
Test di accettazione da parte dell’utente
Azioni immediate in risposta ai risultati del test di accettazione
Iterations, customer always available, unit tests first, when a bug is found create new tests, accepptance tests
Semplicità
Nella progettazione:
Scomposizione del progetto in unità piccole
Nel codice realizzato
Nella realizzazione dei test e quindi nel debug
Simplicity, crc cards, user stories, small releases, refactor
Coraggio
Nell’affrontare cambiamenti di requisiti.
Nell’affrontare nuove tecnologie.
Nel migliorare continuamente il codice.
Refactor, spike solutions, pair programming
XP è facilmente applicabile
Non è niente di completamente nuovo.
È fatta per essere adattabile.
È composta da un insieme piccolo di regole/pratiche.
Un progetto XP
Descrizione delle iterazioni
Ciclo di sviluppo in XP
Condivisione del codice
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”
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.
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.
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.
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.
Strumenti di testing devono essere considerati come editors, compilatori e tutti gli altri strumenti di sviluppo
Dovendo superare i test precedenti ci si mette al riparo da problemi dovuti a modifiche successive realizzate da altri.
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.
Comments