Agile, Scrum e Kanban: cosa diavolo significano davvero queste parole?

Quando uno sviluppatore di software sente notizie su un "nuovo framework JavaScript" o un "nuovo IDE", non ha bisogno di fare altre domande per chiarire di cosa si tratta. Ma se sente parlare di una "nuova struttura agile", probabilmente farà il cenno di Homer-Simpson, fingendo di sapere di cosa si tratta, ma avrà una, e solo una, domanda: cosa diavolo fa "struttura agile" significare?

Nel moderno ambiente di sviluppo software, sentiamo sempre più spesso parole come "agile", "scrum" e "kanban" e sono spesso usate in modo improprio. In questo articolo cercherò di spiegare e chiarire alcuni di questi termini.

Agile

Se vuoi essere l'astuto della folla, dovresti usare la parola "agile" in ogni altra frase quando parli del processo di lavoro. Ha una gamma piuttosto ampia, non ti obbliga a sapere molto sull'argomento di cui stai parlando, ed è un aggettivo o avverbio davvero carino: "pensare agile", "approccio agile", "secondo principi agili". Ma cosa significa veramente "agile"?

"Agile" si riferisce a "sviluppo software agile", l'approccio allo sviluppo che segue i principi agili. Ma cosa diavolo sono i "principi agili?" Dai un'occhiata al Manifesto Agile e ai 12 principi dell'agile, che pongono le basi dello sviluppo agile. Dal Manifesto:

I principi agili incoraggiano la fornitura continua di software funzionante, una stretta comunicazione tra i team e un'elevata adattabilità alle mutevoli esigenze. Se segui questi valori e principi nel tuo lavoro, puoi dire che stai lavorando in un ambiente agile. Quindi, lo sviluppo agile del software non è una metodologia, è solo un insieme di diverse metodologie, framework e tecniche che seguono gli stessi principi. Si può dire che "agile" è un quadro per pensare e prendere decisioni.

Ma perché è così importante seguire questi principi nel nostro lavoro?

Il Manifesto ei principi sono il risultato della ricerca delle migliori soluzioni che si sono evolute nel corso dei decenni in risposta alle sfide dello sviluppo del software. Negli anni '70, '80 e '90, diversi sviluppatori e team in tutto il mondo hanno sperimentato metodi di lavoro e approcci alla risoluzione dei problemi, inventando framework e tecniche diverse (come Scrum e Extreme Programming) e arrivando persino allo stesso idee in parallelo. Infine, nel febbraio 2001, diciassette sviluppatori si sono riuniti e hanno trovato i denominatori comuni per tutte queste diverse idee ed esperienze. Così è stato creato il manifesto.

Mischia

Se parli di metodi "agili" senza sapere cosa significano, potresti sbagliare e dire cose che ti scopriranno davanti all'interlocutore che conosce l'argomento: "Scrum e altre metodologie agili".

Scrum non è una metodologia, anche se tutti l'abbiamo sentito chiamare così più spesso del numero di omicidi in Game of Thrones . Scrum non darà una risposta a tutte le domande e non ti fornirà la procedura precisa per rispondere a ogni situazione che affronti. E probabilmente a causa di questa interpretazione errata, anche la maggior parte delle implementazioni di Scrum sono sbagliate: i team non ottengono valore. Questo si traduce probabilmente nell'affermazione più sciocca su Scrum: "Scrum non funziona".

Cos'è la mischia? La Scrum Guide definisce Scrum come:

Quindi è un framework e, come qualsiasi altro framework, può essere, e viene regolarmente utilizzato, nel modo sbagliato. L'uso efficace di Scrum richiede non solo l'adozione della struttura definita da Scrum, ma anche una profonda comprensione e apprezzamento dei principi Agile nell'intero team.

Scrum è composto dai seguenti ruoli: Product Owner, Scrum Master, Development Team.

Ci sono anche quattro cerimonie Scrum: Planning Meeting, Daily Scrum, Sprint Review, Sprint Retrospective

E i tre artefatti: Product Backlog, Sprint Backlog, Product Increment.

I progetti Scrum sono organizzati in intervalli di tempo regolari, che chiamiamo sprint. In genere durano due settimane.

