Anatomia di una Board Kanban

Una board Kanban è spesso trattata come una semplice griglia: colonne per le fasi, card per gli elementi di lavoro. Ma le board efficaci hanno più struttura di così.

I componenti chiave:

1. Colonne — Fasi attraverso cui passa il lavoro
2. Card — Singoli elementi di lavoro
3. Limiti WIP — Numero massimo di elementi consentiti per fase
4. Swimlane — Divisioni orizzontali per categorizzare il lavoro
5. Policy — Regole su come si muove il lavoro (spesso scritte sulla board)
6. Blocker — Indicatori visivi per il lavoro bloccato
7. Code vs. fasi attive — Distinguere l'attesa dal lavoro in corso

Esploriamo ciascuno di questi in profondità.

La prima regola: le colonne dovrebbero riflettere come il lavoro si muove effettivamente, non come vorresti che si muovesse.

Errori comuni:

• Usare fasi generiche (Da Fare, In Corso, Fatto) che nascondono la complessità
• Mappare un processo idealizzato che nessuno segue
• Copiare la board di un altro team senza comprendere il tuo contesto

L'approccio giusto:

1. Riunisci il team (tutti coloro che toccano il lavoro)
2. Ripercorri elementi di lavoro recenti: "Cosa è successo a questo dopo che è stato creato?"
3. Scrivi ogni fase, inclusi gli stati di attesa
4. Includi la verità scomoda—se il lavoro resta in review per giorni, quella è una fase

Esempio di evoluzione:

• Prima: Da Fare → In Corso → Fatto
• Dopo: Backlog → Pronto → Dev (WIP: 3) → Code Review (WIP: 2) → QA → Pronto per Deploy → Deployato

La board espansa rivela dove il lavoro trascorre effettivamente il tempo. Potresti scoprire che la code review richiede più tempo dello sviluppo.

Non tutte le fasi sono uguali. Alcune rappresentano lavoro attivo (qualcuno sta facendo qualcosa). Altre rappresentano code (il lavoro è in attesa).

Questa distinzione è importante perché:

• Il tempo di attesa spesso domina il lead time
• Le code sono dove il lavoro muore
• Gestisci code e fasi attive in modo diverso

Visualizzare la differenza:

Molti team dividono le colonne in due: un'area "in attesa" e un'area "in lavorazione".

| Ready | Development  | Ready for | Code Review | Ready for | Done |
|       | In Progress  | Review    | In Progress | Deploy    |      |

Oppure usano punti/indicatori sulle card per mostrare "in lavorazione attiva" vs. "in attesa".

L'intuizione: Se la tua colonna "In Corso" è piena di lavoro che nessuno sta effettivamente toccando, hai code nascoste. Rendile visibili.

Ogni colonna ha bisogno di una chiara Definition of Done (DoD): cosa deve essere vero perché il lavoro lasci questa fase?

Senza criteri chiari:

• Il lavoro si sposta prematuramente ("è quasi fatto")
• La qualità varia ("fatto" significa cose diverse per persone diverse)
• I problemi emergono tardi ("pensavo che qualcun altro lo avrebbe fatto")

Esempio di DoD per "Sviluppo":

• Tutti i criteri di accettazione soddisfatti
• Unit test scritti e superati
• Il codice compila senza warning
• Auto-revisionato (nessun problema evidente)
• Il messaggio di commit segue la convenzione

Esempio di DoD per "Code Review":

• Due approvazioni ricevute
• Tutti i commenti della review affrontati
• Pipeline CI superata
• Nessun conflitto di merge

Scrivile sulla board o collegale. Non sono burocrazia—sono comprensione condivisa.