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

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

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

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

Излишне жесткие WIP-лимиты могут подвергнуть вашу организацию сильному стрессу. У компаний с низкой степенью зрелости и невысокой производительностью изначально проблем будет больше. Для таких организаций внедрение канбан-системы может протекать болезненно при наличии слишком жестких WIP-лимитов. Если выявляется большое количество препятствий, отмеченных на стене розовыми карточками, то слишком жесткие WIP-лимиты могут привести к полной остановке работы, так что жертвами простоя окажутся все сотрудники. Конечно, простой можно использовать для концентрации внимания и накопления сил с целью решить проблемы и устранить препятствия, но он может слишком дорого обойтись недостаточно зрелой организации. Руководители начнут испытывать раздражение при виде праздношатающихся людей, которые продолжают получать зарплату.

Внося изменения, необходимо помнить о так называемом эффекте J-кривой. Обычно при каждом изменении WIP-лимитов на графике производительности появляется фигура, похожая на букву J: когда изменения незначительны, размер J невелик. Если установить слишком жесткие WIP-лимиты, то эффект J-кривой окажется слишком глубоким и длительным, что способно привести к нежелательным последствиям. Канбан обнажает все проблемы организации, но в итоге метод могут обвинить в том, что из-за него все стало только хуже. Канбан начнут воспринимать как часть проблемы, а не как ее решение. Поэтому действуйте осторожно. Если организация обладает большей мощностью и зрелостью и реже страдает от неожиданных проблем (вариативностей систематической погрешности), то можно проводить более агрессивную политику WIP-лимитов. Если организация менее слаженна, то изначально стоит ввести более свободные ограничения, с тем чтобы снизить WIP-лимиты позже.

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

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