Con l’ingegneria del software in un ambiente così frenetico, gli approcci tradizionali alla gestione dei progetti non sono più praticabili.
Ciò significa che i professionisti IT devono trovare nuovi modi per gestire le attività di sviluppo che cambiano frequentemente.
Condividendo questa idea e concentrandosi sulle tecniche di sviluppo incrementale esistenti, 17 specialisti di software hanno introdotto la filosofia di gestione dei progetti Agile nel 2001. Nel Manifesto Agile sono stati delineati i principi di sviluppo software flessibile, veloce e incentrato sulla collaborazione.
Extreme Programming (XP) è uno dei numerosi framework Agile applicati dalle aziende IT, che verrà approfondito in questo articolo.
Cos’è la Programmazione Estrema?
Extreme Programming (XP, in italiano Programmazione Estrema) è una metodologia di sviluppo software progettata per migliorare la qualità del software e la sua capacità di adattarsi correttamente alle mutevoli esigenze del cliente.
Il termine “Extreme Programming” fu coniato da Kent Beck come modo per descrivere la metodologia e le pratiche utilizzate dagli ingegneri del software nel progetto C3 (Chrysler Comprehensive Compensation System, un progetto sui salari di Chrysler che si estese dal 1993 al 1999).
Quando Kent Beck è stato assunto come sviluppatore principale del progetto C3 nel 1996, a tre anni dall’inizio del progetto, il programma non funzionava ancora.
Nonostante oltre due anni in più di sviluppo e milioni di dollari di costi, il progetto C3 è stato sospeso nel 1999.
Ma è stato il successo iniziale del progetto C3 che ha scatenato l’ascesa di XP. La vera svolta è stata la capacità del team C3 di aumentare la produttività (e la qualità del codice) implementando i principi della produzione hardware, ovvero la produzione snella, al processo di sviluppo del software.
Secondo Martin Fowler, il progetto ha iniziato alcuni seri lavori di sviluppo, a Smalltalk, nel 1995, ma non è stato in grado di raggiungere uno stato stabile ed è stato riavviato sotto la guida di Kent Beck nel 1996. È stato questo progetto riavviato a mettere insieme tutte le pratiche che sono diventate note come Programmazione Estrema (sebbene Kent avesse usato approcci simili su progetti precedenti).
I membri del progetto C3 hanno continuato a sviluppare il progetto XP dopo che la fine del progetto C3 è stata annunciata nel 1999.
XP come ideologia ha lentamente guadagnato interesse nei successivi due decenni. I metodi e i principi continueranno ad essere adottati dai leader della comunità di sviluppo software in tutto il mondo.
Cinque valori fondamentali
L’intero paradigma di XP è fornito da cinque valori fondamentali, che consentono alle persone coinvolte di sentirsi fiduciose nella direzione che il progetto sta prendendo e di comprendere il loro feedback personale. Essi sono:
Semplicità: Con questo primo principio ci si focalizza con fare solamente ciò che è necessario con lo scopo di massimizzare il valore creato per l’investimento effettuato fino ad oggi. Verranno adottati piccoli e semplici passi verso l’obiettivo e verranno mitigati i fallimenti man mano che si verificano. Si creerà qualcosa di cui si è orgogliosi e lo si raggiungerà a lungo termine a costi ragionevoli.
Comunicazione: tutti fanno parte del team e si cerca pertanto di comunicare faccia a faccia ogni giorno. L’obiettivo di questo secondo principio è quello di lavorare insieme su tutto, dai requisiti al codice, creando congiuntamente la migliore soluzione al problema.
Feedback: verrà preso seriamente ogni impegno di iterazione, ascoltando attentamente e apportando le modifiche necessarie. Si parlerà del progetto e si adotterà al processo, non viceversa.
Rispetto: I membri del team si impegnano a rispettarsi l’un l’altro per comunicare tra loro, fornendo ed accettando feedback che onorano la relazione. Ciò permette di lavorare insieme in armonia e coesione, e ad aiutare più facilmente ad identificare le attività e le soluzioni ai problemi da risolvere.
Coraggio: Kent Beck ha definito il coraggio come “azione efficace di fronte alla paura“. Questa definizione mostra una preferenza per l’azione basata su altri principi in modo che i risultati non siano dannosi per il team. Hai bisogno di coraggio per sollevare problemi organizzativi che riducano l’efficacia del team. Hai bisogno di coraggio per smettere di fare qualcosa che non funziona e provare qualcos’altro. Hai bisogno di coraggio per accettare e agire in base al feedback, anche quando è difficile da accettare.
Pratiche XP
Oltre ai valori chiave, XP è fondato da un insieme interconnesso di pratiche di sviluppo software. Sebbene sia possibile eseguire queste pratiche in modo isolato, molti team hanno scoperto che alcune pratiche rafforzano le altre e dovrebbero essere eseguite congiuntamente per eliminare completamente i rischi che spesso si incontrano nello sviluppo del software.
Le pratiche XP sono cambiate un po’ da quando sono state introdotte inizialmente. Le dodici pratiche originali sono elencate di seguito (se desideri maggiori informazioni su come sono state descritte puoi visitare questo sito in inglese).
- Il gioco di pianificazione
- Piccoli rilasci
- Metafora
- Design semplice
- Analisi
- Refactoring
- Programmazione in coppia
- Proprietà collettiva
- Integrazione continua
- Settimana da 40 ore (Iterazioni)
- Cliente in loco
- Codifica Standard
Esempio di applicazione di Programmazione Estrema
Vediamo ora un esempio di come un progetto può venire completato grazie alla Programmazione Estrema. Di seguito, vengono incluse alcune delle pratiche sopra citate.
Pianificazione
In partenza del progetto, il cliente scrive storie utente, che definiscono la funzionalità che vorrebbe vedere, insieme al valore commerciale e alla priorità di ciascuna di queste funzionalità. Le storie dell’utente non devono essere esaustive o eccessivamente tecniche, devono solo fornire dettagli sufficienti per aiutare il team a determinare il tempo necessario per implementare tali funzionalità.
Da lì, il team crea un programma di rilascio e divide il progetto in iterazioni (da una a tre settimane).
Il team si riunisce il primo giorno della settimana per riflettere sui progressi fino ad oggi, il cliente sceglie le storie che vorrebbero consegnare in quella settimana e il team determina il modo in cui approccerà tali storie. L’obiettivo entro la fine della settimana è avere funzioni testate che realizzino le storie selezionate.
L’intento dietro il periodo di consegna previsto è quello di produrre qualcosa da mostrare al cliente per un feedback. I project manager potrebbero voler creare una sequenza temporale o un diagramma di Gantt semplificato per condividere il programma con il team.
Gestione e Controllo
In questa fase, il project manager imposterà la squadra per avere successo in questa metodologia. Tutti hanno bisogno di lavorare in modo collaborativo ed efficace per comunicare ed evitare qualsiasi errore. Questa fase prevede di:
- Creare un’area di lavoro aperta per il team;
- Stabilire un ritmo sostenibile (ovvero determinare la giusta lunghezza per le iterazioni);
- Misurare la velocità del progetto (la quantità di lavoro svolto sul progetto);
- Riassegnare il lavoro per evitare strozzature o perdita di conoscenza;
- Modificare le regole se XP non funziona perfettamente per il team.
Progettazione
Questa regola ritorna al valore della semplicità: inizia con il design più semplice perché il completamento della soluzione complessa richiederà meno tempo. Non aggiungere funzionalità in anticipo, per mantenere il codice pulito e conciso. Rimuovi la duplicazione dei processi e crea soluzioni per risolvere potenziali problemi prima che rimangano indietro al team.
Questa pratica inoltre suggerisce che devi fare un po’ di lavoro in anticipo per capire la giusta prospettiva del design del sistema, e quindi immergendoti nei dettagli di un particolare aspetto di quel design quando fornisci funzionalità specifiche.
Tutto ciò permette di ridurre il costo delle modifiche e consente di prendere decisioni di progettazione quando necessario sulla base delle informazioni più recenti disponibili.
Codifica e Test
Quindi arriva finalmente il momento di implementare il codice. XP esercita la proprietà del codice collettivo: tutti riesaminano il codice e qualsiasi sviluppatore può aggiungere funzionalità, correggere bug o ridurre processi già presenti. Affinché la proprietà del codice collettivo funzioni, il team dovrebbe:
- Scegliere una metafora del sistema (schema di denominazione standardizzato).
- Esercitarsi nella programmazione delle coppie (pair programming). I membri del team lavorano in coppia, su un singolo computer, per creare codice e inviarlo in produzione. Solo una coppia integra il codice alla volta.
L’idea alla base di questa pratica è che due cervelli e quattro occhi sono meglio di un cervello e due occhi. Ottieni in modo efficace una revisione continua del codice e una risposta più rapida ai problemi fastidiosi che possono impedire a una persona di rimanere indietro. - Eseguire un’integrazione continua: una pratica in cui le modifiche al codice vengono immediatamente testate quando vengono aggiunte a una base di codice più ampia. Il vantaggio di questa pratica è che puoi individuare e risolvere prima i problemi di integrazione.
Il cliente dovrebbe essere disponibile, preferibilmente sul posto, durante l’intero processo in modo che possano rispondere alle domande e stabilire i requisiti. - Applicare la regola del “Ten Minute Build”, che punta a costruire automaticamente l’intero sistema ed eseguire tutti i test in dieci minuti. I fondatori di XP hanno suggerito un intervallo di tempo di 10 minuti perché se una squadra ha una build che richiede più tempo, è meno probabile che venga eseguita su una base frequente, introducendo così un tempo più lungo tra gli errori.
Questa pratica incoraggia il team ad automatizzare il processo di compilazione in modo da avere maggiori probabilità di farlo su base regolare e di utilizzare quel processo di compilazione automatizzato per eseguire tutti i test.
Infine, il team esegue test, analisi e corregge i bug prima che il codice possa essere rilasciato.
Ruoli all’interno di un progetto di programmazione estrema
A seconda della fonte che leggi, troverai chi dà indicazioni, e chi non prende posizione in merito ai ruoli che risiedono in un progetto di programmazione estrema.
A mio parere, in ogni progetto, ci devono essere, per lo meno, questi quattro ruoli più comuni:
Cliente: autoesplicativo. Il motivo del progetto. Decide cosa deve fare il progetto. Fornisce le storie degli utenti.
Programmatore: questa è la persona che:
- Raccoglie le storie che vengono fuori dal cliente;
- Crea attività di programmazione dalle storie;
- Implementa le storie degli utenti;
- Verifica il codice per unità.
Allenatore: l’allenatore è solitamente un consulente esterno o un esperto di XP. Generalmente assicura che il progetto sia sulla buona strada e aiuta ad evitare errori comuni che altrimenti allungherebbero i tempi e i costi di progetto.
Tracker: il Tracker effettua richieste specifiche ai programmatori a un intervallo prestabilito. In genere, va in giro a controllare i progressi dei programmatori, offrendo aiuto ove necessario in diversi modi: rimboccarsi le maniche e aiutare direttamente con il codice, informare l’allenatore o organizzare un incontro con il cliente, a seconda delle necessità.
Alcuni dei ruoli di programmazione estrema possono essere combinati, ma alcuni chiaramente non possono.
Il cliente, ad esempio, non può essere anche il programmatore. Analogamente, il programmatore e il tracker non possono essere la stessa persona.
Quando usare Extreme Programming
La programmazione estrema può funzionare bene per i team che:
- Si aspettano che le funzionalità del loro sistema cambino ogni pochi mesi.
- Sperimentano requisiti in costante evoluzione o collaborano con clienti che non sono sicuri di ciò che desiderano faccia il sistema.
- Vogliono mitigare il rischio del progetto, specialmente in tempi ristretti.
- Includono un numero limitato di programmatori (preferibilmente tra 2 e 12).
- Sono in grado di lavorare a stretto contatto con i clienti.
- Sono in grado di creare unità automatizzate e test funzionali.
Se la collaborazione e lo sviluppo continuo sono priorità per il team, vale la pena provare la programmazione estrema. Poiché questo modello altamente adattabile richiede un feedback costante da parte dei clienti, anticipa gli errori lungo il percorso e richiede agli sviluppatori di lavorare insieme.
XP non solo garantisce una riduzione dei costi di progetto, ma ha anche involontariamente migliorato la produttività per i team di sviluppo di tutto il mondo.
Maggiori informazioni puoi trovarle su:
