XP programming

XP e' un metodologia  "leggera" per teams di dimensioni medio-piccole che sviluppano software avendo requisiti vaghi o che cambiano rapidamente.

A molti XP puo' sembrare una metodologia basata sul buon senso. Allora perche il termine X = estremo P = programmazione?
La risposta e' che XP porta questi principi di buon senso ad estremi livelli.

Cioe':

• Se la revisione del codice e' una buona cosa, revisioneremo il codice di continuo (pair programming = programmazione tra pari = io rivedo il tuo codice, tu rivedi il mio)
• Se testare e' una buona cosa, tutti testeranno sempre (unit testing), anche con i clienti (test funzionale).
• Se la progettazione e' una buona cosa, essa fara' parte dell'attivita' giornaliera di ciascuno (refactoring)
• Se la semplicita' e' una buona cosa, faremo in modo di lasciare il sistema con il piu' semplice progetto che implementa la funzionalita' correntemente richiesta (la cosa piu' semplice che possa funzionare).
• Se l'architettura e' importante, ogniuno lavorera' definendo e affinando l'architettura di continuo (metaphor = metafora)
• Se i test di integrazione (test i vari pezzi del programma insieme: es. WS + FileExServer + DBL) sono importanti allora integreremo e testeremo diverse volte al giorno (CI = continuos integration)
• Se iterazioni di rilascio del sf brevi sono una buona cosa, faremo le iterazioni molto, molto corte - secondi, minuti e ore, non settimane, mesi e anni (Planning game = gioco della pianificazione)
  

Adozione di XP dovrebbe portare i seguenti benefici:

Ai programmatori:

• Saranno in grado di lavorare sempre su cose veramente importanti, ogni giorno.
• Non dovranno affrontare situazioni pericolose da soli.
• Saranno in grado di fare ogni cosa in loro potere per portare il sistema al successo
• Prenderranno le migliori decisioni che possono prendere
• Non prenderanno decisioni che non sono i piu' qualificati a prendere
  

Ai clienti e manager:

• Avranno il massimo risultato possibile da ogni settimana di lavoro.
• Ogni settimana vedranno concreti progressi sugli obbiettivi a loro cari
• Potranno cambiare direzione al progetto nel mezzo dello sviluppo senza incorrere in costi esorbitanti
  

In sinstesi XP promette di:

1. ridurre il rischio del progetto: non portarlo a termine affatto o di non soddisfare le richieste del cliente
2. migliorare la produttivita' per tutto il ciclo di vita del sistema
3. sviluppare divertendosi in gruppo
   

Ancora su cosa e' XP:

• E' avere un feedback anticipato, concreto e continuo dall'adozione di cicli brevi
• E' una pianificazione incrementale la quale fornisce in poco tempo un piano generale che evolvera' durante il ciclo di vita del progetto
• Ha la possibilita' di schedulare in modo flessibile nuove funzionalita' per rispondere ai cambiamenti delle richieste del cliente
• Si basa su test automatizzati scritti dai programmatori e dai clienti per controllare il generale avanzamento dello sviluppo, per consentire al sistema di evolversi e scovare in anticipo i difetti.
• Si basa sulla comunicazione orale, tests, e sorgenti per comunicare la struttura del sistema e intenti.
• Si basa su una progettazione continuativa che dura fintanto che dura il sistema che si sta' sviluppando.
• Si basa sulla collaborazione degli sviluppatori che hanno capacita' simili
• Si basa su pratiche che funzionano sia con l'istinto a breve termine del programmatore e con gil interessi a lungo termine del sistema che si sta sviluppando.
  

XP e' una disciplina di sviluppo del software. E' una disciplina perche' ci sono alcune cose che debbono essere fatte per poter dire di stare sviluppando in XP. Non si puo' scegliere se si scriveranno i test o no: se non lo fai non sei estremo: fine della discussione.

TDD

In una frase possiamo dare il significato di TDD:"Scrivere soltanto il minimo codice necessario per far funzionare un test che fallisce".

• Prima scriviamo un test
• Poi scriviamo il codice per farlo passare
• Poi affiniamo il codice riprogettandolo (refactor), basandoci sul test appena scritto in modo da non rompere la funzionalita' appena creata nel tentativo di migliorarla.
  

Vantaggi per il programmatore:

• Raramente dovremmo avere chiamate di asistenza o finire in lunghe sessioni di debug
• Siamo confidenti sul lavoro da noi svolto (NON E' COLPA MIA SE NON FUNZIONA)
• Abbiamo piu' tempo per altre attivita' per migliorare come professionisti (STUDIO) e/o migliorare il sistema

Vantaggi per azienda (qualita'):