DevOps: La cultura

Nel nostro viaggio nelle organizzazioni DevOps, come anticipato nel nostro articolo “Un’organizzazione DevOps”, ci occupiamo della prima iniziale dell’acronimo CALMS (Culture, Automation, Lean, Measurement e Sharing); ci occupiamo della Culture.

Nel campo DevOps esiste un modello di riferimento chiamato Westrum Model, dal nome del sociologo Ron Westrum. La dimensione principale considerata è quella delle modalità con cui le organizzazioni trasformano, maneggiano e propagano le informazioni, classificandole in comportamenti:

• Orientati al raggiungimento della condizione di potere, detta anche cultura patologica;
• Orientati al raggiungimento della conformità alle regole esistenti, detta anche cultura burocratica;
• Orientati al raggiungimento dei risultati ad elevata performance, detta anche cultura generativa.

Data la natura del lavoro intellettuale, è evidente come l’orientamento della cultura generativa sia l’atteggiamento più efficace. A tal scopo è necessario abbattere le barriere e iniziare a costruire una cooperazione tra gli individui.

Le organizzazioni a silos

Talvolta le persone nelle organizzazioni vengono separate in dipartimenti che non comunicano tra loro, anche dal punto di vista degli spazi fisici oltre che delle strutture organizzative.

Disegnare le organizzazioni per aree, divisioni, settori o gruppi è molto intuitivo e facile da comprendere o rappresentare. Permette sia di ragionare per centri di costo, obiettivi e metriche uniformi, sia di controllare un apparato attraverso le tecniche del management piramidale, dove la strategia è separata dall’operatività.

Questo approccio consente di avere nuclei di conoscenza aggregata molto simili, in direzione di una sempre maggiore competenza ed esperienza in un’area specifica. Nella realtà, la realizzazione di un prodotto o di un servizio necessita invece di un ventaglio di competenze e conoscenze che attraversano tutti i silos organizzativi, indipendentemente dagli aggregati logici di competenza costruiti.

Nelle organizzazioni a silos, le priorità vengono assegnate per area di competenza e non rispetto al valore di business di un prodotto.

Un ulteriore pericolo è quello di scavalcare una parte del processo per avere un vantaggio rispetto al lead-time misurabile.

Il silos è tipicamente l’esempio classico di un gruppo di lavoro e non di un team. Pur avendo competenze e obiettivi simili, le persone che appartengono a un gruppo possono lavorare a compiti diversi e indipendenti tra loro, senza condividere un obiettivo di profitto o una visione di prodotto.

Questo metodo di governance funziona, a volte anche molto bene, in alcuni ambiti produttivi, ma non è compatibile con i metodi DevOps e lo è ancora meno con i metodi per lo sviluppo Agile di software.

Le organizzazioni cross-funzionali

Un team cross-funzionale, al contrario di un gruppo di lavoro organizzato per silos, è una piccola unità organizzativa che condivide il desiderio di raggiungere uno o più risultati comuni perché ne condivide una visione più ampia. La costruzione del team avviene in questo caso considerando tutte le competenze necessarie a realizzare un prodotto o un servizio.

Tutte le figure necessarie alla realizzazione devono essere nella disponibilità del team, senza frizioni, eccessivi costi negoziali e burocrazia lenta e poco utile. Nell’approccio DevOps, il processo secondo il quale il team lavora è sotto il controllo del team stesso. Scrum ed Extreme Programming sono metodi di lavoro che contengono il concetto di cross-funzionalità e sono compatibili con gli obiettivi di DevOps.

Le dimensioni di un team che lavora in modo efficiente non seguono una regola matematica, ma i risultati migliori sono di solito raggiunti da team composti da un minimo di sei fino a un massimo di dodici persone. Si tratta di uno dei parametri di Scrum. Oltre queste dimensioni, si devono adottare metodi per assemblare più team in un’organizzazione.

Ad ogni figura il suo compito nel DevOps

Il DevOps coinvolge operativamente tutta l’organizzazione: dal management, agli sviluppatori ai sistemisti per arrivare agli esperti di qualità. Ciò che conta, però, è il giusto mindset per diffondere la conoscenza.

1 Il manager

La sponsorizzazione di un’iniziativa DevOps deve giungere in primis dalle figure con più alta responsabilità e a capo di un’organizzazione, gli executive.

Queste figure hanno bisogno di ricevere e chiedere ai team dati quanto più possibile precisi, aggiornati e trasparenti sull’andamento dei prodotti e dei progetti, così da prendere decisioni rapide e facilitare la risoluzione dei problemi che non possono essere risolti dal singolo team.

Il coordinamento del team con il resto dell’organizzazione, i clienti e i fornitori è in capo ai manager di progetto, così come la pianificazione delle attività di team.

2 Il programmatore (DEV)

La prima responsabilità che ha lo sviluppatore è comprendere il problema e rendere la soluzione riproducibile in un contesto generico. Si dovrà analizzare la soluzione in modo da comprendere quanto tempo si impiegherà a realizzarla e con quali costi, in modo che il cliente possa decidere se investire.

Altra responsabilità dello sviluppatore è quella di assicurarsi che il codice sia modificabile in futuro e non presenti difetti già corretti in passato.

Storicamente la responsabilità del programmatore è arrivata solo al momento in la produzione dei file sorgenti ci rende in grado di poterli dare in pasto a una o più macchine e, infine, all’infrastruttura di produzione.

Nella realtà non è sufficiente che il software funzioni sulla postazione del programmatore per essere commercializzato, ma deve funzionare con infrastrutture e dati reali.

La visione classica dello sviluppo software indica che un programmatore ha terminato il suo compito quando termina la responsabilità che gli ha assegnato l’organizzazione alla quale appartiene. DevOps considera invece un software finito quando davvero risolve il problema dell’utente.

3 Il sistemista (OPS)

Il sistemista è la figura tecnica responsabile della buona esecuzione del software che viene costruito dagli sviluppatori.

La sua responsabilità è sempre più orientata a mantenere i sistemi affidabili rispetto ai requisiti di disponibilità e qualità di servizio.

Ogni volta che uno sviluppatore introduce una modifica, questa va ovviamente introdotta nel sistema.

Riducendo la dimensione dei pacchetti di cambiamenti e consolidando il meccanismo di introduzione degli stessi, il pericolo insito in ogni modifica si riduce. Anche in questo caso, per via dei silos, non sempre l’Ops ha conoscenza approfondita delle sfide e delle competenze che servono ai programmatori. DevOps intende quindi il sistemista come figura strategica al pari di ogni altro componente del team.

4 L’esperto di qualità (QA)

L’esperto di qualità (o Quality Assurance ) si occupa di assicurarsi che il problema del cliente sia effettivamente risolto.

Il suo ruolo è quello di facilitare il committente nell’articolazione di una descrizione dei bisogni risolutiva e completa.

Altro ruolo del QA è quello di sollecitare il sistema reale per portarlo in condizione di instabilità e stress.

Il programmatore richiede l’intervento del QA quando ritiene di aver completato, per quanto possibile, la funzionalità a cui stava lavorando, oppure quando ha la necessità di un parere esterno.

Conclusioni

Vediamo dunque come la creazione di software in DevOps non sia un mero esercizio di tecnica, ma sia in primis il risultato dello sforzo collettivo di un insieme di persone che fa parte di un’organizzazione.