Una questione di qualità

Dopo aver visto nei precedenti appuntamenti come DevOps sia un approccio olistico, basato su una cultura Lean/Agile e sorretto da cinque pilastri che sviluppano la DevOps Delivery Pipeline (alias Value Stream), focalizziamoci proprio su quello che dovrebbe essere il mantra per ogni organizzazione che abbracci questa mentalità, vale a dire la qualità.

Built-in Quality

Built-in Quality è uno dei principi fondamentali di Lean, base della colonna Jidoka nella famosa immagine House of Lean [1].

L’essenza di questo concetto è semplice: ciò che costringe ad abbassare la qualità del lavoro, e di conseguenza del prodotto, deve essere immediatamente affrontato e rimosso. Si tratta di un vero e proprio rifiuto di operare in modo inverso, e l’organizzazione investe attivamente nella riduzione del debito tecnico, garantendo che il focus dei team coinvolti (progetto, UX, architettura, dev, ops, support, etc.) siano allineati a tale filosofia.

Definire la qualità

Per quanto sembri una scelta ovvia, che rasenta il “banale”, resta una sfida non semplice da affrontare, visto il significato ampio di “qualità” unitamente al fatto che le azioni, che 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, processi e tool sono di supporto nella validazione degli aspetti realizzativi e funzionali del prodotto, ma avere la qualità “innestata” all’interno delle diverse fasi del ciclo di delivery necessità di andare al di là del tecnicismo, valutando cosa realmente è realizzabile in relazione al contesto di riferimento e quindi alle persone coinvolte.

Testing

Non può esistere una valida adozione di DevOps senza un approccio strutturato alla qualità e, in particolare, senza una specifica strategia di testing, che si leghi ai diversi stadi di avanzamento, andando a incidere, con diversa profondità ed enfasi, sulle attività dei vari work center (team) coinvolti.

Nel mondo del software, in particolare, è comune associare l’idea di qualità al testing, anche se il testing è in realtà un suo sottinsieme. Ma spesso non si ha un approccio strutturato al testing, procedendo con “azioni artigianali” che finiscono per concentrarsi soprattutto alla fine delle attività di coding.

Paradossalmente, questo modo di procedere genera uno dei più grandi waste (sprechi, in giapponese muda) che si possano incontrare lungo la filiera di delivery, creando a valle del flusso di lavoro un cosiddetto Lake of Defects in cui i tester devono improvvisarsi “sommozzatori” per poter individuare le deficienze del nostro prodotto e comunicarle in qualche modo agli sviluppatori.

Si intuisce come tale azione sia estremamente lunga e costosa, aumentando notevolmente il Lead Time (il tempo totale di realizzazione di una funzionalità, da quando viene concepita a quando viene rilasciata) e diminuendo la capacità di avere feedback rapidi il più vicino possibile alla cellula (work center, team) che fattivamente sta realizzando la specifica attività.

Il nodo centrale del debito tecnico

Un ampio lago dei difetti, sotteso da un approccio poco efficace ed efficiente alla delivery di una soluzione, acuisce il cosiddetto debito tecnico, che rende impossibile creare una valida DevOps Delivery Pipeline.

La metafora del “Technical Debt” è stata introdotta per la prima volta da Ward Cunningham, parlando della complessità di far evolvere nel lungo periodo un sistema progettato tenendo conto solo dell’immediato (breve/brevissimo periodo). Come ben definito nella voce di Wikipedia:

Il Debito Tecnico è una metafora per indicare le eventuali conseguenze derivanti dalla frettolosa definizione di un’architettura software e da un altrettanto frettoloso sviluppo

Bisogna evidenziare che non esiste un prodotto senza debito tecnico, e se si è convinti del contrario, si ha forse una eccessiva fiducia nel nostro processo e nelle nostre competenze, fino a rischiare di sconfinare nella saccenteria, distaccandoci dal contesto in essere.

I fattori alla base del debito tecnico

Perché diciamo che è esagerato pensare che un prodotto non presenti debito tecnico? Tale considerazione nasce dal fatto che il debito tecnico non è esclusivamente legato a codice scritto male o non testato, ma dipende da fattori intrinsechi, relativi ai team e al loro modo di organizzarsi ed operare:

