Gioco di pianificazione

XP planning affronta due domande chiave nello sviluppo del software: prevedere cosa sarà realizzato entro la data di scadenza e determinare cosa fare dopo. L’accento è posto sulla direzione del progetto – che è abbastanza semplice – piuttosto che sulla previsione esatta di ciò che sarà necessario e quanto tempo ci vorrà – che è piuttosto difficile., Ci sono due passaggi chiave di pianificazione in XP, affrontando queste due domande:

La pianificazione del rilascio è una pratica in cui il Cliente presenta le funzionalità desiderate ai programmatori e i programmatori stimano la loro difficoltà. Con le stime dei costi in mano, e con la conoscenza dell’importanza delle caratteristiche, il Cliente delinea un piano per il progetto. I piani di rilascio iniziali sono necessariamente imprecisi: né le priorità né le stime sono veramente solide, e fino a quando il team non inizierà a lavorare, non sapremo quanto velocemente andranno., Anche il primo piano di rilascio è abbastanza preciso per il processo decisionale, tuttavia, e team XP rivedere il piano di rilascio regolarmente.

La pianificazione dell’iterazione è la pratica in base alla quale alla squadra viene data una direzione ogni due settimane. I team XP costruiscono software in “iterazioni” di due settimane, fornendo software utile alla fine di ogni iterazione. Durante la pianificazione dell’iterazione, il Cliente presenta le funzionalità desiderate per le prossime due settimane. I programmatori li suddividono in attività e ne stimano il costo (con un livello di dettaglio più preciso rispetto alla pianificazione del rilascio)., In base alla quantità di lavoro svolto nell’iterazione precedente, il team si iscrive a ciò che verrà intrapreso nell’iterazione corrente.

Questi passaggi di pianificazione sono molto semplici, ma forniscono ottime informazioni e un eccellente controllo dello sterzo nelle mani del Cliente. Ogni due settimane, la quantità di progressi è interamente visibile. Non c’è “novanta per cento fatto” in XP: una storia caratteristica è stata completata, o non lo era., Questo focus sulla visibilità si traduce in un piccolo paradosso: da un lato, con tanta visibilità, il Cliente è in grado di annullare il progetto se il progresso non è sufficiente. D’altra parte, i progressi sono così visibili e la capacità di decidere cosa verrà fatto dopo è così completa, che i progetti XP tendono a fornire più di ciò che è necessario, con meno pressione e stress.

Test del cliente

Come parte della presentazione di ciascuna funzionalità desiderata, il Cliente XP definisce uno o più test di accettazione automatici per dimostrare che la funzionalità funziona., Il team costruisce questi test e li usa per dimostrare a se stessi e al cliente che la funzionalità è implementata correttamente. L’automazione è importante perché nella pressione del tempo, i test manuali vengono saltati. E ‘come spegnere le luci quando la notte diventa piu’ buia.

I migliori team XP trattano i loro test dei clienti allo stesso modo in cui fanno i test dei programmatori: una volta eseguito il test, il team continua a funzionare correttamente da allora in poi. Ciò significa che il sistema migliora solo, sempre dentellando in avanti, mai retrocedere.,

Piccole versioni

I team XP praticano piccole versioni in due modi importanti:

In primo luogo, il team rilascia software in esecuzione e testato, offrendo valore aziendale scelto dal Cliente, ogni iterazione. Il cliente può utilizzare questo software per qualsiasi scopo, se la valutazione o anche il rilascio agli utenti finali (altamente raccomandato). L’aspetto più importante è che il software è visibile, e dato al cliente, alla fine di ogni iterazione. Questo mantiene tutto aperto e tangibile.

In secondo luogo, i team XP rilasciano spesso anche agli utenti finali., I progetti Web XP rilasciano ogni giorno, i progetti in house mensilmente o più frequentemente. Anche i prodotti termoretraibili vengono spediti ogni trimestre.

Può sembrare impossibile creare buone versioni questo spesso, ma i team XP in tutto lo stanno facendo tutto il tempo. Vedi Integrazione continua per ulteriori informazioni e nota che queste versioni frequenti sono mantenute affidabili dall’ossessione di XP per i test, come descritto qui in Test dei clienti e sviluppo basato su test.

Design semplice

I team XP costruiscono software con un design semplice ma sempre adeguato., Iniziano in modo semplice e, attraverso i test dei programmatori e il miglioramento del design, lo mantengono in questo modo. Un team XP mantiene il design esattamente adatto per le funzionalità attuali del sistema. Non c’è movimento sprecato, e il software è sempre pronto per quello che è il prossimo.

