Storia di un rilascio

di Riccardo Golia, in Ricky,

E' un po' di tempo che non scrivo nel mio blog. Questo è dovuto principalmente al fatto che ultimamente ho avuto molto da fare (e ne avrò fino a fine anno) con un progetto per un grosso cliente (una multinazionale nel ramo farmaceutico). L'obiettivo del mio lavoro è stato quello di creare i presupposti architetturali per un'applicazione enterprise, che, basandosi su un'interfaccia smart-client e integrandosi con il contesto dei servizi aziendali, fornisse supporto alle operazioni di pianificazione e conduzione delle sperimentazioni di laboratorio.

In questo progetto il mio ruolo è stato, manco a dirlo, quello dell'architetto. Ho coordinato un team di 5 persone sugli aspetti tecnici legati allo sviluppo dell'applicazione e sono stato affiancato da due persone dell'azienda, di cui una era il capo progetto e l'altra era il referente tecnico interno (che mi succederà all'inizio del nuovo anno).

Il team di sviluppo, come detto, è composto da 5 ragazzi, ciascuno proveniente da esperienze molto diverse tra loro, chi ex-developer java, chi ex-sviluppatore python, chi proveniente dal C++ e da VB6, chi developer web con ASP e ASP.NET, chi ex-programmatore in ambiente Dynamics. Insomma, all'inizio del progetto, nessuno era un espertone di applicazioni enterprise in ambito .NET, in particolar modo utilizzando .NET Framework 2.0/3.0 e interfaccia smart-client. Questo avrebbe potuto rappresentare un problema, non lo nego, ma a distanza di tempo posso dire che non è stato così.

Per il progetto, iniziato nel lontano mese di luglio, in fase di start-up furono fissate una serie di date per i rilasci intermedi dell'applicazione. Il primo rilascio (Prototipo 1) era previsto per il 30 novembre scorso, ovvero venerdì scorso. Che dire? Ce l'abbiamo fatta, ma è stata dura!

Il progetto è partito un po' in sordina, i requirement non erano chiari e non si riusciva a far decollare le attività di sviluppo. Questo periodo di incertezza si è protratto però per molto, troppo tempo, dal momento che gli analisti americani non riuscivano a fornire informazioni che non variassero nell'arco delle 24 ore. Come team abbiamo trascorso questo tempo definendo gli standard da adottare nello sviluppo, le pratiche operative e la suddivisione dei compiti, preparando l'ambiente di sviluppo e di debug, nonchè approfondendo alcuni aspetti tecnici tramite lo sviluppo di mini prototipi funzionali e facendo formazione tecnica.

Il risultato è stato che a fine ottobre non avevamo ancora una soluzione su cui lavorare e la prima scadenza si stava avvicinando inesorabilmente. Finalmente, dopo una lunga attesa, nella prima settimana di novembre abbiamo avuto il via libera da parte degli analisti e abbiamo potuto cominciare a lavorare su un insieme di requirement sufficientemente stabile da permettere di definire una soluzione applicativa coerente. Inutile dire che, per come erano andate le cose, pochi avrebbero scommesso sul rilascio del primo prototipo entro la data prevista.

E invece il 30 novembre abbiamo rilasciato la versione 1.0.2.20. In venti giorni abbiamo creato una ventina di build, andando a soddisfare tutti i requisiti funzionali previsti per il primo rilascio. Non è stato facile coordinare le attività, ma personalmente sono riuscito a dare il giusto ritmo, affiancando nello sviluppo a turno ciascuno dei ragazzi del team. Ad oggi abbiamo una soluzione che si compone di più di 600 tipi, considerando anche le classi di unit testing. Da parte mia non mi sono limitato a coordinare, ma ho partecipato attivamente allo sviluppo, realizzando tra l'altro un mini service bus basato su WCF (un layer di integrazione out-of-process) per interoperare coi servizi aziendali del cliente.

Sono molto soddisfatto del lavoro svolto e molto orgoglioso dei ragazzi. Il team ha retto bene, anche perchè so di essere una persona molto esigente. Devo dire però che, rispetto al passato, ho imparato ad accettare le imperfezioni nel codice, adattandomi alla situazione e lasciando un po' più di libertà agli sviluppatori di "sbagliare" e di non seguire ciecamente i dettami architetturali. Proprio per questo, nel prossimo mese avremo da fare un po' di refactoring per consolidare il codice, ma già la versione attuale non è male, considerando le premesse e i tempi di sviluppo.

Ciascuno dei ragazzi ha dato il massimo, sono davvero soddisfatto del modo con cui hanno affrontato la situazione. In rigoroso ordine alfabetico, Alessandro, Lorenzo, Luca, Marco e Patrick si sono dati da fare come poche volte ho avuto modo di sperimentare. Se il progetto è stato rilasciato rispettando lo scheduling e contro ogni previsione, il merito è soprattutto loro... Del resto un architetto da solo è come un allenatore senza squadra: non vincerà mai una partita!

Questa esperienza mi ha insegnato molto, non è facile fare i progetti con persone non espertissime, ma non è impossibile. Anche se sulla carta le esperienze delle persone del team non erano delle migliori, la loro voglia di fare, di imparare e l'impegno hanno colmato il gap, ottenendo un risultato al di là delle aspettative. Come un capitano non può scegliersi i soldati per combattere le sue battaglie, così come architetto non sempre ho la possibilità di scegliermi gli sviluppatori con cui fare i progetti dei clienti. A mio avviso, questa è la vera difficoltà del mio lavoro, al di là degli aspetti tecnici.

A fine mese lascerò il progetto in mano al referente tecnico interno e il team dovrà provare a "camminare" da solo, senza di me. Il mio compito presso il cliente si è esaurito, ma non posso non dire che mi dispiace lasciare un gruppo così affiatato e agguerrito. Grazie ragazzi, siete stati grandi!

Commenti

Visualizza/aggiungi commenti

| Condividi su: Twitter, Facebook, LinkedIn

Per inserire un commento, devi avere un account.

Fai il login e torna a questa pagina, oppure registrati alla nostra community.

Nella stessa categoria
I più letti del mese