• Processi e pratiche inadeguate, stratificati con la vana speranza di risolvere i problemi esistenti. Si tratta di soluzioni legate a un approccio tradizionale, all’antitesi di Agile e Lean che invece spronano ad analizzare il problema all’origine e a risolverlo nell’immediato con una valutazione empirica.
• Bassa qualità del codice, dovuta a fattori diversi, dal know-how tecnico ai problemi di team working.
• Deploy manuale e scarsa automazione, che portano l’ultimo miglio a essere spesso attraversato in modo artigianale, generando malfunzionamenti negli ambienti di produzione.

Come per quello finanziario, il debito tecnico va ripagato in modo opportuno e la specifica strategia non può non essere al centro di un’organizzazione che abbracci DevOps nei suoi aspetti più profondi.

Quality Measurement

Alla luce di tutto ciò, per poter agire in ottica Built-In-Quality, è fondamentale poter misurare la qualità di quanto realizzato, in modo da valutare oggettivamente il lavoro svolto e poter tenere sotto controllo il debito tecnico cumulativo, evitando di avvicinarsi al punto di massa critica (Critical Mass of a Software System) oltre il quale non è più economicamente conveniente far evolvere la soluzione specifica, ma diventa più vantaggioso un suo completo rifacimento.

Quanto emerge, in modo statistico, è che tanto migliore è la qualità della soluzione realizzata, tanto più si riesce a deferire nel tempo il punto di massa critica, traendo maggior valore dall’investimento fatto (ROI, Return On Investment) e spalmandone il costo di gestione (TCO, Total Cost of Ownership) su un periodo di più lunga durata.

In questo contesto, l’adozione di pratiche portanti di DevOps, come la Continuous Integration, e di metodologie di sviluppo Agile, come il Test Driven Development, favoriscono la qualità della soluzione che si sta realizzando, aiutando a mitigare il problema del debito tecnico che, nel medio periodo, porta a una rincorsa continua della manutenzione correttiva a scapito di quella evolutiva.

È fondamentale quindi impostare dei livelli minimi di qualità, statici e dinamici, e individuare tool che possano misurarli automaticamente, fornendone costantemente lo stato attuale.

Strategie di test: Test Pyramid

Uno degli approcci più efficaci per “drenare il lago dei difetti” è quello di introdurre il noto modello della piramide di testing (Test Pyramid) [2], facendo attenzione sempre a evidenziare che si tratta di un modello e che, in perfetta chiave Agile, va contestualizzato e convalidato operativamente sul campo.

Lo scopo della Test Pyramid è quello di spalmare il testing ai diversi livelli operativi e, più in generale, inquadrare sistematicamente, lungo l’intera filiera di delivery, tutte le attività annesse al raggiungimento dell’obiettivo di built-in quality. Come già evidenziato, è un approccio obbligato se si desidera realmente identificarsi in una organizzazione operante in chiave DevOps.

Per comprendere la veridicità di questa assunzione, facciamo un esempio riprendendo la DevOps Delivery Pipeline di cui abbiamo parlato nell’articolo precedente: se non ho un insieme valido di unit test all’atto della Continuous Integration, non sto facendo realmente Continuous Integration (CI), ma solo merge del codice! Ricordo che l’obiettivo della CI è fornire rapidamente un feedback su quanto realizzato, non di generare la build!

Con un approccio strutturato alla qualità — o al testing, se preferite leggerlo in tal modo — si riesce a “prosciugare il lago dei difetti”, trasformandolo progressivamente in una pozzanghera (Puddle of Defects) e, idealmente, facendolo scomparire del tutto.

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.

Conclusioni

Si chiude qui il quarto appuntamento con il nostro percorso alla scoperta di DevOps. Nel prossimo articolo vedremo il supporto a DevOps da parte dei framework di processo più comuni e faremo un accenno alle piattaforme tecnologiche a supporto.

Nel frattempo, come sempre, aspettiamo i vostri feedback.

Felice Pescatore

Felice Pescatore è Innovation Manager e Microsoft MVP.
Nel suo lavoro, impiega quotidianamente approcci Lean/Agile per lo sviluppo di soluzioni software enterprise.
Nell’ultimo periodo si è dedicato particolarmente al mondo delle Startup con Lean Startup e all’ottimizzazione della Value Chain tramite DevOps, con uno sguardo sempre più ravvicinato al mondo della Internet of Things (IoT).