Il design in XP non è una cosa una tantum, o una cosa up-front, è una cosa all-the-time. Ci sono fasi di progettazione nella pianificazione del rilascio e nella pianificazione dell’iterazione, inoltre i team si impegnano in sessioni di progettazione rapide e revisioni di progettazione attraverso il refactoring, attraverso il corso dell’intero progetto., In un processo incrementale e iterativo come la programmazione estrema, una buona progettazione è essenziale. Ecco perché c’è così tanta attenzione al design durante tutto il corso dell’intero sviluppo.

Coppia di programmazione

Tutto il software di produzione in XP è costruito da due programmatori, seduti fianco a fianco, alla stessa macchina. Questa pratica garantisce che tutto il codice di produzione sia esaminato da almeno un altro programmatore e si traduca in una migliore progettazione, test migliori e codice migliore.

Può sembrare inefficiente avere due programmatori che fanno “il lavoro di un programmatore”, ma è vero il contrario., La ricerca sulla programmazione delle coppie mostra che l’accoppiamento produce codice migliore all’incirca nello stesso periodo in cui i programmatori lavorano singolarmente. Proprio così: due teste sono davvero meglio di una!

Alcuni programmatori si oppongono ad accoppiare la programmazione senza mai provarla. Ci vuole un po ‘ di pratica per fare bene, ed è necessario farlo bene per un paio di settimane per vedere i risultati. Il novanta percento dei programmatori che imparano la programmazione a coppie lo preferisce, quindi lo consigliamo vivamente a tutti i team.

L’accoppiamento, oltre a fornire codice e test migliori, serve anche a comunicare le conoscenze in tutto il team., Come coppie interruttore, ognuno ottiene i benefici della conoscenza specializzata di tutti. I programmatori imparano, le loro abilità migliorano, diventano più preziosi per il team e per l’azienda. L’abbinamento, anche da solo al di fuori di XP, è una grande vittoria per tutti.

Test-Driven Development

Programmazione estrema è ossessionato con il feedback, e nello sviluppo del software, un buon feedback richiede un buon test. I migliori team XP praticano lo “sviluppo basato su test”, lavorando in cicli molto brevi di aggiunta di un test, quindi facendolo funzionare., Quasi senza sforzo, i team producono codice con quasi il 100 per cento di copertura di prova, che è un grande passo avanti nella maggior parte dei negozi. (Se i tuoi programmatori stanno già facendo test ancora più sofisticati, più potenza per te. Continuate così, può solo aiutare!)

Non è sufficiente scrivere test: devi eseguirli. Anche qui, la programmazione estrema è estrema. Questi “test del programmatore”, o” test unitari ” sono tutti raccolti insieme, e ogni volta che un programmatore rilascia qualsiasi codice nel repository (e le coppie in genere rilasciano due volte al giorno o più), ogni singolo test del programmatore deve essere eseguito correttamente., Al cento per cento, tutto il tempo! Ciò significa che i programmatori ottengono un feedback immediato su come stanno facendo. Inoltre, questi test forniscono un supporto inestimabile in quanto la progettazione del software è migliorata.

Miglioramento del design (Refactoring)

La programmazione estrema si concentra sulla fornitura di valore aziendale in ogni iterazione. Per realizzare questo nel corso dell’intero progetto, il software deve essere ben progettato. L’alternativa sarebbe quella di rallentare e, infine, rimanere bloccati., Quindi XP utilizza un processo di miglioramento continuo del design chiamato Refactoring, dal titolo del libro di Martin Fowler, ” Refactoring: Improving the Design of Existing Code”.

Il processo di refactoring si concentra sulla rimozione della duplicazione (un segno sicuro di scarsa progettazione) e sull’aumento della “coesione” del codice, mentre si abbassa il “coupling”. L’alta coesione e il basso accoppiamento sono stati riconosciuti come i tratti distintivi di un codice ben progettato da almeno trent’anni. Il risultato è che i team XP iniziano con un design buono e semplice e hanno sempre un design buono e semplice per il software., Questo permette loro di sostenere la loro velocità di sviluppo, e infatti generalmente aumentare la velocità come il progetto va avanti.

Il refactoring è, ovviamente, fortemente supportato da test completi per essere sicuri che man mano che il design si evolve, nulla è rotto. Pertanto i test del cliente e i test del programmatore sono un fattore critico di abilitazione. Le pratiche XP si supportano a vicenda: sono più forti insieme che separatamente.

