Close

Framework CALMS

Valuta le tue capacità e misura i progressi compiuti nel percorso DevOps.

Primo piano di Ian
Ian Buchanan

Principal Solutions Engineer


CALMS è un framework che valuta la capacità di un'azienda di adottare processi DevOps e consente anche di misurare i risultati durante una trasformazione DevOps. Il termine è stato coniato da Jez Humble, coautore del libro "The DevOps Handbook", ed è l'acronimo di Culture, Automation, Lean, Measurement e Sharing.

Cultura


DevOps non è semplicemente un processo o un approccio diverso allo sviluppo: è un cambiamento culturale. Inoltre, una parte importante di una cultura DevOps è la collaborazione.

Tutti gli strumenti e le soluzioni di automazione del mondo sono inutili se i professionisti dello sviluppo e dell'IT/operativi non lavorano insieme. Questo perché le attività di DevOps non risolvono i problemi degli strumenti, risolvono i problemi umani.

I team DevOps possono essere considerati un'evoluzione dei team Agile, con la differenza che ora il team operativo è automaticamente incluso. La formazione di team orientati al prodotto per sostituire i team basati sulle funzioni rappresenta un passo nella giusta direzione. A questo bisogna aggiungere lo sviluppo, il controllo di qualità, la gestione del prodotto, la progettazione, le operazioni, la gestione dei progetti e qualsiasi altro set di competenze richieste dal prodotto. Invece di avere un unico team che si occupa di tutto o di assumere «professionisti DevOps», è più importante disporre di team basati sul prodotto in grado di lavorare insieme agevolmente.

Poche cose favoriscono la collaborazione come condividere un obiettivo comune e avere un piano per raggiungerlo insieme. Per alcune aziende, il passaggio improvviso a team basati sui prodotti sarebbe una scelta troppo affrettata. Pertanto, è meglio procedere a piccoli passi. I team di sviluppo possono, e dovrebbero, invitare membri appropriati del team operativo a partecipare a sessioni di pianificazione di sprint, standup quotidiani e demo di sprint. I team operativi possono invitare gli sviluppatori chiave alle riunioni. È un modo Agile e organico per tenersi reciprocamente informati su lavoro, idee e difficoltà.

Icona di trofeo
materiale correlato

Scopri di più sui vantaggi di DevOps

Icona del team
materiale correlato

Crea una cultura DevOps

Le sfide e persino le emergenze sono test efficaci della cultura DevOps. Gli sviluppatori, il team operativo e i Customer Advocate affrontano il problema e lo risolvono come un team? L'analisi retrospettiva degli imprevisti si basa sul miglioramento dei risultati per il prossimo imprevisto invece che sull'individuazione delle colpe? Se la risposta è "Sì", è un segnale positivo che indica che l'organizzazione sta adottando una cultura DevOps.

Le aziende di maggior successo adottano la cultura DevOps in ogni reparto e a tutti i livelli dell'organigramma. Su una scala così ampia, il termine "DevOps" è spesso troppo limitato e non più necessario. Queste aziende dispongono di canali di comunicazione aperti e comunicano regolarmente. Ritengono che la soddisfazione dei clienti sia una responsabilità tanto del reparto di gestione del prodotto quanto del team di sviluppo. Sono consapevoli del fatto che le attività di DevOps non rappresentano il lavoro di un singolo team, ma di tutti.

Automazione


L'automazione elimina il lavoro manuale ripetitivo, produce processi ripetibili e crea sistemi affidabili.

Creazione, test, distribuzione e automazione del provisioning sono punti di partenza tipici per i team, se tali operazioni non sono già state attuate. Quale migliore ragione per sviluppatori, tester e operatori di lavorare insieme se non quella di creare sistemi a vantaggio di tutti?

I team appena entrati nel mondo dell'automazione in genere iniziano con la continuous delivery: una procedura che prevede l'esecuzione di tutte le modifiche del codice attraverso una serie di test automatizzati, spesso facilitati da un'infrastruttura basata su cloud, per poi creare un pacchetto di build e promuoverne l'uso negli ambienti mediante distribuzioni automatizzate.

Questo perché, rispetto alle persone, i computer eseguono i test in modo più rigoroso e accurato e questi test sono in grado di rilevare bug e difetti di sicurezza con una maggiore tempestività. Inoltre, durante la distribuzione automatica, il reparto IT/operativo viene avvisato in caso di discrepanze tra gli ambienti, il che consente di ridurre spiacevoli sorprese al momento del rilascio.

