Відповіді:
Ні, ніякої формули. Немає жодної.
Багато що залежить від того, як працює ваша команда, використовує вашу практику тощо. Якщо ви паруєте програму, у вас буде нижчі межі в стовпці розробок, ніж у кількості розробників.
Якщо ви представите Kanban в існуючій команді, ви можете спробувати зіставити всю роботу, яка зараз триває, в MMF, а потім побачити, скільки функцій у вас є в різних стовпцях. Це дасть вам зрозуміти, які обмеження у вас є насправді, і це хороший вихідний пункт для встановлення меж Канбана.
Ще одна порада, яку ви отримаєте, - піти з почуттям кишечника своєї / вашої команди. Робіть те, що вважаєте правильним. Потім слідкуйте, чи не обмежуються ваші обмеження або занадто вільні, і відрегулюйте. Деякі люди кажуть "рада вам скаже", і це в основному так. Якщо ви стикаєтесь з вузьким місцем щотижня, ви, мабуть, обмежуєте обмеження. Якщо один або два блокатори не є, обмеження проблеми занадто високі.
Я написав пост про те, як ми встановлювали свої межі, коли ми розробляли дошку Kanban: http://blog.brodzinski.com/2009/11/kanban-story-kanban-board.html
Я випробував дві крайності, обидві запропоновані різними людьми. Одне полягає у використанні високих обмежень і підтягуванні їх до тих пір, поки це не зашкодить, а інше - навпаки, для початку з n-1, де n - кількість людей, які могли б тягнути завдання до цього стовпця. Останнє є більш болючим для команд, які не знайомі з канбаном, але це допомогло нам дійти до потоку, максимізуючого швидше, ніж перший варіант, тому що, коли ми відчували біль (вузькі місця), наш перший інстинкт був дослідити проблему з підвищенням межі WIP як В крайньому випадку, і в результаті ми розкрили і вирішили декілька проблемних питань, які могли бути невидимими інакше.
Хоча я згоден, формули як такої немає - водночас існує реальна можливість моделювання вашого процесу Канбана. Це допоможе вам моделювати ймовірні результати для таких речей, як час циклу, час очікування, ефективність тощо.
Я реалізував такий симулятор, який моделює наш процес Kanban. Це імітує потік історій по всій плані в рамках наших обмежень Канбана навколо меж WIP та ресурсів команди. Ми маємо стан, який вимагає зовнішнього огляду клієнта. Всі ми підозрювали, що цей етап щось убиває наш час циклу, створюючи резервні копії наших історій.
Відчуття кишки полягало в тому, щоб пройти цей етап, але ми не знали, чи це просто висуне проблему в іншому місці. Ми також не знали, як далеко піти з боксу часу, а також наскільки велике поліпшення це зробить.
Це все дуже добре говорити, просто продовжуйте налаштування, але це може бути дуже руйнівним. Люди звикають до процесу і засмучуються, коли хтось постійно намагається налаштуватись на переконання. Тому вам часто доводиться робити дуже хороший випадок, перш ніж вносити зміни.
Коли ви моделюєте, ви можете налаштувати без збоїв і мати набагато більшу впевненість у тому, що ваші налаштування забезпечать потрібний результат. Плюс це піде якось до отримання вашої магічної формули.
Я б почав із кількості "прорізів" у кожному стовпчику, що дорівнює кількості людей, які брали б роботу у відповідному стовпчику. Це виявить вузькі місця або больові точки. Зверніться до больової точки, поки вона не зникне.
З часом експериментуйте зі зменшенням кількості слотів у кожному стовпчику.
Я використовую дві методики для визначення межі WIP, коли ми починаємо новий проект або команду.
У разі проекту розвитку: ми працюємо в парах (ми робимо XP), а це означає, що два члена можуть одночасно працювати над одним елементом. Якби команда складалася з 6 осіб, WIP було б 3, виходячи з попереднього речення. Однак програмування пар - це виснажлива робота, і іноді колеги хотіли б трохи попрацювати в поодинці, я даю плюс один, тому обмеження WIP для 6 членів буде 4.
Коли ми говоримо про технічне обслуговування, тест на підтвердження чи проект підтримки, я перевіряю, скільки паралельних робіт можуть виконати різні колеги, підсумовую це число і віднімаю його одним. Наприклад, кожен з вищезгаданої команди може опікуватися двома паралельними питаннями, це зробить обмеження WIP 12, але з -1, це 11. -1 -1 гарантує мені, що команда залишається зосередженою та працює разом. Якби в цьому випадку ліміт WIP був 12, кожен працював би над своїми максимум двома картами, і співпраця не відбулася б.
Я хочу співпереживати, що я використовую ці методи лише на початку, коли починається проект / команда. Після цього коригування межі WIP - це обов'язок команди, виходячи з їх почуттів, навантаження, мети тощо.