Extreme Programming

L’Extreme Programming (XProgramming) è una disciplina di sviluppo software che si basa su sui valori di semplicità, comunicazione, rispetto, feedback e coraggio.

L’eXtreme Programming (XP) è una opportunità per esplorare le tue reali capacità per trovare le tue reali capacità, per essere realmente te stesso.

Sviluppa utilizzando il TDD il più possibile, utilizza il Continuos Integration e automatizza il processo di sviluppo il più possibile. Il deployment dovrebbe esserci almeno una volta al giorno.

Migliora il design ogni volta che è possibile.

Dai il meglio di te stesso e realizza la miglior soluzione ogni volta che è possibile farlo, questo è Extreme ovvero utilizza il massimo delle tue potenzialità.

XP è modo di sviluppare software caratterizzato dallo sviluppo di ottime applicazioni che sono una conseguenza di tecniche di sviluppo software e di una comunicazione chiara.

XP ha seguenti caratteristiche.

Una filosofia di sviluppo software basata sui valori di comunicazione, feedback, semplicità e rispetto.

Una serie di pratiche che migliorano lo sviluppo del sofware, queste pratiche sono collegate e quindi una pratica migliora l’utilizzo dell’altra.

Una community che condivide questi valori e queste pratiche.

XP è anche un percorso di miglioramneto che avviene come persona e come professionista che si attua attraverso lo sviluppo software.

XP ha cicli di sviluppo corti caratterizzati da continui feedback.

Ha un approccio incrementale, il quale consente di far evolvere in progetto in base ai bisogni dei clienti e risponde ai cambiamenti e alle necessità che chiede il business dei clienti.

XP dipende dalla comunicazione orale dei componenti del team, dai tests, dall’interazione del codice con l’intero sistema, XP risponde al design che è in continua evoluzione.

Il desiderio di utilizzare tecniche e metodologie eccellenti è una caratteristica degli ambienti XP.

I valori di XP

XP ha i seguenti valori che guidano lo sviluppo:

comunicazione, semplicità, feedback, coraggio, rispetto.

Questi sono i valori di una organizzazione, di un team. Per mezzo dei valori ci si collega ai principi di XP.

I principi di XP

Umanità.

Sono le persone che sviluppano il software. Avere l’opportunità di aumentare le lore abilità e le loro conoscenze spesso è una grande forma di motivazione per le persone. Le pratiche XP spesso soddisfano sia il business sia i bisogni delle persone.

Economia.

Essere sicuri che ciò che si sviluppa ha un reale valore per il business e incontra le aspettative e gli obbiettivi dei clienti.

Reciproco vantaggio.

Si ha un approccio win win, ovvero tutte le attività dovrebbero soddisfare le persone coinvolte. Ad esempio lo scrivere test automatici consente sia allo sviluppatore, sia al team, sia ai futuri sviluppatori uno strumento per un miglior software.

Self-Similarity.

Questo principio consiste nel provare a copiare una struttura di una soluzione funzionante in un nuovo contesto con le corrette dimensioni, con le corrette semplici ed essenziali implementazioni. Un semplicissimo esempio iniziale è scrivere un test che non funziona e poi modificarlo in un test funzionante.

Miglioramento.

L’approccio è fare il meglio possibile oggi e domani cercare di migliorarlo, può essere il processo di sviluppo, il design, le user stories.

Lo sviluppo incrementale implica il disegn incrementale del software, quindi si ha una ridefinizione del design continua.

Inoltre la collaborazione è migliorata per mezzo del pair programming e continuos integration.

Diversità.

Sarebbe meglio che ogni team avesse persone con diverse abilità, attitudini ed esperienze, questo consente anche di trovare diversi modi per risolvere problemi e diverse implementazioni per risolvere problemi.

Riflessione.

I buoni team non lavorano soltanto ma pensano come possono lavorare meglio e perchè essi lavorano con una certa modalità. Analizzano anche perchè essi hanno successo oppure falliscono nelle cose che fanno. Se fanno errori, non nascondono gli errori perchè sono uno strumento per migliorarsi e per migliorare il team.

Flusso.

