Hai familiarità con la programmazione, ma Extreme Programming (XP in breve) è ancora un po’ un mistero per te.
Non lasciarti scoraggiare dal nome, rischieresti di perderti informazioni utili.
In questo articolo andremo a trattare tutto ciò che devi sapere sulla programmazione estrema “Extreme Programming” in modo che tu possa sfruttarla a tuo vantaggio.
La programmazione estrema è una metodologia di sviluppo software che fa parte di ciò che è noto collettivamente come metodologie agili. XP si basa su valori, principi e pratiche e il suo obiettivo è consentire ai team di piccole e medie dimensioni di produrre software di alta qualità e adattarsi ai requisiti in continua evoluzione e cambiamento.
Ciò che distingue XP dalle altre metodologie agili è che XP enfatizza gli aspetti tecnici dello sviluppo del software. La programmazione estrema è precisa su come lavorano gli ingegneri poiché seguire le pratiche ingegneristiche consente ai team di fornire codice di alta qualità a un ritmo sostenibile.
La programmazione estrema riguarda, in poche parole, buone pratiche portate all’estremo. Poiché la programmazione in coppia è buona, facciamola sempre. Poiché testare in anticipo è buono, proviamo prima ancora che il codice di produzione sia scritto.
XP, a differenza di altre metodologie, si basa su valori e principi importanti e rilevanti, in termini di pratiche ingegneristiche.
I valori forniscono uno scopo ai team. Agiscono come una “stella polare” per guidare le tue decisioni ad alto livello. Tuttavia, i valori sono astratti e troppo sfocati per una guida specifica. Ad esempio: dire che apprezzi la comunicazione può portare a molti risultati diversi.
Le pratiche sono, in un certo senso, l’opposto dei valori. Sono concreti e con i piedi per terra, definendo le specifiche di cosa fare. Le pratiche aiutano i team a ritenersi responsabili dei valori. Ad esempio, la pratica degli spazi di lavoro informativi favorisce una comunicazione trasparente e semplice.
I principi sono linee guida specifiche del dominio che colmano il divario tra pratiche e valori.
I valori di XP: comunicazione, semplicità, feedback, coraggio e rispetto. Diamo un’occhiata a ciascuno di essi in modo più dettagliato.
Fonte dell’immagine Alexsoft.com
Comunicazione: la mancanza di comunicazione impedisce alla conoscenza di fluire all’interno di un team. Spesso, quando c’è un problema, qualcuno sa già come risolverlo. Ma la mancanza di comunicazione impedisce loro di conoscere il problema o di contribuire alla sua soluzione. Quindi, il problema finisce per essere risolto due volte, generando rifiuti.
Semplicità: la semplicità dice che ti sforzi sempre di fare la cosa più semplice che funzioni. Spesso viene frainteso e preso come la cosa più semplice, punto, ignorando la parte “che funziona”.
È anche fondamentale ricordare che la semplicità è altamente contestuale. Ciò che è semplice per un team, è complesso per un altro e dipende interamente dalle capacità, dall’esperienza e dalle conoscenze di ciascun team.
Feedback: il feedback nelle metodologie di sviluppo software più tradizionali, a cascata, spesso è “troppo poco, troppo tardi”.
XP, tuttavia, abbraccia il cambiamento e i team XP si sforzano di ricevere feedback tempestivi e costanti. Se è necessario correggere la rotta, gli XPer vogliono saperlo il prima possibile.
Fonte dell’immagine Alexsoft.com
Il feedback è disponibile in molte forme e dimensioni. Quando stai programmando in coppia, i commenti del tuo collega sono un feedback vitale. Così sono le opinioni degli altri membri del team su un’idea, incluso il cliente che, idealmente, è un membro del team.
I test sono un’altra fonte di feedback preziosi che vanno oltre i risultati dei test. Se scrivere test è facile o difficile lo è anche il feedback. Se hai difficoltà a scrivere test, il tuo progetto è probabilmente troppo complesso. Ascolta il feedback e semplifica il tuo design.
Qualcosa che suona come una grande idea potrebbe non funzionare così bene nella pratica. Quindi, anche il codice finito è una fonte di feedback, così come un prodotto distribuito.
Infine, tieni presente che esistono troppi feedback. Se un team genera più feedback di quanti ne possa gestire, feedback importanti potrebbero scomparire dal radar. È essenziale quindi rallentare e capire cosa causa l’eccesso di feedback e risolverlo.
Coraggio: Kent Beck definisce il coraggio come “azione efficace di fronte alla paura”. Come ingegnere del software, hai molto di cui aver paura e quindi molte opportunità per mostrare coraggio.
Ci vuole coraggio per dire la verità, soprattutto quelle spiacevoli, ad esempio stime oneste. Anche dare e ricevere feedback richiede coraggio. E ci vuole coraggio per evitare di cadere nella fallacia del costo irrecuperabile e scartare una soluzione fallimentare che ha ricevuto investimenti sostanziali.
Rispetto: una premessa fondamentale di XP è che tutti hanno a cuore il proprio lavoro. Nessuna quantità di eccellenza tecnica può salvare un progetto se non c’è cura e rispetto.
Ogni persona è degna di dignità e rispetto e ciò include, ovviamente, le persone interessate da un progetto di sviluppo software. Quando tu e i membri del tuo team vi rispettate e vi prendete cura l’uno dell’altro, del cliente, del progetto e dei suoi futuri utenti, tutti ne guadagnano
I principi forniscono una guida più specifica rispetto ai valori. Sono linee guida che illuminano i valori e li rendono più espliciti e meno ambigui.
Fonte dell’immagine Alexsoft.com
Ad esempio, basandoti solo sul valore del coraggio, potresti concludere che è consigliabile affrontare subito un grande cambiamento nel programma. Tuttavia, il principio di Baby Steps ci dice che i grandi cambiamenti sono rischiosi. Quindi, preferisci invece quelli piccoli.
Umanità: gli esseri umani creano software per gli esseri umani, un fatto spesso trascurato. Ma prendere in considerazione i bisogni umani di base, i punti di forza e le debolezze crea prodotti che gli umani vogliono usare. E un ambiente di lavoro che ti offre l’opportunità di realizzazione e crescita, il sentimento di appartenenza e la sicurezza di base, è un luogo in cui prendi più facilmente in considerazione i bisogni degli altri.
Economia: in XP, i team prestano sempre attenzione alle realtà economiche dello sviluppo del software, valutano costantemente i rischi economici e le esigenze del progetto.
Ad esempio, implementerebbero le storie degli utenti in base al loro valore aziendale piuttosto che a preoccupazioni tecniche.
Vantaggio reciproco: dopo XP, eviti soluzioni che avvantaggiano una parte a scapito di un’altra. Ad esempio, specifiche estese potrebbero aiutare qualcun altro a capirlo, ma ti distoglie dall’implementarlo e lo ritarda per i tuoi utenti.
Una soluzione reciprocamente vantaggiosa consiste nell’utilizzare test di accettazione automatizzati. Ottieni un feedback immediato sulla tua implementazione, i tuoi colleghi ottengono specifiche precise nel codice e gli utenti ottengono prima le loro funzionalità. Inoltre, tutti voi avrete una rete di sicurezza contro le regressioni.
Beneficio (Mutual Benefit): se una data soluzione funziona a un livello, potrebbe funzionare anche a un livello superiore o inferiore. Ad esempio, ottenere un feedback precoce e costante è in gioco a vari livelli in XP.
Miglioramento: secondo il principio del miglioramento, i team non mirano alla perfezione in un’implementazione iniziale, ma a un’implementazione sufficientemente buona, per poi apprenderla e migliorarla continuamente con il feedback degli utenti reali.
Diversità: tu e i tuoi colleghi beneficiate di una diversità di prospettive, abilità e atteggiamenti. Tale diversità spesso porta al conflitto, ma va bene.
Il conflitto e il disaccordo sono opportunità per la nascita di idee migliori quando tutti giocano secondo i valori del coraggio e del rispetto. Coraggio di esprimere punti di vista opposti, rispetto nell’esprimerli in modo civile ed empatico. E tutto questo è un esercizio di comunicazione efficace.
Riflessione: i grandi team riflettono sul proprio lavoro e analizzano come essere migliori. XP offre molte opportunità per questo. Non solo nei suoi cicli settimanali e trimestrali, ma in ogni pratica che promuove.
I sentimenti sono importanti da considerare oltre all’analisi logica. Il tuo istinto può informarti prima che tu possa ragionare su qualcosa. E così può parlare con persone non tecniche, possono porre domande che aprono possibilità completamente nuove.
Flusso: le tradizionali metodologie di sviluppo del software hanno fasi distinte, che durano a lungo e hanno poche opportunità di feedback e correzione del corso. Invece, lo sviluppo del software in XP avviene in attività che si verificano continuamente, in un “flusso” coerente di valore.
Opportunità: i problemi sono inevitabili nello sviluppo del software. Tuttavia, ogni problema è un’opportunità di miglioramento. Impara a guardarli in questo modo ed è molto più probabile che ti vengano in mente soluzioni creative e orientate agli obiettivi che servono anche a impedire che si ripetano.
Ridondanza: il principio di ridondanza dice che se un dato problema è critico, devi impiegare molte tattiche per contrastarlo.
Prendi i difetti. Non esiste una sola tattica che possa impedire a tutti i difetti di sfuggire alla produzione.
Quindi la soluzione di XP è impilare una serie di misure di qualità. Programmazione in coppia, test, integrazione continua. Ognuna una singola linea di difesa, insieme un muro virtualmente impenetrabile.
Fallimento: il fallimento non è uno spreco quando si traduce in conoscenza. Agire e imparare rapidamente ciò che non funziona è molto più produttivo dell’inazione causata dall’indecisione nella scelta tra molte opzioni.
Qualità: spesso le persone pensano che ci sia un dilemma tra qualità e velocità.
È il contrario: spingere per migliorare la qualità è ciò che ti fa andare più veloce.
Ad esempio, il refactoring, ovvero la modifica della struttura del codice senza alterarne il comportamento, è una pratica che rende il codice più facile da capire e modificare. Di conseguenza, è meno probabile che tu introduca difetti nel codice, il che ti consente di fornire più valore prima non dovendo correggere i bug.
Piccoli passi: i grandi cambiamenti sono rischiosi. XP mitiga tale rischio apportando modifiche in piccoli passaggi, a tutti i livelli.
I programmatori scrivono il codice in piccoli passaggi utilizzando lo sviluppo guidato dai test. Integrano il loro codice nella linea principale più volte al giorno, invece che solo ogni poche settimane o addirittura mesi. Il progetto stesso si svolge in cicli brevi piuttosto che in fasi di lunga durata.
Responsabilità accettata: in XP, la responsabilità dovrebbe essere accettata, mai assegnata.
La responsabilità dovrebbe essere accompagnata dall’autorità di prendere decisioni su ciò di cui sei responsabile. Vale anche il contrario. Non vuoi che le persone prendano decisioni se non devono convivere con le loro conseguenze.
Extreme programming, essendo una metodologia agile, si può accogliere e iniziare ad adottarlasenza seguire piani rigidi. Si tratta di un design iterativo piuttosto che di un grande progetto iniziale.
XP differisce notevolmente dalle metodologie tradizionali, ovvero a cascata, evitando fasi di lunga durata.
In che modo XP è diverso dalle altre metodologie agili?
La programmazione estrema, per sua natura, ha molto in comune con le altre metodologie agili ma è anche unica tra loro.
La maggior parte delle altre metodologie di sviluppo non dice molto, se non niente, su come eseguire il lavoro. XP, d’altra parte, è molto supponente quando si tratta di questo e pone grande enfasi sulle pratiche di ingegneria del software.
Scrum è un framework per aiutare i team a sviluppare progetti complessi in modo adattivo. Scrum non determina il modo in cui gli sviluppatori svolgono il lavoro. XP, come accennato, pone molta enfasi sulle buone pratiche di programmazione.
Fonte Immagine net solutions
Inoltre, XP riguarda ovviamente la programmazione. Scrum, d’altra parte, può essere applicato a qualsiasi progetto che benefici di un approccio iterativo.
XP accetta modifiche ai suoi componenti. I team sono autorizzati e persino incoraggiati a modificare le pratiche in base alle loro esigenze specifiche. La Scrum Guide, d’altra parte, è irremovibile nell’affermare che “Sebbene sia possibile implementare solo parti di Scrum, il risultato non è Scrum”.
Inoltre, Scrum è un framework che deve essere completato con metodologie e pratiche per svolgere il lavoro.
Ciò significa che è vivamente consigliato lavorare in extreme programming e Scrum.
Secondo Kent Beck, un team XP maturo non dovrebbe assegnare ruoli rigidi, ma riconoscere che i ruoli possono essere utili per i team principianti, fino a quando non iniziano a rallentare o rendere difficoltosa la collaborazione.
Vediamo alcuni ruoli chiave:
Sono le pratiche adottate in XP. Si dividono in tre gruppi principali: ingegneria del software, ambiente di lavoro e gestione dei progetti.
Programmazione in coppia: in XP, si scrive il codice in coppia seduto su una macchina. Tu e la tua coppia vi parlate mentre analizzate, implementate e testate la funzione su cui state lavorando. La programmazione in coppia è particolarmente efficace nella produzione di codice con meno difetti pur essendo coinvolgente, divertente e stancante.
Limite di dieci minuti: necessario prevede 10 minuti per la generazione dell’intero progetto, inclusa l’esecuzione di tutti i test automatizzati, in dieci minuti al massimo. Questo limite serve a mantenere i test snelli ed efficaci.
I Test prima della programmazione: implementare le funzionalità utilizzando l’approccio test-first, chiamato anche test-driven development (TDD). TDD consiste nello sviluppo utilizzando una semplice procedura iterativa:
TDD porta diversi vantaggi.
Innanzitutto, feedback. Se è difficile scrivere un test, il progetto che stai cercando o che hai ereditato è probabilmente troppo complesso e devi semplificarlo.
In secondo luogo, TDD consente ai programmatori di fidarsi del codice che scrivono e crea un piacevole ritmo ciclico in cui il passaggio successivo è sempre chiaro.
Ultimo ma non meno importante, l’utilizzo di TDD dall’inizio garantisce una copertura del codice del 100%. La suite di test diventa quindi davvero una rete di sicurezza per modifiche future, incoraggiando il refactoring del codice e creando un circolo virtuoso di qualità.
Progettazione incrementale: la pratica della progettazione incrementale significa che è necessario investire ogni giorno nella progettazione dell’applicazione, cercando opportunità per rimuovere duplicazioni e apportare piccoli miglioramenti raggiungendo la migliore progettazione possibile per ciò di cui il sistema ha bisogno oggi.
Integrazione continua: in XP, integri il tuo lavoro nel repository principale condiviso più volte al giorno, attivando una build automatica dell’intero sistema. L’integrazione quanto prima e spesso possibile riduce drasticamente il costo dell’integrazione in quanto rende meno probabile che si verifichino merge e conflitti logici. Espone anche problemi ambientali e di dipendenza.
Codice condiviso (proprietà collettiva): XP promuove il codice condiviso, o proprietà collettiva: ogni sviluppatore è responsabile di tutto il codice. Incoraggia lo scambio di informazioni, riduce il fattore bus del team e aumenta la qualità complessiva di ogni modulo se consideriamo il principio della diversità.
Single CodeBase: Single codebase è noto anche come “sviluppo basato su trunk”. Significa che esiste un’unica fonte di verità. Quindi, invece di sviluppare in isolamento per lunghi periodi di tempo, unisci i tuoi contributi al singolo flusso presto e frequentemente. I contrassegni delle funzionalità aiutano a limitare l’utilizzo delle funzionalità finché non sono completi.
Distribuzione giornaliera: la distribuzione in produzione almeno una volta al giorno è una logica conseguenza dell’integrazione continua:. In realtà, al giorno d’oggi, molti team vanno ancora oltre e praticano l’implementazione continua. Cioè, ogni volta che qualcuno si unisce alla linea principale, l’applicazione viene distribuita alla produzione.
Codice e test: questa pratica significa che il codice sorgente, inclusi i test, è l’unico artefatto permanente di un progetto software. Impegnarsi nella generazione di altri tipi di artefatti, inclusa la documentazione, è spesso uno spreco perché non genera valore effettivo per il cliente.
Se hai bisogno di altri artefatti o documenti, sforzati di generarli dal codice di produzione e dai test.
Analisi della causa principale: ogni volta che un difetto entra in produzione, non limitarti a correggere il difetto. Assicurati di capire cosa l’ha causato in primo luogo, perché tu e i tuoi compagni di squadra non siete riusciti a impedire lo slittamento. Quindi, prendi provvedimenti per assicurarti che non accada di nuovo.
Siediti insieme: in XP, i team preferiscono lavorare insieme in uno spazio aperto. Questa pratica favorisce la comunicazione e il senso di appartenenza a una squadra.
Tutto il team: tutti coloro che sono necessari per il successo del progetto fanno parte del team XP. Questo è altamente contestuale – diverso per ogni team – e dinamico, può cambiare all’interno di un team.
Spazi di lavoro informativi: uno spazio di lavoro informativo utilizza lo spazio fisico del team per visualizzare informazioni che consentono a chiunque di conoscere, a colpo d’occhio, lo stato di avanzamento del progetto. Il modo in cui ciò viene fatto può variare, da note fisiche e grafici a schermate che mostrano schede Kanban e dashboard da un software di gestione dei progetti.
Lavoro energizzato: in XP, lavori solo finché puoi svolgere un lavoro energico. L’orario di lavoro deve essere limitato a 40 a settimana, al massimo.
Analisi: scrivi i requisiti degli utenti in un formato noto come analisi utente. Una analisi utente ha un nome breve e descrittivo e anche una breve descrizione di ciò che deve essere implementato.
Slack: durante la pianificazione di un ciclo, aggiungi attività minori che il team può abbandonare in caso di necessità. Altre storie possono sempre essere aggiunte se il team consegna troppo.
Cicli (mensili e settimanali): lo sviluppo in XP avviene in due cicli principali: il ciclo settimanale e il ciclo mensile.
Riunioni, cicli, rilasci programmati: lo sviluppo in XP funziona in due cicli principali: il ciclo settimanale e il ciclo trimestrale. Inizialmente, Kent Beck ha raccomandato un ciclo di due settimane, ma lo ha cambiato nella seconda edizione del suo libro.
Ciclo settimanale: il ciclo settimanale è il “pulsato” di un progetto XP. Il ciclo inizia con un incontro in cui il cliente sceglie quali storie vuole realizzare durante la settimana. Inoltre, il team rivede il proprio lavoro, compresi i progressi della scorsa settimana, e pensa a come migliorare il proprio processo.
Ciclo mensile: ogni mese, il team riflette e identifica le opportunità di miglioramento nel proprio processo. Il cliente sceglie uno o più temi per quel mese, insieme alle analisi in questi temi.
Come iniziare a lavorare con extreme programming ?
Le abilità tecniche e le abitudini di XP possono essere difficili da imparare. Alcune delle pratiche possono sembrare estranee ai programmatori non abituati a loro.
Ercole Palmeri
Coveware by Veeam continuerà a fornire servizi di risposta agli incidenti di cyber-estorsione. Coveware offrirà funzionalità di forensics e remediation…
La manutenzione predittiva sta rivoluzionando il settore dell'oil & gas, con un approccio innovativo e proattivo alla gestione degli impianti.…
La CMA del Regno Unito ha lanciato un avvertimento circa il comportamento delle Big Tech sul mercato dell’intelligenza artificiale. La…
Il Decreto "Case Green", formulato dall'Unione Europea per potenziare l'efficienza energetica degli edifici, ha concluso il suo iter legislativo con…
