Il crescente utilizzo del Web per il business assegna alla creazione di applicazioni un peso sostanziale nel panorama delle strategie aziendali. Per questo, necessita di metodologie di gestione ad hoc, come può essere quella teorizzata da Beck, che punta sulle coppie di sviluppatori.
Le aziende che investono nello sviluppo applicativo spendono molto in software e risorse umane, specie se i progetti di sviluppo hanno un responsabile e una o più figure intermedie di supporto. Spesso accade che sistemisti e programmatori terzi tengano riunioni di verifica dello stato di avanzamento dei progetti, per evitare che i problemi non rimangano sommersi o non vengano minimizzati per esplodere successivamente. Nonostante ciò, comunemente, nel mondo dello sviluppo software le scadenze sono difficili da rispettare. Anche se, sulla base della pianificazione prevista dal software di gestione progetti, tutto ciò non dovrebbe accadere. Allora è venuto il momento, forse, di ripensare al modo in cui si produce il software.
Proviamo a prendere in considerazione l’Extreme programming (Xp), metodologia di sviluppo software concepita inizialmente da Kent Beck negli anni 90. L’Xp è basato su alcuni semplici concetti che cerchiamo qui di riassumere:
• Mantenere il codice semplice, realizzando cicli di piccole dimensioni. Ciò, tra l’altro, riduce il tempo dedicato alla correzione dei bug, che talvolta risulta superiore a quello per le nuove funzionalità.
• Non perdere tempo nella stesura di pianificazioni immense e rassegnarsi a procedere con l’analisi anche in corso d’opera.
• Considerare la fase di testing come una componente fondamentale del progetto e non come un’attività opzionale.
• Lavorare a diretto contatto con clienti e utenti, trattandoli come se fossero parte del team di sviluppo.
• Estendere la conoscenza dell’intero progetto a tutti i programmatori, evitando che qualcuno divenga esperto solamente di una specifica porzione di codice.
• Non stancarsi mai di riscrivere e migliorare il codice.
• Lavorare "a coppie".
È evidente che si tratta di concetti di comune buon senso, alcuni dei quali erano già presenti nelle definizioni di "programmazione strutturata", risalenti agli anni 70. Da sempre molte organizzazioni tendono ad allinearsi ad essi, ma l’Xp ritiene che queste tendenze debbano essere spinte in forma "estrema", proprio come avviene in alcuni sport.
Bisogna tener presente che l’Xp può essere applicato a qualunque linguaggio di programmazione, ma va adottato solo all’inizio di un ciclo di sviluppo, non a progetto avviato. Un aspetto importante da sottolineare è che l’Xp non si limita a modificare il modo in cui lavorano gli sviluppatori, ma interviene sulle tecniche di pianificazione.
Cambiare il planning
Molti progetti falliscono per una cattiva gestione, altri per insufficienti capacità di realizzazione del software e altri ancora perché fin dall’inizio erano stati concepiti in modo errato. I seguaci dell’Xp ritengono che se un progetto è destinato a fallire è meglio scoprirlo al più presto, prima di sprecare tempo e denaro. Anziché stendere un modello generale "completo", cioè una serie di specifiche definite a priori in base alle quali i programmatori creeranno poi, dopo mesi di lavoro, l’applicazione vera e propria, le tecniche di Xp prevedono di scrivere codice in piccole iterazioni e di rilasciarlo non appena ne sia disponibile una porzione, anche piccola ma sufficientemente funzionante. I progetti dovrebbero quindi essere sviluppati secondo cicli che durano al massimo due o tre settimane.
Resta da vedere come questi rilasci continui siano vissuti dagli utenti finali, i quali solitamente non desiderano che le loro applicazioni si presentino e operino in modo differente ogni volta che le usano, e non amano ricevere frequentemente tante piccole release.
Un’altra idea di base dell’Xp è di mantenere la massima flessibilità nel processo di sviluppo.
Qualcuno potrebbe osservare che se lo sviluppo si discosta troppo dalle specifiche iniziali il progetto sta comunque seguendo una direzione errata, ma secondo l’Xp le applicazioni raramente si presentano nello stesso modo in cui erano state concepite inizialmente e quando ciò accade significa che si è rinunciato alla flessibilità che si sarebbe potuta avere.
Programmazione in coppia
Possiamo forse comprendere meglio l’applicabilità dell’Xp se analizziamo come si attua in pratica un progetto di programmazione in coppia. All’inizio del progetto, i programmatori sono disposti a coppie, ciascuna delle quali inizia a scrivere codice che risponda alle specifiche del lavoro che le è stato assegnato. Una regola consiste nell’accoppiare sempre un programmatore di buone capacità con uno meno esperto: il secondo è il "guidatore", che scrive sulla tastiera, mentre il primo è il "navigatore", che fornisce consigli e controlla l’andamento del lavoro. Quindi il guidatore è responsabile di ciò che riguarda i dettagli della codifica, come la correttezza sintattica, mentre il navigatore è responsabile dell’impostazione della logica dell’intero progetto e deve rilevare gli errori commessi dal guidatore.
L’adozione del modello di pair programming non significa che due sviluppatori debbano stare insieme per tutta la durata del progetto. Due persone possono essere unite per creare un singolo modulo o una particolare funzione, per poi essere sganciate e destinate a compiti differenti. Anche i ruoli possono essere flessibili, per cui il guidatore può passare, in un’altra coppia, a svolgere il ruolo di navigatore, e viceversa. Se, nel corso dello sviluppo, i due programmatori rilevano delle difficoltà che ritengono per loro insormontabili, possono richiedere l’intervento di altre risorse che aiutino a risolvere il problema. In genere uno dei due sarà assegnato a un compito diverso, mentre l’altro rimarrà per spiegare la situazione al nuovo componente della coppia.
Scrivere un programma software è un’attività che sembra concepita per essere realizzata da soli, ma anche in questo caso le teorie di programmazione estrema rompono uno schema consolidato: la programmazione in coppia costituisce l’aspetto più controverso dell’approccio Xp. Secondo questo metodo, ogni porzione di progetto software va realizzata ponendo due programmatori davanti allo stesso computer, con l’obiettivo di ridurre le probabilità di generare codice di cattiva qualità e di rinsaldare al tempo stesso lo spirito di collaborazione nel gruppo di sviluppo.
In effetti può sembrare poco comprensibile che due programmatori lavorando insieme possano produrre la stessa quantità di codice che produrrebbero lavorando singolarmente, ma secondo la teoria dell’Xp il fatto che un numero più alto di programmatori conosca il codice compensa la maggiore durata dei cicli di sviluppo. Inoltre, si riduce il rischio che l’azienda rimanga ostaggio di un programmatore il quale, essendo l’unico a conoscere il funzionamento di una certa porzione di codice, può decidere di mettere in crisi l’intero progetto.
In ogni caso vanno sottolineate un paio di considerazioni. Quattro occhi vedono meglio di due: nessun dubbio sulla qualità del codice risultante. Riguardo alla quantità, se ne potrebbe pronosticare un crollo rispetto a quella prodotta nel caso di lavoro individuale, a causa delle frequenti interruzioni dovute a discussioni tra i due programmatori. Ciò non corrisponde alla realtà. Un esperimento condotto all’Università dello Utah ha visto coinvolti 42 studenti, a cui è stato affidato lo stesso compito, svolto individualmente da 14 di loro, mentre i restanti 28 lo hanno svolto in coppia. Inizialmente, questi ultimi hanno impiegato il 60% in più di tempo, calcolato complessivamente (cioè se un programmatore da solo avesse impiegato 10 ore, una coppia di programmatori ne avrebbe impiegate 8). L’esperimento è stato ripetuto, con le stesse persone, altre due volte e si è arrivati a solamente il 10% in più di tempo impiegato (nell’esempio numerico precedente, la coppia avrebbe impiegato appena 5 ore e mezza). Inoltre, il codice scritto individualmente conteneva il 15% in più di bug.
È indubbio che il metodo della programmazione in coppia presenti tuttavia alcuni limiti non indifferenti: molte persone di talento e dotate di creatività preferiscono lavorare da sole, secondo uno stile proprio, mentre l’Xp non lascia spazio a metodi di lavoro personali. Inoltre, chi abbia provato ad assumere programmatori sa quanto sia difficile reperire persone di adeguata professionalità, che conoscano gli ambienti di sviluppo utilizzati per la realizzazione del progetto e che abbiano una conoscenza della problematica applicativa sufficiente da consentire loro di comprendere le specifiche di analisi. Se a questa lista di requisiti tecnici si aggiungono anche quelli di carattere più generale, come la correttezza nei rapporti umani, il rispetto degli impegni e dei tempi e, infine, la disponibilità ad accettare una retribuzione compatibile con i budget, risulta chiaro quanto sia difficile trovare una persona adatta a ogni porzione di progetto.
Una delle idee dell’Extreme programming che possono trovare parzialmente d’accordo anche chi non ne approva la teoria generale riguarda il cosiddetto refactoring, un concetto che fa riferimento ad alcune tecniche rivolte a identificare e migliorare il codice di cattiva qualità, rimuovere quello non necessario e mantenere il massimo livello di semplicità possibile. Alcuni si spingono fino a ritenere che il codice dovrebbe essere rigenerato al punto da raggiungere un livello di semplicità tale da rendere inutili i commenti nei sorgenti.
Gratificazioni e contrasti
I sostenitori della programmazione a coppie ritengono che questo metodo sia positivo per tutti gli sviluppatori: il principiante può imparare meglio, grazie al contatto e alla guida di una persona più esperta, la quale, invece, può trascurare i dettagli della programmazione e avere più tempo per dedicarsi a questioni di carattere più generale. Esaminata da questo punto di vista la novità non è più tale, visto che la costituzione di coppie composte da un analista e da un programmatore junior è sempre stata una pratica diffusa. Qualcuno ritiene che questo approccio sia alla lunga più economico: migliorando la qualità del software, si dovrà spendere meno nelle fasi di debug. Altri, più ottimisti, si spingono fino a ipotizzare che il lavoro in coppia sia anche più gratificante per i programmatori, i quali quindi sarebbero meno inclini ad abbandonare l’azienda. I più pessimisti osservano invece che per il lavoro in coppia non si deve sottovalutare come i conflitti personali, legati a differenti culture e approcci, ma anche ad aspetti più banali, come l’orario di lavoro o la retribuzione, possano acuirsi notevolmente quando due persone sono costrette a lavorare insieme.
Allo stato attuale rimane da vedere se la programmazione estrema, e in particolare quella a coppie, avrà successo o si rivelerà una teorie destinata a essere utilizzata in situazioni particolari. Un merito che, comunque, va ascritto all’approccio Xp riguarda il riconoscimento che lo sviluppo software è diverso da ogni altro tipo di progetto aziendale da necessitare di una propria metodologia di gestione.
