Secondo Tecnest, azienda specializzata nella fornitura di soluzioni informatiche ed organizzative per la pianificazione, il controllo e la gestione dei processi di produzione e della supply chain, gestire un progetto software, sia che si tratti di nuove funzionalità e moduli standard, sia che si tratti di applicazioni sviluppate su richiesta di un cliente, è un’operazione che presenta diverse criticità per l’azienda che deve realizzarlo, ma anche per il cliente che deve utilizzarlo.
Tecnest ha individuato 4 criticità principali che si incontrano nella gestione di un progetto software.
Primo, l’incertezza dei requisiti. “Generalmente un progetto inizia sempre con una fase di definizione dei requisiti che il software dovrà avere in termini di funzionalità e servizi forniti. Il problema è che spesso è difficile capire cosa serve realmente in un software fino a quando non lo si vede realizzato: ci sono requisiti anche importanti che inizialmente sono espressi in modo poco chiaro e che soltanto in seguito, vedendoli implementati, si riescono a comprendere più compiutamente”, afferma Paolo Fontanot, product manager di Tecnest, responsabile delle evoluzioni applicative della suite software J-Flex di Tecnest.
Secondo, l’interpretazione sbagliata di un requisito. “Può capitare che un requisito sia formulato in modo poco chiaro o sia frainteso, quindi si rischia di sviluppare il progetto in una direzione che si rivelerà poi quella errata”, dice ancora Fontanot.
Un terzo problema è legato all’incertezza dei tempi: “Con le metodologie di progetto tradizionali, cosiddette “a cascata”, i tempi tra la raccolta dei requisiti e il rilascio dell’applicazione finale sono piuttosto lunghi. A questo si aggiunge il fatto che più giorni passano tra il briefing iniziale e il rilascio del software, più aumentano imprevisti e criticità. Può, infatti, accadere che le esigenze manifestate inizialmente cambino nel tempo, con la conseguenza di avere un prodotto finale che non è più in linea con le esigenze attuali. Ciò implica dover realizzare successivi sviluppi o modifiche al software prima di arrivare al risultato desiderato”, spiega Alessandro Bonanni, project manager & supply chain consultant di Tecnest.
La quarta criticità è legata a un coinvolgimento non continuativo del cliente o committente nelle diverse fasi: “Se chi commissiona il software viene coinvolto solo all’inizio e alla fine del progetto, è alto il rischio che il prodotto finale possa non soddisfare completamente le aspettative e che quindi sia necessario fare ulteriori modifiche e implementazioni, con conseguenze negative sui tempi e sui costi di progetto”, aggiunge Bonanni.
Per risolvere queste criticità, Tecnest ha messo a punto negli ultimi anni una sua metodologia agile che mette assieme diversi approcci teorici studiati e testati sul campo. “Siamo partiti nel 2012 con un progetto interno, denominato “Be Agile”, volto all’introduzione delle metodologie dell’Agile Software Development e dell’Agile Project Management attraverso corsi di formazione e collaborazioni con consulenti esperti nella tematica e con il mondo accademico, in particolare con le Università di Udine e Cagliari.– spiega Fontanot – La direzione ha inoltre voluto diffondere queste tematiche innovative anche all’esterno dell’azienda, promuovendo conferenze e seminari sull’argomento”. Aggiunge Bonanni: “Le metodologie agili permettono di superare le criticità tipiche della gestione di un progetto software in quanto si basano su una stretta comunicazione fra tutti gli attori del progetto, sul continuo coinvolgimento del cliente nelle diverse fasi e su rilasci frequenti di versioni intermedie del software, riducendo al minimo la documentazione necessaria. Il focus si sposta sull’accogliere e gestire il cambiamento piuttosto che seguire un piano prestabilito”. Nonostante i vantaggi di queste metodologie, implementare questi approcci in modo fedele alla teoria non si rivela altrettanto semplice nella realtà: “I membri del team di progetto possono essere allocati su più progetti e non essere sempre a stretto contatto, il cliente non ha sempre tempo da dedicare al progetto, e così via. Più risulta complessa l’organizzazione in cui si cerca di adottare queste metodologie e più si trovano difficoltà e ostacoli da affrontare”, dice ancora Bonanni.
Per questo motivo la metodologia messa a punto da Tecnest prende spunto da alcuni degli approcci più diffusi nel mondo dell’agile software development, ma va oltre: “Abbiamo provato a tradurre quello che si legge nei libri applicandolo alla realtà e mettendo assieme diverse metodologie in modo che si potenzino a vicenda – spiega Fontanot -. Ad esempio, abbiamo combinato l’utilizzo del metodo Kanban, che prevede la divisione del progetto in sottoparti, la gestione di rapide iterazioni (“sprint”) con un continuo coinvolgimento del cliente nelle diverse fasi, con lo User Story Mapping, metodo utile per raggruppare i requisiti creando delle vere e proprie storie all’interno delle quali sono definiti diversi scenari e i singoli casi d’uso. Si realizzano percorsi con diverse funzionalità e ad ogni iterazione si sviluppa una storia: si parte con una trama più snella, con pochi dettagli, che poi si arricchisce nei passaggi successivi”. Immaginando scenari diversi è possibile capire meglio i requisiti di cui si ha bisogno e far emergere anche nuove necessità che prima non erano chiare.
Gli strumenti utilizzati da Tecnest a supporto di questa metodologia sono un mix tra tradizionali e innovativi. «In alcune fasi del progetto facciamo uso di strumenti visuali come mappe mentali, tabelloni e post-it che vengono appesi ed esposti in ufficio con l’obiettivo di rendere la condivisione delle informazioni più immediata e intuitiva – prosegue Fontanot –. A seconda delle esigenze a questi sistemi visuali si affiancano anche strumenti elettronici sia tradizionali come fogli di calcolo, sistemi gestionali o database informatici, sia innovativi come soluzioni collaborative in ambiente cloud”.
I vantaggi del metodo sviluppato da Tecnest sono identificabili in termini di riduzione del rischio di progetto e di qualità del risultato finale: suddividendo il progetto in diversi sprint, il rischio di errori e imprevisti si riduce, mentre l’utilizzo delle storie permette di specificare i requisiti per step successivi e di ottenere feedback più precisi nelle diverse fasi grazie alla possibilità di avere una visione d’insieme.
Un metodo apprezzato anche dal cliente, che viene coinvolto direttamente nel progetto: “Coinvolgendo il cliente negli sprint di progetto, vengono condivisi obiettivi, risultati ma anche eventuali problematiche concrete che possono emergere in corso d’opera. In questo modo il cliente diventa di fatto parte del team e, come tale, ha interesse a ottenere il miglior risultato con il giusto impiego di risorse – spiega Bonanni –. Questo ha un effetto forte sulla qualità del lavoro e del prodotto software finale che risulta da subito aderente alle esigenze espresse, senza bisogno di ulteriori revisioni post-progetto”.
