Fonte immagine: pixabay.com

Programmazione estrema

Immagina questo: un progetto di sviluppo software per un nuovo prodotto, basato sul vantaggio del primo mercato, è appena stato individuato sul radar della tua azienda. I metodi tradizionali di programmazione estrema, in cui il cliente sa "esattamente" cosa vogliono, sono fuori. Il tuo team è piccolo e composto da giovani professionisti che probabilmente risponderanno bene a un modello di gestione del progetto radicale. Quali sono le tue opzioni?

Probabilmente dirai, Agile Project Management, ovviamente! Ma quale metodologia ti piacerebbe usare? Esistono diverse opzioni: ad esempio, c'è lo Scrum estremamente popolare: ciò comporta la creazione di brevi "sprint" basati sul portafoglio di attività dei clienti. E poi c'è Kanban, che lavora sull'ottimizzazione della pipeline di lavoro. C'è anche Extreme Programming, spesso abbreviato in XP, che si concentra sull'amplificazione degli aspetti positivi dei modelli di programmazione tradizionali in modo che funzionino al massimo delle loro potenzialità.

La programmazione estrema è una metodologia estremamente popolare (anche se non così popolare come Scrum) incentrata sulla soddisfazione delle mutevoli esigenze dei clienti. Il primo progetto Extreme Programming è stato avviato nel marzo 1996, da Kent Beck a Chrysler. Nel suo libro del 1999, Extreme Programming Explained: Embrace Change, ha dettagliato gli aspetti per lo sviluppo del software.

Kent Beck è stato anche il pioniere dello sviluppo guidato dai test, che ha messo i test dei casi d'uso sul radar come un miglioramento rispetto al modo in cui sono state fatte le cose: scrivere righe e righe di codice e quindi testarlo. È stato anche uno dei firmatari originali del Manifesto Agile, contribuendo a modellare il manifesto per cambiare il modo in cui è stato scritto il software di programmazione estrema.

I cinque valori di Extreme Programming basati su Explained siamo:

Comunicazione

La programmazione estrema non dipende da un'ampia documentazione. È un dato di fatto, la documentazione di programmazione estrema è suggerita solo quando necessario. Quindi la metodologia si basa fortemente sulla comunicazione tra i membri del team e anche con gli utenti.

Semplicità

Questo è al centro della programmazione estrema. La metodologia favorisce i progetti semplici, non pensando troppo al futuro, ma focalizzandosi sui requisiti di oggi, rendendo il programma stesso abbastanza robusto da aggiungere i requisiti che il futuro solleverà.

Risposta

Questo ciclo essenziale di andare avanti e indietro differenzia i sistemi Agile in generale e la Programmazione estrema in particolare, da altre metodologie di gestione dei progetti software. Il feedback continuo può funzionare in diversi modi, ma tutti lavorano per rendere il sistema più forte e più affidabile.

Il feedback può avere diversi gusti:

  • Dal programma stesso: il codice viene testato con forza durante tutto il ciclo di sviluppo del progetto, in modo che gli sviluppatori possano implementare le modifiche.
  • Dal client: questa è una parte essenziale della maggior parte dei sistemi Agile. I clienti scrivono i test di accettazione su cui si basa lo sviluppo e questo costituisce la spina dorsale del processo di sviluppo. Tutte le iterazioni vengono inoltre consegnate al client, per un feedback periodico.
  • Dal team: una volta creato un nuovo caso d'uso / storia, il team ritorna immediatamente con i costi e la stima della sequenza temporale, rafforzando i requisiti man mano che si presentano. Nella programmazione estrema, nessuno "possiede" alcun codice e quindi, all'interno dei team di programmazione estrema, viene incoraggiato il feedback sul codice dell'altro.

Coraggio

Questo potrebbe sembrare uno strano valore nella programmazione estrema per lo sviluppo di software, più adatto a qualcosa come l'Esercito o i Marines! Tuttavia, pensaci: i progetti software sono stati a lungo impantanati dai tradizionali metodi di gestione estrema della programmazione; sicuro nel comfort di un'ampia documentazione e gerarchia che non consente l'innovazione. Questo valore esemplifica il nucleo della programmazione estrema: sii pronto a saltare, senza paracadute se si tratta di questo! Guarda questo diverso stile di gestione del progetto, e sii pronto ad essere responsabile, a rinunciare alla gerarchia, ad essere responsabile e lavorare senza sapere tutto all'inizio stesso.

Rispetto

