Буфер для бутылочного горлышка

Бутылочное горлышко в рабочем потоке может потребовать буфера перед ним, как показано на рис. 10.1. Это типичный механизм амортизации бутылочных горлышек, о чем будет рассказано в главе 16. Важен масштаб буфера – желательно, чтобы он был как можно меньше. Буферы и очереди вносят в систему незавершенные задачи, что увеличивает время выполнения. Однако буферы и очереди делают рабочий поток более равномерным, что улучшает предсказуемость времени выполнения. Тем самым они увеличивают пропускную способность, и канбан‑система может обработать больше задач. Буферы также сохраняют более равномерную занятость людей. Необходим баланс, который и помогают поддерживать буферы. Во многих случаях приходится стремиться к деловой гибкости и более короткому времени выполнения, а также повышению качества, связанному с меньшим количеством незавершенных задач. Однако в погоне за гибкостью или качеством не стоит жертвовать предсказуемостью. Если размеры очереди и буфера слишком малы, так что ваша система страдает от политики «остановка‑запуск», вызванной вариативностью, то время выполнения окажется непредсказуемым, а вариативность – огромной. Выбирая WIP‑лимит для буфера, нужно иметь в виду, что он должен быть достаточно большим, чтобы обеспечить равномерный ход работы по системе и исключить простой перед бутылочными горлышками. Подробнее о масштабах буфера и о том, как создать буферы для бутылочных горлышек с ограниченной пропускной способностью и задержкой доступа элементов, мы расскажем в главе 16.

Размер входящей очереди

Размер входящей очереди можно установить исходя из каденции расстановки приоритетов и пропускной способности, или темпа производства системы. Например, если команда выпускает в среднем пять законченных элементов в неделю (обычно – от четырех до семи в неделю) при установленной еженедельной каденции пополнения очереди, то наиболее вероятный размер очереди – семь. Впрочем, возможны эмпирические поправки. Если система в ходу уже на протяжении несколько месяцев и очередь за это время ни разу полностью не истощилась перед совещаниями по расстановке приоритетов, то, вероятно, ее размер слишком велик, нужно уменьшить ее на одну позицию и посмотреть на результаты. Повторяйте до тех пор, пока на одном из совещаний по приоритетам вы не предложите представителям отделов заполнить все места в очереди.

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

Размеры очереди и буфера должны подвергаться поправкам на основании опыта. Поэтому не стоит слишком долго раздумывать над установлением WIP‑лимита. Не задерживайте ход канбан‑системы из‑за того, что никак не можете договориться об идеальном WIP‑лимите. Сделайте выбор! Лучше начать работу, не имея полной информации, чтобы затем на основании наблюдений внести поправки. Канбан – это эмпирический процесс.

Какой должна быть входящая очередь, если вы используете расстановку приоритетов по запросу? Как уже упоминалось в главе 4, входящая очередь команды XIT состояла из пяти элементов. Она создавалась в расчете на то, что будет достаточно велика для амортизации недельной пропускной способности, исходя из того предположения, что совещания по приоритетам будут еженедельными. Однако вскоре менеджеры продукта пришли к выводу, что совещания не очень нужны, а решения можно принимать по ситуации, как только освобождается место в очереди. Когда это случилось, мне следовало посоветовать Драгошу сократить входящую очередь с пяти позиций до одной. Я этого не сделал по неопытности. Система изменилась. Основания, на которых она выстраивалась, – тоже. Правила о размерах входящей очереди были основаны именно на прежней системе, поэтому их нужно было пересмотреть. Если бы мы так и поступили, то сокращение времени выполнения оказалось бы еще более впечатляющим.

Когда в XIT переключились на расстановку приоритетов по запросу, пополнение очереди обычно занимало около двух часов на один элемент. Можно с уверенностью сказать, что на пополнение очереди никогда не уходило более четырех часов. Однако разработчики находились далеко от менеджеров продукта. Люди, принимавшие решения по приоритетам, сидели в Редмонде, а разработчики – в Хайдарабаде. Все они официально трудились по восемь часов в день, причем время работы у них чаще всего не совпадало. Поэтому нередкими были ситуации, когда сотрудники, жившие в Индии, утром приходили на работу, завершали задачи и ждали пополнения очереди, в то время как у менеджеров продукта в США продолжался сладкий ночной сон. Следовательно, нужно было учесть возможность 16‑часового ожидания пополнения элемента очереди в критических обстоятельствах. Помните, что в этом рабочем процессе бутылочным горлышком были разработчики, и, чтобы максимально увеличить пропускную способность, мы совершенно не хотели их простоя. Поэтому нужно иметь запас прочности: 16 часов – это консервативное решение, учитывая, что в среднем решение по пополнению очереди занимает всего два часа. Итак, какова будет пропускная способность за эти 16 часов? На пике производительности команда реализовывала 56 элементов за квартал, то есть менее пяти в неделю. Так что маловероятно, чтобы за 16 часов они закончили бы хоть один элемент. Таким образом, очередь из одного элемента была вполне приемлемой. А вот отсутствие очереди неприемлемо. При этом сохранялась вероятность, что команда будет простаивать, когда они закончат работу за те 16 часов, пока менеджеры продукта будут недоступны для пополнения очереди.