Che cos’è la programmazione estrema? Una panoramica delle regole e dei valori di XP

Nel 1990, l’ascesa di Internet ha reso necessario un cambiamento nello sviluppo del software. Se il successo di un’azienda dipendeva dalla velocità con cui l’azienda poteva crescere e portare i prodotti sul mercato, le aziende dovevano ridurre drasticamente il ciclo di vita dello sviluppo del software.,

È in questo ambiente che Kent Beck ha creato Extreme programming (XP), una metodologia di gestione del progetto agile che supporta rilasci frequenti in brevi cicli di sviluppo per migliorare la qualità del software e consentire agli sviluppatori di rispondere alle mutevoli esigenze dei clienti.

Sebbene sia possibile riconoscere alcune di queste pratiche e valori da altre metodologie di gestione del progetto, XP porta queste pratiche a livelli “estremi”, come suggerisce il nome della metodologia., In un’intervista con Informit, Kent spiega:

“La prima volta che mi è stato chiesto di guidare una squadra, ho chiesto loro di fare un po’ delle cose che pensavo fossero sensate, come test e recensioni. La seconda volta c’era molto di più sulla linea. Ho asked chiesto alla squadra di alzare tutte le manopole a 10 sulle cose che pensavo fossero essenziali e lasciare fuori tutto il resto.”

Se tu e il tuo team avete bisogno di rilasciare rapidamente e rispondere alle richieste dei clienti, date un’occhiata ai valori e alle regole della programmazione estrema—potrebbe essere una misura perfetta.,

i Valori di estrema metodologia di programmazione

XP è più di una serie di operazioni per la gestione dei progetti, segue una serie di valori che aiuterà il vostro team di lavorare più velocemente e collaborare in modo più efficace.

Semplicità

I team realizzano ciò che è stato chiesto e nient’altro. XP suddivide ogni fase di un processo importante in obiettivi più piccoli e raggiungibili per i membri del team.,

Comunicazione semplificata

I team lavorano insieme in ogni parte del progetto, dalla raccolta dei requisiti all’implementazione del codice, e partecipano alle riunioni standup giornaliere per mantenere aggiornati tutti i membri del team. Eventuali dubbi o problemi sono affrontati immediatamente.

Feedback coerente e costruttivo

In XP, i team adattano il loro processo alle esigenze del progetto e del cliente, non il contrario. Il team dovrebbe dimostrare il proprio software presto e spesso in modo che possano raccogliere feedback dal cliente e apportare le modifiche necessarie.,

Rispetto

La programmazione estrema incoraggia una mentalità “tutto per uno e uno per tutti”. Ogni persona del team, indipendentemente dalla gerarchia, è rispettata per i loro contributi. Il team rispetta le opinioni dei clienti e viceversa.

Coraggio

I membri del team si adattano ai cambiamenti man mano che si presentano e si assumono la responsabilità del loro lavoro. Dicono la verità sui loro progressi—non ci sono “bugie bianche” o scuse per non far sentire meglio le persone. Non c’è motivo di temere perché nessuno lavora mai da solo.,

Rules of extreme programming methodology

Don Wells ha pubblicato le prime regole XP nel 1999 per contrastare le affermazioni secondo cui extreme programming non supporta le attività necessarie allo sviluppo del software, come la pianificazione, la gestione e la progettazione. Dalla pianificazione al test del software, segui questi passaggi di base per ogni iterazione.

Progettazione

Questa fase è dove il USSO magia accade., Invece di un lungo documento sui requisiti, il cliente scrive storie utente, che definiscono la funzionalità che il cliente vorrebbe vedere, insieme al valore aziendale e alla priorità di ciascuna di queste funzionalità. Le storie degli utenti non devono essere esaustive o eccessivamente tecniche: devono solo fornire dettagli sufficienti per aiutare il team a determinare quanto tempo ci vorrà per implementare tali funzionalità.

Con Lucidchart, i clienti possono creare un diagramma di flusso di base e facilmente registrare e condividere la funzionalità desiderata.,

Da lì, il team crea un programma di rilascio e divide il progetto in iterazioni (da una a tre settimane). I project manager potrebbero voler creare una timeline o un diagramma di Gantt semplificato per condividere la pianificazione con il team.

Gestione

In questa fase, il project manager imposterà il team per avere successo in questa metodologia. Tutti hanno bisogno di lavorare in modo collaborativo ed efficace comunicare per evitare eventuali slipups. Questa fase comporta:

• Creazione di uno spazio di lavoro aperto per il tuo team
• Impostazione di un ritmo sostenibile (ad es., determinare la lunghezza giusta per iterazioni)
• Programmazione giornaliera standup meeting
• Misura la velocità dei progetti (la quantità di lavoro fatto sul progetto)
• la Riassegnazione di lavoro per evitare colli di bottiglia o perdita di conoscenze
• Cambiare le regole se XP non funziona perfettamente per il team

Progettazione

Questa regola va al valore della semplicità: Iniziare con il disegno più semplice, perché ci vorrà meno tempo rispetto alla soluzione complessa. Non aggiungere funzionalità in anticipo. Refactoring spesso per mantenere il codice pulito e conciso., Crea soluzioni spike per esplorare soluzioni a potenziali problemi prima che mettano il tuo team alle spalle.

Kent Beck e Ward Cunningham hanno anche creato schede CRC (Class-Responsibility-Collaboration) da utilizzare come parte della metodologia XP. Queste schede consentono all’intero team di progetto di progettare il sistema e vedere come gli oggetti interagiscono. Se vuoi provare questo strumento di brainstorming per te, inizia con il nostro modello Lucidchart.,

Coding

Poi arriva finalmente il momento di implementare il codice. XP pratica la proprietà collettiva del codice: tutti rivedono il codice e qualsiasi sviluppatore può aggiungere funzionalità, correggere bug o refactoring. Affinché la proprietà collettiva del codice funzioni, il team deve:

• Scegliere una metafora di sistema (schema di denominazione standardizzato).
• Pratica paio di programmazione., 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.
• Integrare e commettere codice nel repository ogni poche ore.

Il cliente dovrebbe essere disponibile, preferibilmente in loco, durante l’intero processo in modo da poter rispondere alle domande e stabilire i requisiti.

Testing

Il team esegue unit test e corregge bug prima che il codice possa essere rilasciato. Eseguono anche test di accettazione frequentemente.,

Quando usare extreme programming

Ancora incerto se XP si adatta alle esigenze del tuo team, anche dopo aver letto le sue regole e valori? La programmazione estrema può funzionare bene per i team che:

• Si aspettano che la funzionalità del loro sistema cambi ogni pochi mesi.
• Sperimenta requisiti in continua evoluzione o lavora con clienti che non sono sicuri di cosa vogliono che il sistema faccia.
• Vuole mitigare il rischio del progetto, soprattutto in caso di scadenze ravvicinate.
• Includere un piccolo numero di programmatori (tra 2 e 12 è preferibile).
• 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 tuo team, la programmazione estrema potrebbe valere la pena provare. Poiché questo modello altamente adattabile richiede un feedback continuo da parte dei clienti, anticipa gli errori lungo la strada e richiede agli sviluppatori di lavorare insieme, XP non solo garantisce un rilascio di prodotti sanitari, ma ha anche migliorato involontariamente la produttività per i team di sviluppo di tutto il mondo.,

Se decidi di utilizzare XP, prova a documentare visivamente le storie degli utenti, i programmi di rilascio, le schede CRC e la documentazione di sistema in Lucidchart. Iscriviti per il tuo account gratuito oggi.

---