Extreme Programming è una metodologia di sviluppo software progettata per migliorare la qualità del software e la sua capacità di adattarsi correttamente alle mutevoli esigenze del cliente o del cliente. Durante la metà e la fine degli anni Novanta, mentre lavorava al Chrysler Comprehensive Compensation System (C3) per aiutare a gestire il libro paga dell’azienda, l’ingegnere del software Ken Beck sviluppò per la prima volta la metodologia di programmazione estrema., Nel mese di ottobre 1999, ha pubblicato Extreme Programming Explained, dettagliando l’intero metodo per gli altri, e poco dopo il sito ufficiale è stato lanciato pure.

Simile ad altri metodi di sviluppo Agile, Extreme Programming mira a fornire piccole versioni iterative e frequenti in tutto il progetto, consentendo sia ai membri del team che ai clienti di esaminare e rivedere i progressi del progetto durante l’intero SDLC.,

In questo articolo, esamineremo esattamente cos’è la programmazione estrema e come funziona, dai valori e dai principi che sono alla base, alle regole e alle best practice procedurali utilizzate per implementare un nuovo progetto di programmazione Estrema, quindi iniziamo!,/td>

Rational Unified Process Big Bang Modello V Modello Concettuale Kaizen Modello Kanban Modello Modello a Spirale

i Valori Estremi

Questi cinque valori fondamentali che costituiscono la base su cui la totalità dell’Estrema paradigma di Programmazione integrata, permettendo alle persone coinvolte nel progetto a sentirsi fiduciosi nella direzione che il progetto sta prendendo e per capire il loro feedback personali e comprensione è necessario e benvenuto come chiunque altro.,

Semplicità: faremo ciò che è necessario e richiesto, ma non di più. Ciò massimizzerà il valore creato per l’investimento effettuato fino ad oggi. Prenderemo piccoli semplici passi verso il nostro obiettivo e mitigheremo i fallimenti man mano che accadono. Creeremo qualcosa di cui siamo orgogliosi e lo manterremo a lungo termine a costi ragionevoli.

Comunicazione: Ognuno fa parte del team e comunichiamo faccia a faccia ogni giorno. Lavoreremo insieme su tutto, dai requisiti al codice. Creeremo la migliore soluzione al nostro problema che possiamo insieme.,

Risposte: Prenderemo seriamente ogni impegno di iterazione consegnando il software di lavoro. Dimostriamo il nostro software in anticipo e spesso ascoltiamo attentamente e apportiamo le modifiche necessarie. Parleremo del progetto e adatteremo il nostro processo ad esso, non il contrario.

Rispetto: Ognuno dà e sente il rispetto che meritano come un membro del team di valore. Ognuno contribuisce valore anche se è semplicemente entusiasmo. Gli sviluppatori rispettano l’esperienza dei clienti e viceversa. La direzione rispetta il nostro diritto di accettare la responsabilità e ricevere autorità sul nostro lavoro.,

Coraggio: diremo la verità sui progressi e le stime. Non documentiamo scuse per il fallimento perché abbiamo intenzione di avere successo. Non temiamo nulla perché nessuno lavora mai da solo. Ci adatteremo ai cambiamenti quando mai accadono.

Extreme Rules

Inizialmente pubblicato da Don Wells nel 1999, il proprietario del sito web Extreme Programming, questo insieme di regole di programmazione estreme erano originariamente destinati a contribuire a contrastare le affermazioni che Extreme Programming non supporta alcune delle discipline di spicco necessarie per lo sviluppo moderno.,

Pianificazione

• Le storie degli utenti sono scritte.
• Pianificazione del rilascio crea la pianificazione del rilascio.
• Effettua frequenti rilasci di piccole dimensioni.
• Il progetto è diviso in iterazioni.
• La pianificazione dell’iterazione avvia ogni iterazione.

Gestire

• Dare al team uno spazio di lavoro aperto dedicato.
• Imposta un ritmo sostenibile.
• Una riunione stand up inizia ogni giorno.
• Viene misurata la velocità del progetto.
• Spostare le persone in giro.
• Fissare programmazione estrema quando si rompe.

Progettazione

• Semplicità.,
• Scegli una metafora di sistema.
• Utilizzare le schede CRC per le sessioni di progettazione.
• Creare soluzioni spike per ridurre il rischio.
• Nessuna funzionalità viene aggiunta in anticipo.
• Refactoring quando e dove possibile.

Codifica

• Il cliente è sempre disponibile.
• Il codice deve essere scritto secondo gli standard concordati.
• Codificare prima il test unitario.
• Tutto il codice di produzione è coppia programmato.
• Solo una coppia integra il codice alla volta.
• Integrare spesso.
• Impostare un computer di integrazione dedicato.
• Utilizzare la proprietà collettiva.,

Test

• Tutto il codice deve avere test unitari.
• Tutto il codice deve superare tutti i test unitari prima di poter essere rilasciato.
• Quando viene trovato un bug vengono creati dei test.
• I test di accettazione vengono eseguiti spesso e il punteggio viene pubblicato.

Extreme Practices