Integrazione continua

I team di programmazione Extreme mantengono il sistema completamente integrato in ogni momento. Diciamo che le build giornaliere sono per i wimp: i team XP costruiscono più volte al giorno., (Un team XP di quaranta persone costruisce almeno otto o dieci volte al giorno!)

Il vantaggio di questa pratica può essere visto ripensando a progetti di cui potresti aver sentito parlare (o anche aver fatto parte) in cui il processo di compilazione era settimanale o meno frequentemente, e di solito portava a “integration hell”, dove tutto si rompeva e nessuno sapeva perché.

L’integrazione poco frequente porta a seri problemi su un progetto software., Prima di tutto, sebbene l’integrazione sia fondamentale per la spedizione di un buon codice di lavoro, il team non viene praticato e spesso viene delegato a persone che non hanno familiarità con l’intero sistema. In secondo luogo, il codice raramente integrato è spesso – direi di solito-codice buggy. I problemi si insinuano al momento dell’integrazione che non vengono rilevati da nessuno dei test che si svolgono su un sistema non integrato. In terzo luogo, il processo di integrazione debole porta a lunghi blocchi di codice., Il blocco del codice significa che si hanno lunghi periodi di tempo in cui i programmatori potrebbero lavorare su importanti funzionalità spedibili, ma che tali funzionalità devono essere trattenute. Questo indebolisce la vostra posizione nel mercato, o con gli utenti finali.

Proprietà collettiva del codice

In un progetto di programmazione estrema, qualsiasi coppia di programmatori può migliorare qualsiasi codice in qualsiasi momento. Ciò significa che tutto il codice ottiene il beneficio dell’attenzione di molte persone, che aumenta la qualità del codice e riduce i difetti., C’è anche un altro importante vantaggio: quando il codice è di proprietà di individui, le funzionalità richieste vengono spesso messe nel posto sbagliato, poiché un programmatore scopre che ha bisogno di una funzionalità da qualche parte nel codice che non possiede. Il proprietario è troppo occupato per farlo, quindi il programmatore inserisce la funzione nel proprio codice, dove non appartiene. Ciò porta a un codice brutto e difficile da mantenere, pieno di duplicazione e con una bassa (cattiva) coesione.

La proprietà collettiva potrebbe essere un problema se le persone lavorassero ciecamente sul codice che non capivano., XP evita questi problemi attraverso due tecniche chiave: il programmatore verifica gli errori di cattura e la programmazione a coppie significa che il modo migliore per lavorare su codice sconosciuto è quello di accoppiarsi con l’esperto. Oltre a garantire buone modifiche quando necessario, questa pratica diffonde la conoscenza in tutto il team.

Standard di codifica

I team XP seguono uno standard di codifica comune, in modo che tutto il codice nel sistema appaia come se fosse stato scritto da un singolo individuo molto competente., Le specifiche dello standard non sono importanti: ciò che è importante è che tutto il codice appaia familiare, a sostegno della proprietà collettiva.

Metafora

I team di programmazione estrema sviluppano una visione comune di come funziona il programma, che chiamiamo “metafora”. Al suo meglio, la metafora è una semplice descrizione evocativa di come funziona il programma, come “questo programma funziona come un alveare di api, andando a prendere il polline e riportandolo all’alveare” come descrizione di un sistema di recupero delle informazioni basato su agenti.

A volte non si presenta una metafora sufficientemente poetica., In ogni caso, con o senza immagini vivide, i team XP utilizzano un sistema comune di nomi per essere sicuri che tutti capiscano come funziona il sistema e dove cercare la funzionalità che stai cercando o trovare il posto giusto per inserire la funzionalità che stai per aggiungere.

Ritmo sostenibile

Team di programmazione estremi sono in esso per il lungo termine. Lavorano sodo e ad un ritmo che può essere sostenuto indefinitamente. Ciò significa che lavorano gli straordinari quando è efficace, e che normalmente lavorano in modo tale da massimizzare la produttività settimana dopo settimana., È abbastanza ben compreso in questi giorni che i progetti di death march non sono né produttivi né producono software di qualità. Le squadre XP sono in esso per vincere, non per morire.

Conclusione

La programmazione estrema è una disciplina di sviluppo software basata su valori di semplicità, comunicazione, feedback e coraggio. Funziona riunendo l’intero team in presenza di pratiche semplici, con un feedback sufficiente per consentire al team di vedere dove si trovano e di sintonizzare le pratiche sulla loro situazione unica.