Risposte:
No, nessuna formula. Non ce n'è uno.
Molto dipende dal modo in cui lavora il tuo team, dalle pratiche che usi, ecc. Se abbini un programma avrai limiti inferiori nella colonna di sviluppo rispetto a un certo numero di sviluppatori.
Se introduci Kanban nel team esistente, puoi provare a mappare tutto il lavoro attualmente in corso in MMF e quindi vedere quante funzionalità hai in colonne diverse. Ti darebbe un'idea di quali limiti hai davvero in questo momento e questo è un buon punto di partenza per impostare i limiti Kanban.
Un altro consiglio che ricevi è andare con la sensazione del tuo / la tua squadra. Fai ciò che ritieni giusto. Quindi controlla se i tuoi limiti non sono troppo stretti o troppo ampi e regola. Alcune persone dicono "il consiglio te lo dirà" ed è sostanzialmente vero. Se colpisci il collo di bottiglia ogni settimana, probabilmente hai limiti impostati troppo bassi. Se uno o due bloccanti non sono un problema, i limiti sono troppo alti.
Ho scritto un post su come impostare i nostri limiti durante la realizzazione della nostra scheda Kanban: http://blog.brodzinski.com/2009/11/kanban-story-kanban-board.html
Ho provato due estremi, entrambi suggeriti da persone diverse. Uno è usare limiti alti e modificarli fino a quando non fa male, e l'altro è l'opposto, per iniziare con n-1 dove n è il numero di persone che potrebbero portare un'attività in quella colonna. Quest'ultimo è più doloroso per i team che non conoscono il kanban, ma ci ha aiutato ad arrivare a un punto di massimizzazione del flusso più velocemente della prima opzione perché quando sentivamo dolore (strozzature) il nostro primo istinto era esaminare il problema con l'aumento del limite WIP come ultima risorsa e, di conseguenza, abbiamo scoperto e risolto diversi problemi di processo che altrimenti sarebbero stati invisibili.
Anche se concordo sul fatto che non esiste una formula in quanto tale, allo stesso tempo esiste la reale possibilità di modellare il processo Kanban. Questo ti aiuterà a simulare i probabili risultati per cose come il tempo di ciclo, il tempo di attesa, l'efficienza, ecc.
Ho implementato un simile simulatore che modella il nostro processo Kanban. Simula il flusso di storie su tutta la linea sotto i nostri vincoli Kanban attorno ai limiti WIP e alle risorse del team. Abbiamo uno stato che richiede la revisione di un cliente esterno. Sospettavamo tutti che questo palcoscenico fosse qualcosa che stava uccidendo il nostro tempo ciclo sostenendo le nostre storie.
La sensazione è stata quella di programmare il tempo in questa fase, ma non sapevamo se questo avrebbe semplicemente spinto il problema altrove. Né sapevamo fino a che punto andare con il pugilato a tempo né quanto grande sarebbe stato un miglioramento.
Va benissimo dire solo di continuare a modificare, ma può essere molto dirompente. Le persone si abitueranno a un processo e si sentiranno frustrate da qualcuno che cerca costantemente di modificare il sospetto. Quindi spesso devi fare un ottimo caso prima di implementare il cambiamento.
Quando modellerai puoi modificare senza interruzioni e avere una sicurezza molto maggiore che le tue modifiche produrranno il risultato che desideri. Inoltre andrà in qualche modo a procurarti la tua formula magica.
Comincerei con un numero di "slot" in ogni colonna che è uguale al numero di persone che riprenderebbero il lavoro nella colonna associata. Ciò rivelerà colli di bottiglia o punti di dolore. Affronta il punto dolente fino a quando non scompare.
Nel tempo, sperimenta la riduzione del numero di slot in ogni colonna.
Uso due tecniche per specificare il limite WIP quando iniziamo un nuovo progetto o un team.
Nel caso di un progetto di sviluppo: stiamo lavorando in coppia (stiamo facendo XP), il che significa che due membri possono lavorare su un elemento alla volta. Se il team fosse composto da 6 persone, il WIP sarebbe 3, in base alla frase precedente. Tuttavia, la programmazione delle coppie è un lavoro estenuante, e a volte i colleghi vorrebbero lavorare un po 'da soli, ne do uno in più, quindi il limite WIP per 6 membri sarebbe 4.
Quando parliamo di un progetto di manutenzione, test di verifica o supporto, quindi controllo quanto lavoro parallelo possono fare i vari colleghi, sommo questo numero e lo sottraggo con uno. Ad esempio, tutti i membri del team precedentemente citato possono occuparsi di 2 problemi paralleli, il limite WIP sarebbe 12, ma con -1, è 11. Il -1 mi assicura che il team rimanga concentrato e lavori insieme. Se in questo caso il limite WIP fosse 12, ognuno lavorerebbe sulle proprie due carte al massimo e non si verificherebbe alcuna collaborazione.
Voglio sottolineare che uso queste tecniche solo all'inizio del progetto / team. Successivamente l'adeguamento del limite WIP è compito della squadra in base ai propri sentimenti, carico, obiettivo ecc.