The DevOps Ways - pt.4 @ DOH19

Questo è l’ultimo post della serie dedicata al mio intervento “The DevOps Ways” presentato alla conferenza DevOps-Heroes 2019 e in questa parte cercherò di raccontarvi cosa significa, almeno per me, lavorare in modo DevOps.

Nelle puntate precedenti vi ho raccontato gli errori concettuali che ho fatto e li potrei riassumene così:

1. gli strumenti sono i “come”, gli strumenti NON sono i “perché”
2. il tool non fa il DevOps… non basta usare alcune pratiche e alcuni tool per essere DevOps
3. “bad name”! DevOps è un processo che include sia il management che il market/customer
4. DevOps is abount “collaboration”, non basta comunicare

La cultura DevOps: The Three Ways

Non esiste un manifesto che identifica i valori o i principi DevOps e neanche un manuale del Perfetto DevOps, però anche DevOps si basa su dei valori e dei principi. I valori hanno radici lontane nel tempo e hanno orgini nel settore industriale, visto che sono stati inspirati dal Toyota Production System o da movimenti da esso derivati. I principi, invece, sono stati formalizzati per la prima volta nell’articolo The Three Ways: The Principles Underpinning DevOps scritto da Gene Kim nel 2012.

E’ arrivato il momento di raccontarvi i principi che guidano il modo di lavorare DevOps e perché essi possono portare un vantaggio nel nostro modo di sviluppare software.

The First Way: System Thinking

Spesso si fa riferimento a questo come “The Principle of Flow” oppure “The Principle of Value Stream”, ma è inutile formalizzarsi sul nome e passiamo subito al concetto!

Il focus del primo principio è sul flusso del valore (abilitato dall’IT), nella sua interezza. In altre parole, DevOps inizia quando vengono identificate le necessità del mercato o dei clienti e termina quando il valore viene consegnato agli utenti finali. Il processo DevOps adotatto per creare valore non solo attraversa tutte le fasi di sviluppo del software (analisi, sviluppo, IT Operations, QA, Security, etc.), ma copre anche tutte le fasi precedenti e successive e.g. design, raccolta dei requisiti, user testing.

Identificato il flusso del valore, cioè il processo utilizzato, si cerca di enfatizzare le prestazioni dell’intero processo al fine di ridurre il Lead Time e incrementare la qualità (intesa come numero di difetti riscontrati). L’approccio da adottare è quello del System Thinking: “concentrarsi sui collegamenti e le interazioni tra le parti che compongono un sistema (o processo) e analizzarlo nella sua interezza, piuttosto che suddividerlo in elementi separati e studiarli in modo isolato”.

Le conseguenze del primo principio sono:

1. non permette che una ottimizzazione “locale” del processo vada a creare un degrado a livello globale;
2. non “trasmettere” un difetto alle successive postazioni di lavoro (scritto così fa molto catena di montaggio, ma il senso è chiaro, no?);
3. cercare di migliorare il flusso del lavoro velocizzandolo e incrementandolo.

The Second Way: Amplify Feedback Loops

La chiave di questo principio sono le parole Amplify e Loops (notate il plurale). La mia esperienza mi porta a classificare i “loop” in 2 gruppi distinti, in base alle categorie di persone che li originano: esterni ed interni.

I feedback esterni sono quelli che ci arrivano dal mercato e dai clienti finali. Questi feedback si possono ottenere in svariati modi: interviste o questionari ai clienti, monitor dell’applicazione, collezionare e analizzare le recensioni dei clienti, etc. Lo scopo dei feedback acquisiti è comprendere le esigenze del cliente e verificare costantemente che quello che siamo facendo stia effettivametne creando un valore per esso!

I feedback interni, invece, sono quelli generati dalla persone che lavorano al prodotto, dal processo stesso oppure dagli strumenti che monitorano lo stato di salute dei nostri produtti. Gli scopi di questi feedback sono molteplici e i principali sono garantire la qualità e monitorare il sistema per comprendere quando non sta funzionando come dovrebbe.

Lo scopo di questi feedback è:

1. comprendere meglio le esigenze dei nostri utenti;
2. rispondere in modo più preciso alle esigenze del mercato o dei clienti;
3. garantire la qualità percepita dall’utente finale

The Third Way: Company Culture

Questo principio è probabilmente il più discusso e il più bistrattato. Personalmente credo sia il più importante dei tre principi DevOps e proprio una Company Culture che permette di sperimentare e imparare dai fallimenti è necessaria per poter applicare e sfruttare appieno i primi 2 principi.

