The DevOps Ways - pt.3 @ DOH19
Nella seconda puntata di questa serie di post vi ho mostrato la visione che avevo del processo DevOps e perché tale visione era sbagliata:
- gli strumenti sono i “come”, gli strumenti NON sono i “perché”
- il tool non fa il DevOps… non basta usare alcune pratiche e alcuni tool per essere DevOps
- “bad name”! DevOps è un processo che include sia il management che il market/customer
In questa terza puntata vi voglio fornire la visione aggiornata che include anche management e market/customer e applicare nuovamente la metafora dell’arciere per verificare se ora il modello ha senso!
2015 - Visione DevOps n.2
Nel 2015 la mia visione aggiornata di cosa fosse DevOps, potrebbe essere riassunta nel seguente modo:
- DevOps è un processo per lo sviluppo del software che va dal Management al Market/Customer
- le persone coinvolte dal processo sono tecnici (sviluppatori, sysAdmin, tester, etc.), Stackholders, clienti, concorrenti
- gli strumenti che rendono il nostro processo un processo DevOps non solo solo pratiche tecniche, ma anche tutte le metodologie che servono a gestire il prodotto o il processo
Proviamo ad applicare nuovamente la metafora di prima e vediamo se ora ha più senso. I ruoli nella metafora non sono cambiati e sono:
- il processo è l’arco
- gli arcieri sono solo i tecnici, che eseguono il processo
- le frecce che abbiamo a disposizione nella nostra faretra sono gli strumenti
Proviamo a raccontare con una metafora questo caso: il management chiede di implementare, in modo minimale, una funzionalità perché vuole verificare se potrebbe essere utile ai nostri clienti. Essa deve entrare in produzione il prima possibile, appena pronta, e messa a disposizione solo ai clienti più “fedeli”; inoltre, dobbiamo fornire al management un feedback per capire se i clienti la usano o meno.
La matafora potrebbe essere: gli arcieri scoccano la freccia della Continuous Integration/Delivery per consegnare rapidamente ai clienti la nuova funzionalità e la freccia del A/B Testing per selezionare i clienti che possono acceddere alla nuova funzionalità. Usiamo anche la freccia delle telemetrie per fornire al management il numero di utenti che hanno utilizzato la funzionalità 3 o più volte.
Ora la metafora mi sembra funzionare! Introducendo altre “personas” abbiamo i bersagli delle nostre freccie e anche qualcuno che ci chiede di scoccarle; inoltre, stiamo usando i tool in modo corretto, cioè essi sono il come e dei non arcieri ci forniscono lo scopo, il perché dovremmo utilizzarli.
In realtà, c’è ancora qualcosa che non mi convince! DevOps risulta essere in secondo piano… sembra che i DevOps siano dei meri esecutori, dei passacarte, quasi degli strumenti nelle mani del business. Essi dovrebbero essere il cuore del processo, starò sbagliando ancora qualcosa?
DevOps enables “communication”
In questa visione i tecnici hanno creato un flusso di informazioni che vanno dal management al market/customer e viceversa. In pratica abbiamo “abilitato” la comunicazione tra i 2 estremi del processo e l’abbiamo fatto creando una condotta stagna con solo 2 aperture, una per estremità.
In questa visione, i tecnici si sono limitati ad abiltiare il flusso delle informazioni e del valore. Certamente apportano anche del valore, perché implementano la soluzione, la mettono in produzione, la mantengono in funzione, etc.
I tecnici hanno abilitato la comunicazione, ma essi si comportano comesoggetti passivi rispetto al processo, al flusso si comportano come meri esecutori!
DevOps is about “collaboration”
Ecco un altro errore! Mi sono concentrato sulla comunicazione e sull’abbattere i muri che separano le persone, ma quello che fa realmente la differenza è la collaborazione!
Cosa vuol dire collaborazione? Ci sono tante definizioni, ma a me piace riassumerla nei seguenti 4 principi:
- il perseguimento di un obiettivo comune;
- l’unione degli individui (e delle loro capicità) a beneficio del gruppo;
- l’accettazione dei ruoli (emersi o imposti);
- l’assunzione di responsabilità come gruppo e degli individui verso il gruppo.
Conclusioni pt.3
La mia nuova visione di DevOps funziona bene con la metafora descritta nella seconda parte, ma i tecnici sono finiti in secondo piano rispetto alle altre persone. I tecnici, tramite gli strumenti a loro dispospiù che un errore, il mio è una mancanzaizione, hanno permesso la comunicazione end-to-end, sono degli abilitatori, sono dei “tramite”, ma non si sentono parte del processo.
Rimettere i tecnici, i DevOps, sullo stesso piano delle altre persone, significa iniziare a collaborare tutti insieme per raggiungere l’obiettivo comune.
Questa volta il mio errore è stato di pensare alla comunicazione, ma DevOps is about collaboration!
Nell’ultima parte di questa serie di post, proverò a raccontarvi cosa significa per me lavorare in modo DevOps.