Riportare la fluidità nel flusso di lavoro con i limiti WIP

Nello sviluppo Agile, i limiti del lavoro in corso (WIP) impostano la quantità massima di lavoro che può esistere in ogni stato di un flusso di lavoro. Limitare la quantità di lavoro in corso semplifica l'identificazione delle inefficienze nel flusso di lavoro di un team.

I colli di bottiglia nella pipeline di consegna di un team sono visibili chiaramente prima che la situazione diventi disperata. Concentrandosi sul completamento dei task in corso prima di iniziarne di nuovi, i team (di tutti i tipi) aumentano l'efficienza, riducono i cambi di contesto e forniscono risultati significativamente migliori.

A questo punto starai pensando: "Voglio saperne di più!"

I limiti WIP migliorano la produttività e riducono la quantità di lavoro "quasi pronto", costringendo il team a concentrarsi su una serie di task più piccoli. A un livello fondamentale, i limiti WIP incoraggiano una cultura del "completato".

Ancora più importante, i limiti WIP rendono visibili i bloccanti e i colli di bottiglia. I team possono confrontarsi sui problemi che bloccano il lavoro in modo da comprenderli, implementare azioni correttive e risolverli quando c'è un chiaro indicatore di quale sia il lavoro esistente che sta causando un collo di bottiglia. Una volta rimossi i blocchi, il lavoro all'interno del team riprende a fluire.

Questi vantaggi garantiscono incrementi di valore per il cliente più rapidi, rendendo i limiti WIP uno strumento prezioso per lo sviluppo Agile.

Durante lo sviluppo è facile pensare: "Ok, interrompo un attimo questo lavoro mentre inizio a lavorare su quest'altro". Avere due ticket aperti significa passare da un contesto a uno diverso o trasferire il lavoro ad altri membri del team. Rallentare la risoluzione di un ticket per passare a un altro ha un prezzo: è dispendioso in termini di tempo e riduce la concentrazione.

Quasi sempre, è meglio risolvere il problema originale prima di iniziare (e non completare) un nuovo lavoro. In altre parole, i limiti WIP evitano ci impediscono di ostacolare il nostro stesso flusso. 

Infine, i limiti WIP evidenziano le aree di inattività o di sovraccarico cronici. Aiutano il team a vedere le inefficienze nell'intero processo invece che solo nell'area specifica in cui lavora.

Ora che ti sei convinto della loro validità, veniamo al sodo.

Quando si implementa un nuovo flusso di lavoro, decidi con il team di determinare i limiti WIP per ogni stato. Ti consigliamo di impostare i limiti WIP dopo aver monitorato il numero medio di elementi di lavoro in ogni stato per alcuni sprint. Di seguito è riportato un esempio di board Agile con limiti WIP utilizzata da un tipico team di sviluppo software.

Nell'immagine riportata sopra è stato impostato un limite WIP per la revisione del codice. Poiché la colonna sta superando il limite, lo sfondo è diventato rosso.

Una volta che un ticket viene risolto, non ci sono altre azioni da intraprendere, quindi non è necessario impostare un limite WIP. Nella board Kanban sopra, "Da fare" significa che la story è stata completamente esaminata dall'owner di prodotto e dal team. Il team di sviluppo invia il lavoro dallo stato "Da fare" a quello "In corso" non appena inizia a gestire gli elementi di lavoro. Come best practice, è importante mantenere una quantità di lavoro sufficiente nello stato "Da fare", in modo che ogni membro del team di sviluppo rimanga pienamente occupato. Mantenendo solo un numero limitato di story con lo stato "Da fare", l'owner di prodotto non si spinge troppo avanti con la definizione dei requisiti e il programma risponde meglio ai cambiamenti.