Un altro importante contributo di DevOps è la "Configuration as Code". Gli sviluppatori cercano di creare applicazioni modulari e componibili perché sono più affidabili e di più facile manutenzione. Lo stesso ragionamento può essere esteso all'infrastruttura che le ospita, indipendentemente da dove questa risieda, nel cloud o sulla rete aziendale.

"Configuration as Code" e "continuous delivery" non sono gli unici tipi di automazione presenti nel mondo DevOps, ma meritano una menzione speciale perché aiutano ad abbattere i muri tra i team di sviluppo e operativi. Inoltre, quando il team DevOps utilizza distribuzioni automatiche per inviare codice accuratamente testato ad ambienti con provisioning identico, la frase "sul mio computer funziona" diventa irrilevante.

Lean


Quando sentiamo parlare di "Lean" nell'ambito del software, in genere pensiamo all'eliminazione di attività a basso valore aggiunto e a movimenti rapidi, scattanti, Agile. Ancora più rilevanti per DevOps sono i concetti di miglioramento continuo e accettazione degli errori, che sono alla base di un approccio sperimentale.

La mentalità DevOps riconosce opportunità di miglioramento continuo ovunque. Alcune sono ovvie, ad esempio l'organizzazione di retrospettive condotte regolarmente per migliorare i processi del team. Altre sono più sottili, ad esempio test A/B che sperimentano diversi approcci di onboarding per nuovi utenti del prodotto.

Il miglioramento continuo è diventata un'idea di tendenza grazie allo sviluppo Agile. I primi ad adottare la metodologia Agile hanno dimostrato che un prodotto semplice nelle mani dei clienti oggi è più prezioso di un prodotto perfetto nelle mani dei clienti tra sei mesi. Se il prodotto viene migliorato continuamente, i clienti resteranno fedeli.

Tuttavia, gli errori sono inevitabili. Quindi, tanto vale preparare il team a rilevarli, correggerli e imparare da essi (alcuni definiscono questo approccio come “anti-fragile”). In Atlassian, riteniamo che se non sbagli almeno una volta ogni tanto, significa che non ti stai impegnando abbastanza.

Nel contesto di DevOps, l'errore non è un reato punibile. I team partono dal presupposto che prima o poi qualcosa è destinato ad andare storto, pertanto si preparano a rapidi rilevamenti e ripristini. Le analisi retrospettive si focalizzano su dove si sono verificati gli errori nei processi e su come rafforzare i processi stessi, non su quale membro del team abbia commesso errori nella creazione di codice. Questo perché il miglioramento continuo e gli errori vanno di pari passo.

Misurazione


Senza dati è difficile dimostrare che i tentativi di miglioramento continuo stiano effettivamente producendo dei risultati. Fortunatamente, sono disponibili moltissimi strumenti e tecnologie per misurare le prestazioni, come il tempo di utilizzo del prodotto da parte degli utenti, le vendite generate da post del blog o la frequenza con cui vengono visualizzati avvisi critici nei log.

Sebbene sia possibile misurare praticamente tutto, ciò non significa che si debba misurare tutto. Prendi ispirazione dallo sviluppo Agile e inizia dalle basi:

Quanto tempo ci è voluto per passare dallo sviluppo alla distribuzione?

Con che frequenza si verificano bug o errori ricorrenti?

Quanto tempo occorre per il ripristino dopo un errore di sistema?

Quante persone utilizzano il prodotto attualmente?

Quanti utenti hai acquisito/perso questa settimana?

Con una base solida, è più facile acquisire metriche sofisticate sull'utilizzo delle funzioni, sui percorsi dei clienti e sugli accordi sui livelli di servizio (SLA). Le informazioni ottenute sono utili al momento della definizione degli obiettivi e delle specifiche per la prossima grande mossa.

Tutti questi dati utili aiuteranno il tuo team a prendere decisioni, ma saranno ancora più preziosi se condivisi con altri team, soprattutto di altri reparti. Ad esempio, il team di marketing è sempre alla ricerca di nuove funzioni da commercializzare. Tuttavia, nel frattempo si assiste a un tasso elevato di abbandono da parte dei clienti perché il prodotto è sommerso dal debito tecnico. Fornire dati utente a supporto della tua roadmap, anche se carenti di funzioni e pieni di correzioni, consente di creare consenso più facilmente e di ottenere la fiducia degli stakeholder.

