Che cos'è Agile?

Completato

Il termine Agile nel modulo precedente è stato usato per descrivere uno degli elementi essenziali delle impostazioni cultura di DevOps, che rappresenta la possibilità di rispondere rapidamente ai commenti e alle esigenze dei clienti. Questo termine è apparso anche più volte nell'unità che descrive la correlazione tra DevOps e il ciclo di vita dell'applicazione. Tuttavia, esiste anche un altro significato più specifico di Agile (in formato in maiuscolo), che descrive un approccio allo sviluppo software e alla gestione dei progetti. Questo approccio è comunemente associato alle procedure DevOps. Nello scenario di esempio, la transizione dall'approccio a cascata tradizionale a Agile consente all'organizzazione di realizzare una serie di vantaggi DevOps. In questa unità vengono esaminate le caratteristiche principali di Agile ed esaminarne la correlazione con DevOps.

Principi e valori Agile

Agile è un approccio allo sviluppo di software che promuove la collaborazione in team, il miglioramento continuo e l'automazione, con l'obiettivo finale della distribuzione di software più veloce, affidabile e incentrato sul cliente. Il termine è nato dal Manifesto Agile, creato nel 2001 da un gruppo di sviluppatori di software, fornendo un set di principi guida per lo sviluppo software moderno. Il manifesto include quattro affermazioni fondamentali che hanno prioritario le persone e le interazioni, le soluzioni di lavoro e la collaborazione dei clienti su processi e strumenti rigidi. In particolare, queste istruzioni hanno assegnato più valore a:

• Individui e interazioni su processi e strumenti.
• Il software funzionante più che la documentazione esaustiva.
• La collaborazione con il cliente più che la negoziazione dei contratti.
• Rispondere ai cambiamenti piuttosto che seguire un piano.

Metodi e procedure Agile

I principi Agile Manifesto e Agile forniscono un set di valori e linee guida, ma intenzionalmente non sono prescrittivi in termini di metodi e procedure specifici. Agile è invece progettato per essere flessibile e facilmente adattabile, consentendo alle organizzazioni e ai team di scegliere un approccio più dettagliato in base alle proprie preferenze e esigenze.

Questi approcci dettagliati e completi sono comunemente definiti framework. Il loro scopo è quello di coprire tutte le fasi del ciclo di vita di DevOps, tra cui pianificazione, sviluppo, distribuzione e operazioni. Alcuni dei framework Agile più diffusi includono Scrum e Kanban.

Che cos'è Scrum?

Scrum è un framework usato dai team per gestire il lavoro e risolvere i problemi in modo collaborativo in breve (in genere tra una e quattro settimane) iterazioni chiamate sprint. Per facilitare la collaborazione e lo stato di avanzamento, gli sprint sono strutturati in base a eventi, artefatti e ruoli.

• Gli eventi, comunemente definiti cerimonie, includono riunioni che si svolgono ogni giorno (Scrum giornaliero, in genere limitato a 15 minuti, noto anche come standup giornaliero) e agli inizi e alle conclusioni di ogni sprint (pianificazione dello sprint, revisione dello sprint e retrospettiva dello sprint).
• Gli artefatti definiscono un elenco con priorità di funzionalità, miglioramenti e correzioni da sviluppare. Tali artefatti potrebbero coprire l'intervallo di un progetto o di uno sprint (Product Backlog o Sprint Backlog, rispettivamente), oppure potrebbero aiutare le riunioni scrum giornaliere (bacheche delle attività e grafici burndown sprint). Una bacheca delle attività consente di tenere traccia dello stato di avanzamento di ogni elemento del backlog. Visualizza gli elementi di backlog divisi nelle attività necessarie per completarlo. Le attività vengono inserite in colonne separate (con etichetta To do, In progress e Done) in base al relativo stato. Il grafico di avanzamento sprint funge da indicatore visivo per determinare se il team sia sulla buona strada per completare il lavoro assegnato entro la fine dello sprint. È costituito da un grafico che visualizza il totale giornaliero del lavoro rimanente, in genere mostrato in ore.
• I ruoli includono il proprietario del prodotto, il master Scrum e il team Scrum, ognuno con le proprie responsabilità chiaramente definite. Il proprietario del prodotto rappresenta gli stakeholder del progetto ed è responsabile della definizione, della gestione e della definizione delle priorità del backlog del prodotto. Il master Scrum supervisiona il processo Scrum, cercando aree per miglioramenti, risolvendo eventuali problemi di blocco e assicurandosi che vengano seguiti i principi scrum. Il team Scrum è responsabile della creazione del prodotto, con la proprietà dei componenti di progettazione e qualità.

Nell'evento Sprint Planning il team sceglie gli elementi di backlog da usare durante lo sprint successivo. La selezione viene effettuata in base alla priorità e alla quantità stimata di lavoro necessaria per completare un elemento. La metrica denominata velocità viene usata per misurare la quantità di lavoro che un team può completare in un determinato sprint. Dopo l'avvio dell'esecuzione dello sprint, il team decide come lavorare sugli elementi del Sprint Backlog. Durante la revisione di Sprint, il team dimostra i propri risultati agli stakeholder. L'analisi retrospettiva Sprint fa parte dell'apprendimento continuo. Funge da opportunità per esaminare lo sprint completato più di recente, identificare le aree per il miglioramento e determinare l'elenco delle azioni per lo sprint successivo.

