Tutti sappiamo che DevOps è un cambiamento culturale, che coinvolge tutte le risorse di un’organizzazione. Abbattere il cosiddetto “wall of confusion”, la divisione tra sviluppo (Dev) e Ops vuol dire creare collaborazione e DevOps incoraggia una cultura di collaborazione ed apprendimento.
DevOps favorisce team cross-funzionali e, naturalmente, richiede specialisti operativi. Ma DevOps non è uno specifico ruolo o team.
Parlando del “DevOps Team”, ci sono opinioni contrastanti anche tra gli esperti: deve esistere un DevOps team? L’articolo “The Industry Just Can’t Decide about DevOps Teams”* mostra diversi punti di vista. L’opinione più diffusa è che l’idea stessa di team DevOps sia controproduttiva: si possono creare ulteriori silos e, più in generale, tutte le risorse all’interno di un’organizzazione dovrebbero aderire alla cultura DevOps.
Questa l’opinione di Theresa Naete, in “Break down DevOps team roles so you can actually get to DevOps”** : “Il punto è che non stiamo facendo DevOps se continuiamo a dividere i team.(…) Nel mondo DevOps, dev e ops appartengono allo stesso team. Lo ripeto: è lo stesso team. Quello che alcuni di noi non capiscono è che la cultura è imprescindibile e viene prima degli strumenti. Questa cultura prevede di abbattere silos e barriere lavorative e quindi anche i ruoli all’interno di un team DevOps, in modo che ogni strumento scelto possa essere ottimizzato per raggiungere i risultati desiderati.”
Ma ci sono anche sostenitori dell’idea che i team DevOps siano un modo efficace per effettuare la transizione ad un nuovo modo di lavorare e, nonostante la maggioranza di esperti del settore pensi che i team non siano il giusto approccio per lo sviluppo delle competenze DevOps all’interno di un’organizzazione, i team DevOps sono in aumento.
L’obiettivo di DevOps all’interno di un’organizzazione è quello di ottimizzare la creazione di valore per i clienti e per l’organizzazione; organizzazioni diverse potrebbero aver bisogno di diverse strutture di team per poter creare un’efficace collaborazione tra Dev e Ops. Questo significa che la struttura ideale per poter implementare DevOps dipende da tante variabili.
Ruoli DevOps
Come abbiamo detto in precedenza, non esiste una struttura di team DevOps universale e valida per tutti (o potremmo dire che non esiste qualcosa come un team DevOps!). I ruoli e le responsabilità varieranno in base all’organizzazione: l’importante è identificare quelli che sono i ruoli e le responsabilità chiave ed assegnarli alle risorse con le giuste competenze.
Secondo TechBeacon*** i ruoli DevOps più diffusi, cruciali per ogni organizzazione che vuole adottare l’approccio DevOps, sono:
- DevOps Evangelist: la risorsa che promuove i benefici di DevOps all’interno dell’organizzazione. Appassionato/a di DevOps, il suo ruolo è quello di assicurare partecipazione e sostegno da parte dei team sviluppo e operation. La figura del DevOps Evangelist è il tuo DevOps Leader.
- Release Manager: a volte chiamato anche Release Engineer o Product Stability Manager; responsabile dell’insieme dei progressi, coordina e gestisce il prodotto dallo sviluppo alla produzione.
- Automation Architect: chiamato anche Automation Engineer/Expert o Integration Specialist; analizza, progetta ed implementa diverse strategie per lo sviluppo continuo del prodotto. Questo ruolo è fondamentale perché assicura un ambiente affidabile completamente automatizzato e libero dagli ostacoli.
- Software Developer/Tester: naturalmente questo ruolo è al cuore di un’organizzazione DevOps (si tratta della Dev di DevOps!). Ma in un ambiente DevOps gli sviluppatori sono responsabili non solo di trasformare nuovi requisiti in codici, ma anche di testing di unità, di sviluppo e di monitoraggio continuo.
- Professionista di Experience assurance (XA): se nello sviluppo software “classico” la Quality Assurance (QA) ha un ruolo vitale per la consegna del prodotto finale, in DevOps diventa “Experience assurance”, perché questo ruolo deve anche assicurare che tutte le nuove feature e funzioni siano rilasciate tenendo conto dell’esperienza dell’utente finale.
- Security Engineer: lavora al fianco degli sviluppatori, mettendo in sicurezza il prodotto che si sta sviluppando.
- Utility technology Player: professionista di operation IT tradizionale o amministratore di sistema che si focalizza sul mantenere i server funzionanti; opera efficacemente su piattaforme di sviluppo, network, database, server e tool.
Cultura DevOps
Adottare DevOps significa condividere ed apprendere; quindi non basta avere le risorse con le giuste competenze ma è necessario che il team sia composto da risorse che vogliano continuamente apprendere e che siano disposte a cambiare.
Queste sono le tre caratteristiche di un/una professionista DevOps:
- sa lavorare in team e si adatta bene alla cultura aziendale;
- è una persona curiosa, che vuole sperimentare continuamente e che non ha paura di provare e sbagliare finché non ha capito cosa funziona e cosa no: DevOps incoraggia l’insuccesso, ma deve essere un “insuccesso responsabile”;
- è un professionista adattabile, che può accogliere il cambiamento con positività.
Hai già scaricato Capire DevOps in 7 punti? La nostra raccolta di blog post per capire al meglio la filosofia e metodologia che ha rivoluzionato il mondo IT
Vuoi saperne di più? QRP International offre formazione DevOps. Non esitate a contattarci per maggiori informazioni.
Copyright 2017-2019 Peoplecert International Ltd.
Altre fonti:
*Helen Beal, The Industry Just Can’t Decide about DevOps Teams
**Theresa Naete, Break down DevOps team roles so you can actually get to DevOps
***7 key DevOps roles you need to succeed
What Team Structure is Right for DevOps to Flourish?
