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

I limiti del lavoro in corso non hanno in realtà lo scopo di limitare i tuoi progressi, ma di agevolarli.

Dan Radigan Di Dan Radigan
Sfoglia tra gli argomenti

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.

Suggerimento:

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.

Limiti WIP | Agile Coach Atlassian

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.

Since there's nothing left to do once an issue reaches done, there is no need for a WIP limit there. In the board above, "To do" signifies that the story has been fully vetted by the product owner and team. The development team pulls work from "To do" into "in progress" as they start on work items. As a best practice, it's important to keep enough work in the "To do" status so that each member of the development team remains fully utilized. By keeping only just enough stories in the "To do" state, the product owner doesn't get too far ahead of the game when it comes to fleshing out requirements, and the program becomes more responsive to change.

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 Agile riportata sopra, il team ha troppe revisioni del codice, quindi la colonna è diventata rossa per indicare questa situazione.

Anti-pattern a cui prestare attenzione:
  • 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.

Suggerimento:

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.

Prossimo contenuto
Kanban e Scrum a confronto