ASCOLTA L’ARTICOLO
Scritto da Federico Moretti
Cos’è il DevOps
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) e 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:
- miglioramento del time-to-market, con conseguente riduzione dei cicli di sviluppo;
- miglioramento della produttività;
- miglioramento dei rapporti con la clientela;
- maggiore innovazione;
- 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.
Cosa lo ostacola
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.
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).
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.
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.
La soluzione
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.