Condivisione


Per quanto si possa desiderare uno strumento che trasformi tutti i team in team DevOps ad alte prestazioni, questo processo richiede una combinazione di pratiche, filosofie culturali e strumenti. Tuttavia, è uno sforzo che vale la pena compiere, visti i vantaggi che derivano dall'abbattimento dei silos dei team di sviluppo e delle operazioni: maggiore fiducia, rilasci dei software più rapidi, distribuzioni più affidabili e un ciclo di feedback migliore tra team e clienti.

L'adozione di DevOps non è un'attività semplice. Tuttavia, con la mentalità, l'impegno e gli strumenti giusti, un'organizzazione può operare al suo interno una trasformazione DevOps che offre vantaggi significativi.

L'attrito di lunga data tra team di sviluppo e operativi è dovuto in gran parte alla mancanza di un terreno comune. Riteniamo che la condivisione di responsabilità e successi possa fare molto per colmare questo divario. Gli sviluppatori possono ottenere gratitudine immediata contribuendo a farsi carico di uno dei principali oneri dei team operativi: il pager (che al giorno d'oggi è più un concetto simbolico). La cultura DevOps è fermamente convinta che le stesse persone che creano un'applicazione debbano essere coinvolte nel rilascio e nella gestione.

In conclusione...


Da questa idea nasce il concetto che chi crea qualcosa la gestisce, il che favorisce un approccio pratico tra team. Ciò non significa assumere sviluppatori e aspettarsi semplicemente che siano anche eccellenti. Significa che sviluppatori e operatori devono collaborare in tutte le fasi del ciclo di vita dell'applicazione. Inoltre, i report hanno dimostrato che il codice e i prodotti sottoposti a revisione paritaria rappresentano l'unica revisione che si traduce in un miglioramento della consegna e delle prestazioni; di fatto, l'efficacia della revisione esterna non si è rivelata maggiore rispetto alla scelta di non condurre alcuna revisione.

I ruoli all'interno dei team che adottano DevOps sono spesso intercambiabili. Ad esempio, gli sviluppatori che gestiscono i ticket rilevati dagli utenti finali risolvono anche i problemi di produzione. Queste persone rispondono ai ticket urgenti segnalati dai clienti, creando patch quando necessario, e agiscono tramite il backlog dei difetti segnalati dai clienti. Lo "sviluppatore di assistenza" apprende molto sul modo in cui l'applicazione viene utilizzata nella vita reale. Inoltre, grazie all'elevata disponibilità del team operativo, i team di sviluppo costruiscono fiducia e rispetto reciproco.

Atlassian ha creato Open DevOps per i team che vogliono creare la toolchain desiderata con gli strumenti che preferiscono grazie alle integrazioni con i fornitori leader di settore e alle app del Marketplace. Provalo subito.

Ian Buchanan
Ian Buchanan

Ian Buchanan è Principal Solutions Engineer per DevOps presso Atlassian, dove si occupa della community DevOps emergente e dell'applicazione di Jira, Bitbucket e Bamboo per migliorare la continuous integration e la continuous delivery. Ian Buchanan vanta una lunga e vasta esperienza delle tecnologie Java e .NET ed è noto per essere un promotore delle pratiche Lean e Agile nelle aziende di grandi dimensioni.

Nel corso della sua carriera, ha gestito con successo strumenti per lo sviluppo software aziendale in tutte le fasi del loro ciclo di vita, dall'inizio alla fine. Si è occupato del miglioramento dei processi a livello di organizzazione riuscendo a ottenere maggiore produttività, qualità superiore e migliore soddisfazione del cliente. Ha creato team Agile multinazionali in cui viene valorizzata la capacità di gestire e organizzare autonomamente il lavoro. Quando non parla o codifica, Ian si dedica alle sue passioni: parser, metaprogrammazione e linguaggi specifici di dominio.


Condividi l'articolo
Argomento successivo

Letture consigliate

Aggiungi ai preferiti queste risorse per ricevere informazioni sui tipi di team DevOps e aggiornamenti continui su DevOps in Atlassian.

Illustrazione su Devops

Community DevOps

Illustrazione su Devops

Percorso di apprendimento DevOps

Illustrazione di una mappa

Inizia gratis

Iscriviti alla nostra newsletter DevOps

Thank you for signing up