In passato abbiamo abbondantemente parlato del Debito Tecnico (si veda Critical Mass of Software System: quando la qualità del software significa manutenibilità e altri) e della necessità di gestirlo adeguatamente all’interno del nostro processo ALM, evitando che lo stesso raggiunga il Punto di Massa Critica e diventi ingestibile a causa di una soluzione non più mantenibile.
Spesso le soluzioni delle aziende che decidono di avviare la DevOps Transformation sono viziate da un alto Debito Tecnico, rendendo praticamente impossibile andare a creare le condizioni per deployment frequenti e automatizzati.
Per meglio comprendere gli aspetti che hanno portato all’As-Is è opportuno dividere l’analisi su tre direttrici:
- Processi e Azioni di Management che si sono aggiunte e stratificate con la vana speranza di risolvere i problemi esistenti. Si tratta di soluzioni legate ad un approccio tradizionale, antitesi di Agile e Lean che invece spronano ad analizzare il problema all’origine e risolverlo nell’immediato;
- Bassa Qualità del Codice dovuta a fattori diversi, dal know-how tecnico ai problemi di team working;
- Manualità nel Delivery e/o nel Deployment, portando a processi spesso farraginosi e facilmente proni a generare malfunzionamenti in ambienti di produzione.
http://technical-debt.org/cycle.png
Quindi la domanda di fondo è: come possiamo rompere questa spirale distruttiva che, prima o poi (molto più prima che poi!) ci porterà fuori mercato dando un vantaggio competitivo costante ai nostri competitor?
La risposta è estremamente complessa, passando attraverso la presa di coscienza che il Debito Tecnico va pagato, esattamente come va pagato il debito finanziario, altrimenti il proprio destino è già segnato.
Nelle organizzazioni che hanno messo al centro della loro Lean Transformation l’abbattimento del Debito Tecnico, è stato fondamentale identificare una metafora da trasformare in un Information Radiator ben visibile e che esprimesse chiaramente il perché fosse necessario abbattere il Debito Tecnico. Ad esempio: “Il Debito Tecnico è come pretendere di camminare attraverso le sabbie mobili”, o anche “Il Debito Tecnico è come affrontare una scalata portandosi dietro 50kg di zavorra”.
I primi elementi che finiscono sotto la lente di ingrandimento sono i task poco automatizzati, spesso fonte di problemi per l’intera filiera di Deployment.
Ripagare il Debito Tecnico
Nell’ottimo “The Phoenix Project”, gli autori parlano dei “Three Ways”, ovvero delle tre parti costituenti un efficace percorso di trasformazione DevOps:
- Il First Way è focalizzato sulla creazione di flussi di lavoro veloci e costanti, rimuovendo il muro tra l’area Development e quella Operation, muro che rappresenta anche il confine tra il business ed i clienti;
- Il Second Way porta a trovare il modo di velocizzare ed amplificare i loop di feedback in modo da migliorare la qualità dei vari task ed evitare inutili ripetizioni di lavoro;
- Il Third Way spinge alla creazione di una Cultura orientata alla sperimentazione, all’apprendimento derivato dal fallimento, ed alla comprensione che la pratica e la ripetitività sono pre-requisisti per diventare maestri nelle proprie attività.
Il più fido alleato in questo processo è il Product Owner (ok, se non avete ancora Team Agili capite chi ha la vera governance, il Project Manager, il Product Manager, ecc…) che deve strutturare il Product Backlog (e suggerire al Team di fare lo stesso per l’Iteration Backlog) considerando opportuni Work Item relativi all’abbattimento del Debito Tecnico, andando a sfruttare in tal senso il miglioramento della produttività del Team che normalmente si verifica costantemente in chiave Agile/Lean. Inoltre il PO deve allungare lo sguardo al di là dell’orizzonte, preoccupandosi delle attività di Operation.
Il punto è che l’intera struttura IT deve ragionare in chiave “product-centric” e non “finance-driven”, ricordando che DevOps è molto più che semplice automazione, ma è Culture-Automation-Lean-Metrics-Sharing.
So, be CALMS!
