I team di software di oggi sono, almeno nei loro processi, più Agili! Sono disposti a pensare al di fuori dei parametri impostati per seguire ciò che funziona per loro. Sono desiderosi di apprendere e adottare nuove tecniche di project management e processi di progetto.
Un metodo di gestione del progetto chiamato Kanban ha fatto il giro del settore del software per diversi anni e ha guadagnato valuta negli ultimi cinque anni. Insieme alle metodologie Agile, l'adozione del metodo Kanban ha dato alle aziende molto da festeggiare.
Ma c'è anche la critica che Kanban non è altro che un elenco glorificato di cose da fare. Quindi di cosa si tratta? Scopriamolo.
Che cos'è Kanban?
Se la tua azienda è pronta ad andare oltre il tradizionale approccio di gestione dei progetti software, oggi non c'è carenza di tecniche di gestione dei progetti.
Per uno, esiste il sistema di gestione dei progetti Agile, che si concentra su metodi non lineari e iterativi di sviluppo software. L'uso di metodi Agile è evidente in Scrum, che si concentra su un approccio più flessibile alla gestione del progetto.
Agile ha anche collegamenti ad altri framework di gestione dei progetti come Kanban ed Extreme Programming. Di questi, Kanban ha raggiunto molta popolarità. Dopotutto, chi non vuole un processo evoluto dai giapponesi?
Kanban è un concetto che si è evoluto nello stabilimento di produzione di Toyota per ottenere una produzione just-in-time (JIT) che riduce i costi e consente un minore utilizzo delle risorse. Fondamentalmente, segue il principio del "pull" del lavoro, nel senso che compiti o prodotti devono essere "tirati" dai requisiti e dalla domanda e non "spinti" dall'alto verso il basso. È stato sviluppato per garantire una migliore conservazione dei componenti automobilistici negli stabilimenti Toyota, in base alla domanda. Ciò significava che con l'aumento della domanda, le richieste sarebbero state completate.
Il concetto è stato adattato all'industria del software con alcuni cambiamenti di David Anderson, nel suo libro del 2010, Kanban . Da allora, è stato utilizzato per vari progetti con grande successo. Può essere di grande aiuto in progetti complessi che hanno il potenziale di soffrire di sovraccarico da un lato del ciclo di sviluppo.
Fondamentalmente, il sistema Kanban considera il processo del progetto software come una pipeline. Supponiamo che un processo software abbia tre tipi di attività: analisi, sviluppo, test e infine implementazione. Diciamo che ci sono venti attività che devono essere completate.
Nel caso di un tradizionale sistema di gestione dei progetti se, ad esempio,
- Ci sono 25 storie in totale
- Gli analisti sono in grado di gestire cinque storie a settimana
- Gli sviluppatori sono in grado di gestire cinque storie a settimana
- I tester sono limitati a tre storie a settimana
In questa situazione, il lavoro si accumula semplicemente alla fine dei tester. Alla fine della settimana 1, la situazione sarà la seguente:
- Solo tre storie sono passate alla distribuzione.
- Gli sviluppatori e gli analisti lavorano su tre storie, poiché i tester non sono in grado di prendere l'output degli sviluppatori e testare lo stesso.
- Il lavoro viene ammucchiato, lasciando gli sviluppatori, gli analisti e il project manager, in una soluzione.
Gli analisti e gli sviluppatori ora possono semplicemente fare schioccare i pollici! Oppure il loro manager potrebbe rendersi conto che sono inattivi e riallocarli in un altro progetto, in cui potrebbe verificarsi una situazione simile. Quindi ci sono due progetti che ora sono bloccati nella fase di test!
I problemi in una situazione del genere non sono difficili da vedere. Qual è lo scopo di sviluppare dieci storie (o bit di software) quando non saranno testate presto?
Adesso passiamo al metodo Kanban.
Il metodo Kanban è un concetto estremamente semplice. Segue una semplice logica di utilizzare un "metodo pull" per rimuovere prima i colli di bottiglia e limitare i lavori in corso (WIP) per migliorare i processi di lavoro.
Nella sua forma più semplice, Kanban, letteralmente, "lavagna visiva" aiuta "estraendo" gli elementi da un elenco di cose da fare, piuttosto che lavorare con le linee temporali. Il metodo Kanban aiuta a identificare i colli di bottiglia in modo da gestire meglio il flusso di processo.
Una scheda Kanban di base ha un elenco di attività da eseguire, attività in corso e attività completate.
Nella gestione del software, tuttavia, le attività possono essere un po 'più complesse. La maggior parte dei progetti Agile ha anche una scheda simile. In una scheda Kanban, le fasi della distribuzione sono chiaramente contrassegnate, insieme a un numero per ogni colonna. Questo numero rappresenta il numero massimo di attività o storie che un determinato passaggio può gestire.
Il nostro esempio su una tavola Kanban sarebbe simile a questo, all'inizio della seconda settimana. Ciò significa che gli sviluppatori e gli analisti non lavoreranno sul numero ottimale di storie quella settimana. Sarebbe ovvio che il lavoro si sta accumulando alla fine del tester. E le organizzazioni possono garantire che i team lavorino insieme per completare i test. In alternativa, possono esaminare altri modelli di flusso di processo in modo che ciò non accada.
Quando i progetti vengono gestiti attraverso il sistema Kanban, c'è meno spazio per l'accumulo di lavoro. Le storie vengono riprese in base alla larghezza di banda massima disponibile.
In una tipica configurazione kanban, il lavoro verrà ripreso in base alla larghezza di banda disponibile e il lavoro verrà eseguito dai team, in modo che siano sempre alla massima capacità. Il sistema consente anche una corsia preferenziale, per compiti che sono urgenti, in modo che si muovano attraverso la scheda con il minimo sforzo.
Dai un'occhiata a questa tavola Kanban.
È chiaro che tutti i passaggi funzionano alla massima efficienza. E viene anche presa in considerazione l'attività che si trova sulla "corsia preferenziale".
Kanban non è affatto l'unico metodo utilizzato per aumentare l'efficienza limitando il WIP. Esistono altri sistemi che ottengono lo stesso risultato, ad esempio i sistemi CONWIP (Constant Works in Progress) e DBR (Drum-Buffer-Rope), destinati principalmente alle industrie manifatturiere.
Tuttavia, Kanban è il sistema che è stato meglio modificato per adattarsi all'industria del software.
In che modo Kanban è diverso dalle metodologie agili?
Alla base, Kanban è una metodologia che utilizza alcuni elementi di Agile Project Management. Molti progetti nel quadro Agile hanno radici negli approcci Lean. La differenza tra la metodologia Kanban e la gestione dei progetti Agile non è così in bianco e nero come i sostenitori dei due metodi vorrebbero farci credere. Hanno più in comune delle differenze.
Il framework Agile non è un assoluto. La domanda non è se i team siano Agili o meno. Le squadre hanno spesso agilità a vari livelli. Uno dei metodi per avere più agilità nel processo di sviluppo del software è usare Kanban.
Esistono alcune differenze tra le metodologie Kanban e Agile. Alcune delle caratteristiche dello sviluppo Kanban, che sono leggermente diverse da Agile, sono:
- Le linee temporali non sono un fattore significativo . Questo è un concetto difficile per avvolgere la testa, in quanto sembra molto intuitivo. "Come lavori senza scadenze?" Le persone spesso chiedono. Ma se ogni membro del team è impegnato alla massima efficienza, il tempo cessa di essere un fattore.
- Le storie (attività) sono più grandi che nei tipici sistemi Agile. In genere, la lunghezza e la complessità delle storie sono più lunghe rispetto a un tipico progetto Scrum. Dal momento che l'attenzione non si concentra sulla stima del tempo, ma semplicemente sull'avanzamento del processo, Kanban può permettersi di lavorare su storie più grandi.
- Non ci sono cambiamenti significativi nei processi esistenti. I principi di Kanban per lo sviluppo del software, come articolato dal suo fondatore, David Anderson, nel suo blog, includono i seguenti principi di base:
-
- Inizia con quello che fai ora
- Accetto di perseguire un cambiamento progressivo ed evolutivo
- Rispettare il processo, i ruoli, le responsabilità e i titoli attuali
- Ogni storia è misurata in tempo di ciclo . Il progetto non viene valutato dal tradizionale calcolo Agile della velocità (il numero di storie completate in un determinato tempo), ma in base al tempo di ciclo. Ciò significa che Kanban pone l'accento sul tempo impiegato per completare un'attività. Spesso puoi vedere un ticker su molte schede Kanban che menzionano quanti giorni il team impiega per finire una storia. Questa stima alimenta il ciclo successivo.
Kanban: una tavola, ma che altro?
Quindi, Kanban è una lavagna che ci mostra come sono organizzate le storie - è che anche un grosso problema, molti lo chiedono. Vi è, in effetti, una grande discussione su ciò che Kanban è e può fare.
Kanban è solo un metodo per gestire il flusso di lavoro? O è qualcosa che si può usare insieme alle metodologie Agile per la massima efficienza? Oppure può essere un modo completamente nuovo di gestire il flusso di lavoro?
Ogni squadra usa Kanban come ritiene opportuno, per la sua situazione particolare. Indipendentemente da ciò, Kanban ha il potenziale per funzionare come uno stile di vita per lo sviluppo del software, se utilizzato al suo livello ottimale.
Sia che venga utilizzato per gestire il flusso di lavoro o come nuovo paradigma nello sviluppo del software, non si può negare che aiuta a gestire i WIP.
Per far funzionare al meglio Kanban, è importante pensarlo non solo come la gestione dei WIP, ma come un framework di gestione dei progetti. Alcune linee guida di base aiuteranno il processo.
- Ottimizza le squadre in modo che nessuna squadra inizi qualcosa che non può finire. Questo aiuta il processo lungo.
- Non resistere alle modifiche dal sistema Kanban originale. Se il tuo progetto andrà bene con scadenze e scadenze, incorporalo come faresti. Questo rende l'ambiente di sviluppo più sano e robusto.
- Non evitare il lavoro di squadra. Kanban può sembrare, ma non è, un modello basato su individui che lavorano in isolamento. Il lavoro di gruppo deve essere parte integrante dello sviluppo del software Kanban.
- Pensa fuori dagli schemi. Pensa ai cambiamenti nel flusso di lavoro. Molti team stanno ora optando per lo sviluppo guidato dai test, con lo sviluppo guidato dai test di accettazione, in cui i test di accettazione vengono eseguiti prima con casi d'uso, che quindi guidano le funzionalità richieste e la natura dello sviluppo.
ibridi
Dato che sempre più aziende utilizzano gli strumenti di gestione dei progetti più adatti alla loro situazione particolare, non sorprende che due delle migliori metodologie di gestione dei progetti: Scrum e Kanban, siano state integrate con successo.
L'ibrido, chiamato Scrumban, si sta facendo strada in molti progetti.
Se un'organizzazione sta già utilizzando Scrum, ma ha difficoltà a tenere insieme il progetto, sia con gli sprint che non funzionano bene, sia per i test non ermetici, potrebbe essere il momento di prendere in considerazione Scrumban.
Per spiegarlo semplicemente, Scrumban prevedeva di portare una lente d'ingrandimento agli sprint. Non si tratta solo degli sprint come parte del progetto, ma di ciò che accade all'interno degli sprint. Scrumban aiuta a capire come una storia viene elaborata in uno sprint e questo potrebbe fare la differenza.
Scrumban, o una qualsiasi delle sue varianti, è un cambiamento minimo rispetto alle pratiche esistenti. Il bello dell'uso di Kanban è che può essere utilizzato praticamente con qualsiasi tipo di modello di gestione del progetto: cascata, Agile o qualsiasi altra via di mezzo.
Introduzione a Kanban
È facile iniziare con il sistema Kanban. È anche possibile implementare Kanban in maniera minima come prova per una parte particolare di un progetto.
- Mappare il processo di sviluppo del software. Crea una mappa chiara dell'intero processo. In che modo funziona il progetto, dalla progettazione iniziale, allo sviluppo, al collaudo, ai cambiamenti nelle caratteristiche, nella realtà?
- Elencare i passaggi in cui verrà utilizzato Kanban. Usa i passaggi interamente sotto il tuo controllo. Ciò comprende in genere le fasi di analisi, sviluppo, revisione e test.
- Lavora su punti importanti come:
- Limiti ai lavori in corso per ogni passaggio.
- Processi per lavori accelerati / bloccati
- Stime retroattive per quanto riguarda il tempo di ciclo
- Frequenza della scheda Kanban / revisione del processo / stima
- Acquista una lavagna e una pila di note Post-It.
- Iniziare
- Rivedere come richiesto.
- Ripetere
Quindi, vai avanti e inizia Kanban!
Non aver paura se non si rivela come avevi inizialmente pensato. L'idea alla base delle metodologie Agile è quella di accogliere i cambiamenti nelle persone e nei processi! Facci sapere delle tue esperienze con il metodo Kanban.
Articoli consigliati
- 6 Best Help A Project Management Office (PMO)
- 8 passaggi utili per creare sofisticate mappe delle storie per il tuo progetto
- I 5 valori importanti della programmazione estrema (potente)