Il tabù della qualità nel software. Parte 1, il modello di gestione

Se sviluppi software, se la tua azienda sviluppa software o lo commissiona, saprai benissimo che predire la qualità di un software è davvero difficile.

Sì perché la qualità del software è un tabù. Nessuno ne parla o fornisce dati oggettivi, anche se molti sono in grado di capire se un software funziona bene oppure no. Mi spiego meglio, fare un buon prodotto software dipende da moltissime variabili e il più delle volte non è verificabile ai primi utilizzi.

Inoltre non dipende dal talento dello sviluppatore, o dal talento di alcuni sviluppatori di una squadra. Forse questo può essere vero in una fase di start up di una piccola impresa, ma raramente questo risultato è ripetibile quando il team di sviluppo comincia ad allargarsi.

Il risultato finale dello sviluppo è difficilmente quantificabile in maniera preventiva. A volte è difficile individuare il livello di qualità di un software anche durante i test.

Le dimensioni della qualità del software

Quindi quand’è che si capisce se un software e di qualità oppure no?

Innanzitutto la qualità di un software dipende principalmente da queste 6 caratteristiche.

• Funzionabilità
• Affidabilità
• Efficienza
• Usabilità
• Manutenibilità
• Portabilità

Ma svilupperemo questi concetti nel secondo video dedicato alle metriche del software.

Qui mi interessa invece un altro aspetto, quello dell’organizzazione che deve avere una software house per garantire i punti suddetti.

Qualità esterna e qualità interna

Nella maggior parte dei casi, la qualità di un software, non si può valutare neanche dopo le prime release. E cioè, a meno che non si manifestino problemi grossolani nella prima release si tende ad accettare il software come buono. Questo è quello che va sotto il nome solitamente di qualità esterna. Cioè la qualità percepita dal cliente.

E poi c’è la qualità interna, quella che viene invece percepita da chi ha sviluppato e deve manutenere il software. È da questo lato che solitamente si manifestano i problemi più critici e pesanti da risolvere. E si manifestano anche dopo molto tempo, quando il software ha già qualche anno di sviluppi, modifiche, aggiornamenti vari. Ogni singola modifica ulteriore, rallenta le prestazioni del software, ne rende quasi impossibile la manutenzione, allungando i tempi di risposta delle change request, i costi della manutenzione e via dicendo.

Insomma, un software fatto male, è una bomba ad orologeria per tutti: per il cliente che l’ha pagato e che non ha risolto il suo problema in maniera efficiente, per il produttore che deve rimetterci le mani in continuazione spendendo soldi e tempo all’infinito e poi anche per chi lo ha commissionato, perché ovviamente perde il cliente e la reputazione.

Ora, questo problema non ce l’ha tanto lo sviluppatore singolo, ma riguarda tutte le aziende che commissionano software oppure che lo producono. Sì perché non hanno quasi mai il controllo del prodotto finale, a parte i primi incontri di analisi.

Anche la micro azienda di sviluppo software può avere questo problema, magari sulle prime può sembrare di no, perché gli sviluppatori lavorano tutti a stretto contatto, ma ci sono delle cose (come ad esempio la mancanza di un semplicissimo standard di sviluppo condiviso) che rappresentano un grandissimo rischio per la qualità del prodotto finale.

Anche chi lavora nell’ambito delle certificazioni di qualità, non affronta quasi mai l’argomento della qualità del software. Prima di tutto perché sono in pochi a capirci davvero qualcosa. Gli specialisti di qualità software spesso non sono dei bravi consulenti di strategia. E viceversa.

Ma per fortuna ci sono almeno un paio di strategie che possono ridurre e prevenire i rischi di un software fatto male.

Quindi quali sono le prime due strategie che un produttore di software deve almeno prendere in considerazione per assicurarsi di non perdere soldi, tempo e reputazione?

La prima strategia: il modello di gestione interno

la prima è sicuramente dotarsi di un modello di gestione interno. Uno strumento organizzativo, un sistema, che lo aiuti a far sì che ogni punto critico della sua delivery sia presidiato da un controllo o da dalle prassi. Si, mi riferisco a delle procedure, scritte e condivise (leggi qui il metodo delle 6C per creare delle procedure efficaci).

Oggi ci sono tanti modi per dotarsi di un modello di gestione. A cominciare dalle tecniche di sviluppo agili (che, attenzione, non significa che se si sviluppa il software in maniera agile o “agiàil”, si può fare che cavolo ci pare, ci sono dei paletti anche lì) fino alle tecniche scrum e alle più classiche metodologie waterfall. Non mi sento di consigliare un modello di gestione piuttosto che un altro a priori, le scelte a priori vanno lasciate agli Evangelisti di una o dell’altra dottrina, ai pasionari della moda del momento. Ogni azienda deve scegliere il suo modello di gestione in funzione della maturità aziendale, della rapidità del mercato in cui si muove, delle dimensioni dei suoi progetti, sulle tipologia dei suoi lavori se a commessa o a mercato, in funzione delle tipologie di clienti o degli utenti finali che serve.

Però ci sono dei capisaldi che ogni azienda deve considerare. Quindi, a meno che tu non abbia già un modello di gestione, tieni bene in mente questi punti.

Punto primo, il team di sviluppo deve essere definito a priori, in base alle competenze e alle capacità personali di ciascuno, ognuno dovrà avere dei singoli ruoli all’interno del team. Mi raccomando, non ti sto dicendo questo per fare un bell’esercizio e prendere un bel voto a scuola, ti sto chiedendo di scrivere nero su bianco chi è lo Sviluppatore, chi l’Analista, chi è il Capo Progetto, chi è il Project Manager. Anche se alla fine il team è composto da 3 persone soltanto. È importante scriverlo nero su bianco, le persone hanno la memoria corta. E nascono i casini.

