Quali sono le attuali metodologie per lo sviluppo di software personalizzato? Oppure, in altre parole: cosa ci si deve aspettare nel momento in cui si rivolge a una società di sviluppo software per vedere soddisfatte le proprie richieste? Questa è una domanda tutt’altro che scontata, e per molti motivi differenti. Va sottolineato prima di tutto che esistono diverse metodologie per lo sviluppo di software, che possono portare a conseguenze diverse per il cliente. Ci sono infatti delle metodologie giudicate ormai universalmente – o quasi – più efficaci, le quali portano quindi tendenzialmente allo sviluppo di soluzioni migliori, le quali però, come vedremo, richiedono un impegno non trascurabile da parte del cliente. E ci sono altre metodologie, che in molti etichettano come superate, che richiedono una partecipazione nettamente minore da parte del cliente, a fronte però di risultati non ugualmente garantiti. Partendo da questo presupposto, cercheremo di spiegare quali sono le metodologie per lo sviluppo di software personalizzato che seguiamo in Saidea, ipotizzando inoltre due tipi di progetti, un più piccolo e uno più grande

Perché e quando richiedere lo sviluppo di un software personalizzato?

Prima di vedere quali sono le migliori metodologie per lo sviluppo software, vale la pena scoprire velocemente in quali casi le aziende dovrebbero richiedere la creazione di soluzioni ad hoc. Abbiamo già affrontato questo tema in modo esaustivo in un post dedicato per l’appunto allo sviluppo di software custom: qui ci limiteremo a ricordare che, ad oggi, le richieste di sviluppo da zero di software personalizzati sono piuttosto rare. Questo perché, semplicemente, il mercato offre un’ampia gamma di gestionali e programmi già pronti, una gamma tale da rendere poco conveniente lo sviluppo di soluzioni nativamente personalizzate. Quando si parla di software custom, nella maggior parte dei casi, si fa dunque riferimento a delle integrazioni a livello di backend o a livello di frontend per rendere maggiormente efficienti delle piattaforme già esistenti, oppure a software personalizzati creati appositamente per rendere fruibili dei nuovi hardware.

Metodologie: dal metodo a cascata...

A partire dai presupposti visti sopra, si capisce che solo l’azienda che ha delle esigenze specifiche – che non possono essere soddisfatte dalle soluzioni pronte e presenti sul mercato – richiede lo sviluppo di software custom. Questo ci porta a un’altra considerazione: le necessità di questa azienda saranno in buona parte peculiari, non comuni. Si capisce quindi che la prima e fondamentale difficoltà di chi sviluppa software e gestionali personalizzati è proprio quella di capire quali sono le reali necessità, problematiche e particolarità del cliente.

Ecco dunque che la prima preoccupazione è quella di comprendere di cosa ha bisogno il cliente. Ed è proprio da qui che parte la metodologia classica per lo sviluppo di software, la famosa waterfall, dove tutti i passaggi si susseguono per l’appunto a cascata: prima l’incontro con il cliente, poi l’analisi preliminare, poi il lavoro di sviluppo in base ai requisiti predefiniti, infine, il test, seguito dalla consegna del software. Facile, no? Semplice, per il cliente come per lo sviluppatore, che affronta per settimane o mesi il processo di analisi e, una volta ricevuta l’approvazione del cliente, si tuffa per altre settimane o mesi nello sviluppo.

...allo sviluppo agile di software personalizzato

Abbiamo visto la metodologia classica, a cascata, dominante negli anni negli anni Novanta e fino a pochi anni fa. Il problema però è che nel mondo attuale, e sempre di più, il progresso a livello informatico e in più generale tecnologico è velocissimo. L’analisi preliminare effettuata una settimana prima, iperbolicamente, è già vecchia la settimana dopo: un software sviluppato sulla base di quanto scritto due, tre o più mesi fa, da questo punto di vista, non può che risultare in buona parte obsoleto ancor prima di essere consegnato al cliente. Ma non è tutto qui, in quanto va considerata la possibilità che il cliente si dimentichi di trasmettere delle informazioni importanti prima della fase di analisi preliminare. Questo può accadere per i più diversi motivi: per una dimenticanza, per una disattenzione, per il subentro di nuove problematiche, nonché per il semplice fatto che all’inizio di un progetto non è per nulla facile, per il cliente, sapere perfettamente cosa dovrà fare il software una volta ultimato. Sviluppare un software secondo i prerequisiti fissati, dunque, non equivale e sviluppare il migliore dei software possibili.

