Agile vs DevOps: Quale Scegliere e Perché

Quando i team lavorano in silos, si creano lacune di comunicazione che portano al caos. Invece, quando i team lavorano in sinergia, sono molto più efficaci. 

Nell’ambito di questo articolo, tratterò gli approcci agili e DevOps, esempi di quando adottare metodologie specifiche e come il testing viene impattato in ognuno di questi scenari. 

Best practice per lo sviluppo software agile

Rispetto al processo di sviluppo a cascata, l'agile si concentra su uno dei principi cardine, ovvero soddisfare i clienti fin dalle prime fasi del processo e tramite una consegna continua. La consegna continua è possibile solo se coinvolgiamo il team di qualità all'inizio del processo e collaboriamo con loro frequentemente. 

Attualmente, alcune aziende di piccole e medie dimensioni si trovano in una situazione in cui non seguono né l'approccio agile né quello a cascata in modo completo, ma una combinazione di entrambi. I membri dei cosiddetti team agili concentrano così tanta energia su processi granulari come standup di 30 minuti e riunioni di retrospettiva di 60 minuti, dimenticandosi del ritorno sull’investimento che portano, con il risultato che vengono trovati molti bug in produzione. 

JOIN THE COMMUNITY

Upgrade your inbox with more tech leadership wisdom for delivering better software and systems.

Sign up with:

LinkedInGoogleMicrosoft

Or sign up with email:

Comments

This field is for validation purposes and should be left unchanged.

Name*

First name Last name

Business email*

This field is hidden when viewing the form

Free Account Module

Bottom BarLanding PageFooterInlinePop UpSidebarSSO

LinkedIn profile

Seniority*

Select an optionExecutive / C-suiteVPDirectorManagerIndividual ContributorOther

Company's AI adoption maturity*

Select an optionExploring opportunitiesRunning pilotsScaling adoptionEmbedded in the business model

Il settore si è davvero trasformato da un approccio a cascata? 

Sei mai stato in un’organizzazione (che pensavi adottasse processi di sviluppo software agili) solo per scoprire che il team di qualità viene coinvolto nei test solo a sviluppo completato? 

In questo esempio, veniva comunque chiamato agile perché i membri del team di sviluppo lavoravano su più branch (o funzionalità) contemporaneamente in modo iterativo. Ma quando dovevano far testare le proprie feature, aspettavano che tutto lo sviluppo fosse terminato—che è l'essenza del metodo a cascata. Tuttavia, poiché le aziende vogliono muoversi più velocemente per poter ampliare la propria base di clienti, la maggior parte delle volte i team finiscono per accumulare debito tecnico. 

Il modo migliore per risolvere questo problema è trasformare completamente l’organizzazione in agile e lavorare mano nella mano in modo iterativo con il team di qualità. Ciò comporta lavorare con tutti gli stakeholder per assicurarsi che comprendano le conseguenze del mancato passaggio e come questo possa influire sull’esperienza dell’utente finale. 

Framework agili e relative varianti

Per l’ambito di questo articolo, parlerò di due dei framework agili più popolari:

1. Scrum
2. Kanban

Scrum è una metodologia agile utilizzata nello sviluppo software basata su processi iterativi e incrementali. Consiste nell’aderire a periodi di sviluppo a tempo fisso chiamati sprint. La durata degli sprint varia a seconda dell’organizzazione: settimanale, mensile o trimestrale.

C’è una sessione di pianificazione dello sprint, seguita dallo sprint in cui avvengono implementazione e testing, che include daily standup, e si conclude infine con una sessione di retrospettiva. 

Scrum è solitamente implementato nei team di sviluppo prodotto dove i membri devono limitare temporalmente il proprio lavoro per rispettare le scadenze del cliente. Si applica soprattutto alle applicazioni B2C, perché se si attende troppo, la nuova funzionalità potrebbe non essere più una novità—qualcun altro potrebbe averla già implementata! 

Nelle applicazioni B2B, che riguardano principalmente le aziende enterprise, si sfrutta una versione modificata della metodologia agile chiamata SaFe - Scaled Agile framework. 

La maggior parte dei progetti presso le aziende enterprise rientra in una delle seguenti categorie:

1. Livello team
2. Livello programma
3. Livello portafoglio

I progetti a livello di team sono sviluppi basati su funzionalità che coinvolgono ogni membro del team nella gestione del proprio progetto e dei propri processi. Questi team solitamente utilizzano Scrum o Kanban a seconda della natura del loro lavoro.

Se i team fanno parte di organizzazioni di ricerca & sviluppo o di automazione dei test, è fondamentale che seguano il Kanban, che è meno rigido e mira maggiormente a completare il compito attuale piuttosto che passare subito alla prossima novità! Se i team fanno parte dell'organizzazione di sviluppo prodotto, allora tendono a utilizzare i processi scrum. 