Punto secondo. Il tempo dedicato all’analisi non è mai abbastanza. È chiaro che alla fine dovremo trovare un compromesso fra la fase iniziale di analisi e l’inizio dell’implementazione, però questo è lo snodo nevralgico su cui combattono sempre il cliente, gli sviluppatori, e l’imprenditore. È risaputo che “cannare” l’analisi porta sempre a dei risultati deprimenti per tutti, ma anche fare un’ottima analisi non è sufficiente per ottenere un prodotto eccellente. Sì, è una condizione necessaria, ma non sufficiente. Fare una buona analisi permette chiaramente anche di quantificare bene il progetto a livello economico.

la qualità, o la paghi prima o la paghi dopo (e di solito dopo è molto più cara)

Punto terzo, la pianificazione. Anche in questo caso, è necessario scrivere nero su bianco con qualsiasi mezzo, che sia una lavagna nell’area di sviluppo, che sia un documento condiviso, che sia un tool web, l’importante è che siano scritte nero su bianco le fasi del progetto, gli step di verifica e test, le date di rilascio del prototipo, mockup, versione finale, eccetera. Anche in questo caso non ti sto chiedendo di fare un esercizio di stile, è proprio fondamentale scriverlo nero su bianco e condividerlo con il team di sviluppo.

Punto quarto. Il test del software è un’attività che ti può davvero salvare la faccia di fronte ai clienti. Ho visto così tante volte aziende committenti e produttrici arrivare ai ferri corti solo perché era stata trascurata la fase di test. Fino a qualche anno fa c’era il tempo da dedicare quasi la metà del budget di progetto alla fase di test. Oggi non c’è più. Il mercato è troppo veloce per consentire di fare dei test approfonditi, ma una buona pianificazione dei test o degli sprint, con strumenti e metodologie adatte, rende possibile farlo in maniera economica e sostenibile. La valenza dei test è doppia:

1. I test del codice hanno lo scopo di verificare se il codice fa quello che si è detto che deve fare.
2. I test del progetto hanno lo scopo di verificare se il prodotto sviluppato sia effettivamente quello che vuole il cliente, il committente, o l’utente finale! Sono dei test più allargati, con una visione più ampia e che spesso possono essere estesi anche al cliente, in un’ottica di collaborazione.

Quindi, ricapitolando, nella prima strategia del modello di gestione, i punti essenziali sono:

1. definire bene i team di sviluppo NERO SU BIANCO
2. ANALISI fatta bene
3. PIANIFICAZIONE “intelligente”
4. TEST, verifiche e interazione con il cliente/utente

La seconda strategia: controllo delle dimensioni della qualità del software

La seconda strategia che ogni produttore di software deve assolutamente fare, è dotarsi di uno strumento per controllare le 6 dimensioni principali della qualità del software di cui ho parlato prima. Ti sto parlando adesso della qualità del prodotto software. Quando un’azienda ha dei prodotti propri, o quando il prodotto sviluppato per un cliente ha una certa complessità, è importante essere consapevoli di che cosa stanno facendo i propri sviluppatori. E questo lo puoi fare soltanto usando delle metriche, dei KPI, degli indicatori pensati per capire se il tuo prodotto è di qualità oppure no. Sto parlando di dati oggettivi, linee di codice, lunghezza delle linee di codice, usabilità del prodotto, manutenibilità, portabilità. Tutte metriche che possono fare una differenza abissale fra un software mediocre destinato a durare pochi anni, ed un software eccellente destinato a vincere sul mercato.

Parlerò del tema delle metriche del software in un prossimo video (sopra un esempio di indicatori di qualità), in cui sviscereremo ciascuna delle 6 dimensioni per cui un software può essere ritenuto di qualità oppure no.

I modelli di gestione e le norme di riferimento

Tornando al modello di gestione, solitamente si fa riferimento allo standard di qualità del processo più diffuso al mondo. La norma ISO 9001.

La ISO 9001 da sola non garantisce che i prodotti sviluppati siano di qualità. Ma effettivamente garantisce l’applicazione di un ottimo modello di gestione della qualità anche alle aziende che sviluppano software, e se il sistema di gestione ISO 9001 è architettato bene da qualcuno che conosce bene il software, effettivamente reca un beneficio straordinario all’azienda che lo implementa.

Attenzione, ti sto parlando di uno dei più collaudati standard di miglioramento della qualità, diffuso in 180 paesi in tutto il mondo che definisce come un’azienda dovrebbe organizzare i propri processi. Il limite della ISO 9001 è che non è uno standard pensato esclusivamente per le aziende di sviluppo software, ma un buon consulente, insieme ad un buon imprenditore o manager, può implementare un modello di gestione veramente eccellente anche soltanto riferendosi ai requisiti della ISO 9001.

Altro standard più avanzato è la ISO 20000 che è proprio specifico per il settore del software. È uno standard molto impegnativo per cui consiglio alle piccole aziende di tenerlo presente solo come riferimento e non come standard di certificazione. Come standard di certificazione invece consiglio l’eccellente modello di gestione della ISO 9001.

Ok. Fine della prima parte. Nella seconda entreremo nel merito della qualità del prodotto software (vedi la seconda parte).

Se l’articolo ti è piaciuto metti un commento e condividi sul tuo social preferito.

Se vuoi farmi delle domande su questo tema scrivi qui sotto nei commenti o cerca i miei contatti sul sito o sul mio profilo linkedin per restare in contatto.