Дэвид Андерсон - Канбан. Альтернативный путь в Agile

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

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

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

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

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

В вытягивающей системе, связанной с теорией ограничений и известной как «барабан-буфер-канат», WIP-лимит всех рабочих станций после бутылочных горлышек не установлен. Это основано на предположении, что пропускная способность этих рабочих узлов выше, чем у бутылочных горлышек, так что они обладают резервной мощностью, что приводит к простою. Поэтому устанавливать WIP-лимит нет необходимости. Это отражено на рис. 10.2а, который основывается на метафоре, использованной в книге Элияху Голдратта и Джеффа Кокса «Цель: процесс непрерывного улучшения» [7]и показывает скаутский патруль, идущий змейкой. Между ведущим и самым медленным скаутом (четвертый в змейке) натянут канат. Самый медленный в змейке – это и есть бутылочное горлышко в пропускной способности (то есть в темпе хода скаутов). Необходим только один канат, поскольку скауты, идущие вслед за самым медленным из них, никогда от него не отстают, так как могут идти быстрее, чем четвертый в змейке, который снижает темп перемещения всего патруля.

Рис. 10.2. Человечки, иллюстрирующие четыре различных варианта WIP-лимитов в разных вытягивающих системах

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

В некоторых случаях в канбан-системе приемлемо отсутствие лимита на следующие этапы процесса. В примере Microsoft XIT было высказано предположение, что пользовательская база, доступная для проведения приемочного тестирования, практически бесконечна и доступна сразу же, поэтому для приемочного тестирования не нужны WIP-лимиты. В Corbis ограничения не касались очереди на подготовку к релизу. Это основывалось на предположении, что очередь на подготовку к релизу никогда не превысит пропускную способность при установленной двухнедельной каденции релиза. А если все же скапливался излишний материал для подготовки релиза, это повышало его сложность, так что координационные и операционные издержки на релиз слишком возрастали и пришлось бы установить WIP-лимиты и на этом этапе. Однако в Corbis такого не случалось, поэтому ограничения для данной фазы не устанавливались.