C'è qualche vantaggio nel ridurre artificialmente il WIP in un sistema Kanban? [chiuso]

L'idea alla base della limitazione del conteggio WIP in kanban è quella di fornire a tutti l'opportunità di concentrarsi correttamente sui pochi oggetti a loro assegnati e di far avanzare gli elementi nella fase successiva nel modo più efficiente possibile.

Il problema con l'accumulo di tutto il lavoro su quello sviluppatore è che le reazioni tipiche sono

• Prova a lavorare su "tutto" allo stesso tempo, perdendo in tal modo l'efficienza nel contesto cambia tra i problemi
• Essere sopraffatti dalla quantità di lavoro e dalla perdita di concentrazione a causa di ciò.

Entrambi hanno il risultato finale che lo sviluppatore diventa più di un collo di bottiglia.

Il difetto più grande nella tua implementazione è che gli oggetti "non lavorabili" vengono assegnati allo sviluppatore, che quindi dedica tempo prezioso a indagare sul problema, solo per giungere alla conclusione che ancora non lo capisce o non può fare nulla a proposito.

I maggiori miglioramenti possono essere apportati assicurando che i problemi bloccati non vengano assegnati allo sviluppatore.

• I problemi che non possono essere risolti all'interno dei vincoli di sistema correnti devono essere chiusi come "Non risolveranno" o dovrebbero essere messi in uno stato speciale "In attesa".
• Problemi / requisiti non chiari dovrebbero essere assegnati al mittente (o qualcuno che può agire per conto del mittente) per chiarimenti. È responsabilità di tutti i soggetti coinvolti evitare che questi problemi inizino a rimbalzare avanti e indietro.
• I problemi che non possono essere riprodotti devono essere assegnati a un tester per la riproduzione e una descrizione su come riprodurli. Se è davvero una tantum, dovrebbe avere la priorità di conseguenza.

Il sistema dovrebbe consentire un certo livello di cherry-picking per lo sviluppatore nei problemi che vuole occupare. Dopo aver lavorato su alcuni problemi molto difficili, è bello sbarazzarsi di un po 'di frutta bassa per ottenere un arretrato un po' e dare al tuo cervello un po 'di riposo allo stesso tempo.

Mi piacerebbe che implementaste un meccanismo di pull - in modo che lo sviluppatore autoassegnasse i nuovi biglietti sbloccati a se stesso non appena ha finito con quelli su cui sta lavorando, invece di assegnare a qualcun altro biglietti per lui. In questo modo, rimane occupato e si concentra sul finire ciò che ha iniziato e iniziare un nuovo lavoro quando è pronto per questo.

Inoltre, se qualcosa su cui sta lavorando deve essere bloccato per una delle ragioni che hai menzionato, dovrebbe bloccarlo in modo che sia visibile sia a lui che agli altri membri della squadra, in modo che tutti possano contribuire risolvi il blocco e aiuta a chiudere il ticket con successo. Idealmente non dovrebbero essere spostati indietro nel backlog (stato non assegnato) poiché ci devono essere stati buoni motivi per riprenderlo in primo luogo. Solo in casi eccezionali i biglietti bloccati devono essere riportati al backlog.

Un limite WIP formale garantisce che i ticket in-process (compresi quelli bloccati) vengano dealati PRIMA che altri vengano coinvolti - e per un periodo di tempo, assicura che il lavoro fluisca da Backlog a Completion, invece di rimanere nel sistema per un periodo prolungato periodi di tempo.

Il vero Kanban - come praticato al di fuori dell'industria del software - non ha questo problema. Kanban nel mondo del software è in gran parte un sistema "push", esattamente contrario al modello originale di Ohno.

Nel Kanban corretto, lo sviluppatore non può avviare un altro ticket perché la quota di correzioni non testate a valle da esse è troppo alta. Ciò richiama l'attenzione sulla necessità di più tester, test più efficienti o altri miglioramenti nel processo di test. A meno che il motivo delle correzioni non venga testato, i tester sono bloccati dal loro consumatore a valle. E così via. Questa è una delle idee chiave di Kanban: il rifiuto incorporato nel processo diventa ovvio e può essere risolto.