Built-in Quaility è uno dei principi fondamentali di Lean, base del pillar Jidokadella famosa House of Lean. Il concetto di per sé rasenta il “banale”: ogni prodotto realizzato deve incorporare e abbracciare strutturalmente gli aspetti di qualità. La questione, però, è che il significato specifico di “qualità” e le azioniche concorrono al suo raggiungimento sono elementi tutt’altro che univoci e definibili in modo predefinito e/o predittivo. In fondo, siamo nel modo dei sistemi complessi, dove dobbiamo costantemente validare le nostre assunzioni per trovare la soluzione migliore adatta al prodotto e al contesto.
Strumenti, pratiche, processie toolci consentono di validare gli aspetti realizzativi e funzionali del prodotto, ma essere opportunamente innestatiall’interno del ciclo di sviluppo, dando dignità soprattutto alle Persone che ne sono i veri detentori, operativi e di know-how.
Nel mondo del software è comune associare l’idea di qualità al testing (anche se è un pelino riduttivo) ma spesso non si ha un approccio strutturato relativo, andando a fare “azioni artigianali” che finiscono per concentrarsi soprattutto alla fine delle attività di coding. Paradossalmente, questo modo di procedere genera uno dei più grandi Waste (Muda, Sprechi) che si possano incontrare lungo la filiera di Delivery, creando a valle del flusso di lavoro un Lake of Defects in cui i tester devono improvvisarsi sommozzatoriper poter individuare le deficienze del nostro prodotto e comunicarle in qualche modo agli sviluppatori.
Lake of Defects
Si intuisce come tale azione sia estremamente lunga e costosa, aumentando notevolmente il Lead Time (che, lo ricordiamo, è il tempo totale di realizzazione di una funzionalità, da quando viene inserita nel Product Backlog a quando viene rilasciata) e diminuisce la capacità di avere feedback rapidi il più vicino possibile la cellula(o team) che fattivamente sta realizzando la specifica attività.
L’approccio che mi capita spesso di utilizzare per cominciare a “drenare il lago” è quello di introdurre il noto modello della Piramide di Testing(Testing Pyramid, rif Mike Cohn), facendo attenzione sempre ad evidenziare che, appunto, si tratta di un modello e che, in perfetta chiave Agile, lo stesso va contestualizzato e validato operativamente sul campo.
Testing Pyramid
Lo scopo è quello di spalmareil testing, ma più in generale tutte le attività annesse al raggiungimento dell’obiettivo build-in quality, lungo l’intera filiera di delivery. Si tratta di un approccio fondamentale e portante per avviare una “vera” trasformazione in chiave DevOps.
Facciamo un esempio: se non ho un insieme valido di unit testall’atto della Continuous Integration, non sto facendo Continuous Integration (CI), ma semplicemente merge del codice! Ricordo che l’obiettivo della CI è quello di fornire rapidamente un feedback su quanto realizzato, non quello di generare la build!
Con un approccio strutturato alla qualità (o al testing, se preferite leggerlo in tal modo), si riesce ad asciugare il lago, trasformandolo progressivamente in una pozzanghera (Puddle of Defects) e, idealmente, facendolo scomparire del tutto.
Puddle of Defects
Migliorando costantemente il proprio approccio alla qualità, la necessità di avere un “team di testing” viene tendenzialmente meno e le Persone che prima si comportavano da sommozzatori, possono dedicarsi a portare un reale e costante valore aggiunto, mettendo al centro il cliente in chiave Customer centric.
Stay tuned J