Le variabili in gioco sono quindi tante, troppe, tali da non permettere più un approccio a cascata, caratterizzato dal rischio di ritrovarsi con ore e ore di analisi e di sviluppo da cestinare. Per questo motivo, sull’onda di quanto fatto dalle aziende statunitensi a partire dagli anni Duemila, in Saidea abbiamo adottato la metodologia di sviluppo agile.

L’obiettivo, con la metodologia di sviluppo agile, non è più quello di soddisfare i prerequisiti: la meta è invece la piena soddisfazione dei bisogni del cliente. Lasciata alle spalle la marcia forzata e a oltranza della metodologia cascata, si procede invece con lo sviluppo di piccole parti del progetto in poco tempo, di volta in volta. Quando un nuovo pezzo di software è stato sviluppato, viene consegnato al cliente, per avere un test sul campo: il cliente è quindi chiamato in gioco spesso, per la prova di pezzi di software non completi (ma funzionanti) avendo così la certezza di avere alla fine dei lavori un software custom perfetto, che soddisfi davvero ogni requisito – anche quello che all’inizio non era stato espresso.

La distinzione tra progetto piccolo e grande

Abbiamo visto che, nello scenario attuale, la metodologia agile rappresenta senza dubbio il migliore approccio per lo sviluppo di software. Per questo in Saidea ci atteniamo fermamente a questi principi, facendo però un passo ulteriore, che ci porta a dividere i progetti di due gruppi: da una parte ci sono i progetti piccoli (che potrebbero richiedere per esempio un mese di lavoro), dall’altra ci sono i progetti grandi (i quali possono arrivare a un anno o più di lavoro).

In entrambi i casi il confronto tra sviluppatori e azienda cliente deve essere continuo, ed è per questo motivo basilare individuare un referente interno all’azienda. Non parliamo di un tecnico, né di una persona con particolari competenze informatiche: l’importante è che il referente conosca perfettamente le necessità dell’azienda, che abbia potere decisionale per poter far avanzare il progetto senza ostacoli e che sia disposto a seguire regolarmente i lavori.

A partire dalla definizione della figura del referente, si capisce che nei progetti più piccoli, e dunque più brevi, in cui il rapporto è continuo e diretto tra sviluppatore e referente, l’agilità dello sviluppo è ancora maggiore, con la possibilità di definire le scadenze in base alle necessità dell’uno e dell’altro.

Nei progetti più grandi, pur partendo da un approccio agile, si rende necessaria invece una programmazione di massima, con il bisogno cioè di definire per esempio le scadenze per i vari rilasci di software: si potrebbe per esempio decidere a monte la consegna di una nuova release ogni 4 settimane (pur con la possibilità di accorciare o di allungare gli intervalli tra una consegna e l’altra in base alle esigenze degli attori in gioco e alle particolarità delle singole attività di sviluppo). Il progetto più corposo, più lungo, resta comunque agile e dinamico, pur con una programmazione maggiore rispetto al progetto più breve.

La tua azienda ha bisogno di un software personalizzato, di un’integrazione o di una personalizzazione del gestionale? Per soddisfare le tue richieste seguiremo la metodologia agile così come esposta in questa pagina, per avere la certezza di sviluppare la soluzione più efficace per la tua organizzazione.

Desideri ricevere degli aggiornamenti sulle novità e sulle best practice del mondo IT? Iscriviti adesso alla nostra newsletter: condivideremo con te pochi ma preziosi contenuti per la tua azienda!