Da sviluppatore vecchia scuola, iniziando l’attività negli anni ’90 dopo la laurea in Ingegneria Informatica, era abitudine seguire la metodologia RUP (Rational Unified Process), standard proposto unanimemente per migliorare l’intera attività di sviluppo software.
Sicuramente, il passare dalla modalità “di navigazione a vista” alla metodologia Rational era un grosso passo avanti, soprattutto lavorando in Siemens dove le risorse erano tante e si aveva il tempo di pianificare l’attività di progettazione del software.
La metodologia RUP, tuttavia, avrebbe cominciato a mostrare i sui limiti negli anni seguenti, quando, tra la fine degli anni ’90 e gli anni 2000, sono cominciate a mutare molte prospettive nel campo della progettazione delle applicazioni software, con uno spostamento del focus che vede sempre più il software come onnipresente e pervasivo.
Qualunque azienda ha cominciato ad introdurre i software per le proprie attività, a partire dai primi gestionali fino agli attuali CRM (Customer Relationship Management) ed ERP (Enterprise Resource Planning). E per quanto un osservatore esterno potrebbe ingenuamente ipotizzare che ogni frontiera sia ormai stata raggiunta e superata, proprio per la grande diffusione delle applicazioni è oggi tanto più necessario produrre personalizzazioni o porting, oltre alla normale manutenzione delle applicazioni esistenti.
Ebbene, con queste nuove necessità la metodologia RUP ha finito per risultare oggi sempre più “sovradimensionata“, più adatta alle grandi aziende e ai grandi progetti piuttosto che alle Pmi. Il cliente tipico della Pmi, infatti, ha bisogno del software per necessità: interessa poco che il prodotto finale integri una certa tecnologia o meno, l’importante è che sia solo facile da usare e che funzioni. In questo senso la metodologia RUP risulta pesante e proporzionata.
Da punto di vista degli sviluppatori potrebbe sembrare una lacuna non ricorrere all’ultima versione di un certo prodotto, addirittura denunciando tale mancanza al cliente stesso! Il punto chiave, però, è che azienda e piccolo imprenditore hanno una diversa ottica e soprattutto perseguono risultati differenti, con una logica costi-benefici chiara e inequivocabile.
Nel 2001, quindi, con la pubblicazione dell’Agile Manifesto inizierà quel movimento che viene oggi chiamato Movimento Agile e che tanto bene risponde alle rinnovate esigenze di sviluppo software per le piccole realtà d’impresa. In parole semplici, la metodologia agile sta allo sviluppo software come la metodologia del “Just in time” sta alla pianificazione industriale.
Ricordo ancora una delle prime, accese, discussioni dove difendevo il RUP e un collega me lo smontava pezzo per pezzo: sembrava assurdo all’epoca che potesse esserci un modo per sviluppare progetti in gruppo senza che si formalizzasse alcuno dei fondamenti del RUP. Un limite di chi aveva usato per oltre dieci anni i “vecchi metodi”.
L’Agile, in realtà, è indicato per i software da sviluppare per le Pmi proprio perchè fornisce immediati riscontri al cliente: si fa una proposta e ci si aggiorna entro una deadline per valutare la prima Alfa realizzata, spesso non coincidente con l’idea che il cliente aveva delle proprie necessità ma suscettibile di perfezionamenti in linea con le sue esigenze e indicazioni.
Con l’Agile si raccolgono i requisiti e si dividono in user stories – che possiamo vedere come un caso d’uso dei diagrammi UML – e ciascuna user story (task) verrà valutata con un certo numero di punti, rappresentanti le risorse (uomini e tempo) che un team dovrà produrre per portarla a termine.
Al project manager spetta il compito di dividere i requisiti in user stories, ma egli non riveste lo stesso ruolo e la stessa “importanza” che ha nel RUP, tanto che spesso nella metodologia Agile viene chiamato con altre nomenclature.
Un insieme di user story è qualcosa di tangibile per il cliente, che viene coinvolto spesso nella valutazione dell’avanzamento lavori e nell’importanza delle user story stesse.
Di solito, un gruppo di sviluppo Agile è diviso in un certo numero di team (in genere due persone a team). Alcuni usano anche il pair programming.
Ogni team valuta insieme al project manager l’assegnazione dei punti, e si valuta assieme il caso qualora vi sia larga divergenza di vedute tra i “punti” da assegnare ai task.
Quanti punti assegnare al giorno per ciascun team? La risposta è data da numerosi fattori: in genere, dopo la prima settimana, si calcola una “velocità” di ogni team.
Una altra domanda tipo: il team andrà piano all’inizio e alla fine, e veloce alla metà del progetto come nel RUP? No, se i team sono ben assortiti e sanno fare il loro lavoro la velocità dovrebbe essere più o meno costante.
La velocità costante è data dalla granularità della singola user story: nessuno può garantire che si starà perfettamente nei tempi, però si cerca di limitare i ritardi cronici tipici di alcune tecniche tradizionali.
Un limite de RUP è che il rilascio, spesso a mesi di distanza, poche volte si mantiene in linea con la deadline e in tale caso si rischia il sovraccarico di task per il rilascio successivo. Nell’Agile non avendo mai task che superano la settimana, si riesce a lavorare serenamente e in linea con le aspettative del cliente.
Nell’Agile, invece, per tenersi aggiornati basta lo “stand-up meeting“: riunione informale che si tiene la mattina alle 9 o la sera alle 18. La sua funzione principale è ricapitolare risultati raggiunti, punti svolti in giorno precedente ed eventuali difficoltà riscontrate dal team. Semplice…ed agile!