I progetti a livello di programma coinvolgono più team che lavorano verso un obiettivo specifico, come la migrazione AWS. Anche se questo progetto può ricadere tra i progetti a livello di portafoglio, sostengo che non necessariamente influenzi i team HR o contabilità.

In questo caso, il progetto di migrazione AWS potrebbe durare mesi a causa di problemi imprevisti, quindi l'obiettivo è completare con successo la migrazione AWS suddividendola in sprint giustificabili. 

I progetti a livello di portafoglio coinvolgono diverse organizzazioni all'interno dell'azienda; un esempio potrebbe essere l'implementazione di JIRA. Ogni organizzazione avrebbe bisogno di workflow JIRA implementati in modo diverso in base alle proprie esigenze. I team delle risorse umane non richiedono test; l'obiettivo è principalmente gestire richieste specifiche dei dipendenti e, una volta risolte, il compito viene contrassegnato come "completato".

Le metodologie Agile dovrebbero essere adottate dalle organizzazioni che sono soggette a continui cambiamenti. Tuttavia, questi cambiamenti devono comunque passare attraverso una fase di test e correzione dei bug, e i test non sempre sono automatizzati, portando così ad un aumento dei tempi di processo.

Infine, quando le funzionalità sono pronte per essere rilasciate, vengono affidate al team build/ops. Quindi, i test vengono svolti iterativamente rispetto all'approccio waterfall, ma non si va molto più indietro nel flusso poiché l'obiettivo non è il test e il rilascio continui. Da qui nasce la necessità dell'approccio DevOps! 

I migliori strumenti di gestione dei test Agile!

1. 

   Testiny

   This is an aggregated rating for this tool including ratings from Crozdesk users and ratings from other sites.

   4.9

   Visit Website
2. 

   Testpad

   This is an aggregated rating for this tool including ratings from Crozdesk users and ratings from other sites.

   4.1

   Visit Website
3. 

   TestMonitor

   This is an aggregated rating for this tool including ratings from Crozdesk users and ratings from other sites.

   4.6

   Visit Website

Approccio DevOps

L’approccio DevOps si focalizza su aspetti che vanno oltre lo sviluppo e il testing e promuove una pipeline CI/CD completamente automatizzata insieme a capacità di monitoraggio. Se Agile accoglie i cambiamenti, l’approccio DevOps punta su test e consegna continui per garantire che i rilasci frequenti agli utenti finali abbiano successo. 

L’obiettivo del team IT Operations è scalare il processo di sviluppo software per accelerare la scrittura e l’aggiornamento del codice responsabile della creazione di nuove applicazioni e servizi e l’aggiornamento delle funzionalità all’interno del team IT.

Anche per quanto riguarda l’organizzazione dei team, attualmente i team qualità e operations IT fanno parte della stessa organizzazione così da poter lavorare fianco a fianco. Infatti, è stato introdotto un nuovo ruolo chiamato TestOps con il compito specifico di configurare le pipeline CI/CD dove i test automatizzati vengono eseguiti contro le pull request, offrendo feedback immediato ai team di sviluppo.

Il testing automatizzato è essenziale per scalare gli sforzi di test e il suo valore si perde se non viene integrato nel test continuo e nel ciclo di rilascio e distribuzione continui. Di conseguenza, il personale TestOps è sempre impegnato nella manutenzione dell’infrastruttura per i test automatizzati.

Ciò assicura che i membri del team operations possano concentrarsi sul fornire un’infrastruttura di livello mondiale per lo sviluppo software senza essere distratti dall’infrastruttura di testing. 

Oggi ci sono molti strumenti e pratiche DevOps che semplificano l’intero processo. 

• Un file di stato di Terraform si riferisce a un insieme di infrastrutture definite e gestite come un’unica unità—così vengono definiti e gestiti i vari ambienti di testing e sviluppo. Terraform aiuta a configurare i server, ma serve un’infrastruttura su cui eseguire questi server. 

• AWS fornisce l’infrastruttura tramite istanze EC2, che attualmente rappresentano il modo più conveniente per configurare ed eseguire questi server. Per fare un passo in più, se il tuo stack tecnologico prevede molti microservizi, con docker compose puoi definire ed eseguire più ambienti docker containerizzati.

• Ansible automatizza il processo di configurazione delle macchine per eseguire qualsiasi processo o server. 

• Kubernetes aiuta a gestire un cluster di queste istanze EC2 come un pod e pianifica l'esecuzione dei container su questo cluster in base alle risorse di calcolo disponibili. 

I migliori strumenti DevOps!

1. 

   SonarQube

   This is an aggregated rating for this tool including ratings from Crozdesk users and ratings from other sites.

   4.4

   Visit Website
