Un’organizzazione DevOps

Abbiamo già celebrato, con DevOps compie 10 anni, i primi dieci anni di DevOps. Ci siamo successivamente occupati, con DevOps: Dalle macchine virtuali ai container, dell’impatto architetturale che DevOps ha portato nello sviluppo del software.

La creazione di software è però, oltre ad un esercizio di tecnica, soprattutto il frutto del lavoro di un’organizzazione. Lo sviluppo di software è il risultato dello sforzo collettivo di un insieme di persone che fa parte di un’organizzazione.

Il sociologo tedesco Amitai Etzioni e lo statunitense Talcott Parsons definiscono le organizzazioni come “unità sociali (o raggruppamenti sociali) deliberatamente costruite e ricostruite per il raggiungimento di fini specifici”.

Le caratteristiche delle organizzazioni sono dunque:

• Suddivisione del lavoro, del potere e delle responsabilità […];
• Presenza di uno o più centri di potere che controllano gli sforzi unitari dell’organizzazione […];
• Sostituibilità del personale.

John Willis and Damon Edwards coniarono nel 2010 l’acronimo CAMS che venne, in seguito, evoluto da Jez Humble nell’acronimo CALMS. Questo comprende cinque iniziali.

Culture (Cultura)

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. Il silos è tipicamente l’esempio classico di un gruppo di lavoro e non di un team. Un team cross-funzionale in DevOps, 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. Il DevOps coinvolge operativamente tutta l’organizzazione: dal management, agli sviluppatori ai sistemisti per arrivare agli esperti di qualità. La creazione di software in DevOps non è un mero esercizio di tecnica, ma è in primis il risultato dello sforzo collettivo di un insieme di persone che fa parte di un’organizzazione.

Automation (Automazione)

Uno dei classici problemi del software complesso prodotto con il metodo tradizionale è che tipicamente non rilasciamo una piccola lavorazione, ma un grande blocco di modifiche. Infrastructure-As-Code (IaC) è il processo di gestione e provisioning dei data center attraverso file di definizione leggibili dalle macchine. Tutti gli strumenti di Continuous Configuration Automation (CCA) sfruttano l’IaC per modificare, configurare e

automatizzare l’infrastruttura e forniscono anche visibilità, efficienza e flessibilità nella gestione dell’infrastruttura. Le tecniche di automazione sono il limite inferiore dei metodi DevOps e il grado massimo di automazione raggiungibile passa per l’esistenza di strumenti di automazione. L’automazione ottenibile attraverso gli strumenti IaC e CCA è dunque abilitante per un approccio DevOps orientato ad un aggiornamento continuo dei sistemi

È economicamente più conveniente e predicibile utilizzare i computer per le operazioni ripetitive. Inoltre, meno interventi umani equivalgono a minori rischi di errore.

Il tempo sottratto alle operazioni manuali, talvolta anche alienanti, può così essere reinvestito in attività a più elevato valore.

Lean

Il precursore del lean manufacturing è il Toyota Production System (TPS) sviluppato tra il 1948 ed il 1975 da Ono Taiichi e Eiji Toyoda. Chiamato originariamente just-in-time manufacturing, Toyota ha riassunto la sua filosofia, i suoi valori e i suoi ideali di produzione in The Toyota Way che consiste in principi in due aree chiave: miglioramento continuo e rispetto per le persone. Il Lean software development è una traduzione dei principi e delle pratiche di lean manufacturing al dominio dello sviluppo del software. Mary e Tom Poppendieck, nel 2003, pubblicano Lean Software Development individuando 22 pratiche. Lo sviluppo snello può essere riassunto in sette principi. Ancora l’Extreme Programming è una metodologia di sviluppo del software che ha lo scopo di migliorare la qualità del software e la reattività alle esigenze dei clienti. Come tipologia di sviluppo agile del software, sostiene frequenti rilasci in brevi cicli di sviluppo, che hanno lo scopo di migliorare la produttività e introdurre punti di controllo in cui le nuove esigenze del cliente possono essere adottate.

Measurement (Misurazione)

Tanto più i metodi di misurazione e aggregazione sono analiticamente determinati, tanto meno opinabili e più oggettivi saranno i presupposti sui quali prendiamo le decisioni. Il Lean considera la misurazione come un’attività che non genera valore e sottrae tempo alle persone: per questo è consigliabile ridurla al minimo. Il Lean e i metodi Agili si basano su un approccio sistematico alla risoluzione dei problemi guidato dagli insegnamenti di William E. Deming. Per lavorare con questo metodo è necessario un ambiente di lavoro in cui la cultura di accettazione dell’errore sia ben integrata e basata sul presupposto della fiducia. Risulta quindi determinante lo stile di management adottato. Il Lean, i metodi Agili e DevOps mirano al miglioramento sistemico nel lungo periodo ricorrendo a strumenti come il visual thinking, il Domain Driven Design, l’Event Storming e le Kanban board. A tutti i processi di lavorazione del software possono essere applicate le quattro metriche Lead time, Wait time, Process time e Delivery time. Risulta così possibile costruire diversi diagrammi a supporto delle decisioni: Control Chart, Release Chart e Cumulative Flow Diagram. Per monitorare la performance di rilascio di software nella nostra organizzazione, gli indicatori principali di cui possiamo servirci sono il throughput e la stabilità. Nel contesto dell’operatività, il rilascio, le operation a supporto di un servizio software, le metriche e indicatori di uso più frequente sono di seguito indicate: Release frequency, Mean-Time-To-Recover, Quality of Product e Change Failure Rate.

Sharing (Condivisione)

Per ridurre il time-to-market, procedere per piccoli step e correre meno rischi, il programmatore ha bisogno di introdurre nuove modifiche al software, il che significa rilasciare spesso e frequentemente. Il sistemista, invece, ricerca l’affidabilità, ovvero sistemi stabili e senza interruzioni di servizio. Apparentemente, quindi, rilasciare spesso è in contrapposizione con le responsabilità dei sistemisti. Questa tensione può essere superata creando uno spazio condiviso e di fiducia, dove sia i sistemisti sia i programmatori possono discutere e pianificare gli interventi con adeguata coordinazione. Organizzarsi per team cross-funzionali, come abbiamo visto, è il primo passo, il secondo è iniziare a essere corresponsabili. Per adottare DevOps è indispensabile mettere da parte le barriere e costruire un clima positivo e di collaborazione. Risulta

determinante uno stile di management che incoraggi il confronto e lo scambio di informazioni. Il patrimonio di informazione persistente in un team è in fondo la sua storia e costituisce parte del suo valore.

Di questi cinque aspetti del DevOps ci occuperemo nei prossimi appuntamenti.