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

Ускоренный класс обслуживания и класс с фиксированной датой поставки обеспечивали постоянное своевременное выполнение важных элементов. В то же время элементы, имевшие стандартный класс, обычно отставали всего на 1–2 релиза (14 или 28 дней соответственно). Клиенты чувствовали доверие к каденции релизов, и оно было вполне заслуженным. Мы неизменно выпускали релиз каждую вторую среду. Поскольку издержки из-за отсрочки выполнения многих элементов стандартного класса (а также нематериального класса, который в то время еще не был выделен) были невелики, клиенты сосредоточивались на уже сделанном и планировали будущие элементы, не беспокоясь из-за того, что работа над ними все еще идет.

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

Назначение класса обслуживания

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

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

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

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

Использование классов обслуживания

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

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

Распределение мощности по классам обслуживания

На рис. 11.3 представлена канбан-система, общий WIP-лимит для которой равен 20. Классы обслуживания обозначены карточками четырех цветов. Белые карточки ускоренного класса не учитываются в общем WIP-лимите, но ограничены одним элементом за раз. Таким образом, они (если есть в наличии) вносят 5 %-ный вклад в общую мощность, доводя реальное количество незавершенных заданий до 21. В этом примере фиолетовые карточки для элементов с фиксированной датой поставки составляют 20 % от общего количества. Это значит, что на доске может быть только четыре фиолетовые карточки в один и тот же момент, однако присутствовать они могут в любом столбце. Желтые элементы стандартного класса составляют 50 % всей мощности, а остальные 30 % отведены зеленым элементам нематериального класса.

Рис. 11.3. Стена карточек, демонстрирующая распределение мощности по классам обслуживания

Сейчас, когда мы распределили мощность по разным классам обслуживания, деятельность по пополнению входящей очереди осложняется, поскольку надо учитывать доступную мощность для каждого класса. На рисунке видно, что есть место для одного элемента с фиксированной датой поставки и трех – нематериального класса. Это порождает множество вопросов. Что если у нас нет сейчас спроса на элемент с фиксированной датой поставки? Как быть? Возможно, заполнить свободное место элементом стандартного класса? Но нужно ли в таком случае переводить этот элемент в класс с фиксированной датой поставки? Или продолжать обрабатывать его как элемент стандартного класса? А не является ли все это нарушением правил распределения мощности?

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

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

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

Распределение мощности – это еще одна стратегия в канбан-системе. Если вы считаете, что распределение не соответствует спросу, то внесите в него изменения: поменяйте правила и соответствующие WIP-лимиты.

Выводы

• Классы обслуживания – это удобный метод оптимизации удовлетворенности клиентов.