2. 

   ManageEngine Applications Manager

   This is an aggregated rating for this tool including ratings from Crozdesk users and ratings from other sites.

   4.3

   Visit Website
3. 

   Spacelift

   Visit Website

Dovresti utilizzare Agile o DevOps?

Sebbene lo sviluppo software Agile vs. DevOps sia un dibattito costante all'interno delle organizzazioni, il modo migliore per affrontarlo è porsi le seguenti domande:

• Qual è l'adattabilità della nostra organizzazione rispetto alle nuove tecnologie? 
• Riusciamo ad opporci ai nostri concorrenti in termini di qualità dei nostri prodotti? 
• I clienti sono propensi a utilizzare i nostri prodotti perché soddisfano le loro aspettative? 

Se le risposte alle domande sopra implicano una qualche forma di negazione, allora è il momento di concentrarsi maggiormente su una combinazione di entrambi gli approcci e personalizzarla in base alle nostre esigenze.

La metodologia ideale per lo sviluppo software

La differenza principale tra i processi di sviluppo software basati su agile e DevOps è che il primo si concentra maggiormente sull'accogliere cambiamenti continui, mentre il secondo si focalizza su test, delivery e deploy continui. La collaborazione tra il team di sviluppo e quello operativo è fondamentale affinché il team dev non sia bloccato. 

Quindi, secondo me, un processo ideale di sviluppo software dovrebbe includere quanto segue:

• Gestione delle customer/user persona e integrazione del feedback dei clienti
• Focus sulle migliori pratiche per evitare l'accumulo di debito tecnico
• Miglioramento continuo, test continui, integrazione continua, delivery continua, deployment continuo e monitoraggio

Questo è come potrebbe apparire il processo:

Gestire diverse personas di cliente non è limitato ai team di product management. Alla fine, perché stiamo sviluppando questi prodotti? Qual è lo scopo di questi prodotti se non vengono usati dai clienti? 

Prendi il classico esempio di Nokia: quando hanno continuato ad accumulare debito tecnico, non tenendo il passo con le tendenze di mercato, nello specifico con l’innovazione del loro concorrente Apple. Si sono concentrati sul seguire cicli sprint rigorosi solo per essere poi dimenticati! 

Tutte le aziende dovrebbero capire perché vengono sviluppate certe funzionalità e a quale tipo di clienti si rivolgono. Questo assicurerà lo sviluppo di funzionalità user-centric. 

Quando viene rilasciato un nuovo prodotto, sia esso una mobile app o una web app, assicurati sempre che ci sia un modo per i clienti di lasciare il proprio feedback. Non tutte le aziende seguono un processo rigoroso di stretta collaborazione con l’assistenza clienti. 

CI/CD

Infine, promuovi l'integrazione continua e la delivery continua basate su AI/ML. Quando un progetto fallisce, non significa necessariamente una mancanza di competenze nei membri del team; spesso si tratta invece di test insufficienti e dell’incapacità di individuare i problemi prima durante lo sviluppo.

Ma a volte, anche con test adeguati e automazione in atto, le cose vanno storte: quindi, se esistesse un sistema di raccomandazione per individuare quando rilasciare e quando invece no, forse si potrebbero evitare tali fallimenti catastrofici.

Iterazioni frequenti aiutano il team di sviluppo a comprendere cosa funziona e cosa no, e favoriscono la riflessione sulla scalabilità. L’avvertimento è che è un processo che richiede tempo! Se un altro sistema di raccomandazione/predizione potesse raccogliere dati sui clienti e prevedere se una specifica funzione possa ottenere successo o fallire ancora prima dell’avvio dello sviluppo, aiuterebbe a snellire il processo per realizzare un prodotto di alta qualità dal giorno 1! 

L’obiettivo complessivo è assicurare che gli impatti sul business si moltiplichino più velocemente quando queste best practice vengono adottate come parte del processo di sviluppo. 

Considerazioni finali

Alla fine, sia Agile che DevOps svolgono ruoli fondamentali nello sviluppo software moderno, ma la scelta giusta dipende dagli obiettivi della tua organizzazione, dalla struttura del team, dalle opzioni di prezzo e dalle necessità del progetto.

Agile si concentra sullo sviluppo iterativo e sulla flessibilità, mentre DevOps enfatizza la consegna continua, l'automazione e la collaborazione tra sviluppo e operazioni. Molte organizzazioni trovano successo combinando entrambi gli approcci per massimizzare efficienza e qualità. Qualunque strada tu scelga, è fondamentale allineare strumenti e processi per favorire l'innovazione e offrire valore più velocemente.

Per ulteriori approfondimenti su come ottimizzare i tuoi flussi di lavoro di sviluppo e rimanere aggiornato sulle tendenze del settore, iscriviti alla newsletter di The CTO Club.