Réponses:
Non, pas de formule. Il n'y en a pas.
Cela dépend beaucoup du fonctionnement de votre équipe, des pratiques que vous utilisez, etc.
Si vous introduisez Kanban dans une équipe existante, vous pouvez essayer de mapper tout le travail qui est actuellement en cours dans les MMF, puis voir combien de fonctionnalités vous avez dans différentes colonnes. Cela vous donnerait un aperçu des limites que vous avez réellement en ce moment et c'est un bon point de départ pour définir les limites Kanban.
Un autre conseil que vous obtenez est d'aller avec le sentiment intestinal de votre / votre équipe. Faites ce que vous pensez être juste. Vérifiez ensuite si vos limites ne sont pas trop serrées ou trop lâches et ajustez. Certaines personnes disent "le conseil vous le dira" et c'est fondamentalement vrai. Si vous atteignez le goulot d'étranglement chaque semaine, vous avez probablement des limites trop basses. Si un ou deux bloqueurs ne sont pas un problème, les limites sont trop élevées.
J'ai écrit un article sur la façon dont nous avons fixé nos limites lors de l'élaboration de notre tableau Kanban: http://blog.brodzinski.com/2009/11/kanban-story-kanban-board.html
J'ai essayé deux extrêmes, tous deux suggérés par des personnes différentes. L'une consiste à utiliser des limites élevées et à les ajuster jusqu'à ce que ça fasse mal, et l'autre est le contraire, pour commencer par n-1 où n est le nombre de personnes qui pourraient tirer une tâche vers cette colonne. Ce dernier est plus douloureux pour les équipes novices en kanban, mais il nous a aidés à arriver à un point de maximisation du flux plus rapidement que la première option car lorsque nous avons ressenti de la douleur (goulots d'étranglement), notre premier instinct a été d'examiner le problème de l'augmentation de la limite WIP en tant que en dernier recours et en conséquence, nous avons découvert et résolu plusieurs problèmes de processus qui auraient pu être invisibles autrement.
Bien que je convienne qu'il n'y a pas de formule en tant que telle - en même temps, il y a la possibilité réelle de modéliser votre processus Kanban. Cela vous aidera à simuler des résultats probables pour des choses telles que le temps de cycle, le temps d'attente, l'efficacité, etc.
J'ai implémenté un tel simulateur qui modélise notre processus Kanban. Il simule le flux d'histoires à travers le tableau sous nos contraintes Kanban autour des limites WIP et des ressources de l'équipe. Nous avons un état nécessitant un examen client externe. Nous pensions tous que cette étape tuait notre Cycle Time en sauvegardant nos histoires.
L'intuition était de chronométrer cette étape, mais nous ne savions pas si cela pourrait simplement pousser le problème ailleurs. Nous ne savions pas non plus jusqu'où aller avec la boxe temporelle ni l'ampleur de son amélioration.
C'est très bien de dire juste continuer à peaufiner mais cela peut être très perturbant. Les gens s'habitueront à un processus et seront frustrés par quelqu'un qui essaie constamment de peaufiner une intuition. Vous devez donc souvent présenter un très bon dossier avant de mettre en œuvre le changement.
Lorsque vous modélisez, vous pouvez modifier sans interruption et avoir une plus grande confiance que vos réglages vont produire le résultat que vous souhaitez. De plus, cela vous aidera à obtenir votre formule magique.
Je commencerais par un certain nombre de "créneaux" dans chaque colonne qui est égal au nombre de personnes qui chercheraient du travail dans la colonne associée. Cela révélera des goulots d'étranglement ou des points douloureux. Traitez le point douloureux jusqu'à ce qu'il disparaisse.
Au fil du temps, essayez de réduire le nombre d'emplacements dans chaque colonne.
J'utilise deux techniques pour spécifier la limite WIP lorsque nous démarrons un nouveau projet ou une équipe.
Dans le cas d'un projet de développement: nous travaillons en binôme (nous faisons XP), ce qui signifie que deux membres peuvent travailler sur un élément à la fois. Si l'équipe était composée de 6 personnes, le WIP serait de 3, sur la base de la phrase précédente. Cependant, la programmation par paire est un travail épuisant, et parfois des collègues aimeraient travailler un peu seuls, j'en donne un plus, donc la limite WIP pour 6 membres serait de 4.
Lorsque nous parlons d'un projet de maintenance, de vérification ou de support, je vérifie combien de travail parallèle les différents collègues peuvent faire, je additionne ce nombre et je le soustrais avec un. Par exemple, tout le monde de l'équipe susmentionnée peut s'occuper de 2 problèmes parallèles, cela ferait la limite WIP 12, mais avec le -1, il est 11. Le -1 me garantit que l'équipe reste concentrée et travaille ensemble. Si dans ce cas la limite WIP était de 12, tout le monde travaillerait sur son maximum de deux cartes, et aucune collaboration ne se produirait.
Je tiens à souligner que je n'utilise ces techniques qu'au début, lorsque le projet / l'équipe démarre. Ensuite, l'ajustement de la limite WIP est le devoir de l'équipe en fonction de ses sentiments, de sa charge, de son objectif, etc.