Il legame storico tra DevOps e Agile è innegabile. La nascita della relazione con DevOps risale alla Conferenza Agile del 2008, durante la quale Patrick DuBois e Andrew Clay Schafer cercarono di definire il concetto di "infrastruttura Agile".

Sebbene Patrick abbia coniato il termine "DevOps" in un secondo momento, la Conferenza Agile continua a onorare questa connessione con DevOps. Ma approfondiamo la questione e consideriamo le relazioni pratiche esistenti tra Agile e DevOps, esaminando quello che c'è sotto la superficie di Scrum e della continuous delivery.

In alcuni team, Scrum è la differenza tra una lotta costante e frustrante e un lavoro di squadra produttivo e gratificante. In altri, sostituisce le politiche e l'eccessivo impegno per l'obiettività e la concentrazione. Può anche essere accolto come se fosse un dogma. Quando i vincoli dell'azienda o del lavoro stesso richiedono qualcosa di diverso, un team Agile sfrutterà i principi che sono alla base di Scrum, quindi ispezionerà le loro pratiche e si adatterà per diventare più efficace. Ciò è particolarmente importante quando Scrum viene applicato al di fuori del contesto dello sviluppo software.

Nella comunità DevOps, coloro che hanno esperienza in ambito Agile prendono atto del fatto che Scrum è utile per tenere traccia del lavoro pianificato. È possibile pianificare alcune attività operative: rilascio di una grande modifica di sistema, spostamento tra data center o esecuzione di aggiornamenti del sistema. Tuttavia, la maggior parte delle attività operative non viene pianificata: picchi di prestazioni, interruzioni del sistema e violazioni della sicurezza. Questi eventi richiedono una risposta immediata. Non c'è tempo di attendere per assegnare la priorità in un backlog o durante la successiva sessione di pianificazione degli sprint. Per questo motivo, molti team che hanno adottato il pensiero DevOps, guardano oltre Scrum, in direzione di Kanban. Questo li aiuta a tenere traccia di entrambi i tipi di lavoro e a capire l'interazione che li lega. In alternativa, adottano un approccio ibrido, spesso chiamato scrumban o kanplan (Kanban con un backlog).

Per molti versi, l'elemento chiave per un'adozione estesa di Scrum potrebbe essere il fatto di non imporre pratiche tecniche. Le pratiche di gestione leggera di Scrum spesso fanno una grande differenza per un team. Laddove una volta c'erano priorità concorrenti provenienti da più origini, ora c'è un'unica serie di priorità nel backlog. Inoltre, laddove un tempo c'era troppo lavoro in corso, ora c'è un piano vincolato da ciò che il tempo ha dimostrato essere realmente possibile. Questi fattori, combinati, possono portare un team a nuovi livelli di produttività. Tuttavia, il team potrebbe trovarsi vincolato dalla mancanza di pratiche tecniche, come revisioni della codifica, test di accettazione automatizzati e continuous integration.

Altri processi Agile, come l'Extreme Programming, hanno forti posizioni su come le pratiche tecniche supportino la capacità del team di mantenere un ritmo sostenibile e di fornire trasparenza e visibilità al management e agli stakeholder. Alcuni team Scrum sono costretti a inserire i task tecnici nel backlog. Sebbene questa scelta rientri nelle indicazioni di Scrum, evidenzia subito il problema pratico del pregiudizio dell'owner di prodotto verso le funzioni. A meno che l'owner di prodotto non disponga di una certa conoscenza tecnica, potrebbe non avere le competenze necessarie per valutare il rapporto costi-benefici delle pratiche tecniche. Ciò diventa ancora più difficile per un owner di prodotto poiché le attività tecniche si estendono alle operazioni per supportare affidabilità, prestazioni e sicurezza.

In Atlassian, abbiamo riconosciuto la necessità di avere due ruoli diversi per i prodotti che gestiamo. I nostri owner di prodotto sono bravi a comprendere le funzioni di cui gli utenti hanno bisogno, ma non lo sono altrettanto nel valutarle rispetto a capacità non funzionali come prestazioni, affidabilità e sicurezza. Pertanto, per alcuni prodotti SaaS di Atlassian è presente anche un owner di servizio, che ha il compito di definire le priorità di tali capacità non funzionali. Di tanto in tanto i due ruoli potrebbero essere costretti a una sorta di braccio di ferro, ma la maggior parte delle volte i team possono lavorare in modo indipendente. Questo potrebbe non essere l'unico modo per "amplificare il feedback" dei team operativi, ma aiuta a superare un pregiudizio fin troppo comune negli owner di prodotto riguardo alle funzioni. Questo approccio che prevede la presenza di due owner non è l'unico percorso che conduce a DevOps. Ciò che è importante è comprendere queste caratteristiche non funzionali come" funzioni" ed essere in grado di pianificarle e definirne le priorità, proprio come qualsiasi storia utente funzionale.

