いいえ、数式はありません。ありません。
多くは、チームのしくみ、使用するプラクティスなどに依存します。プログラムをペアリングすると、多くの開発者よりも開発列の制限が低くなります。
既存のチームにかんばんを導入する場合は、現在進行中のすべての作業をMMFにマッピングしてから、さまざまな列にある機能の数を確認できます。これにより、現時点で実際に持っている制限がわかります。これは、かんばんの制限を設定するための良い出発点です。
あなたが得るもう一つのアドバイスはあなたの/あなたのチームの直感で行くことです。あなたが正しいと思うことをしてください。次に、制限が厳しすぎないか、緩すぎないかを監視し、調整します。 「理事会が教えてくれる」と言う人もいますが、それは基本的にそうです。ボトルネックが1週間ごとに発生する場合は、制限を低く設定しすぎている可能性があります。 1つまたは2つのブロッカーが問題でない場合、制限が高すぎます。
かんばんボードの作成時に制限を設定する方法を投稿しました。 http://blog.brodzinski.com/2009/11/kanban-story-kanban-board.html
私は2人の極端な方法を試しましたが、どちらも異なる人から提案されました。 1つは上限を使用し、それが痛くなるまで調整することです。もう1つはその逆で、n-1から開始します。nは、その列にタスクをプルできる人の数です。後者は、かんばんを初めて使用するチームにとってはより痛みを伴いますが、痛み（ボトルネック）を感じたときの最初の本能は、WIP制限の引き上げに関する問題を最後の手段として、その結果、他の方法では見えなかったかもしれないいくつかのプロセスの問題を明らかにして解決しました。
そのような公式はないことに同意しますが、同時に、かんばんプロセスをモデル化する実際の可能性があります。これは、サイクルタイム、待機時間、効率などの可能性のある結果をシミュレートするのに役立ちます。
私はかんばんプロセスをモデル化するそのようなシミュレーターを実装しました。 WIP制限とチームリソースに関するカンバン制約の下で、全体のストーリーの流れをシミュレートします。外部からのレビューが必要な状態です。私たちは皆、この段階が私たちのストーリーをバックアップすることによって私たちのサイクルタイムを殺す何かであると疑いました。
直感はこの段階でタイムボックス化することでしたが、これが単に問題を他の場所にプッシュするかどうかはわかりませんでした。タイムボクシングでどこまで行けるか、それがどれほど大きな改善になるかについても知りませんでした。
微調整を続けるだけで十分ですが、混乱を招く可能性があります。人々はプロセスに慣れ、常に直感的に微調整しようとする誰かに不満を感じるでしょう。したがって、変更を実装する前に、非常に適切なケースを作成する必要があることがよくあります。
モデル化すると、中断することなく微調整を行うことができ、微調整によって必要な結果が得られるという確信がはるかに高まります。さらに、それはあなたにあなたの魔法の調合を手に入れることになるでしょう。
まず、各列の「スロット」の数から始めます。これは、関連する列で作業を引き受ける人数と同じです。これにより、ボトルネックまたは問題点が明らかになります。それがなくなるまで、問題点に対処します。
時間をかけて、各列のスロット数を減らして実験してください。
新しいプロジェクトまたはチームを開始するときに、WIP制限を指定するために2つの手法を使用します。
開発プロジェクトの場合：ペアで作業しています（XPを実行しています）。つまり、2つのメンバーが一度に1つの要素で作業できます。チームが6人で構成されている場合、WIPは前の文に基づいて3になります。ただし、ペアプログラミングは骨の折れる仕事であり、同僚が少しだけ仕事をしたい場合があります。私はプラス1を与えるので、6人のメンバーのWIP制限は4になります。
メンテナンス、検証テスト、またはサポートプロジェクトについて話しているときは、さまざまな同僚が実行できる並列作業の量を確認し、この数を合計して1を差し引きます。たとえば、前述のチームの全員が2つの並列の問題を処理でき、WIP制限は12になりますが、-1の場合は11になります。-1の場合、チームが集中し、一緒に作業することが保証されます。この場合、WIP制限が12の場合、全員が最大2枚のカードで作業し、コラボレーションは行われません。
これらのテクニックは、プロジェクト/チームの開始時のみに使用することを共感したいと思います。その後、WIP制限の調整は、感情、負荷、目標などに基づくチームの義務です。