Questo principio riguarda due fattori:

• promuovere la sperimentazione continua, l’assunzione dei rischi e l’apprendimento dai fallimenti;
• la pratica e l’esercizio sono fondamentali per acquisire la padronanza degli strumenti e dei processi adottati.

Entrambi i fattori sono molto importanti! Il primo ci garantisce il miglioramento continuo tramite la sperimentazione, ma esso ci porta a correre dei rischi e a entrare in una zona di potenziale pericolo. Abbandoniamo la confort zone e andiamo incontro a qualcosa di ignoto. La padronanza, invece, ci permette di andare in una zona tranquilla, eludere i pericoli oppure ad affrontarli e “sconffiggerli” prima che essi possano arrecare danni irreparabili. Quando si esplora e sperimenta è possibile andare incontro a un fallimento, ma esso deve essere trasformato in una esperienza positiva! da cui possiamo imparare qualcosa e dobbiamo essere in grado di tornare in una zona tranquilla. Un approccio spesso utilizzato è il Ciclo di Deming.

Ora che abbiamo definito anche questo principio e i fattori che lo compongono voglio parlarvi delle persone e dei loro comportamenti. Partiamo da due considerazione generali:

• i comportamenti delle persone sono dettati e influenzati dalla loro cultura
• la cultura è definita dall’insieme dei comportamenti delle persone

La cultura e i comportamenti sono in stretta correlazione e, normalmente, tendono a rafforzarsi l’uno con l’altro. Questa relazione porta a mantenere inviariato lo status quo. In che modo possiamo uscire da questo schema e provare a cambiare le cose? E’ possibile avviare un processo di cambiamento della cultura esistente? La risposta è: sì! Partendo da un nostro comportamento differente, prossibilmente positivo e migliorativo, possiamo “contagiare” le persone che ci circondano (il team in cui lavoriamo) e introdurre un piccolo cambiamento nella cultura “locale” del nostro team. Una volta che questo piccolo cambiamento è avvenuto, il team (o meglio i suoi membri), inizieranno a comportarsi in un modo differente con le persone che lo circondano (PM, Staskholders, altri team, etc.) e questo comportamento differente puà “contagiare” anch’essi. In questo possiamo dare il via a una piccola e lenta spirale positiva di cambiamento della cultura aziendale! Il tutto è nato da alcuni piccoli e isolati comportamenti. Purtroppo, mediante un approccio al cambiamento che parte dal basso non saremo in grado di cambiare la cultura aziendale di una multinazionale, ma di certo può portare benefici locali, senza grossi attriti. Se l’azienda è piccola, invece, la nostra influenza potrebbe essere maggiore e generare le condizioni favorevoli per una transizione strutturata dell’intera azienda verso la cultura Lean/Agile/DevOps e le sue metodologie.

Conclusioni

In conclusione, per applicare realmente la metodologia DevOps bisogna avere una forma mentis e una cultura aziendale che promuovono la sperimentazione continua, l’assunzione dei rischi e l’apprendimento dai fallimenti. I rischi sono mitigati dalla padronanza degli strumenti e dei processi adottati e che abbiamo consolidato tramite la pratica e l’esercizio frequente. Solo grazie a una cultura di questo tipo è possibile applicare con successo le tecniche relative ai primi due principi e ottenere i vantaggi a essi legati. Adottare un approccio, una cultura, DevOps offre il vantaggio di avere Lead Time ridotto, alta qualità dei prodotti/servizi offerti, incentrare le attività di sviluppo e manutenzione sulle esigenze del cliente finale, in altre parole generare valore in modo rapido e costante.

La cultura aziendale è definita dall’insieme dei comportamenti delle persone che compongono l’azienda e i comportamenti delle persone dipendono dalla cultura aziendale e questi due fattori cultura aziendale e comportamenti si rafforzano a vicenda per mantenere lo status quo. Rompendo questo cerchio, mutando i nostri comportamenti possiamo influenzare le persone che ci circondano ed esse a loro volta possono influenzare chi le circonda e in questo modo possiamo avviare un processo che muta la cultura aziendale. Tale processo non sarà rapido e i risultati dipendono dalle dimenzione dell’azienda, ma sono convinto che possa essere utile sia per migliorare localmente il modo in cui lavoriamo (noi e i team con cui abbiamo a che fare) e ci predispone a una transizione efficace verso metodologie Lean/Agile/DevOps.