In ultima analisi, nessuna di queste critiche mosse a Scrum è del tutto inerente a Scrum stesso. Come per tutti i metodi Agile, Scrum presenta un meccanismo di "miglioramento del processo" integrato chiamato retrospettiva. Pertanto, è ragionevole credere che alcuni team Scrum attingeranno a DevOps come fonte di ispirazione e useranno la retrospettiva Scrum come opportunità per adattarsi a DevOps. Tuttavia, è facile comprendere che la maggior parte dei team ha bisogno di idee esterne. Fino a quando non diventerà una tendenza comune (e forse anche insegnato a scuola), DevOps non sarà un risultato organico di Scrum. Il fatto che il team coinvolga un Agile Coach o un coach DevOps è probabilmente irrilevante, a condizione che quella persona possa portare esperienza nell'automazione attraverso la creazione, i test e la distribuzione di software.

Se eseguita correttamente, la disciplina della continuous delivery aiuta a limitare il lavoro in corso, mentre l'automazione della distribuzione contribuisce a elevare i vincoli. In questo modo, la CD aiuta il team di sviluppo software a effettuare consegne con una maggiore frequenza e una qualità superiore, invece di dover scegliere tra l'una e l'altra cosa. Tuttavia, così come i team che si concentrano solo su Scrum potrebbero perdere di vista il contesto più ampio di Agile, allo stesso modo anche i team che si concentrano sulla continuous delivery potrebbero non cogliere il contesto più ampio di DevOps.