Un Product Owner è responsabile di guidare la direzione del progetto. Quando vengono determinate nuove attività e funzionalità, il proprietario del prodotto le aggiunge a un backlog di prodotto. Uno sprint inizia con una riunione di pianificazione in cui il team di sviluppo seleziona le attività dal backlog su cui lavorare e pianifica come verranno implementate. Segue lo sviluppo, durante il quale il team di sviluppo utilizza il backlog per tenere traccia dei progressi e si riunisce per la riunione quotidiana al fine di sincronizzare le attività e modificare il piano, se necessario. Il risultato dello sviluppo dovrebbe essere un incremento del prodotto, qualcosa che può essere applicato al prodotto e rilasciato immediatamente. Alla fine dello sprint, l'incremento del prodotto viene presentato al Product Owner durante la revisione dello sprint, dove il product backlog viene aumentato se sono necessarie ulteriori modifiche. Successivamente, l'intero team partecipa alla retrospettiva dello sprint dove parla del processo di lavoro e di come può essere migliorato.

È facile imparare e capire Scrum, ma è difficile da adottare. Ci sono molte ragioni per cui questo framework può o non può essere adatto a un progetto. Spesso richiede molti cambiamenti, non solo nello sviluppo quotidiano, ma anche culturalmente. Scrum si adatta meglio allo sviluppo di prodotti complessi, che durano a lungo e che includono diversi tipi di specialisti.

Perché Scrum è così popolare e perché ha un vantaggio rispetto al tradizionale modello a cascata? In poche parole, perché offre più valore a un prodotto e ai clienti. Con metodi "pesanti" come la cascata, abbondano storie dell'orrore in cui nessuno vede nulla del progetto per mesi. Con Scrum non è possibile.

Scrum è tutto incentrato sul valore che viene fornito agli utenti finali. Se utilizzi davvero Scrum, devi fornire qualcosa di valore ad ogni sprint. Il valore può essere misurato e il team è anche costretto a ispezionare gli impedimenti e ad adattarsi, con l'obiettivo di fornire più valore nell'iterazione successiva.

Nella maggior parte dello sviluppo software non stiamo costruendo un grattacielo; non è necessario che l'intero piano sia pronto prima di iniziare e attenersi a quel piano fino alla fine. Stiamo sviluppando software e abbiamo la capacità di adattarci a diverse situazioni e di modificare i requisiti del prodotto durante lo sviluppo. Per molto tempo, molti sviluppatori hanno considerato questo come l'ottavo peccato mortale, ma dal punto di vista del prodotto è un enorme vantaggio per l'ottimizzazione della prevedibilità e il controllo del rischio. Scrum si sviluppa attorno a questa capacità e la sua implementazione offre un modo affidabile ed efficiente per affrontare i cambiamenti necessari.

Molte tecniche vengono utilizzate insieme a Scrum: planning poker, pair programming, test-driven development (TDD), behavior-driven development (BDD) e altre. Non fanno realmente parte di Scrum, ma piuttosto tecniche compatibili. Un metodo spesso menzionato insieme a Scrum è il kanban, e c'è molta confusione su cosa significhino queste due cose in relazione l'una con l'altra.

Kanban

Quando parli di mischia e kanban, una delle domande più frequenti da parte della folla sarà: "Che cosa è meglio, mischia o kanban?" E non saprai cosa rispondere perché è come confrontare mele e arance, o chiedere: "Cosa c'è di meglio, frittelle o birra?" Entrambi sono migliori.

Kanban è un metodo semplice che mira alla consegna just-in-time senza sovraccaricare i membri del team. È simile a Scrum in quanto l'obiettivo è fornire il massimo valore alla fine, ma è molto più flessibile di Scrum.

Kanban non è stato inventato dalla comunità di sviluppo software. In effetti, ha le sue origini nei processi di produzione in Toyota e ha un ampio utilizzo in altri ambiti. Non ci sono procedure rigorose che dovresti seguire e nessun modo rigoroso in cui dovresti implementare e utilizzare kanban; è, piuttosto, un insieme di principi e pratiche e puoi scegliere tra queste pratiche in base alle tue esigenze. Ma c'è un'implementazione di kanban più utilizzata nello sviluppo di software che include l'uso di una scheda kanban , costituita da colonne che rappresentano le fasi del lavoro e le attività.

Le colonne rappresentano lo stato di un'attività nel processo di sviluppo. L'esempio più semplice è costituito da tre colonne: "Da fare", "In corso" e "Fatto". Pertanto, le attività vengono aggiunte a "Da fare", spostate su "In corso" all'inizio dello sviluppo e considerate "Completate" quando vengono spostate nell'ultima colonna. Ma ovviamente potrebbe essere più complesso:

