Quali sono le 6 differenze principali tra DevOps e Scrum? (DevOps e Scrum a confronto)

Durante le lezioni DevOps dal vivo e i corsi di preparazione ai programmi di certificazione abbiamo notato che una domanda torna sempre. Oggi ho deciso di scrivere questo breve articolo per rispondere: «Quali sono le differenze tra DevOps e Scrum?», ossia «DevOps e Scrum a confronto».

Oggi esaminerò le 6 differenze principali. Cominciamo!

Differenza 1: Con DevOps distribuisci il codice in produzione alla fine di ogni iterazione (sprint), mentre con Scrum l'obiettivo è solo avere codice rilasciabile alla fine di ogni iterazione.

È uno dei principali limiti di Scrum e uno dei motivi più importanti, se non il primo, per cui Scrum fallisce in molte organizzazioni. Se non distribuisci il codice alla fine di ogni iterazione, di solito lo conservi sui server di staging o, peggio, lo lasci fermo nel sistema di controllo di versione (CVS) finché un direttore di progetto, che di solito non sa nulla di ingegneria del software, decide quando mandarlo in produzione. Conosco grandi banche e società di telecomunicazioni che eseguono deployment in produzione ogni 6 mesi. Sembra uno scherzo, ma non lo è. Questi deployment big bang provocano molti incidenti della massima priorità e gravità in produzione, peggiorano il morale e spingono più dipendenti ad aggiornare il curriculum. Senza contare le accuse reciproche e le lotte interne tra persone senza competenze tecniche che cercano qualcuno a cui attribuire i propri fallimenti.

Differenza 2: Con DevOps, l'automazione dei test e l'integrazione continua del software, prerequisiti del rilascio continuo, sono parte integrante dello sviluppo. Con Scrum il rilascio del software passa in secondo piano ed è pianificato e gestito da persone estranee allo sviluppo.

Anche questa è una delle debolezze più gravi di Scrum. Il processo Scrum offre un contributo minimo o nullo alle pratiche di rilascio, mentre DevOps richiede una pipeline di rilascio, test automatizzati e un'architettura di produzione che consenta ai team di eseguire deployment in produzione con un solo clic. Il processo Scrum per il rilascio del software risale al 1986. Hirotaka Takeuchi e Ikujiro Nonaka lo presentarono per la prima volta su Harvard Business Review con un articolo intitolato «New Product Development Game». Oltre 30 anni dopo il debutto di Scrum, le modalità con cui i team dovrebbero gestire il rilascio del software sono notevolmente migliorate. Oggi DevOps risponde a domande a cui Scrum non ha dato risposta.

Differenza 3: Con DevOps i progetti sono orientati a prodotti e servizi che creano valore per l'organizzazione, mentre Scrum non offre la maturità necessaria per contribuire ai risultati di business.

DevOps considera i team di ingegneria unità intelligenti che portano a termine il lavoro e forniscono prodotti e servizi software funzionanti per servire i clienti e generare ricavi. Purtroppo Scrum non insegna ai suoi membri nulla sulla maturità aziendale. Se hai mai pensato che tutti questi rituali «indiscutibili» di Scrum, come il divieto di partecipare da seduti alla riunione quotidiana in piedi, sembrino piacevoli, ma che ingegneri altamente qualificati e ben pagati si comportino come bambini all'asilo e lo Scrum Master come il loro insegnante, è perché Scrum non insegna agli ingegneri a comportarsi da professionisti. Con DevOps, tutte le persone in un'organizzazione di ingegneria, a prescindere dalle effettive competenze ed esperienze, lavorano da professionisti per creare valore aziendale. Si evitano quindi discussioni inutili su argomenti assurdi, come chiedersi se ci si possa sedere durante la riunione quotidiana in piedi. Con DevOps usi le energie del brainstorming per individuare e migliorare le soluzioni software che possono far guadagnare di più alla tua azienda!

Differenza 4: Con DevOps tutti gli ingegneri del team si occupano della qualità del servizio, quindi del software, e dell'eccellenza operativa. Con Scrum, l'assicurazione della qualità e le attività operative sono compito di qualcun altro.