Che cos'è Kanban?

Kanban è la parola giapponese per un'insegna o un cartellone. Nel contesto di Agile, il concetto di Kanban è stato concepito come mezzo per migliorare l'efficienza dei processi di produzione, ma, negli ultimi anni, è diventato prevalente nei progetti di sviluppo software.

Il principio chiave di questo approccio è la visualizzazione del lavoro correlato al progetto sotto forma di bacheche Kanban. Possono trattarsi di schede fisiche o applicazioni software che visualizzano schede disposte in colonne che rappresentano lo stato dei singoli elementi del progetto. I nomi delle colonne comunemente usati includono To-do, Doing e Done, anche se i team possono personalizzarli in modo accurato in modo da riflettere in modo accurato tutte le fasi pertinenti in un flusso di lavoro di recapito del progetto ,ad esempio sviluppo e test. La visualizzazione del lavoro come schede in stati diversi in una bacheca semplifica la valutazione dello stato del progetto e l'identificazione di potenziali problemi di produttività.

Queste schede corrispondono agli elementi di backlog del prodotto nel framework Scrum. Le schede possono essere personalizzate per includere riferimenti ad altri elementi nel processo di distribuzione del prodotto, ad esempio attività e test case.

Anche se il concetto di backlog è comune in Kanban e Scrum, è importante notare che Kanban è più flessibile e non comporta iterazioni. È possibile aggiungere, riscrivere o rimuovere elementi di lavoro dal backlog in base alla capacità del team e alle esigenze mutevoli del progetto o del servizio gestito con Kanban.

In particolare, Kanban promuove l'uso di un modello pull, in cui gli stakeholder aggiungono richieste all'elenco backlog di attività, elementi o lavoro che devono essere completati. Il team di sviluppo seleziona gli elementi dal backlog e li aggiunge al processo di lavoro attivo in base alla priorità e alla disponibilità delle risorse del team. Ciò riduce al minimo i problemi di qualità associati al modello pull, in cui gli stakeholder assegnano arbitrariamente il lavoro ai team di sviluppo, spesso con scadenze irrealistiche. Inoltre, per ottimizzare la produttività, Kanban supporta l'imposizione di limiti al numero di elementi su cui sta lavorando il team di sviluppo, detto lavoro in corso o semplicemente WIP.

Il framework Kanban si basa anche sulle metriche del tempo di lead time e del ciclo per misurare l'efficacia e la velocità effettiva del flusso di lavoro. Il lead time è il tempo totale necessario per passare da un elemento di lavoro all'inizio fino alla consegna al cliente. Il tempo di ciclo rappresenta la durata del lavoro effettivo su un elemento una volta che è stato portato nello stato di lavoro attivo.

Un altro componente comunemente usato di Kanban è un diagramma di flusso cumulativo (CFD). Si tratta di un grafico che illustra il numero di elementi in ogni stato nel tempo, in genere tra diverse settimane. È simile a un grafico di serie temporali in pila, con l'asse orizzontale che rappresenta la sequenza temporale e l'asse verticale che rappresenta il numero cumulativo di elementi di lavoro. Ogni stato viene visualizzato come area diversamente colorata, semplificando l'identificazione delle tendenze nell'elaborazione degli elementi backlog. Un aumento delle dimensioni di una o più aree colorate indica in genere un problema nel flusso di lavoro, ad esempio un collo di bottiglia o un'inefficienza.

Quali sono le differenze tra Scrum e Kanban?

Sia Scrum che Kanban sono considerati framework Agile con l'obiettivo comune di migliorare l'efficienza e l'efficacia dello sviluppo di software. Tuttavia, ognuno di essi offre un approccio diverso per raggiungere questo obiettivo, inclusi i rispettivi principi e procedure. In particolare:

• Frequenza di lavoro: Scrum usa sprint a lunghezza fissa, mentre Kanban opera in base a un modello di flusso continuo, con il lavoro sottoposto a pull dai team di sviluppo in base alla disponibilità delle risorse.
• Ruoli e cerimonie: Scrum ha chiaramente definito ruoli e cerimonie, mentre Kanban non prescrive alcuno, consentendo invece ai team di adattarli in base alle loro esigenze specifiche.
• Pianificazione del lavoro: Scrum usa un backlog prioritario con il lavoro eseguito durante la pianificazione sprint. Kanban usa un backlog dinamico, senza impegni per un periodo specifico. Kanban supporta inoltre il concetto di limiti wip.
• Adattabilità al cambiamento: Scrum scoraggia modifiche al lavoro impegnato durante lo sprint. Kanban facilita l'adattamento alle modifiche in qualsiasi momento.
• Visualizzazioni: Scrum usa lavagne sprint e grafici burn-down. Kanban si basa sulle schede Kanban.
• Metriche: Scrum usa metriche correlate allo sprint, ad esempio velocità e grafici burn-down. Kanban enfatizza tali metriche come il lead time e il tempo del ciclo.