Второй принцип канбан – ограничить объем незавершенной работы

Объем незавершенной работы (work in process) – это фраза, которую вы часто слышите в канбан-сообществе.

Простой людей или простой в работе?

Настройка объема незавершенной работы WIP может легко стать темой для многочисленных обсуждений. Лучше попробовать что-нибудь, а затем приспособить. Простой способ помочь вам увеличить или уменьшить объем WIP заключается в следующем:

• Если ваш лимит WIP слишком высок, работа станет простаивающей. Возникнут рабочие элементы, за которые никто не отвечает. Это может быть хорошим сигналом для снижения ограничения WIP.
• Если ограничение WIP слишком низкое, люди будут бездействовать. Например, все элементы заблокированы, а новую работу нельзя втянуть в работу. Вам остается только совместно работать над задачей, либо повысить ограничение WIP.

Принципы на установку объема незавершенной работы

Простой, но мощный инструмент для ограничения вашей незавершенной работы – это согласие стремиться завершить текущую работу, прежде чем начинать что-то новое. Это соглашение будет поддерживать низкий уровень WIP.

Самый простой способ начать – принять слоган для вашей команды:

Хватит начинать, давайте заканчивать!

Хорошей идеей может быть размещение этого утверждения над доской, где вы будете встречаться каждое утро. Или почему бы не использовать слоган в качестве вводной или заключительной фразы ваших ежедневных Stand-up?

В этом простом лозунге есть великая сила, потому что он подталкивает вас к снижению работы в процессе. Это поможет вам не только ограничить количество рабочих элементов, над которыми вы работаете одновременно, но и сократить сроки выполнения заказов, выполнить всю цепочку создания стоимости, получить обратную связь и улучшить свой процесс.

Желательно стремиться к низкому пределу WIP, потому что он даст вам лучший поток. Но и слишком низкий его уровень, вероятно, будет негативным для вашего потока. Например, если у вас установлен предел WIP, равный единице, любое нарушение в потоке – например, передача, отсутствие нужного человека в офисе и т. д. – остановит всю работу.

Вы должны стремиться к малому числу, но не обязательно это должен быть 1.

Подход ограничения работы в процессе к целой канбан-доске, целой команде разработки

Предположим, у вас есть команда из пяти человек. Вы можете начать с решения о лимите WIP, равном одному на человека.

Довольно скоро вы обнаружите, что этот подход создает некоторые проблемы. Дальше вы решите, что более разумно разрешить не более двух элементов каждому. Людям будет чем заняться, если один элемент заблокирован. Это делает общие ограничение WIP равным размеру команды, умноженному на два.

Но это ограничение также может быть нецелесообразным, поскольку оно допускает ситуации, в которых каждый член команды продолжает работать над не заблокированным элементом работы, не нарушая ограничение WIP. Обычно ограничения WIP должны подталкивать вас к решению проблем, а не позволять вам продолжать работать, не замечая их.

Чтобы подтолкнуть команду к этому, вы можете снизить ограничение с 10 до 8. Если у каждого члена команды будет по одному заблокированному элементу, то не все смогут взять другую работу. В этой ситуации оставшимся членом команды придется что-то делать с заблокированными элементами. Если вы хотите побудить к решению проблем еще раньше, понизьте ограничение WIP еще.

Обратите внимание, что числа в наших примерах не так уж важны. Помните – нет правильного предела WIP, который можно рассчитать. Вы должны найти тот, который подходит вашей команде и вашей ситуации лучше всего. Наиболее рациональным способом поиска своего пути является попытка установить ограничение WIP, а затем изменять его при необходимости.

Если ваша команда использует практики совместной работы, такие как парное программирование, вам, вероятно, следует еще больше снизить лимит WIP. В таких случаях вы можете установить ограничение WIP на число, меньшее количества людей в команде. Вы можете взять число людей в команде и разделить на 1,5 (или другое число, которое вы считаете нужным), чтобы получить низкий предел WIP.

Для нашего примера команды из пяти человек это будет всего около трех элементов для работы.

В этом случае члены команды должны будут сотрудничать над элементами, чтобы завершить их, используя парное программирование, составляя вместе спецификации или тестируя в парах. Это именно такой тип сотрудничества, которое гибкие команды стремятся достичь. Как хороший побочный эффект, рабочие элементы будут быстро перемещаться по доске.

Это может быть большим изменением для некоторых команд, которые не привыкли тесно сотрудничать. Как всегда, не устанавливайте ограничение работы в процессе слишком низким. Скорее уменьшайте его постепенно, одновременно улучшая свой процесс.

Отображение ограничения работы в процессе на колонках канбан-доски

Все рабочие процессы где-то всегда имеют узкое место, которое задает темп работы. Если вы можете определить узкое место в вашем рабочем процессе, имеет смысл использовать ограничения WIP в столбце до него.

Давайте посмотрим на пример. Здесь у нас представлен рабочий процесс, в котором рабочие элементы накапливаются в очереди перед узким местом: столбец «тестирование». Если ничего не предпринимать, то работа будет накапливаться, а время выполнения заказа и WIP увеличиваться. Если вместо этого вы установите ограничение WIP, скажем, 3, на весь столбец разработки, разработчикам придется остановить работу по разработке, когда количество элементов превысит 3. Что они должны делать вместо этого? Они могут помочь тестировщикам закончить свою работу. Что бы они ни делали, им не следует начинать новую работу, потому что это только увеличит количество работы в процессе.

Как вы можете видеть, наложение ограничения WIP на шаг, питающий узкое место, предотвратит затопление узкого места и таким образом улучшит весь поток.

Существует столько же способов ограничения WIP, сколько существует команд в мире. Я упомяну лишь один – путем использования пунктов историй (story points).

Вам, вероятно, придется экспериментировать, чтобы найти ограничение работы в процессе, подходящее для вашей команды. Многие команды, использующие Scrum, уже делают это. Когда они планируют следующую итерацию, они смотрят на то, сколько пользовательских историй они обычно заканчивают и вытягивают примерно такое же количество новой работы в итерацию.