Lo sviluppo di nuove applicazioni e l’ammodernamento di soluzioni software sempre più indispensabili per supportare funzioni nevralgiche all’interno delle aziende (ma anche nella società in cui viviamo) sta facendo affiorare una problematica tecnica, il cui impatto è però direttamente collegato alle performance e alla produttività aziendale: quella della qualità del software.
Assicurare l’assenza di errori, la corretta rispondenza all’uso e il buon funzionamento, sono attività che competono ai team di sviluppatori; team che oggi si trovano sempre più spesso stretti nella morsa delle esigenze provenienti dal business, da un lato, e dalla produzione veloce di soluzioni applicative a sostegno di queste richieste, dall’altro. Per evitare che situazioni di questo tipo, ormai all’ordine del giorno di moltissime imprese, impattino eccessivamente sulla qualità del software e sui processi di sviluppo e test applicativo, alcuni studiosi e analisti propongono approcci che Forrester identifica come metodi “Don Chisciotte” (per evidenziarne l’inefficacia), perché molto invasivi e di derivazione dai processi di manufacturing. Secondo Forrester, infatti, si tratta di metodologie e approcci che hanno due grossi problemi: prevedono dei cambiamenti (organizzativi, tecnologici e di processo) troppo complessi e poco sostenibili; lo sviluppo software non può essere paragonato ad un processo di produzione o assemblaggio manifatturiero perché ha esigenze, caratteristiche e finalità molto diversi.
Tre consigli preliminari
Secondo Forrester, parlare di qualità del software significa: incontrare i business requirement, fornire una soddisfacente user experience, evitare defezioni (inefficienze a livello di sviluppo che poi si ripercuotono sulla produttività dell’utente e, quindi, sulle performance dell’azienda).
Per garantire la qualità in questo specifico ambito, molte aziende hanno già investito in tool tecnologici, processi e persone ma stanno ancora “lottando” per raggiungere dei risultati soddisfacenti. Ciò di cui avrebbero bisogno, sempre secondo l’analisi della società di ricerca americana, sono consigli pratici. Forrester ne suggerisce tre:
1) trovare i finanziamenti: sarebbe già un’ottima soluzione avere all’interno dei propri team di sviluppo degli skill dedicati al quality assurance e dei tool specifici per il testing applicativo. Se così non fosse, Forrester suggerisce alle aziende di trovare il modo per recuperare il budget necessario a questi investimenti, magari puntando sul fatto che delle “rotture” all’interno del ciclo di sviluppo (test manuali da rifare, bug ed errori, ecc.) hanno dei costi molto elevati e un’importante ricaduta sull’efficienza aziendale nel suo complesso;
2) fare attenzione alle “rivolte”: prevedere dei cambiamenti pervasivi o aggiungere nuovi task a team che sono già sovraccarichi di lavoro, potrebbe essere rischioso, non solo per l’efficacia del lavoro svolto che tende a diminuire, ma anche per l’insoddisfazione degli sviluppatori che rischiano così di diventare attori “passivi”. Prevedere nuovi processi, così come suggeriscono molti guru del quality software, non è semplice e spesso richiederebbe davvero la “bacchetta magica”.
3) rallentare i processi: dire al business che dovrà attendere a lungo per avere le applicazioni richieste, non è certo una via percorribile. Tuttavia, il business capisce perfettamente il linguaggio legato a costi, rischi, benefici. Vanno quindi ricercate le misure più equilibrate tra processi di sviluppo applicativo veloci ed efficacia di tali processi (anche di diretto impatto sul business), onde evitare che la velocità vada a discapito dell’efficienza (con rischi troppo elevati, costi crescenti, scarsa produttività degli utenti, ecc.).
Le sette vie del cambiamento
E per dare un quadro un po’ più dettagliato di quelle che possono essere le opportune scelte da compiere per iniziare a ragionare sul miglioramento dei processi legati allo sviluppo applicativo, Forrester ha identificato sette cambiamenti (figura 1):
1) definire la qualità in funzione delle proprie necessità;
2) identificare e trasmettere metriche di qualità molto semplici;
3) mettere a punto “goal” individuali e di team che includano gli aspetti di qualità;
4) ricevere i giusti requirement;
5) impostare un approccio di tipo ”test smarter to test less”;
6) fare attenzione al design delle applicazioni per ridurre i rischi bug;
7) ottimizzare e automatizzare tutti i processi e le attività attraverso l’utilizzo di tool specifici per il testing delle applicazioni.
Cambiamento n. 1: la perfezione non esiste, seguire le proprie necessità
Tutti vogliono un software perfetto, ma i budget ridotti, le priorità del business, la capacità delle risorse spesso rendono impossibile raggiungere la “perfezione”. Se allora questo è un obiettivo impossibile, come agire per avere comunque un risultato qualitativamente soddisfacente? Innanzitutto, suggerisce Forrester, riconoscere che il vero “goal” del testing è la riduzione dei rischi, non la loro eliminazione. Le applicazioni non devono essere perfette, ma devono supportare i processi di business in tempo per cogliere le nuove opportunità del mercato senza esporre l’azienda ad ulteriori rischi competitivi. Motivo per cui la qualità del software non è univoca per tutte le soluzioni, ogni applicazione ha i propri “quality requirements”. È quindi fondamentale riuscire a definire a priori la qualità di ciascuna specifica applicazione trovando le regole giuste a raggiungere l’equilibrio tra “inaccettabile, abbastanza buona, perfetta”.
Seguendo questo approccio, la capacità di raggiungere la qualità richiesta migliora, dato che non si perde tempo a seguire la perfezione e a dare priorità ad attività destinate a risultati poco realisitci.
Cambiamento n. 2: impostare semplici metriche
I team di sviluppo vogliono raggiungere il più alto livello di qualità possibile, naturalmente. Ma per sapere qual è necessitano di metodi e strumenti per verificare i vari livelli qualitativi e capire se sono soddisfacenti o meno (e che impatto hanno sulla base delle richieste cui devono aderire). Per riuscire ad avere questa visibilità, secondo Forrester, non servono complicati modelli metrici ma dei parametri di identificazione chiari e semplici come, per esempio, il numero totale di difetti riscontrati, qual è la loro origine o in quale fase dello sviluppo applicativo si riscontrano, ecc. Il valore aggiunto viene, semmai, dall’accessibilità a questi dati: è fondamentale assicurarsi che tutto il team di sviluppo comprenda dove e come poter migliorare le attività, ognuno per il ruolo che gli compete.
Cambiamento n. 3: servono obiettivi individuali e comuni
Se nei processi di sviluppo delle applicazioni non sono ancora stati inseriti degli obiettivi specifici in riferimento alla qualità, è bene procedere per gradi ed iniziare a definire regole e obiettivi semplici, chiari e, naturalmente, raggiungibili sia a livello individuale (identificando prima quali sono ruoli e skill sui quali impostare un approccio di questo tipo) sia di gruppo. L’importante, evidenzia Forrester, è che, anche in questo caso, ci sia la massima trasparenza e una visibilità trasversale in modo che tutti i team sappiano quali sono gli obiettivi e come poterli raggiungere.
Uno dei benefici maggiori di questo approccio è il lavoro di squadra e la condivisione che, stando alle analisi di Forrester, porta a dei significativi miglioramenti nei processi di sviluppo e test applicativo, con la qualità che si ripercuote direttamente sul business (sia in termini di user experience/produttività, sia in termini di performance aziendali).
È chiaro però, che parliamo di un metodo organizzativo che richiede quindi delle doti di management da parte dei responsabili dell’area dello sviluppo applicativo o della partnership con figure intermedie con competenze sia tecniche sia di business.
Cambiamento n. 4: agilità per gestire i requirement corretti
Cambiare le richieste a progetto (e processi) già avviati è sempre rischioso, oltre che costoso. È tuttavia innegabile che, in contesti economici così dinamici come quelli odierni, le richieste da parte del business siano mutevoli con impatti anche sull’area dello sviluppo applicativo. È importante allora impostare un metodo che faciliti i processi di test e sviluppo anche a fronte di cambiamenti e nuove richieste. Forrester suggerisce di coinvolgere attivamente nei team di sviluppo anche figure di business come i cosiddetti “business analyst” o i “QA professional” in modo da limitare gli impatti e i rischi nei processi e identificare le vie più corrette per dare una risposta ai cambiamenti richiesti, senza rallentare le fasi di sviluppo o accrescere i rischi.
Cambiamento n. 5: test smarter to test less
Se è vero che il testing è di assoluta importanza per garantire la qualità del software, è anche vero che in molte realtà si “esagera” con queste attività, con conseguenti ritardi e costi elevati. Non solo, in alcune aziende i test sono ancora manuali e questo nasconde rischi ulteriori (di errori e, quindi, di inefficienza).
Forrester suggerisce di indirizzare il testing sulle aree più importanti, mission-critical, e su quelle più rischiose, razionalizzando i processi di test e automatizzando i controlli anche con il supporto di tool tecnologici.
Cambiamento n. 6: design per ridurre i rischi
La complessità architetturale, le tecniche di coding un po’ approssimative e il design non sempre coerente rendono alto il rischio di bug ed errori all’interno delle applicazioni sviluppate. Migliorare il design applicativo riduce notevolmente questo rischio, con diretto effetto sulla qualità della soluzione e sulla sua efficacia. Agire a livello di design applicativo significa adottare scelte che vadano nell’ordine della semplificazione tecnologica, soprattutto attraverso framework chiari e semplici che aiutino a separare ogni singolo aspetto della progettazione applicativa che facilita i controlli e gli interventi in casi di errore.
Cambiamento n. 7: ottimizzare l’uso dei tool di test
Testare un prodotto software significa eseguirlo con l’obiettivo di scoprirne i malfunzionamenti; automatizzare il testing ne aumenta efficienza ed efficacia. Progettare ed eseguire test di elevata qualità contribuisce a migliorare, parallelamente, anche la qualità del prodotto finale. Motivo per cui, spiega Forrester, è bene definire il testing a priori, come tassello fondamentale dell’intero processo e del ciclo di vita dello sviluppo applicativo. L’utilizzo dei tool tecnologici, poi, diventa un supporto indispensabile non solo per velocizzare le operazioni, ma anche perché consentono di generare dati utili a test successivi e creare una base di “modelli di test” replicabili. Riduzione di rischi, minori errori, più velocità e maggior efficienza sono i benefici riconducibili a questa scelta.
Figura 1 – Pratiche, ruoli e impatti per migliorare la qualità del software
(cliccare sull'immagine per visualizzarla correttamente)