La pratica di CD non risolve direttamente i problemi di comunicazione tra l'azienda e un team software. Se l'azienda ha un ciclo di pianificazione che dura un anno ed è basato sul budget, il team che consegna ogni commit in produzione potrebbe dover attendere mesi prima che l'azienda possa reagire. Troppo spesso queste reazioni arrivano come funzioni graduali, ad esempio l'annullamento del progetto o, peggio ancora, il raddoppiamento delle dimensioni del team di progetto (poiché l'afflusso di un elevato numero di nuove persone crea scompiglio).

Il modello Agile Fluency indica come primo livello di fluidità il "Focus on Value", in cui i team si concentrano sulla trasparenza e l'allineamento. Senza questa fluidità, la CD potrebbe facilmente degenerare in un ciclo infinito di miglioramenti tecnici che non produce alcun valore apprezzabile per l'azienda. Un team potrebbe diventare bravo nel consegnare velocemente un prodotto di alta qualità che, tuttavia, ha un valore basso per gli utenti finali o l'azienda. Anche quando sono presenti numerosi utenti che esprimono un giudizio positivo, la valutazione del valore basso potrebbe essere effettuata solo a un livello di portfolio aziendale più ampio. In assenza di questa importante fluidità, è difficile valutare le pratiche tecniche rispetto alle funzioni. Si tratta di un aspetto particolarmente importante per un team con una base di codice legacy, che potrebbe non disporre di test automatici o di una progettazione adatta per una distribuzione frequente. In un contesto legacy, la trasformazione CD può richiedere anni. Quindi, è molto più importante essere in grado di dimostrare i vantaggi aziendali.

DevOps è molto più dell'automazione della pipeline di distribuzione. Per usare le parole di John Allspaw, DevOps è "un team operativo che pensa come un team di sviluppo e un team di sviluppo che pensa come un team operativo". Elaborando ulteriormente questo pensiero, Gene Kim spiega i tre modi che rappresentano i principi di DevOps:

La continuous delivery (CD) si concentra sul primo modo: automazione del flusso dallo sviluppo alle operazioni. L'automazione svolge un ruolo evidente nell'accelerare un sistema di distribuzione. Tuttavia, il pensiero sistemico è molto più complesso della semplice automazione.

Il secondo modo si basa sul principio che "anche gli sviluppatori portano il cercapersone".  Sebbene l'uso letterale dei cercapersone possa non essere necessario, questa frase significa che anche gli sviluppatori devono essere coinvolti nella risoluzione dei ticket operativi, in modo che possano comprendere meglio le conseguenze delle loro scelte di sviluppo. Ad esempio, il loro coinvolgimento potrebbe indurli a posizionare i messaggi dei log in luoghi migliori e a renderli più significativi. Non è solo una questione di consapevolezza. Gli sviluppatori portano anche la loro comprensione interna del sistema nelle attività di risoluzione dei problemi, in modo da accelerare l'individuazione e l'implementazione di una risoluzione.

Il terzo modo consiste nell'effettuare esperimenti incrementali nel sistema nel suo insieme, non solo in termini di modifiche all'applicazione che si sposta nella pipeline. In altre parole, è relativamente facile vedere quanto tempo impiega l'automazione e utilizzare un'infrastruttura sempre più potente per continuare a migliorarla. È più difficile capire in che modo i passaggi di consegne tra ruoli o organizzazioni introducano ritardi. Ciò significa che i team effettuano "ispezioni e adattamenti" lungo l'intero flusso di lavoro di consegna, alla ricerca di opportunità di miglioramento della collaborazione umana. Per questo motivo, la CD richiede l'abitudine di adattarsi e migliorare. Se il team non riflette su come diventare più efficace per mettere a punto e correggere il suo comportamento su qualsiasi altro aspetto, anche la CD non crescerà e non farà progressi. Il team deve sentirsi in grado di risolvere i propri problemi.

In Scrum, ogni retrospettiva offre l'opportunità di migliorare le pratiche e gli strumenti. Tuttavia, se il team non approfitta di queste opportunità per risolvere problemi tecnici sia a breve che a lungo termine, si limiterà semplicemente ad attendere che l'owner di prodotto inserisca i task di CD nel backlog, cosa che non accadrà mai.

La metodologia Scrum si basa principalmente sul principio Agile "Accogliamo positivamente l'evoluzione dei requisiti, anche in fase avanzata di sviluppo. I processi Agile sfruttano il cambiamento per il vantaggio competitivo del cliente"."

La continuous delivery si basa principalmente sul principio Agile "La nostra massima priorità è soddisfare il cliente attraverso la continuous delivery di software di valore in tempi brevi".

Ciò significa che essere Agile riguarda di più l'accettazione dei cambiamenti in entrata e in uscita piuttosto che le cerimonie, come le riunioni stand-up e la pianificazione sprint. In realtà, ci sono altri 10 principi nel Manifesto Agile. Piuttosto che cercare di scegliere tra i principi, si dovrebbero considerare come unica entità. Insieme questi principi rappresentano un'attitudine verso il cambiamento comune sia ad Agile che a DevOps.

Queste persone sono rimaste bloccate nel tentativo di eseguire sistemi fragili che sono anche quelli più importanti per l'azienda e pertanto rappresentano anche gli ambiti in cui sono necessari i cambiamenti più urgenti. In quanto tale, l'idea Agile di accogliere il cambiamento non è fine a se stessa, ma riguarda il fatto di ritenere lo sviluppo responsabile della qualità delle modifiche introdotte, migliorando al contempo la capacità complessiva di fornire valore aziendale. Questa attenzione al valore aziendale è un altro aspetto condiviso da Agile e DevOps.

Infine, né Agile né DevOps sono di per sé obiettivi aziendali. Entrambi sono movimenti culturali che possono ispirare la tua organizzazione a raggiungere i suoi obiettivi con mezzi migliori. Agile e DevOps funzionano meglio quando operano insieme e non come avversari. Il segreto per evitare di cadere nella trappola di confrontare queste due idee è di comprendere i valori e i principi più profondi su cui si sono formate. Delle definizioni rapide, ma ristrette, determinano un pensiero in silos. Ora che sai che Agile è molto di più di Scrum e che DevOps è molto di più della CD, sei pronto a provare la potente combinazione di Agile e DevOps.

Forse la sfida più grande che si incontra quando si lavora con più strumenti è il costante cambiamento di contesto e l'interruzione che ne deriva. Possono essere necessarie ore per tornare al flusso se si viene interrotti da un task non codificato. Per questo motivo, sempre più persone stanno automatizzando i loro fornitori e gli strumenti di gestione del lavoro Git. Ecco tre delle regole di automazione più comuni:

1. Quando viene creato un commit e lo stato è "Da Completare", effettua la transizione del ticket Jira a "In corso". Vai alla regola.

2. Viene effettuata la transizione a "Completato" quando viene eseguito il merge della pull request. Vai alla regola.

3. Se una build non riesce in Jenkins, aggiungi un commento al ticket Jira e invia un messaggio Slack al team. Vai alla regola.

Consulta queste regole di automazione e centinaia di altre regole nella libreria dei modelli di Automazione Jira.

Vai alla libreria