Lo stato "In corso" indica il lavoro in fase di sviluppo attivo. L'obiettivo dei limiti WIP in questo caso è di garantire che tutti abbiano del lavoro da completare, ma che nessuno abbia più task da portare avanti. Nella board riportata sopra, il limite per gli elementi "In corso" è 4 e attualmente sono presenti 3 elementi con tale stato. Questo indica che il team ha la capacità di prendere altro lavoro. Come best practice, alcuni team impostano il limite massimo di WIP al di sotto del numero di membri del team, in modo da lasciare spazio per l'applicazione di buone pratiche Agile. Se uno sviluppatore completa un elemento, ma il team ha già raggiunto il limite WIP, sa che è ora di eliminare alcune revisioni del codice o affiancare un altro sviluppatore per una programmazione di coppia.

Lo stato "revisione del codice" indica le story che sono state completamente scritte ma che devono essere riviste prima di essere unite nel codice base. Le revisioni tempestive del codice costituiscono una best practice che stabilisce la qualità, accelera l'introduzione di innovazioni sul mercato, semplifica le unioni riducendo i branch aperti e diffonde le conoscenze in tutto il team tecnico. Gli elementi con questo stato dovrebbero essere gestiti con urgenza, per i seguenti motivi:

• Il codice non ristagna quando i membri del team aggiungono nuovo codice.

• Lo sviluppatore non perde il contesto che ha acquisito nella scrittura del codice originale.

• La funzione può essere sottoposta a merge nel branch principale per il rilascio.

I limiti WIP garantiscono che non si accumuli codice non rivisto. 

Tieni presente che nella board riportata sopra, il team ha troppe revisioni del codice, quindi la colonna è diventata rossa per indicare questa situazione.

Come ogni nuova attività, all'inizio i limiti WIP possono sembrare complicati. L'obiettivo è ottimizzare il team nel medio termine e la difficoltà a breve termine è in realtà un fatto positivo, perché fa sì che il team si renda conto di alcune criticità del processo. Dopo che il team ha utilizzato i limiti WIP per alcune settimane, apporta le modifiche necessarie. Resisti alla tentazione di rimuovere un limite WIP solo perché il team continua a raggiungerlo. Cogli l'opportunità per aumentare la capacità, idealmente istruendo il team, fornendo a ogni membro nuove competenze o rendendo più efficiente qualche aspetto del processo di sviluppo.

Obiettivo 1: dimensionare i singoli task in modo coerente. Quando si analizzano i requisiti e le user story, è importante non superare le 16 ore di lavoro per ogni task. Ciò aumenta la capacità del team di effettuare stime attendibili e aiuta a prevenire i colli di bottiglia. Non c'è nulla che possa rallentare un team e rendere più gravosi i limiti WIP quanto un elemento di lavoro che intasa la pipeline.

Obiettivo 2: mappare i limiti WIP alle competenza del team. L'esempio precedente presuppone che i membri del team abbiano competenze simili. Se il tuo team include degli specialisti, i limiti del lavoro in corso possono essere diversi quando lo specialista è coinvolto. Crea uno stato specifico per il lavoro dello specialista. Se in questo stato si verificano colli di bottiglia, sfrutta l'opportunità per indicare agli altri membri del team di aggiungere ulteriore capacità per le competenze dello specialista e aumentare il flusso per l'intero team.

Obiettivo 3: ridurre l'inattività. Quando un membro del team ha un tempo di inattività, invitalo ad aiutare un altro membro del team a monte o a valle. Contribuirà a migliorare la produttività complessiva del team e imparerà qualcosa lungo il percorso.

Obiettivo 4: proteggere una cultura di progettazione sostenibile. I limiti del lavoro in corso non hanno lo scopo di indurre gli sviluppatori ad accelerare il lavoro per evitare il sovraccarico in uno stato specifico. Sono pensati per supportare solide pratiche di progettazione Agile che proteggono la qualità del prodotto e lo stato di integrità della base di codice. 

Se il tuo team è pronto a implementare i limiti WIP, usa il nostro modello di board Kanban per iniziare gratuitamente.