1 La programmazione estrema.

Questa pagina è un riassunto (più o, meno approssimato) del libro 'Programmazione Estrema - introduzione' di Kent Beck (Addison Wesley ISBN 88-7192-088-0).

1.1 La metafora e i quattro valori

La programmazione estrema (XP) è una disciplina di programmazione, cioè una 'filosofia' di come progettare, programmare e lavorare alla costruzione di sistemi software. L'esigenza che si vuole soddisfare è quella di scrivere rapidamente, programmi di qualità, con requisiti variabili anche con frequenza. L'idea dell'autore è che applicando la XP ai progetti software, il costo del cambiamento nel tempo, non ha un andamento esponenziale (come vorrebbe la teoria classica dell'ingegneria del software), ma un andamento asintotico ad un asintoto orizzontale, quindi il costo del cambiamento tende a diventare costante con l'andare del tempo.

La metafora utilizzata è quella di un'auto su un'autostrada americana, lunghissima e drittissima. Per arrivare, non si mirerà un punto all'orizzonte bloccando il volante con quell'angolo, ma si faranno piccoli aggiustamenti lungo tutto il percorso per tenere una direzione rettilinea.  Secondo l'autore la disciplina classica dell'ingegneria del software cerca di arrivare a destinazione puntando una direzione all'orizzonte, per questo non può avere successo se non in casi particolari.

Attorno alla metafora sono costituiti quattro valori:

• Comunicazione,
• Semplicità,
• Feed back,
• Coraggio.

1.1.1 Comunicazione.

Questo è un valore primario dal momento che qualsiasi problema possa affliggere un progetto, questo è sempre riconducibile ad un problema di comunicazione: qualcuno non ha detto qualcosa quando avrebbe dovuto, qualcuno ha detto qualcosa troppo tardi, qualcuno non ha ascoltato qualcun altro.

1.1.2 Semplicità.

Le cose semplici sono le più facili: da capire, da correggere, da modificare, da scrivere. L'XP tende a fare la cosa più semplice che possa funzionare. In questo senso l'XP fa una scommessa: è meglio scrivere la cosa più semplice oggi (cioè che soddisfi strettamente i requisiti di oggi), che non una cosa più complessa che possa soddisfare le esigenze di domani. Infatti è probabile che i requisiti cambino e quindi, meglio una cosa semplice da modificare invece che aver perso tempo a fare cose inutili.

1.1.3 Feed back.

Il feed back è inteso come riscontro del proprio codice. Da questo valore discende la necessità di scrivere molti test automatici, persino scrivendo i test prima del codice, in modo da avere piena fiducia nel codice. Una volta che il proprio programma superi i test, allora funziona e può essere integrato. Ogni volta che si modifica qualcosa si rieseguono i test per essere sempre sicuri di avere una base di codice corretto.

1.1.4 Coraggio.

Questo valore serve per far funzionare il tutto, si applica in generale alle scelte, cioè a scegliere in maniera obiettiva, quale sia la soluzione migliore per il progetto, senza basarsi sull'emotività. Se si scopre che l'architettura sta crescendo male, meglio buttare e rifare quello che non va bene.

1.2 I Principi.

Dai valori si possono derivare alcuni principi guida:

• Feed back rapido = i test automatici.
  
• Presumere la semplicità = ogni problema ha una soluzione semplice.
  
• Modifica incrementale = tutti i problemi sono risolti con cambiamenti piccoli, ma significativi.
  
• Accettare il cambiamento = lasciare aperte più strade risolvendo il problema più pressante
  
• Lavoro di qualità = è più divertente
  

Altri principi:

• insegnare ad apprendere.
  
• piccolo investimento iniziale.
  
• giocare per vincere.
  
• esperimenti concreti.
  
• comunicazione aperta e onesta.
  
• assecondare gli istinti della gente, non contrariarli.
  
• accettare la responsabilità.
  
• adattamento locale.
  
• viaggiare leggeri.
  