Nella maggior parte dei team Scrum l'assicurazione della qualità del software è monopolio di tester esterni. Il deployment e la gestione operativa sono affidati agli amministratori di sistema. La distanza dei team Scrum dalla qualità del rilascio e da ciò che avviene al software in produzione è un altro dei motivi principali per cui molte organizzazioni che adottano Scrum incontrano difficoltà. In DevOps l'assicurazione della qualità è responsabilità condivisa da tutti nell'organizzazione di ingegneria del software. Gli ingegneri full-stack DevOps tengono d'occhio rilascio, sicurezza, stabilità, prestazioni, manutenibilità, operatività e tutti gli altri aspetti non funzionali, dall'ideazione fino alla fine del ciclo di vita. I team DevOps che riuniscono tutte le competenze per sviluppare, garantire la qualità e gestire il software sono nelle condizioni di riuscire e ottenere ottimi risultati aziendali.

Differenza 5: DevOps offre indicazioni su come progettare l'architettura del software per garantire qualità e rilascio continuo, mentre Scrum non dà supporto per definire un'architettura adeguata.

Scrum non offre supporto o indicazioni ai team di ingegneria per definire una direzione e una visione architetturali adeguate. Ricorda che sono passati più di 30 anni da quando Hirotaka Takeuchi e Ikujiro Nonaka lo hanno introdotto. Con DevOps, prodotti, servizi e API di microservizi nell'architettura devono essere debolmente accoppiati. Ogni team DevOps deve rispondere di una sola parte di questa architettura e può progettare, sviluppare e distribuire il proprio software in autonomia. Un meccanismo di avviso precoce nella pipeline di deployment dovrebbe informare automaticamente e rapidamente i team DevOps dei possibili effetti indesiderati di qualsiasi check-in di codice.

Differenza 6: DevOps si concentra sull'intera organizzazione di ingegneria del software per ottenere ottimi risultati aziendali, mentre Scrum si occupa soltanto degli sviluppatori.

Scrum si concentra su piccoli team di sviluppo da 5 a 9 persone. Se chiedessi se possono essere 10, secondo la teoria Scrum la risposta sarebbe no. Perché? Non si sa! Comunque, questa visione ristretta dell'ingegneria del software di solito rende Scrum poco adatto alle organizzazioni perché Scrum non spiega come integrare un team Scrum in un'organizzazione professionale per creare valore. DevOps suggerisce di creare team orientati a prodotti e servizi. Sono team indipendenti, interfunzionali, autonomi, autosufficienti e di solito piccoli, che coprono tutte le fasi del ciclo di ingegneria del software di un prodotto e servizio, anziché di un progetto temporaneo. Si occupano di architettura, progettazione, codifica, test, sperimentazione, deployment, attività operative e manutenzione. Hai letto bene. Chi può gestire e mantenere il software meglio di chi lo ha creato? Nessuno, naturalmente. Per questo non sorprende che i team DevOps più efficaci di Amazon e Netflix non abbandonino prodotti e servizi dopo il rilascio. Sono anche responsabili di gestire e mantenere il software nei propri sistemi di produzione.

Dopo aver letto queste differenze, dovresti capire perché DevOps sta diventando la prossima generazione dell'agilità!

Tra pochi anni DevOps sarà pienamente accettato come un approccio più ampio che comprende Scrum perché organizzazioni molto grandi come Google, Amazon, Facebook, Etsy, Netflix e molte altre hanno già adottato DevOps.

Presto arriverà ovunque!

International DevOps Certification Academy™ ti offre tutto ciò che serve per imparare DevOps con facilità e superare l'esame di certificazione DevOps! Come sempre, io e il mio team siamo a disposizione per qualsiasi domanda.

Scopri la migliore offerta per iniziare, solo oggi! >>

Accedi a International DevOps Certification Academy™ >>

P.S.: siamo sinceri per un momento! Sappiamo che oggi poche persone leggono i post dei blog. Continuiamo comunque a dedicare il nostro tempo a scrivere per te, perché anche se soltanto poche persone leggono questo articolo e imparano qualcosa, consideriamo riuscita la nostra missione di servire la comunità DevOps mondiale!

Se apprezzi il lavoro che abbiamo dedicato a scrivere questo articolo, faccelo sapere! Se hai letto fin qui e hai trovato utile l'articolo, lascia una recensione in fondo alla pagina e condividilo con i tuoi contatti!

GRAZIE IN ANTICIPO! :)