Le pratiche XP tendono a un flusso continuo delle attività. Si tende ad effettuare piccoli deploy incrementali ma più frequenti. Ad esempio una build effettuata ogni giorno è flow oriented.

Opportunità.

Si impara che i problemi sono una opportunità di cambiamento e di miglioramento.

Ridondanza.

Alcune pratiche sono ridondanti, ad esempio Pair Programming, Continuos Integration, sederti tutti insieme, daily deployment.

Fallimento.

Anche se effettui una implementazione o fai qualcosa che non funziona, c’è siduramente qualcosa che si può imparare da essa.

Qualità.

I progetti non non finiscono prima se la qualità è bassa e allo stesso tempo non vanno più lentamente se la qualità è alta.

Baby steps.

L’obbiettivo è quello di realizzare grossi cambiamenti per mezzi di piccoli cambiamenti.

Pratiche

“Sedersi insieme”.

La comunicazione, la coversazione è importante, quindi il sedersi attorno a un tavolo con tutto il team e con i clienti consente l’attivazione di più sensi rispetto a una comunicazione di sole emails.

“Tutta la squadra”.

Tutte le persone della squadra si supportano l’un l’altro, questo vale sia per il progetto sia per l’apprendimento, sia per lo studio di metodologie e tecniche.

“Informative Workspace”.

L’ open space del team deve essere informativo, ovvero devono esserci informazioni che consentono di trarre informazioni inerenti al progetto al quale si sta lavorando, ad esempio questa pratica si attua con le story cards sul muro.

Pair Programming.

Il pair programming è una pratica nella quale due perosne programmano insieme, effettuano design insieme, migliorano il codice insieme, testano il codice insieme, analizzano il codice insieme. Lo spazio personale deve essere rispettato da entrambi i pair.

Storie.

Si scrivono le story cards. Una volta scritte si prova a estimare il tempo necessario per l’implementazione della storia stessa (Ideal Engineering Time).

Utilizzare le story cards consente la descrizione del business in modo simile alla vita reale.

Weekly Cycle.

Pianificare il lavoro settimanalmente, una volta alla settimana, meglio di lunedì mattina. Durante il meeeting vedere cosa si è fatto la settimana precedente, che cosa si ha intenzione di fare nella settimana in corso per mezzo delle story cards. Convertire le story cards in tasks che verranno stimati dal team come tempistica di sviluppo.

Quarterly Cycle.

Ogni tre mesi riflettere sul progetto, sul team, sui progressi effettuati.

Ten minute build.

La build compresi i test automatici non dovrebbe essere più lunga di 10 minuti, è consigliato avere una master build di al massimo 2, 3 minuti.

Continuos integration.

Gli steps di integrazione non sono predittivi, ma se si integra in modo continuo si hanno molto meno i problemi di integrazione e la loro soluzione è molto più veloce.

Test First Programming.

Scrivi un test che fallisce prima di fare qualsiasi cambiamento di codice.

Questo consente di verificare il comportamento del sistema.

Design Incrementale.

Lavora ogni giorno per migliorare il design.

I team XP lavorano affinchè il costo del cambiamento delle features del software non sia oneroso. Questo si realizza tramite i test automatici, i miglioramento continuo del design e altre pratiche. Si effettuano piccoli steps per migliorare il design, ad esempio il TDD consente questo.

Inoltre il design senza duplicazione di codice è molto più facilmente migliorabile.

Quindi può esserci inizialmente un sistema piccolo che che cresce a seconda delle necessità in modo incrementale.

Conclusione.

Le pratiche menzionate sono basate su feedback, comunicazione e rispetto che facilitano la semplicità e il coraggio, i valori di XP.

Si ha un veramente un team XP quando queste pratiche vengono effettuate.

 

Bibliografia:

Extreme Programming Explained: Embrace Change
Kent Beck with Cynthia Andres Foreword by Erich Gamma

http://www.amazon.it/Extreme-Programming-Explained-Embrace-Change/dp/0321278658/

 

 

 

 

Alessandro Ceseno

PS: se hai domande scrivimi pure per mezzo della sezione contatti.