Extreme Programming - P.M. Consulting
Menu principale:
- Home Page
- Mission
- Servizi
-
Spazio P.M.
- Introduzione
- Fondamenti
- Processi
- Ciclo di Vita
- Pratiche di Project Mgmt
- Coffee Break
METODI "AGILE" -
Extreme Programming (XP) è una disciplina che organizza i gruppi di lavoro verso la produzione di software di alta qualità in modo più produttivo che con metodi tradizionali. XP cerca di ridurre i costi delle modifiche ai requisiti decomponendo le attività di sviluppo in molti cicli brevi piuttosto che in un unico lungo ciclo. Secondo questa dottrina, le modifiche ai requisiti rappresentano un aspetto naturale, inevitabile e persino desiderabile dei progetti di sviluppo software, ribaltando così il principio secondo cui i requisiti di un progetto devono essere definiti all'inizio e non possono cambiare se non in via eccezionale.
XP introduce elementi che vanno ad aggiungersi a quelli dichiarati dall'"Agile Alliance".
ATTIVITA'
1. Programmazione
secondo XP l'unico prodotto davvero importante in un processo di sviluppo software è il codice, perché senza il codice non c'è prodotto.
Il codice può essere utilizzato con profitto anche come strumento di comunicazione tra programmatori per rappresentare la soluzione più idonea a qualsiasi problema si presenti nel corso dell'attività. Questo perché, non essendo soggetto ad interpretazioni, può trasmettere con estrema chiarezza qualsiasi informazione. Chi riceve la comunicazione sotto forma di codice può rispondere nella stessa forma.
2. Test
L'approccio XP è che un estensivo utilizzo dei test può eliminare molti difetti del codice.
Lo Unit Test consente di verificare se un singolo componente lavora come previsto. Il programmatore scrive tanti test automatici quanti è possibile per individuare eventuali errori. Quando tutti i test sono stati superati il lavoro di programmazione è completo e il componente può passare alla fase successiva.
I test di accettazione (Acceptance Test) verificano l'aderenza del prodotto finale ai requisiti espressi dal cliente. Questa attività ha luogo nella fase di esplorazione per la pianificazione del rilascio.
3. Ascolto
I programmatori devono ad ascoltare il cliente quando illustra le sue aspettative sul sistema da sviluppare e le devono comprendere sufficientemente bene da poter fornire di ritorno al cliente l'informazione di come il problema può essere risolto e di cosa non può essere risolto.
4. Disegno
La programmazione da sola non basta per ottenere un prodotto di qualità. E' necessario che il Sistema sia progettato con un disegno d'insieme che ne organizzi la logica, così che ogni singolo componente possa essere dimensionato e costruito nel modo più idoneo per il ruolo che deve svolgere all'interno del sistema. Un buon disegno eviterà inutili dipendenze tra le varie componenti, migliorando le performance del sistema e rendendone più semplice la manutenzione.
VALORI
1. Comunicazione
La comunicazione dei requisiti agli sviluppatori è essenziale per poter realizzare del software. Normalmente questa esigenza viene assolta con la documentazione. Le tecniche di XP prevedono invece la diffusione capillare di conoscenza tra i membri del team di sviluppo mediante una visione condivisa del sistema che corrisponda alla visione degli utenti e che si avvalga di un disegno semplice, della costante collaborazione tra sviluppatori e utenti e della comunicazione verbale.
2. Semplicità
Sviluppare anzitutto solo le funzioni di base. Le altre funzionalità possono essere aggiunte successivamente. In questo modo ci si focalizza su quello che è veramente necessario oggi e non su ciò che servirà in futuro. Il vantaggio di questo approccio, oltre a ridurre tempi e costi del rilascio iniziale, è di evitare il rischio di sviluppare delle funzioni sulla base di requisiti che potrebbero non essere più validi quando le si dovrà utilizzare, aumentando così il rischio di spendere inutilmente delle risorse.
Un disegno e una programmazione semplici migliorano la qualità della comunicazione in quanto più facili da comprendere da parte dei programmatori.
3. Riscontri
La comunicazione durante lo sviluppo deve produrre riscontri utili al gruppo di lavoro:
Riscontri dal Sistema: l'esecuzione dei cicli di test fornisce ai programmatori l'informazione sullo stato del sistema dopo l'implementazione di una modifica
Riscontri dal Cliente: i test di accettazione di ogni componente sono scritti dagli utenti, che possono verificare di continuo l'aderenza di quanto sviluppato alle loro esigenze, e informarne gli sviluppatori
Riscontri dal Team: A fronte di nuovi requisiti espressi dal cliente, il gruppo di lavoro stima l'impatto che avrà sul piano di lavoro (e sui costi del progetto) delle modifiche necessarie
4. Coraggio
L'adozione di XP richiede il coraggio delle proprie decisioni. Per disegnare e sviluppare solo il codice che serve oggi e non quello che servirà domani. Per ristrutturare il codice già realizzato, se e quando è necessario, in modo da rendere più semplice l'implementazione degli sviluppi successivi. Per cancellare del codice già sviluppato quando è necessario o rimuovere del codice obsoleto.
5. Rispetto
I programmatori devono avere rispetto degli altri e di se stessi. Non eseguire modifiche che danneggiano l'integrità dei programmi o provocano ritardi nell'attività del gruppo. Rispettare il proprio lavoro puntando alla qualità del codice e del disegno, intervenendo quando necessario per ristrutturare il codice già realizzato. Tutti i componenti del gruppo di lavoro sono apprezzati e considerati. Questo assicura una buona motivazione e incoraggia la lealtà verso il gruppo e verso gli obiettivi del progetto.
P.M. Consulting s.a.s. di Donato Dolini & C. | chi siamo | dove siamo | contattaci