Il rispetto, il quinto valore, è stato aggiunto in seguito e significa rispetto per gli altri e il sé. Implica anche il rispetto per il codice che viene scritto e per le aspettative e le esigenze del cliente. Questo valore è alla base anche della comunicazione tra le diverse parti interessate.

Attività di un progetto di programmazione estrema

Extreme Programming distingue quattro semplici attività di un progetto. Loro sono:

  • Coding : Extreme Programming considera questa l'attività più importante. "Senza codice, non c'è nulla", afferma Kent Beck, fondatore di Extreme Programming.
  • Test : il codice è proprio questo se non testato. Extreme Programming è ossessivo riguardo ai test, utilizzando i test unitari per confermare che il codice funziona e i test di accettazione generati dal cliente per confermare che il codice sta testando ciò che deve essere testato.
  • Ascolto: l' ascolto, esemplificato dal valore fondamentale della comunicazione, è un'attività che richiede agli sviluppatori non solo di ascoltare i clienti, ma di ascoltare realmente ciò che vogliono. Lo sviluppo e il business sono due cose diverse e spesso gli sviluppatori non riescono a capire il caso aziendale di una decisione particolare. Le esigenze del cliente, così come quelle degli sviluppatori, costituiscono la base dell'attività di "ascolto".
  • Progettazione : potrebbe sorprendere il fatto che in un progetto di sviluppo software, l'attività di progettazione, spesso così importante e primaria, venga posta alla fine. Questo perché Extreme Programming vuole deliberatamente far uscire le persone dalla mentalità di "progettazione e sviluppo" che l'industria ha coltivato per molti anni. Non è per limitare l'importanza della progettazione. Piuttosto, un design buono e minimale è uno dei tratti distintivi di un progetto.

Dai valori e dalle attività emergono i 12 principi della programmazione estrema, come ideato dal suo fondatore, nel suo libro, Extreme Programming Explained.

  • Gioco di pianificazione
  • Coppia di programmazione
  • Test Driven Development
  • Intera squadra
  • Integrazione continua
  • Miglioramento del design
  • Piccoli rilasci
  • Standard di codifica
  • Proprietà del codice collettivo
  • Design semplice
  • Metafora del sistema
  • Ritmo sostenibile

Alcune di queste pratiche di programmazione estreme, tutte associate alle migliori pratiche di ingegneria del software, sono diverse dalle metodologie Agile generiche. Alcune delle pratiche di programmazione estrema sono spiegate di seguito:

  1. Gioco di pianificazione

Questa è la parte di pianificazione del progetto, indicata come "Gioco di pianificazione". Include la pianificazione per la prossima iterazione e rilascio, in consultazione con l'utente / client, nonché una pianificazione interna dei team, in merito alle attività su cui lavoreranno.

  1. Coppia di programmazione

Ciò comporta due persone che lavorano su un pezzo di codice. Una persona, chiamata tastiera, digita il codice mentre l'altra, chiamato monitor, supervisiona il codice, commentandolo e perfezionandolo, in caso di necessità. Le due persone spesso scambiano i loro ruoli. Ciò ha dimostrato di migliorare significativamente l'efficienza del codice. Questo potrebbe non essere adatto a tutti gli scenari di sviluppo ed è qualcosa da considerare prima di iscriversi a Extreme Programming.

  1. Sviluppo guidato dai test

Tutto il codice che viene scritto viene rivisto a livello di unità, ovvero ogni pezzo di codice che può fare qualcosa viene prima testato. La programmazione estrema pone molta enfasi sui test. Ciò aiuta a confermare che il codice funziona e che può quindi essere considerato per l'inclusione nel progetto di programmazione estrema stesso. È analogo ai test unitari a scuola: piccole informazioni testate, in modo che l'insegnante / studente possa apportare correzioni ai corsi e non dimenarsi durante gli esami annuali!

  1. Miglioramento del design (refactoring)

I progetti XP, basati sulla sua caratteristica di semplicità, mirano a migliorare continuamente il codice scritto. Ciò significa che l'intero codice (e talvolta anche il database) viene sempre migliorato. Il refactoring non aggiunge alcuna funzionalità; migliora semplicemente il codice esistente. Lo rende più stretto e più chiaro. È simile a modificare un pezzo di scrittura, lucidandolo e migliorandolo.

  1. Design semplice

Nella programmazione estrema, le funzionalità non vengono aggiunte fino a quando non sono specificamente richieste. Anche se il codice su cui si sta attualmente lavorando è molto simile a quello che potrebbe essere richiesto in futuro, non viene utilizzato a meno che non venga concordato come user story.

  1. Metafora del sistema

