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

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

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

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

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

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

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

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

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

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