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

По опыту знаю, что использование классов обслуживания – это очень мощная техника. В 2007 году примерно 30 % всех запросов моей команды выполнялось позже целевого времени выполнения. Мы учитывали это в показателе «доля выполнения в срок». Он никогда не превышал 70. И несмотря на такое низкое соответствие дедлайнам, жалоб поступало очень мало. Причины очевидны: все важные элементы, сопряженные с высоким риском или большой ценностью, всегда выполнялись вовремя. Поэтому заказчики были уверены, что опаздывающие элементы будут готовы через 2–4 недели, поскольку релизы выходили регулярно.

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

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

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

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

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

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

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

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

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

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

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

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