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

Ниже приведены примеры правил расстановки приоритетов для четырех определенных ранее классов обслуживания. Разумеется, каждая реализация определения классов обслуживания уникальна и правила их использования будут отличаться от данных примеров. Представленные правила основаны на эмпирических свидетельствах и довольно точно отражают ситуации в реальных командах.

Правила для ускоренного класса обслуживания

• Для ускоренных запросов используются белые карточки.

• Разрешается обработка только одного ускоренного запроса за раз. То есть ускоренный класс обслуживания имеет WIP-лимит 1.

• Квалифицированные сотрудники должны немедленно вытягивать ускоренные запросы. Вся другая работа приостанавливается до окончания обработки ускоренного запроса.

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

• При необходимости планируется специальный (внеочередной) релиз, чтобы как можно быстрее реализовать ускоренный запрос.

Правила для класса обслуживания с фиксированной датой поставки

• Для элементов с фиксированной датой поставки используются фиолетовые карточки.

• Требуемый дедлайн записывается в правом нижнем углу карточки.

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

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

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

• Элементы с фиксированной датой поставки должны соотноситься с WIP-лимитом.

• Элементы с фиксированной датой поставки поступают в очередь на релиз, когда они закончены и подготовлены к релизу. Они выпускаются в соответствии с календарем релизов непосредственно перед дедлайном.

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

Правила для стандартного класса обслуживания

• Для элементов стандартного класса обслуживания используются желтые карточки.

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

• Для элементов стандартного класса, вытянутых в систему, используется алгоритм FIFO (в порядке поступления). Обычно когда есть выбор, член команды вытягивает самый старый элемент стандартного класса, если отсутствуют элементы ускоренного класса или с фиксированной датой поставки.

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

• Оценка для определения количества усилий или времени выполнения не проводится.

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

• Элементы стандартного класса обычно реализуются в течение x дней после выбора, выполнение в срок составляет m процентов.

Типичное соглашение об уровне обслуживания для стандартного класса может включать 30-дневное время выполнения с 80 %-ным выполнением в срок. Иными словами, за 30 дней должны быть выполнены четыре запроса из пяти.

Нематериальный класс обслуживания

• Для элементов нематериального класса обслуживания используются зеленые карточки.

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

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

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

• Оценка для определения количества усилий или времени выполнения не проводится.

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

• Обычно элемент нематериального класса откладывается ради обработки ускоренного запроса.

• В случае с элементами нематериального класса предоставление соглашения об уровне обслуживания может оказаться необязательным. Если оно все же необходимо, то должно иметь менее жесткие ограничения, чем предлагаемые для элементов стандартного класса: например, 60 дней с 50 %-ным выполнением в срок.

Соглашение об уровне обслуживания

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

Чтобы определить целевое время выполнения, следует опираться на предыдущие данные. Если их нет, то постарайтесь сделать предположение, близкое к истине. После этого внесите сроки выполнения (от изначального выбора до релиза) в статистический пакет управления процессами или инструмент отслеживания в канбане, который поддерживает статистическое управление процессами (например, Silver Catalyst), и установите верхнюю контрольную отметку (граница плюс 3-сигма) в качестве целевого времени выполнения. Так вы получите оптимальное время, в которое наверняка сможете уложиться в обычных условиях, а задержки связаны только с реальными проблемами, возникающими из-за систематических погрешностей (подробнее об этом – в главе 19).

Если предыдущий абзац показался вам трудным для понимания, то можно сформулировать иначе: необходимо, чтобы время выполнения было достижимым, но при этом планка должна быть задана достаточно агрессивно для сохранения командой концентрации. Скорее всего, ваши рабочие единицы будут отличаться по размерам, сложности, риску и уровню требуемой компетенции. Разным будет и время выполнения. Это совершенно нормально. Если, проведя анализ предыдущих данных, вы видите, что около 70 % заданий выполняется в течение 28 дней, а оставшиеся 30 % растягиваются еще на 100 дней, то вполне разумно сделать целевым временем именно 28 дней.

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

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