Con questo nuovo appuntamento relativo ad AgileEngineering concludiamo l’overview relativo alla fase di Engineering, e lo facciamo affrontando due tematiche troppo spesso penalizzate nell’operatività quotidiana per far spazio alla “quantità”: stiamo parlando della qualità e delle metriche.
Quality and Metrics
La qualità è un elemento fondamentale che deve essere posta al centro della visione di progetto e, in particolare, di quella del/dei prodotto/prodotti annessi. Cosa realmente significhi “qualità”, e cosa implichi, dipende molto dal dominio specifico, dagli standard afferenti e dalle regolamentazioni annesse.
Nonostante ciò, è possibile definire un modello astratto (ispirato alla Test Pyramid) che chiameremo Quality Pyramid e che può essere rappresentato come segue:
Quality Pyramid
L’aspetto fondamentale è che la qualità passa attraverso una serie di test e validazioni a più livelli, cercando di estremizzare l’automazione nei livelli più bassi della piramide dove, normalmente, si realizzano i diversi componenti del prodotto e dove gli sviluppatori usano le pratiche e gli strumenti più adatti al dominio afferente.
È evidente che più si riesce a ottimizzare il testing ai livelli più bassi, meno problemi dovrebbero sorgere quando ci si sposta verso la punta della piramide, dove, generalmente, il focus è di tipo end-to-end (verso l’utilizzatore finale) ed eventuali problematiche hanno un consto di risoluzione molto più alto, alcune volte non assorbibile.
Continuous Quality
In modo molto astratto, AgileEngineering considera la quality come un “gate” abilitante che si basa su un approccio orientato alla Continuous Quality: non esiste il “ni” nella qualità, ovvero o si rispettano le relative attese, oppure il componente/modulo in analisi non è pronto per l’integrazione con gli altri o per la consegna al cliente.
L’approccio alla Continuous Quality indica l’attenzione ad un miglioramento continuo nelle pratiche e negli strumenti affini, evidenziando ancora una volta come l’evoluzione contingente, e pragmatica, sia alla base di una buona gestione di tutto quanto afferisce a un prodotto complesso, rispetto al quale la conoscenza si affina proprio durante la sua realizzazione.
Il miglioramento non può però essere lasciato (unicamente) all’intuito, ma deve basarsi su dei dati oggettivi, dei numeri, che possano evidenziare dei fatti e non dare adito ad opinioni che sono sempre affette dalla propria capacità e declinazione interpretativa.
Proprio per questo, AgileEngineering definisce una serie di metriche di base che aiutano a valutare oggettivamente la capacità di sviluppo e di reazione dei team di lavoro:
Metrics
In particolare, si hanno:
- Il Cycle Time, che calcola il tempo medio impiegato per completare l’intero ciclo di lavorazione di un componete e/o un modulo.
- Il Lead Time, che calcola il tempo medio impiegato per completare l’intero ciclo di lavorazione di un sotto-insieme del prodotto (generalmente composto da più componenti, moduli) che può essere consegnato al cliente.
- Il Mean Time to Recovery (MTTR), ovvero il tempo medio di risoluzione di un problema.
Si tratta, chiaramente, di metriche di base, che normalmente vengono integrate con indicatori specifici del contesto, ma che sono al contempo particolarmente utili per accelerare le capacità di improvement dell’interno team di delivery.
Con questo appuntamento si chiude la nostra overview sulla fase di Engineering. Nel prossimo appuntamento ci concentreremo sulla fase di Workout, ovvero di “consegna” del prodotto.
Stay tuned :)
