Comprendere il concetto di Tempo Alla Qualità
Oggigiorno esistono molti indicatori utilizzati per monitorare i progressi dell’Assicurazione Qualità (QA). La maggior parte di essi è piuttosto utile, ma tendono tutti ad essere monodimensionali, nel senso che sono istantanee di un momento, o di uno sprint, nel tempo. Questo vale anche per gli indicatori di tasso e di tendenza, che sono estremamente importanti, ma, ancora una volta, restano istantanee nel tempo.
Quando lavoravo in Symantec, ho notato questo:
Venivano impiegati molti indicatori per determinare il livello di qualità raggiunto (presumibilmente) entro la data di rilascio. Ma non venivano raccolti indicatori, né in fase di lavorazione né a posteriori, per misurare il costo di conseguire quella qualità.
In altre parole, non ci preoccupavamo di quanto efficientemente si fosse raggiunta quella qualità durante la vita del progetto.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Il tuo prodotto può anche essere stato rilasciato con un'elevata qualità, ma era davvero necessario impiegare così tanto tempo ed energie per raggiungere quel risultato?
Questa è una questione di efficienza, non propriamente di qualità, ma le due sono strettamente correlate.
L’intersezione tra qualità ed efficienza
Qualità ed efficienza si intersecano perché uno dei motivi principali per cui i progetti software spesso sforano di molto le scadenze previste (e spesso ciò si rivela come un’imprevista “tegola” nell’ultima fase del progetto) è la scarsa qualità del codice. Non solo la qualità iniziale, ma durante tutta la durata del progetto.
Un altro motivo, che in realtà è solo una conseguenza inevitabile della scarsa qualità del codice, sono i difetti che richiedono molteplici cicli di tentativi di correzione, spalmati su diversi passaggi di test o sprint prima che il difetto sia effettivamente risolto. Se mai lo sarà.
Queste interminabili iterazioni di correzione, test e nuovi fallimenti aggiungono settimane-uomo praticamente a ogni progetto software.
E, in modo interessante, questo schema di fallimento non viene identificato in modo specifico da nessun altro indicatore di progetto o di qualità che io abbia mai visto. Perché, come già detto, tutti questi indicatori sono istantanee nel tempo, e quindi non riescono a catturare questo fenomeno.
Mi è venuto in mente che c’era un modo semplice per cogliere questo schema di fallimento. Ho elaborato un indicatore che ho chiamato "Time to Quality", ovvero TTQ.
Introduzione di un nuovo indicatore: Time To Quality (TTQ)
L’indicatore in sé è molto semplice. Funziona così:
Per ogni passaggio di test (a prescindere da come venga definito), registra non solo quanti test sono stati superati o falliti, ma quanti sono stati superati al primo tentativo. E quanti ne hanno richiesti due, tre, o più prima di risultare finalmente superati.
Ad esempio, se esegui 20 test e 5 vengono superati al primo tentativo, il tuo rapporto TTQ è del 25%. Più alta è questa percentuale, meglio è. Si tratta di un indicatore semplice, calcolabile e facilmente accessibile della qualità complessiva del codice.
Questo indicatore è un ottimo parametro per la qualità iniziale del codice.
Infatti, migliore è la qualità del codice, meno volte dovrai sottoporre un test su quella parte prima che venga superato. E viceversa. Questo indicatore è molto più preciso dei conteggi e delle tendenze dei bug.
TTQ è anche un parametro estremamente utile per il monitoraggio di progetto.
Ad esempio, se al primo passaggio di test il 70% dei test è stato superato, e il 30% fallito, puoi ragionevolmente presumere che il progetto sia ancora in linea con la tabella di marcia. Ma se, per esempio, solo il 20% dei test è stato superato al primo tentativo, allora, per dirla in termini tecnici, "Amica mia, sei nei guai! "
Perché significa che in realtà non hai effettuato un vero e proprio primo passaggio riuscito. E che quel tempo dovrà essere riaggiunto in un passaggio successivo come debito di qualità.
L’indicatore TTQ è estremamente utile come quello che mi piace definire un “indicatore di soglia”.
Se lo utilizzi in modo costante, ti fornirà dati molto accurati che permetteranno al PM di capire se il progetto sta deragliando molto prima che il treno esca davvero dai binari.
Questo significa che si possono adottare misure proattive molto prima per riportare la situazione sotto controllo. Evitando così imbarazzanti ammissioni a gioco ormai quasi concluso che le scadenze del progetto sono andate in fumo. In altre parole, usa una soglia TTQ per definire se il progetto è ancora in verde, in giallo o sta per andare in rosso. Rendilo parte integrante dello stato del progetto stesso.
Perché diciamolo, una delle patologie ricorrenti nei progetti di sviluppo software è la persistente negazione che le cose stiano andando per il verso sbagliato – e in modo significativo – quando diventa per la prima volta palese che è così. Tutti hanno paura di essere bollati come “negativi”, o di essere considerati troppo pigri o svogliati per sistemare le cose, o di non essere “giocatori di squadra”. Il parallelo con le famiglie disfunzionali è francamente evidente.
Questa negazione e repressione di ciò che tutti sanno realmente stia succedendo crea uno schema di fallimento fatto di rifiuto nell’ammettere che il progetto è molto, molto fuori tabella fino all’ultimo minuto utile.
Quando questo non può più essere nascosto ai vertici, la spiacevole sorpresa che ciò provoca non fa che minare, a volte in modo permanente, la loro fiducia nei team di sviluppo. E chi potrebbe biasimarli?
Ma se incorpori costantemente il TTQ nei tuoi indicatori e nel project management—e agisci in base a ciò che quell’indicatore ti sta dicendo—puoi evitare tutto questo.
Misurare il Time To Quality depersonalizza la decisione di riconoscere che rischi di calendario e qualità stanno accumulandosi nel progetto già nelle sue prime fasi.
Diventa tutto molto chiaro e schematizzato, una questione di numeri. Non più una questione di eroismo personale, che spesso comporta un grande costo per la persona.
La metrica TTQ è anche molto utile per il retrospettivo/post mortem di un progetto.
Permetterà al team di individuare esattamente quali sezioni del codice sono state, e sono rimaste, deboli durante tutto il progetto. E per estensione quanto il team sia stato efficiente nel produrre qualità come tale. Oppure quanto sia stato costoso.
Questa è una domanda spesso evitata nei retrospettivi di progetto. In parte perché i team non hanno il vocabolario concettuale per formularla, e in parte perché è spesso politicamente delicato sottolineare la qualità costantemente scarsa del codice dall'ingegneria.
In sintesi
TTQ offrirà un'enorme trasparenza e prevedibilità ai vostri progetti quasi senza alcun costo in termini di tempo o sforzo, dal momento che si tratta semplicemente di una meta-analisi delle metriche che già state raccogliendo.
Uso il TTQ nei miei progetti di QA da due decenni, e ha riscontrato un'ampia accettazione tra i project manager che ho formato, per tutti i motivi sopra riportati.
Provate, e vedrete voi stessi. Sarà davvero un punto di svolta per il vostro team. Come sempre, buona fortuna.
P.S. Se volete ascoltare più aneddoti e le ragioni dietro il TTQ, ne ho parlato con Jonathon Wright al QAL Podcast.
