Se tu dovessi decidere di fare un primo passo, uno solo, per incominciare a mettere in sicurezza il tuo software, da cosa dovrebbe partire? Quale potrebbe essere la singola azione più redditizia da mettere in pratica immediatamente per avere dei risultati evidenti soprattutto nel medio e lungo periodo e consolidati che portino ad un evidente e misurabile miglioramento della qualità del codice prodotto?
Te lo racconto a partire da una storia vera che mi è successa tanti anni fa, all’inizio della mia carriera lavorativa, ma che somiglia a tantissime altre storie simili che sicuramente saranno successe a te e a tutti coloro che si occupano di software.
Stavo sviluppando un piccolo pezzo di programma per un cliente, che metteva in collegamento due tool diversi, un “bridge” diciamo. Rilasciata una prima versione del software, ho cominciato a ricevere da parte del cliente una serie di email che mi segnavano alcune anomalie. All’inizio analizzavo le segnalazioni ed apportavo prontamente delle correzioni. Benissimo, il codice comunque funzionava bene e faceva già da subito il suo “dovere”. Ma non bastava.
Le email hanno cominciato ad accavallarsi e a dimostrarsi strumento poco adatto a gestire la situazione: non era chiaro quali erano i problemi aperti e quelli risolti, in che versione erano stati risolti, per cui si è passati ad un sistema rudimentale di Bug Tracking, basato su Excel, su cui tornerò. Questo accorgimento ha migliorato molto la situazione, anche se non era finita così.
Si procedeva comunque abbastanza bene fino a quando ad un certo punto, si sono cominciate a creare delle situazioni non proprio piacevoli, anche se molto note: il cliente ha cominciato a lamentarsi sì di funzionalità non presenti o che non funzionavano poco, ma anche di aspetti tutto sommato estetici o del tutto secondari. Anche qua sembrava risolto, al momento.
Alla fine, sono fioccate richieste che seppur apparentemente logiche, del tipo: i file di log devono avere il formato YYYY_MM_DD_HH_SS.log invece che HH_SS_DD_MM_YYY.log e decine simili che erano sicuramente ragionevoli, ma che avevano in comune con tantissime altre una caratteristica:
NESSUNO LE AVEVA CONCORDATE PRIMA!
Stava succedendo una cosa MOLTO spiacevole: il cliente mi tempestava di richieste, diligentemente divise per priorità, catalogate e condivise in un sistema di tracciamento errori, ma la verità era una soltanto.
IL CLIENTE SE NE STAVA APPROFITTANDO CHIEDENDO FUNZIONALITÀ’ ED ASPETTI LOGICI ED ESTETICI CHE NON AVEVAMO STABILITO E CONCORDATO IN ALCUN MODO
Ed era una cosa apparentemente senza fondo: sono dovuto andarmi a riguardare le email scambiate all’inizio ma di formale, di scritto a livello di dettagli c’era ben poco. Un capitolato di poche decide di righe con le funzionalità di alto livello e basta. Quasi tutto il dettaglio era stato uno scambio verbale non registrato da nessuna parte. E il cliente ne stava approfittando.
Ma la stessa cosa capita a parti invertite, stai tranquillo: a volte sicuramente eri tu il cliente e hai litigato con i fornitori che ti hanno fornito un prodotto che secondo te era incompleto, malfunzionante, lacunoso ma non avevi a disposizione argomenti solidi per contestare quanto secondo voi mancava.
Altre volte mi sono capitate cose simili senza necessariamente cattiva fede: semplicemente, non avendo messo nero su bianco quello che il cliente o committente esterno ma anche interno vogliono, si creano dei profondi disallineamenti tra richiesta da una parte e offerta dall’altra.
Quante volte ti è capitata una cosa del genere? Quanti di queste fraintendimenti, ambiguità, contraddizioni, estensioni non richieste delle funzionalità, capitano sia con aziende esterne che a volte all’interno della stessa azienda, tra team diversi? O addirittura si creano scollamenti tra manager e sviluppatori o tra designer e coloro che vengono dopo?
Tutto questo ha una causa ben precisa, che gli americani riassumono in uno dei loro soliti acronimi brevissimi e fulminanti:
GIGO
(Garbage In, Garbage Out)
Tradotto: la Qualità di qualunque processo, qualunque esigenza, qualunque lavorazione, qualunque ricetta dipende sicuramente dal metodo, dalla competenza, dalla professionalità ma in primis dipende dai dati in ingresso, dagli “ingredienti”, dall’input.
E questo diventa un principio fondamentale, valido in una qualunque delle fasi del Ciclo di Vita del Software:
se la qualità dei dati in ingresso di un processo è pessima, i risultati in uscita NON possono essere che altrettanto scarsi!
Io posso avere il miglior cuoco del mondo e la cucina più attrezzata: ma se uso uova marce, farina infestata, latte scaduto, ingredienti avariati come posso pensare di ottenere in uscita qualcosa di commestibile?
Se discuto delle caratteristiche di un prodotto, software, attività con una serie di email confuse, riunioni senza un report, scambi al telefono come posso pensare di farmi capire correttamente dal mio cliente o dal mio fornitore?
Ora posso rispondere alla domanda iniziale: qual è la tua prima mossa che DEVI implementare per iniziare un rapido, efficace e duraturo processo di miglioramento della Qualità del Sofware?
I REQUISITI
Esatto: senza dei requisiti adatti, non può nemmeno esistere il concetto di un software che sia:
- corretto: che si comporti come da richiesta del cliente o come pubblicizzato, in maniera formale e dimostrabile
- completo: in cui siano presenti e funzionanti correttamente tutte le funzionalità desiderate o offerte
- tracciabile: che contenga SOLO le caratteristiche descritte nei requisiti e che non abbia al suo interno funzionalità obsolete, nascoste o inattive che possano improvvisamente attivarsi creando funzionamenti indesiderati
- verificabile: per poter dimostrare a qualunque cliente, committente o commissione che ogni singola funzionalità, ogni requisito non solo è stato tracciato ma è anche stato verificato e testato
- ripetibile: se hai un ottimo set di requisiti, potresti dare il compito di realizzare lo stesso software a team o aziende diverse e avresti dei risultati funzionalmente del tutto equivalente
Basare tutto il ciclo di vita della produzione del software sui Requisiti è un passo assolutamente fondamentale per la rimozione dell’ambiguità, per la definizione certa dello stato di avanzamento di un progetto, per avere delle interfacce certe e formali con clienti e fornitori, per rendere tutto lo sviluppo di un prodotto contenente software un processo stabile, certo, ripetibile quindi in poche parole ingegneristico.
Per cui se devi puntare ad una singola azione volta migliorare il tuo processo di sviluppo, a creare una cultura adeguata del software, a rivoluzionare il tuo modo di lavorare riducendo enormemente i rischi ed abbassando i costi, devi capire bene cos’è un REQUISITO e come si scrive correttamente (e come NON si scrive).
Ma come si scrivono correttamente i requisiti? Il METODO PER LO SVILUPPO EFFICIENTE DEL SOFTWARE prevede che i requisiti abbiano 5 caratteristiche fondamentali per essere utili ed efficaci e non diventino un’arma a doppio taglio. Perché i requisiti siano davvero uno strumento potente che vada ad accrescere la Qualità e al contrario non aumentino la confusione, l’ambiguità e non si trasformino in un’attività che viene percepita come noiosa, inutile e controproducente per cui abbandonata dopo alcuni tentativi iniziali, è indispensabile seguire alcune regole ed evitare degli errori comuni.
Ci scriverò un prossimo articolo, ma se sei già curioso ora ne ho parlato anche in una Whitepaper che puoi ricevere gratuitamente iscrivendoti alla Newsletter: