Канбан. Альтернативный путь в Agile - [45]

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

Не устанавливать WIP-лимит – это ошибка

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

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

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

Распределение мощности

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

На рис. 10.3 изображена стена карточек из главы 6 с WIP-лимитами по столбцам – всего 20 карточек. Мощность распределена по типам работы: 60 % идет на запросы изменений, 10 % – на элементы поддержки и 30 % – на производственные текстовые изменения.

Рис. 10.3. Стена карточек с «плавательными дорожками» для каждого типа единиц работы с указанными для каждой дорожки WIP-лимитами

Это соответствует таким значениям WIP-лимитов для каждой «плавательной дорожки»: 12 для запросов изменений, 2 для элементов поддержки и 6 для производственных текстовых изменений.

Распределение мощности позволяет гарантировать обслуживание для каждого типа работы, введенного в канбан-систему, и должно производиться в соответствии с примерным спросом для каждого типа работы. Таким образом, чтобы разумно распределить WIP-лимиты для каждого типа работы по «плавательным дорожкам», важно провести некоторый анализ предъявляемых требований.

Выводы

• WIP-лимиты должны быть согласованы с заинтересованными лицами из других подразделений и высшего руководства на основе общего консенсуса.

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

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

• Обычно лимит задается из расчета 1–3 единицы на 1–2 человек или на команду.

• Лимиты для очереди должны быть достаточно небольшими – обычно такими, чтобы амортизировать естественную (случайную) вариативность в размере элементов и длительности задач.

• Бутылочные горлышки нужно снабдить буфером.

• Размер буфера должен быть минимальным, но при этом достаточным для обеспечения оптимальной производительности в бутылочном горлышке и устойчивого распределения рабочего потока по системе.

• Все WIP-лимиты можно изменять эмпирически.

• Канбан – это эмпирический процесс.

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