Dopo aver trascorso anni nel ruolo di project manager e team leader nell’ambito dello sviluppo software ho finalmente trovato la board perfetta per la gestione dei task e delle issue.
Scopo del kanban board
Un (o una) kanban board, per analogia, è una lavagna sulla quale applicare una serie di post-it, ciascun post-it sarà un singolo task da svolgere da uno o più individui del team di sviluppo.
Il suo scopo è tenere traccia dello stato di ogni singola attività nel flusso operativo e avere a colpo d’occhio lo stato di avanzamento di un progetto nell’insieme.
Un kanban perfetto e adatto a tutti i flussi non esiste. Bisogna ovviamente ragionare sul flusso di lavoro, sui ruoli di ogni singolo componente del team e in base a questi due fattori è possibile progettare un kanban ideale al proprio scopo.
Per esempio, consideriamo il processo di manutenzione di un software.
Accettazione ed organizzazione preliminare della segnalazione
“chi ben comincia è a metà dell’opera”.
Ippolito Nievo, “Confessioni di un Italiano”
Una volta ricevuta una segnalazione sarà valutata da una persona preposta a tale scopo e ne determinerà:
- la bontà (se si tratta di anomalia, il problema è replicabile e/o il contesto della richiesta è corretto?)
- la sufficienza delle informazioni (i dati forniti dall’utente permettono di riprodurre il problema o di analizzare in dettaglio le necessità esposte?)
- Il tipo di segnalazione (si tratta di un bug, di una nuova funzionalità o di un task da svolgere occasionalmente?)
- l’urgenza (attività da prendere in carico immediatamente o nel rispetto della timeline del progetto)
Questa fase può essere identificata come Triage: la segnalazione viene valutata e organizzata per il team.
Superato il punto 1 dell’elenco, c’è da valutare sufficienza, tipo (solitamente aggiungo il prefisso “is:“) e urgenza (aggiungo il prefisso “severity:“).
Quindi viene affidata a un componente del team (Todo), segnata come nuova funzionalità se è un qualcosa che non è previsto dall’attuale software (is:Feature) o rimandata nuovamente al segnalante per ottenere nuovi dettagli (Need More Info).
Se si tratta di un problema si etichetta come bug (is:bug) e se invece si tratta di task da fare una sola volta, si etichetta come task (is:task).
Se il problema blocca i processi produttivi riceve una severità massima (severity:high), se altrimenti è importante perché crea qualche disservizio ma non blocca la produzione, riceverà una severità media (severity:medium). In tutti gli altri casi riceverà un livello di urgenza bassa (severity:low)
Si sono delineate quindi una serie di etichette per il nostro kanban.
- Etichette che descrivono l’avanzamento di un’attività
- Triage
- Todo
- Need More Info
- Etichette che descrivono il tipo di attività:
- is:feature
- is:bug
- is:task
- Etichette che descrivono la criticità della segnalazione:
- severity:high
- severity:medium
- severity:low
Il processo di sviluppo
Avanzando nel flusso di lavoro, la segnalazione è arrivata nella colonna dei Todo e dovrà essere presa in carico da un tecnico, quindi passerà nello stato di lavorazione (Work In Progress).
Durante la lavorazione il tecnico potrà svolgere completamente il suo task, assegnarlo ad altri o chiedere maggiori informazioni al committente (Need More Info).
Al termine della lavorazione segnerà il task come eseguito (Done) ed assegnato nuovamente al Project Manager che determinerà che fine dovrà fare la richiesta.
Al kanban si aggiungo quindi due nuove etichette di avanzamento:
- Work In Progress
- Done
Test e rilascio
Un’attività svolta deve essere verificata dal Quality Manager. In un piccolo team questo ruolo è ricoperto il più delle volte dal Project Manager che verifica la modalità con cui è stata risolta la problematica o implementata la nuova funzionalità svolgendo una fase di test (QA: Quality Assurance/ Testing)
Se la fase di test non ha esito positivo, la richiesta sarà segnata nuovamente come da fare (Todo) con le dovute motivazioni, altrimenti procede allo step successivo (Ready to stage) e assegnata a chi di competenza.
Quando una richiesta è pronta per essere rilasciata, solitamente transiterà per un server di stage per ulteriori verifiche, quindi sarà coinvolto un DevOps o lo stesso Project Manager/Team Leader svolgerà questo compito che notificherà l’applicazione in stage della fix, patch, feature o quello che sia (Staged).
Solitamente il processo di messa in stage è legato a pipeline che eseguono test unitari sul codice e generano i necessari report di buon funzionamento. Quindi, se i risultati ottenuti sono quelli aspettati, si procederà al rilascio (Ready to deploy). In alternativa si tornerà ad una delle fasi precedenti (Todo oppure Ready to stage) con le opportune motivazioni fornite al tecnico che dovrà gestire la condizione anomala.
In conclusione il DevOps, procederà al deploy (Deployed) e segnalerà l’attività al Project Manager che potrà procedere alla chiusura del task.
Le etichette quindi evidenziate in questa fase sono:
- QA/Testing
- Ready to stage
- Staged
- Ready to deploy
- Deployed
Il kanban completo
Guardando l’insieme delle etichette che descrivono il flusso di lavoro, si trovano tre tipi di etichette:
- Etichette che descrivono l’avanzamento di un’attività
- Triage
- Todo
- Need More Info
- Work In Progress
- Done
- QA/Testing
- Ready to stage
- Staged
- Ready to deploy
- Deployed
- Etichette che descrivono il tipo di attività:
- is:feature
- is:bug
- is:task
- Etichette che descrivono la criticità della segnalazione:
- severity:high
- severity:medium
- severity:low
In conclusione
Il flusso di lavoro per ogni tipo di progetto può cambiare radicalmente e secondo la dimensione del team, la complessità del progetto e le figure coinvolte.
Quindi le etichette sopra possono essere arricchite di nuove fasi intermedie o addirittura semplificate.
L’avere 3 tipi di etichetti ti aiuta anche nel definire kanban board diverse che ti permettono di avere una visione sullo stato delle criticità o sulla tipologia delle attività sulle quali il team è maggiormente concentrato.
Infine uno strumento del genere aiuta a comprendere, specie in grandi team, se uno specifico micro-team ha bisogno di una risorsa in più e se è possibile sganciarne una da un’altro micro-team, al fine di ottimizzare i costi di gestione.
Comunque, la board va preparata solo a seguito di una profonda comprensione del processo operativo e non in corso d’opera, o si rischierà di creare confusione o processi estremmente macchinosi ed articolati.
Solitamente in Axio Studio, prima di preparare una board analizziamo i processi, li ottimizziamo, ed adattiamo il nostro flusso di lavoro alle abitudini del committente.
E tu come organizzi il tuo flusso di lavoro?