Ciò include la standardizzazione di tutte le convenzioni di denominazione in modo che il suo scopo e la sua funzione siano facilmente decifrati. Ad esempio, le operazioni o possono aiutare qualsiasi programmatore a comprendere la propria funzionalità. Questo dovrebbe essere fatto attraverso l'intero progetto di programmazione estrema, in modo che sia facile per chiunque guardare il codice e modificarlo o migliorarlo, a seconda dei casi.

Ruoli all'interno di un progetto di programmazione estrema:

Come Scrum, Extreme Programming ha alcuni ruoli designati all'interno di ciascun progetto. Ora, i ruoli non devono sempre essere interpretati da persone distinte e una persona può assumere più di un ruolo.

I ruoli di Extreme Programming sono:

  • 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 viene fuori dal cliente
    • Crea attività di programmazione dalle storie
    • Implementa le storie degli utenti
    • Verifica il codice per unità
  • Allenatore : l'allenatore generalmente assicura che il progetto sia sulla buona strada e salta anche per aiutare quando richiesto.
  • 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 il Coach o organizzare un incontro con il cliente, a seconda delle necessità.
  • Tester : esegue test funzionali. Il tester non esegue test unitari, che sono eseguiti dagli stessi programmatori.
  • Doomsayer: Questo, come suggerisce il nome, è simile al Black Hat nel sistema di pensiero di gruppo di Edward De Bono. Chiunque potrebbe essere un Doomsayer, che in genere segnala potenziali problemi e aiuta a mantenere i problemi nella prospettiva corretta.
  • Manager : il manager in un progetto di programmazione estrema è più simile a uno scheduler, garantendo che le riunioni si svolgano come pianificato e assicurando che le decisioni prese durante le riunioni vengano passate alla persona appropriata, il più delle volte, il Tracker. Il gestore, tuttavia, non dice alle persone cosa fare e quando farlo. Questo viene fatto dal cliente e / o dalle storie degli utenti stessi.
  • Proprietario dell'oro : Il proprietario dell'oro è la persona che finanzia il progetto. Questo potrebbe essere il cliente, ma non necessariamente.

Alcuni dei ruoli di programmazione estrema, come descritto sopra, 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.

I ruoli di programmazione estrema sono definiti in modo abbastanza chiaro da non creare confusione e creati per la massima flessibilità ed efficienza.

Svantaggi della programmazione estrema:

Mentre i sostenitori della programmazione estrema dipingono un quadro roseo, il fatto è che la programmazione estrema, come suggerisce probabilmente il nome, è estremamente difficile da implementare. Le sfaccettature della programmazione estrema possono essere incorporate nei progetti con maggiore successo rispetto all'adozione completa di XP.

Alcuni degli aspetti negativi della programmazione estrema sono:

  • La programmazione estrema si rivela più efficace nei gruppi più piccoli . La sua efficienza nei gruppi più grandi è contestata e un'opzione migliore è quella di dividere i team di programmazione estremi in modo che i gruppi siano più piccoli.
  • Una delle caratteristiche chiave di Extreme Programming, la programmazione a coppie non funziona bene in molti casi . La codifica complessa potrebbe richiedere due teste, ma non tutte le attività potrebbero richiedere due persone, con la seconda persona a peso morto. In effetti, la programmazione di coppia, se uno dei membri non è sincronizzato con l'altro, è uno dei motivi principali per cui la programmazione estrema fallisce in molti casi.
  • La dipendenza dal cliente, al punto da suggerire una risorsa in loco dal lato del cliente, può essere profondamente snervante. Può anche portare a interferenze, sia reali che immaginate, durante lo sviluppo.
  • L'attenzione di Extreme Programming alla semplicità può rendere molto difficile l'aggiunta al progetto attuale, il che significa un budget più elevato anche per semplici modifiche, che non rimangono più semplici.
  • La struttura gerarchica piatta significa che il team dovrebbe essere sempre concentrato, e in assenza di un manager per mettere a confronto tipi di persone divergenti, un team di programmazione estrema dipende interamente dalla maturità emotiva di tutti i membri del team, un fattore che non è sempre affidabile .

Anche con questi fattori, Extreme Programming rimane uno strumento potente da utilizzare per il progetto giusto, con le aziende che segnalano un aumento della loro efficienza dopo aver adottato il processo di programmazione estrema. Un sistema guidato dallo sviluppatore al contrario di Scrum, che è più di un sistema guidato dal processo, Extreme Programming, o almeno parti di esso, può portare a una rivoluzione nel modo in cui sviluppiamo software di programmazione estrema.

Categoria:

Sviluppo dell'imprenditorialità