Backlog → Definizione delle specifiche → Pronto per lo sviluppo → Sviluppo → Revisione del codice → Test → Distribuito (→ Nessuno lo usa davvero → Rimosso completamente).

Ogni colonna può avere sottocolonne; ad esempio, “Sviluppo” può essere suddiviso in “Pianificazione” e “Codifica”; I "test" possono essere suddivisi in "test unitari" e "test di integrazione" e così via. Le colonne potrebbero essere dedicate agli specialisti, se del caso. Il team definisce le colonne e le fasi in base alle proprie esigenze. Secondo la filosofia "pull", le attività dovrebbero entrare nel flusso di lavoro solo quando la loro richiesta è immediata.

Lo scopo di questa bacheca è visualizzare il flusso di lavoro , che è la prima pratica chiave in kanban. In effetti, il kanban può essere fatto senza una tavola! Potrebbe essere un semplice elenco di attività in un foglio Google con diversi colori di sfondo che indicano lo stato dell'attività, oppure possono essere diagrammi di Gantt, diagrammi, tabelle... Potrebbe anche essere un insieme di secchi nel tuo ufficio, dove ognuno rappresenta lo stato dell'attività e dove le palline vengono utilizzate come attività. Basta visualizzare il flusso di lavoro e fornire trasparenza all'intero processo.

Un altro principio importante è ridurre la dimensione del lotto dei tuoi sforzi . Semplificato, questo significa evitare il multitasking. Ciò può significare ridurre il volume delle attività su cui lavori contemporaneamente. Se hai tre designer in un team, il team potrebbe impostare il numero massimo di attività nella colonna "Progettazione" su tre.

Come la mischia, anche kanban vede la squadra come la figura più importante nel processo. Ma non suggerisce ruoli come fa Scrum e potresti mantenere i ruoli esistenti per evitare di apportare modifiche al tuo processo esistente. Lo stesso sta per miglioramento continuo: Kanban generalmente ti incoraggia a imparare e migliorare continuamente, ma non prescrive un evento specifico solo per quel processo, come fa la Sprint Retrospettiva di Scrum.

Quale dovrei usare?

Scrum e kanban non si escludono a vicenda e non sono realmente comparabili. In Scrum, ci sono ruoli definiti, mentre kanban dice: "Che diavolo, mantieni i tuoi ruoli e responsabilità attuali". Scrum ti costringerà a cambiare il tuo modo di lavorare; kanban ti consente di iniziare con il tuo processo esistente. In Scrum, il framework prescrive un programma chiaro per gli eventi; in kanban non hai eventi. Tuttavia, hanno molte somiglianze: entrambi sono incentrati sul valore, i membri del team sono rispettati come "capi" del sistema e, in sostanza, hanno la stessa missione: eliminare continuamente gli sprechi e rimuovere gli ostacoli.

Ma la domanda: "Cosa dovrei usare nel mio particolare progetto e con il mio particolare team?" ha molto più senso. Kanban non richiede molto del processo e dei cambiamenti culturali e, nella maggior parte dei casi, sarà più facile da adottare rispetto a Scrum. Scrum, d'altra parte, offre una struttura significativamente maggiore per guidare il processo, il che può eliminare una grande quantità di sovraccarico fintanto che tutti sono sulla stessa pagina.

Ma il bello di entrambi è che nessuno dei due è un rigido insieme di regole. Non c'è niente che ti impedisca di scegliere e scegliere i migliori elementi di Scrum per te, come una riunione o una revisione quotidiana. E non c'è motivo per cui non puoi incorporare una scheda kanban in Scrum.

Scrum ha dimostrato di essere un framework altamente efficace quando l'intero team lo comprende bene. Tuttavia, nella mia esperienza, trovo difficile lavorare in Scrum con alcuni clienti. Il processo e i cambiamenti culturali necessari per una corretta implementazione di Scrum possono essere eccessivi (soprattutto quando si ha a che fare con qualcuno che crede di creare un nuovo Google!). D'altra parte, il kanban è più flessibile e non costringe le persone a cambiare. Alcuni autori affermano anche che il kanban è un buon percorso verso l'agilità e offre una più semplice implementazione di Scrum. Altri dicono che l'uso di Scrum dovrebbe portare al kanban alla fine.

La verità è che ogni progetto è diverso e non esiste una soluzione valida per tutti. In qualità di project manager, spetta a te determinare cosa funziona meglio per il tuo team.