C’era una volta la figura professionale del “programmatore”, uno specialista che si dedicava alla stesura di righe di codice con i più disparati scopi: dalla realizzazione di piccole logiche di automazione fino allo sviluppo di applicazioni che erano di supporto alla ordinaria gestione di una azienda. Era il responsabile di tutto l’iter di sviluppo del progetto, dalla raccolta delle specifiche fino alla messa in produzione finale.
Poi grazie alla pervasiva digitalizzazione delle aziende il “semplice” programmatore si è evoluto acquisendo una professionalità diversa che raggruppa un più ampio spettro di competenze, dalla conoscenza tecnica dei linguaggi di programmazione alla managerialità nella gestione di progetti e risorse.
Proprio in questo contesto evolutivo e di crescente complessità le aziende stanno comprendendo la necessità di strutturare progetti di digitalizzazione che vedono l’Information Technology come parte attiva nella creazione di valore. In questo ambito si combinano logiche di condivisione che coinvolgono le Operations con il Development di nuovi strumenti digitali. Stiamo parlando del DevOps, una delle chiavi nel processo di Digital Transformation che nel prossimo breve periodo coinvolgerà molte aziende.
Che cosa è il DevOps?
Per arrivare a definire cosa è il DevOps è prima necessario comprendere le esigenze e gli obiettivi delle Aziende. Una organizzazione che opera nei mercati attuali è in grado di creare valore solo se è in grado di rispondere prontamente alle esigenze del cliente soddisfacendo, se non addirittura anticipando, le richieste.
Non si tratta solo una metodologia ma un vero e proprio mindset che sta alla base di un modello composto da una combinazione di tool, framework, principi e pratiche. In questo modello i 2 team dedicati allo sviluppo del software ed il team dedicato alla produzione realizzano una sinergia che inizia dalle prime fasi del progetto. In questo modo i 2 team che (solitamente) interpretano diversamente il proprio ruolo all’interno di un progetto, sono costretti a condividere lo stesso linguaggio innescando un loop cooperativo ed eliminando le barriere. Grazie a questa collaborazione, le Operation IT, dato che sono coinvolte già nella fase di specifica, avranno quindi un ruolo attivo che influenzerà la fase di sviluppo. Dall’altro lato, durante la messa in produzione del software, il team di sviluppo assisterà le Operation per risolvere eventuali problemi.
Lo schema di riferimento del DevOps si divide sostanzialmente in 2 parti che, interagendo all’interno di un loop infinito, definiscono l’automatismo delle fasi di sviluppo ed il successivo rilascio in produzione del software.
(…) > Planning > Coding > Building > Testing > Packaging > Releasing > Operating > Monitoring > Planning > (…)
Senza addentrarci nel dettaglio di ogni passaggio, riteniamo fondamentale evidenziare che per ogni fase sono disponibili dei tool che agevolano il lavoro.
Il paradigma DevOps viene convenzionalmente rappresentato con il simbolo dell’infinito, evidenziando il significato di un processo continuo.
Iniziamo a focalizzarci sulla parte DEV, dove la velocità e la frequenza con cui vengono rilasciate le versioni software (bug fixing, nuove features, migliorie, …) possono essere viste in coerenza con l’adesione al Manifesto Agile. Un aspetto chiave dell’approccio Agile è il coinvolgimento dei team cross-funzionali che possono definire la pianificazione, già dalle fasi iniziali, coinvolgendo continuamente il cliente finale (interno o esterno) nel processo di sviluppo. Ulteriori framework di sviluppo come Scrum e KanBan possono risultare importanti in quanto possono aiutare nella definizione di obiettivi e priorità, nella assegnazione compiti e ruoli e nell’individuazione preventiva di eventuali azioni di intervento nel caso di problematiche.
Sulla base di queste considerazioni dobbiamo enfatizzare la necessità di avere a disposizione strumenti innovativi che permettano di automatizzare tutte le attività che in condizioni “normali” richiederebbero tempo ed interventi “manuali” per raggiungere la condizione di validazione del progetto.
Se aggiungiamo alla ricetta iniziale un po’ di automazione e ci collochiamo in una realtà aziendale emergono ulteriori aspetti funzionali: Continuous Delivery (CD), Continuous Integration (CI), Continuous Operation e Continuous Assesment.
Continuous Delivery
È realizzato automatizzando il flusso di distribuzione, dallo sviluppo alla produzione, ed è l’insieme degli strumenti e delle procedure che hanno l’obiettivo di consentire il rilascio in produzione in qualsiasi momento. Scendendo nei particolari ci riferiamo alla esecuzione automatizzata di un insieme di attività che comprendono anche dei test pianificati già nella fase di sviluppo, che validano costantemente le release software rendendola di fatto “production ready”. Nel CD è fondamentale la standardizzazione che deve riguardare sia le infrastrutture e sia le pratiche di gestione dei ruoli coinvolti nel processo.
Continuous Integration
Il valore aggiunto di un programmatore è lo sviluppo di nuove funzionalità, ragione per cui l’automatismo definito dal CD gli consente di rimanere focalizzato sull’integrazione continua del codice.
Sintetizzando, la CI è quindi la pratica con cui viene chiesto agli sviluppatori di integrare il loro codice più volte al giorno, sfruttando la possibilità di automatizzare lo sviluppo grazie a strumenti di condivisione e di check-in per l’identificazione di eventuali errori. Nella catena di distribuzione del software vengono aggiunti i test funzionali e strutturali (prestazioni, accessi, sicurezza, ecc.) che vengono eseguiti in maniera automatica ogni volta che viene completata una modifica.
Continuous Operations
Parlare di Continuous Operation significa sapre gestire le modifiche al sistema digitale in modo che non venga impedito all’utente finale di utilizzare il software. In altre parole, deve essere garantita la condizione di Business Continuity fino al momento in cui la nuova versione non è perfettamente funzionante.
Continuous Assessment
Anche nel DevOps, come ogni altra metodologia, è necessario valutare continuamente il buon esito dell’applicazione finale ed i feedback sono la cartina tornasole del risultato finale. Questa è la ragione per cui è importante progettare anche degli strumenti di Feedback loops, in cui l’applicazione finale è monitorata continuamente sia attraverso degli indicatori che ne evidenziano lo stato di salute e sia attraverso la raccolta delle opinioni degli utilizzatori.
Dalla elaborazione dei feedback emergono le Planning Prioritization, ovvero vengono attribuite delle priorità alle attività di intervento, valutate in base alle esigenze di creazione di valore.
Alcuni feedback incidono sulla gestione del budget (Portfolio Investment) ed in questo contesto il gruppo di pianificazione viene coinvolto nella decisione delle risorse da assegnare e nella priorità degli investimenti.
Siamo alle battute finali, la metodologia DevOps è ancora poco diffusa ma l’attenzione verso i suoi principi è in aumento. La crescente necessità di digitalizzare per incrementare la competitività delle Aziende giocherà un ruolo fondamentale nella diffusione del nuovo paradigma. In aggiunta riteniamo che vi sia intrinsecamente un ulteriore fattore abilitante e il contributo che verrà dato dall’uomo ne determinerà il successo. Non solo sviluppatori e amministratori saranno chiamati a condividere obiettivi, ma team cross funzionali, che coinvolgeranno figure delle altre unità funzionali (Operation, Sales, Marketing, Finance, HR, …) saranno coinvolti nella gestione di progetti che in passato erano riservati al solo mondo IT. Non ci saranno più compartimenti stagni e le linee di confine verranno indebolite e, come in ogni progetto di cambiamento, le persone saranno chiamate ad essere le principali protagoniste. Per questo motivo, siamo certi che non sarà una moda che passerà facilmente.
