Scritto da Federico Moretti 

La filosofia DevOps, sebbene di recente introduzione nel mondo professionale, porta con sé un obiettivo ambizioso: aiutare le aziende a sviluppare software in modo più rapido e di maggiore qualità, sfruttando la collaborazione e l’integrazione tra l’attività di sviluppo (Dev) con la parte produttiva/operations (Ops).

Dalla sua introduzione nel 2009, la metodologia DevOps ha – negli ultimi anni – preso piede in diverse organizzazioni, soprattutto di dimensioni medio-grandi, in diversi settori, e anche in Italia. Sebbene lo stato di adozione e le strutture organizzative per il governo della transizione al DevOps siano molto diversi tra le diverse aziende, spesso le tappe del processo appaiono molto simili tra loro, così come i rischi della trasformazione e le opportunità emergenti.

I vantaggi dell’approccio DevOps sono molteplici. Una ricerca di Harvard Business Review sull’argomento del 2019 riporta che i principali vantaggi dell’approccio DevOps, raccolti tramite 654 interviste, sono: 1) miglioramento del time-to-market, con conseguente riduzione dei cicli di sviluppo; 2) miglioramento della produttività; 3) miglioramento dei rapporti con la clientela; 4) maggiore innovazione; e 5) miglioramento della qualità dei prodotti/servizi offerti. In un recente studio di Forbes, l’azienda Liberty Mutual Insurance riporta di aver velocizzato il processo di sviluppo e rilascio di codice di circa 200 volte rispetto a cinque anni fa, prima della transizione a DevOps.

Ma quali sono i principali ostacoli all’adozione del DevOps, e come affrontarli? Bucena e Kirikova (2017) offrono degli ottimi spunti sugli “impedimenti” che un’organizzazione può trovarsi ad affrontare all’interno del processo. Questi ostacoli sono riconducibili a:

1 . Lavori in corso (work in progress) – task richiesti dal cliente che non portano ad alcun valore per lo stesso. Spesso, questi task restano all’interno del ciclo di sviluppo e non entrano in produzione.

Esempio di vita vissuta: una modifica evolutiva che rappresenta un nice-to-have a cui si è iniziato a lavorare ma non ha mai raggiunto il completamento perché a priorità inferiore rispetto ad altre – tuttavia ci si continua a spendere tempo per mantenere aggiornata la branch di sviluppo.

2. Processi aggiuntivi (extra processes) – attività che creano lavoro aggiuntivo per l’organizzazione, senza creare valore per la stessa (es. revisioni, produzione di documenti, iter aziendali complessi).

Esempio di vita vissuta: produzione periodica ripetuta di documentazione a scopo di compliance non altrimenti utilizzata come strumento di lavoro – la documentazione è uno strumento di lavoro importante, tuttavia dove si produce manualmente documentazione che non apporta valore diretto al team si corre il rischio di ottenere informazioni che diventano rapidamente obsolete con aggravio operativo del team.

3. Feature aggiuntive (extra feature) – parti aggiunte al ciclo di sviluppo senza un bisogno esplicito. Queste consumano tempo e risorse, rallentando i tempi del ciclo di sviluppo.

4. Passaggi di consegne (handovers) – ovvero lo smistamento di lavori di sviluppo non completi tra un team e l’altro, che causano ritardi sullo sviluppo stesso e perdita di concentrazione del team.

Esempio di vita vissuta: uno sviluppatore applicativo conosce alcuni elementi utili alla schedulazione dell’esecuzione di un programma, ma deve passare le consegne a esperti di schedulazione per l’effettiva realizzazione dello script di lancio, perché loro assicurano la presenza di elementi importanti quali backup e ripristino (e molti altri). Questo genera spesso un andirivieni di informazioni e richieste di precisazioni che prende più tempo del necessario.

5. Ritardi (delays) – generati da interdipendenze tra lo sviluppo di diverse parti del codice (es. team A che deve attendere il rilascio di team B per poter continuare a lavorare).

6. Spostamenti “non richiesti” (unnecessary motion) – ovvero tutti i cambiamenti all’interno del team e delle attività che interrompono il ritmo del normale ciclo di sviluppo.

7. Errori/difetti (failure demand) – tutte le attività che i team devono affrontare a seguito di un errore o di un’attività non completata. Anche in questo caso, tutte le attività generate consumano tempi e risorse, rallentando il ciclo di sviluppo.

8. Cambi di contesto (context switching) – ovvero tutte le situazioni in cui i team si trovano a gestire più attività in contemporanea, di fatto rallentando o interrompendo il normale ciclo di sviluppo.

9. Potenziale (unmet human potential) – tutte le situazioni in cui le competenze e le abilità dei team non vengono valorizzate e coltivate nella maniera corretta, di fatto riducendo la performance potenziale dei team stessi.

Come gestire questi problemi? Sulla base della nostra esperienza, come Gruppo RES proponiamo un processo strutturato in quattro fasi, riportato in figura.

La prima fase, cosiddetta di Focus, ​​prevede di:

  • Censire i punti di attenzione (need) per ogni servizio/applicazione​
  • Prioritizzare servizi e punti di attenzione

La seconda fase, Backlog, permette di:

  • Stimare il livello di maturità dell’organizzazione attorno alle attività prioritarie/oggetto di focus
  • Constatare i bisogni e le risorse necessarie, impostando un ciclo di sviluppo rapido
  • Definire il backlog degli obiettivi

La terza fase – Strategy – ​​ permette di:

  • Valutare pratiche e strumenti (eg. standardizzazione + cont. deployment + cont. monitoring, GIT + Jenkins + Splunk)​
  • Progettare il cambiamento organizzativo​
  • Progettare il cambiamento tecnologico​

Infine la quarta fase di implementazione (Execution) porta a:

  • Formazione del personale coinvolto (eg. formazione ad applicativi sulle motivazioni della scelta di uno stack standard)​
  • Misurazione di KPI e SLI prima del cambiamento (eg. elaborazione dei dati di time to market dalle fonti e rappresentazione in Splunk)​
  • Messa in atto del cambiamento e misurazione successiva​

La tua azienda sta valutando l’adozione di questa metodologia? La transizione è già iniziata ed è necessario un confronto esterno? Gruppo RES, attraverso la LOB di Consulenza Manageriale, offre supporto alle iniziative DevOps: dalla valutazione dello stato attuale, all’implementazione, fino alla comunicazione dei risultati raggiunti. Scopri di più con una mail a consulting@res-it.com.