• misurazione onesta.
  
  

  1.3 Le attività basilari.

  1.3.1 Scrivere il codice.

  Questa è l'attività per antonomasia del programmatore. L'XP è centrata sul programmatore. Alla fine della giornata deve esserci un programma, quindi è necessario scrivere codice. Nel codice c'è tutto quello che ci serve per capire e modificare il sorgente stesso. Scrivere codice è imparare, insegnare, trasmettere informazioni.
  

  Il codice sorgente è l'unica parte veramente necessaria per un programma, deve essere usato per quante più finalità dell'ingengeria del software siano possibili.
  
  

  1.3.2 Testing.

  Se non può essere misurato non esiste. Quanto è buono il codice che abbiamo scritto? I test dell'XP sono funzionali e di unità. I test funzionali sono scritti da (o con l'aiuto) di un utente del sistema, mentre i test di unità sono scritti dai programmatori quando implementano le unità stesse. Il test può controllare non solo i risultati, ma anche le prestazioni e l'aderenza del codice allo standard. Il test non è un lavoro finito, quando si modifica il sorgente (e capita spesso), si deve modificare anche il test.
  
  

  1.3.3 Ascoltare.

  Ascoltare è porsi in rapporto con il cliente/utente. Durante l'ascolto aiutiamo il cliente a capire cosa è facile e cosa è difficile, quindi è un ascolto attivo. Le regole da utilizzare devono incoraggiare la comunicazione, ma scoraggiare la comunicazione inutile, devono individuare il giusto numero di dettagli da comunicare.
  
  

  1.3.4 Progettare.

  In XP la progettazione è quotidiana e avviene durante la scrittura del codice, mira alla costruzione di un sistema logico, scarta o modifica soluzioni non efficaci.
  
  

  1.4 Le pratiche.

  Ed eccoci infine al succo, cosa vuol dire tutto quanto scritto sopra in pratica?
  
  

  1.4.1 Planning Game

  Nell'XP il planning non è qualcosa di scolpito nella pietra, ma un continuo dialogo tra le parti per determinare cosa sia possibile e cosa desiderabile.
  
  

  Il planning game è appunto un gioco tra le parti:
  

  • I manager decidono su: portata del progetto, priorità, composizione dei rilasci, date dei rilasci.
    
  • I programmatori decidono su: stime, conseguenze tecniche delle decisioni strategiche, organizzazione del lavoro e del gruppo (processo), planning dettagliato (cioè all'interno del rilascio)
    
  
  

  1.4.2 Brevi cicli di rilascio

  I rilasci avvengono di frequente. Il rilascio deve avere un senso compiuto, cioè le funzionalità implementate devono essere complete. Le prime funzionalità implementate saranno quelle di maggior valore.
  
  

  1.4.3 Metafora

  Ogni progetto XP è guidato da una sola metafora. La metafora serve per dare i nomi alle cose e per poter comunicare sinteticamente. A volte la metafora è semplice (es. gestione dei contratti), altre volte necessita di qualche spiegazione (ad esempio la scrivania).
  
  

  1.4.4 Semplicità di progetto

  Il progetto XP ideale è quello che in ogni istante, fa funzionare tutti i test, non ha logiche duplicate, è comprensibile, ha il minor numero possibile di classi e metodi.

  
  

  1.4.5 Testing

  Ciò che non è testato non esiste. La finalità del test di unità è la fiducia del programmatore nel programma. La finalità del test funzionale è la fiducia dell'utente nel sistema.

  
  

  Non è necessario un test estensivo, ma solo delle operazioni più critiche (cioè quelle che possono fallire).

  
  

  1.4.6 Refactoring

  Il refactoring è un'attività continua, che serve per aumentare la coerenza logica del sistema, evitare le duplicazioni e scartare le funzionalità inutili.

  
  

  1.4.7 Programmazione a coppie

  Tutto il codice XP deve essere scritto a coppie, con un solo computer, una sola tastiera e mouse. L'ufficio deve essere strutturato in modo che questo sia possibile in modo semplice.

  
  

  Nella coppia i ruoli sono differenti: chi scrive pensa alla maniera migliore di implementare la funzionalità, chi guarda pensa a come si colloca quello che si sta scrivendo nel contesto generale.

  Le coppie devono cambiare, in questo modo la conoscenza del sistema si diffonde a tutti.

  
  

  1.4.8 Proprietà collettiva

  Chiunque può modificare il codice scritto da chiunque se vede un modo di migliorare il codice o se ha necessità di modificare le funzionalità. La suite di test impedisce di introdurre degli errori, e l'adozione di standard di codifica comuni facilita la coesione del codice.

  
  

  1.4.9 Integrazione continua

  Un'altra attività svolta con continuità è l'integrazione. Il codice una volta scritto e sottoposto ai test, viene integrato. L'idea è quella di avere una macchina dedicata all'integrazione, in questo modo il codice viene integrato sequenzialmente.

  
  

  1.4.10 Settimana di 40 ore.

  L'XP richiede un lavoro di qualità e questo lavoro non è possibile quando i programmatori sono stanchi. Non è possibile fare straordinarie per più di due settimane di seguito.

  
  

  1.4.11 Cliente sul posto

  Per poter fare le cose giuste e risolvere effettivamente i veri problemi del cliente è necessario che ci sia un utente finale dell'applicazione sul posto. Questo può essere costoso, ma a) probabilmente l'utente non sarà richiesto al 100% del tempo e quindi potrà svolgere il suo lavoro, b) nel costo complessivo del progetto, il costo di un utente, probabilmente può rientrare, soprattutto se commisurato al costo di un eventuale fallimento.

  
  

  1.4.12 Standard di codifica

  Lo standard è necessario perchè il codice appartiene a tutto il gruppo e non al singolo. Dovrebbe essere impossibile dire che ha scritto un certo codice. Lo standard deve richiedere uno sforzo minimo, evitare le duplicazioni, favorire la comunicazione ed essere adottato volontariamente dal gruppo.

  
  
  
  

  1.5 Gestione del progetto

  Viste le pratiche vediamo ora come è gestito un progetto XP. Innanzitutto sono molto importanti le metriche, cioè le misurazioni. In particolare le misurazioni dei tempi stimati e dei tempi effettivi. Questi rapporti sono utili per aggiustare le stime future e capire come sta funzionando il lavoro di squadra.
  

  Le misure vengono evidenziate con un bel diagramma appeso al muro (invece che tramite una serie di e-mail). Il diagramma è aggiornato una volta alla settimana dal manager. Il diagramma serve per comunicare su quali aspetti sia necessario lavorare e per questo le misurazioni mostrate possono essere differenti (non più di 3/4 contemporanee).

  Il coach è una sorta di architetto o capo progetto informatico: infatti si occupa dell'esecuzione tecnica e dell'evoluzione del progetto. Il suo compito non è tanto quello di prendere delle giuste decisioni tecniche, ma di farle prendere agli altri. Il coach deve essere un buon comunicatore, tecnicamente ben preparato e non deve lasciarsi prendere troppo facilmente dal panico. Il coach non svolge direttamente task di sviluppo, ma è disponibile a far 'coppia' soprattutto con i programmatori nuovi o per i compiti più difficili. Ha la visione degli obiettivi di refactoring a lungo termine e incoraggia la ristrutturazione su piccola scala. Aiuta i programmatori a migliorare le proprie capacità tecniche. Infine spiega il processo ai dirigenti.
  

  Il tracker è l'altro componente di rilievo del management XP. Il tracker raccoglie le misure e si assicura che il gruppo sia al corrente. Il tracker inoltre è l'animatore e moderatore del planning game. Questi compiti devono essere svolti con una burocrazia e un'intrusione minima: non più di un paio di volte alla settimana.
  
  

  1.6 Varie

  1.6.1 Sui diagrammi

  Secondo i principi dell'XP i diagrammi dovrebbero essere pochi e usati all'inizio, i diagrammi dovrebbero essere convertiti immediatamente in codice non più conservati.

  
  

  1.6.2 L'architettura

  L'architettura è per metà basata sulla metafora, e per l'altra metà viene costruita nel svolgersi del progetto, tramite il planning game. In ogni caso l'architettura riflette la programmazione, risolve il problema immediato.

  
  

  1.6.3 La documentazione

  Non esiste documentazione all'infuori del codice. Le informazioni sono condivise tra i programmatori e quindi la documentazione è sostanzialmente tramandata oralmente nel team. Dal momento che lo stato naturale di un progetto XP è quello della manutenzione, il gruppo si trova a evitare di aggiornare la documentazione.
  

  Alla morte del progetto (cioè fine dello sviluppo e della manutenzione), il coach può scrivere qualche pagina di documentazione, una serie di note che potrebbe essere comodo avere di li a qualche anno se si dovesse riprendere la manutenzione.
  
  

  1.6.4 Quando non usare l'XP

  Sostanzialmente quando non è possibile applicare i principi: cliente che non si presta, management che vuole fissare tutti i parametri dello sviluppo (portata, tempi, costi e qualità), ambiente non adatto e non modificabile, impossibilità di mettere in produzione software con potenziali difetti.
  
  

  1.6.5 Framework (librerie)

  L'XP non è applicabile a componenti di cui si vuole programmare in anticipo il riuso. È tuttavia possibile produrre un framework in due modi. Il primo è quello di estrarre il framework dal lavoro di gruppo una volta che il gruppo abbia acquisito esperienza a risolvere determinati tipi di problemi. Il secondo è avere un cliente che definisce i requisiti del framework e quindi si impegna ad usarlo e a collaudarlo.