Cosa sono 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.
Perché i limiti WIP sono importanti?
Forse ora ho stuzzicato la tua curiosità (me lo auguro!)
I limiti WIP migliorano la produttività e riducono la quantità di lavoro "quasi completato", obbligando il team a concentrarsi su un insieme più piccolo di task. Essenzialmente, i limiti WIP incoraggiano una cultura del completamento del lavoro. Soprattutto, rendono visibili i bloccanti e i colli di bottiglia. I team possono occuparsi dei ticket bloccanti per comprenderli, implementarli e risolverli quando vi è un indicatore chiaro di quale sia il lavoro che sta causando un collo di bottiglia. Una volta rimossi i blocchi, il lavoro dell'intero team ricomincia a fluire. Questi vantaggi garantiscono che gli incrementi di valore vengano offerti ai clienti in tempi più brevi, rendendo i limiti WIP uno strumento prezioso nello sviluppo Agile.
Durante lo sviluppo, è facile pensare che sia possibile fermare l'attività su un ticket e iniziare a lavorare su un altro". Avere due ticket aperti significa cambiare contesto tra due situazioni diverse o trasferire il lavoro tra i membri del team. Passare da un ticket all'altro ha un costo: richiede tempo e riduce la concentrazione. È quasi sempre preferibile completare il ticket iniziale invece di iniziare un nuovo lavoro senza completarlo. In altre parole, i limiti WIP ci scoraggiano dall'ostacolare il 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.
I team che non conoscono i limiti WIP si sentiranno a disagio. Prenditi il tempo necessario per parlarne con loro nelle prime iterazioni. Comprendi quando e perché il team ha raggiunto i limiti WIP. Resisti alla tentazione di correggerli in modo arbitrario all'inizio. Se una violazione diventa coerente, significa che il limite WIP è troppo restrittivo o che il processo del team è inefficiente.
Utilizzo dei limiti WIP con i team Agile
Ora che ti sei convinto della loro validità, veniamo al sodo.
Quando si implementa un nuovo flusso di lavoro, si prende una decisione a livello di team per determinare i limiti WIP per ogni stato. È consigliabile 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.
- I limiti WIP vengono aumentati in base alle esigenze in modo che il team non li raggiunga più.
- Ognuno ha un grande "task in background" che viene usato per mascherare i momenti in cui, diversamente, sarebbe inattivo.
- I membri del team restano inattivi in attesa che arrivi altro lavoro, invece di occuparsi dei colli di bottiglia.
- È preferibile dedicare più ore-uomo a colli di bottiglia persistenti invece di migliorare le pratiche di progettazione o i processi del team.
Quattro obiettivi per i team Agile che utilizzano i limiti WIP
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 storie utente, è 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.
Quando i limiti del lavoro in corso funzionano per il team, la durata ciclo di un ticket si riduce. La durata ciclo è la quantità di tempo necessaria per completare un ticket. Dai un'occhiata alla nostra pagina sulle metriche Agile per saperne di più.
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.
