Rilasciare software di valore e in maniera continua, si può!
Qualche giorno fa, insieme a degli esperti del settore, al Pycon @ Firenze si è tenuto un panel dove il concetto di “valore” era utilizzato per raccontare come questo leghi il software sotto diversi punti di vista.
Sotto forma di una chiaccherata tra amici, insieme ai super Fabio Mora -autore di “DevOps”, Raffaele Colace che fa da moderatore (socio e fondatore di 20tab) e al fantastico Filippo Morelli (dev di 20tab) abbiamo raccontato quella che è l’esperienza maturata in merito al tema DevOps, e l’abbiamo fatto sfruttando un video piuttosto singolare.
Ma cominciamo dall’inizio…
Manifesto Agile e software di “valore”
Il primo principio del manifesto dice chiaramente che bisogna **la nostra massima priorità è soddisfare il cliente rilasciando software di valore, ** fin da subito e in maniera continua..
Questo vuol dire che si parla di rilasciare un prodotto che abbia del valore, sopratutto per l’utente finale. Ma come possiamo definire la parola valore?
Questo concetto può riportare a diverse sfumature di significato, a seconda del target: il valore può essere il fornire una soluzione al cliente realizzando il prodotto richiesto, e generando quindi un valore; può essere anche inteso come quello percepito dal cliente rispetto alla soluzione che ha a disposizione per il suo problema.
Non solo: il valore rappresenta anche l’importanza data dai feedback ricevuti dall’utente finale e dal valore con cui il fornitore porta alla realizzazione del prodotto.
Non a caso, Fabio nel suo manuale, ha dedicato un intero capitolo ad un tema così delicato!
Per concludere, nel settore IT e soprattutto per tutti coloro che sposano la filosofia DevOps, ciò che lega il servizio o il prodotto con l’utente finale, ma anche lo sviluppo stesso e le persone.
Non esiste quindi un solo modo per misurarlo: questo dipende da molteplici fattori, dove lo sviluppo della soluzione ha un ruolo da coprotagonista rispetto all’intero processo; non dimentichiamo, come abbiamo detto, l’importanza del valore del feedback durante il processo di progettazione e l’implementazione del prodotto!
DevOps vs Continuous Delivery
Quando parliamo di cultura DevOps, è facile imbattersi in una serie di definizione che possono portare confusione: qual è lo stato attuale della cultura media in Italia su questi temi? La realtà è che, come sempre, in Italia arriviamo tardi: partendo dal fatto che sono passati più di 20 anni dal manifesto Agile e di XP (eXtreme Programming) e quasi 15 dalla nascita del movimento DevOps, possiamo affermare con certezza che questa cultura ha iniziato a prendere piedi qui intorno al 2014-2015.
Se analizzassimo, ad esempio, la ricerca del termine “DevOps” rispetto anche ad altri termini di ricerca utilizzando Google Trends, noteremmo che in Italia questo termine ha un interesse di ricerca relativamente basso. Questo non vuol dire che il livello di curiosità sia basso: l’adozione di questa cultura grazie all’industria del software americana (e non solo) ha portato dei benefici innegabili ed è da lì che il movimento inizia a prendere forma, grazie al modello Toyota.
Il termine “DevOps” nelle ricerche dal 2004
La cosa curiosa è che su Wikipedia c’è un’interessante definizione della relazione che c’è tra Continuous Delivery e DevOps. Ma quali sono le principali differenze e perché ancora vengono spesso confuse tra di loro?
La definizione riporta quanto di seguito:
Relationship to DevOps (cfr. https://en.wikipedia.org/wiki/Continuous_delivery)
Continuous delivery and DevOps are similar in their meanings and are often conflated, but they are two different concepts. DevOps has a broader scope, and centers around cultural change, specifically the collaboration of the various teams involved in software delivery (developers, operations, quality assurance, management, etc.), as well as automating the processes in software delivery. Continuous delivery, on the other hand, is an approach to automate the delivery aspect, and focuses on bringing together different processes and executing them more quickly and more frequently. Thus, DevOps can be a product of continuous delivery, and CD flows directly into DevOps.
L’ultima frase, in particolare, può essere tradotta come: “pertanto, DevOps può essere un prodotto della Continuous Delivery e la CD fluisce direttamente in DevOps.
Questa frase può creare più confusione che altro, quindi proviamo ad utilizzare una metafora per spiegare come questi due concetti, spesso confusi, sono invece molto diversi.
Se sfruttiamo il concetto di un aeroporto, possiamo paragonare la cultura DevOps all’intera infrastruttura che permette ai viaggiatori di volare sicuri e spostarsi rapidamente da un paese all’altro.
D’altra parte, la Continuous Delivery rappresenta gli addetti allo scarico bagagli che, quando l’aereo atterra, prendono i bagagli dalla stiva e li portano verso il nastro trasportatore.
E il Continuous Deployment? Sfruttando la stessa metafora, possiamo dire che questo concetto può essere assimilato alla consegna dei bagagli ai passeggeri tramite il nastro trasportare, così che questi possano lasciare l’aeroporto e godersi la vacanza.
Quanto conta il fattore umano?
Se parliamo di CD e DevOps, spesso si fa riferimento al Cloud, ai tool. Ma quanto è importante il fattore umano all’interno di un processo di sviluppo/rilascio di un software?
Si tratta di una parte del processo fondamentale: potremmo menzionare le tante esperienze vissute dove una stretta collaborazione col cliente allo scopo di produrre valore in maniera condivisa e consapevole funziona, in contrapposizione a uno scenario dove le specifiche e le tempistiche vengono imposte dall’alto.
La cultura DevOps permette di far emergere il valore del prodotto che stiamo sviluppando proprio grazie all’importanza data al feedback dell’utente finale e alla qualità apportata in fase di progettazione e sviluppo: tutto questo è sicuramente in gran parte dovuto al fattore umano!
L’importanza del feedback
Che importanza hanno i feedback in un processo di rilascio del software? Di che tipo di feedback abbiamo bisogno per produrre software di valore?
A queste domande, sarebbe possibile dare mille risposte diverse, e sarebbero tutte -probabilmente- giuste: il feedback dell’utente finale, come già ampiamente descritto, assume un ruolo centrale durante il processo di sviluppo di un prodotto, ma c’è molto di più dietro.
I feedback positivi sono e assumono un ruolo votivo: servono a dare credito al nostro lavoro e mostrare i risultati ottenuti, garantendo anche un clima di collaborazione ottimale all’interno del team.
Abbiamo più bisogno dei feedback negativi: questi sono infatti informativi e ci permettono di porre l’attenzione e l’effort sulle giuste funzionalità.
Possono essere scoraggianti? Demotivanti? Assolutamente sì.
Rappresentano però uno spunto di riflessione per migliorare una parte o l’intero processo: come in un’attività di data analytics, l’applicazione di una serie di tecniche consolidate può portarci in una comfort zone pericolosa: a volte, dei valori outlier o una loss function hanno meno valore del risultato prodotto per l’utente finale!
E qual è il passo più piccolo per iniziare ad avviare un processo di CD?
Esistono tantissimi cambiamenti che possiamo intraprendere per sposare la Continuous Delivery: uno di questi, è rappresentato dall’adozione di un sistema che permetta l’automazione del processo di build. Docker, in questo senso, come tecnologia agevola non poco il processo, permettendo ai developers (e non solo) di impacchettare i propri “artefatti” in un registry centralizzato, tralasciando tutto ciò che rappresenta l’infrastruttura stessa.
Non solo: integrare pratiche adottate in diversi casi di studio che ci possono sembrare interessanti e adatti alle nostre esigenze, con l’idea di portare valore all’azienda e apprendere nuove tecnologie, è uno step importante.
Sì, ma dove parto?
Dall’attività più noiosa. Automatizzare una parte del flusso di lavoro dove spendiamo più tempo e che ci annoia di più è sicuramente il modo migliore per iniziare!