Create utilizzando quelle che all’epoca erano considerate le migliori pratiche di sviluppo software, queste dodici Extreme Programming Best Practice descrivono in dettaglio le procedure specifiche che dovrebbero essere seguite quando si implementa un progetto utilizzando Extreme Programming.,

Fine-scale feedback

Pair programming

In sostanza, pair programming significa che due persone lavorano in tandem sullo stesso sistema durante lo sviluppo di qualsiasi codice di produzione. Ruotando frequentemente i partner in tutto il team, Extreme Programming promuove una migliore comunicazione e team-building.

Gioco di pianificazione

Spesso questo prende la forma di una riunione ad un intervallo frequente e ben definito (ogni una o due settimane), dove si svolge la maggior parte della pianificazione per il progetto.,

All’interno di questa procedura esiste la fase di pianificazione del rilascio, in cui vengono effettuate le determinazioni relative a ciò che è necessario per i rilasci imminenti. Le sezioni della pianificazione del rilascio includono:

• Fase di esplorazione: le carte storia vengono utilizzate per dettagliare i requisiti più preziosi dei clienti.
• Fase di impegno: la pianificazione e gli impegni del team sono fatti per soddisfare le esigenze della prossima versione del programma e farlo uscire in tempo.,
• Fase di sterzo: ciò consente di adeguare i piani precedentemente sviluppati in base alle esigenze in evoluzione del progetto, in modo simile a molte altre metodologie di modello Agile.

Dopo la pianificazione del rilascio è anche la sezione Iteration Planning, che consiste delle stesse tre sotto-fasi proprie, ma con varianti sulle loro implementazioni:

• Exploration Phase: Tutti i requisiti del progetto sono scritti.
• Fase di impegno: le attività necessarie ancora da completare per soddisfare la prossima versione di iterazione sono assegnate agli sviluppatori e pianificate in modo appropriato.,
• Fase di sterzata: lo sviluppo avviene e, al termine, l’iterazione risultante viene confrontata con le story card delineate create all’inizio della procedura di pianificazione.

Test-driven development

Mentre un intero articolo potrebbe essere scritto sullo sviluppo test-driven, il concetto è abbastanza noto tra gli sviluppatori e significa efficacemente che i test vengono generati per ogni esigenza del progetto, e solo allora viene sviluppato il codice che supererà con successo quei test.,

Intero team

Come con molti altri metodi e pratiche SDLC, Extreme Programming promuove l’inclusione di clienti e clienti durante l’intero processo, utilizzando il loro feedback per aiutare a modellare il progetto in ogni momento.

Processo continuo

Integrazione continua

Un’altra pratica comune nello sviluppo moderno, l’idea alla base dell’integrazione continua è che tutto il codice sviluppato in tutto il team viene unito in un unico repository comune molte volte al giorno., Ciò garantisce che eventuali problemi di integrazione nell’intero progetto vengano notati e affrontati il prima possibile.

Refactoring del codice

Un’altra pratica molto comune, l’idea alla base del refactoring del codice è semplicemente quella di migliorare e ridisegnare la struttura del codice già esistente, senza modificarne il comportamento fondamentale. Semplici esempi di refactoring includono la correzione impropria di nomi variabili o metodi e la riduzione del codice ripetuto fino a un singolo metodo o funzione.,

Piccole versioni

Molto in linea con le pratiche del modello iterativo, questo concetto assicura che il progetto sarà caratterizzato da iterate, piccole versioni su base frequente, consentendo al cliente così come tutti i membri del team, per ottenere un senso di come il progetto si sta sviluppando.

Comprensione condivisa

Standard di codifica

Lo standard di codifica è semplicemente un insieme di best practice all’interno del codice stesso, come la formattazione e lo stile, che l’intero team rispetta per tutto il ciclo di vita del progetto., Ciò promuove una migliore comprensione e leggibilità del codice non solo per i membri attuali, ma anche per i futuri sviluppatori.

Proprietà collettiva del codice

Questa pratica consente a qualsiasi sviluppatore del team di modificare qualsiasi sezione del codice, se necessario. Anche se questa pratica può sembrare pericolosa per alcuni, accelera i tempi di sviluppo e qualsiasi potenziale problema può essere risolto con un test unitario adeguato.

Design semplice

C’è poco motivo di complicare le cose ogni volta che è disponibile un’opzione più semplice., Questa pratica di base di mantenere tutti i componenti e il codice il più semplice possibile assicura che l’intero team stia sempre valutando se le cose potrebbero essere fatte in modo più semplice.

System metaphor

Miglior pensiero come parte degli standard di codifica, la metafora del sistema è l’idea che ogni persona del team dovrebbe essere in grado di guardare il codice di alto livello che viene sviluppato e avere una chiara comprensione di quale funzionalità quel codice sta eseguendo.,

Programmer welfare

Sustainable pace

Un concetto chiave per un migliore equilibrio vita-lavoro con gli sviluppatori su un progetto di programmazione estrema è l’idea che nessuno dovrebbe essere richiesto di lavorare in eccesso rispetto alla normale settimana lavorativa programmata. Gli straordinari sono disapprovati, così come il concetto di “crunch time”, in cui gli sviluppatori dovrebbero lavorare ore estreme vicino alla fine di una versione per completare tutto in tempo.