Дэвид Андерсон - Канбан. Альтернативный путь в Agile
- Название:Канбан. Альтернативный путь в Agile
- Автор:
- Жанр:
- Издательство:Литагент МИФ без БК
- Год:2017
- Город:Москва
- ISBN:978-5-00100-530-8
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Дэвид Андерсон - Канбан. Альтернативный путь в Agile краткое содержание
Дэвид Андерсон приводит расширенный набор тех идей (визуализация процесса и правил работы, типизация элементов работы, классы обслуживания, каденции, метрики и графики для управленческого учета и анализа), которые определяют канбан-метод.
В книге описаны инструменты, позволяющие эффективно вводить идеи бережливого производства в технологические разработки и IT-операции с минимальным сопротивлением изменениям и при этом сохранять оптимальный для всех вовлеченных в работу сотрудников темп.
На русском языке публикуется впервые.
Канбан. Альтернативный путь в Agile - читать онлайн бесплатно ознакомительный отрывок
Интервал:
Закладка:
• Обычно элемент нематериального класса откладывается ради обработки ускоренного запроса.
• В случае с элементами нематериального класса предоставление соглашения об уровне обслуживания может оказаться необязательным. Если оно все же необходимо, то должно иметь менее жесткие ограничения, чем предлагаемые для элементов стандартного класса: например, 60 дней с 50 %-ным выполнением в срок.
Соглашение об уровне обслуживания
В приведенном примере целевое время выполнения для стандартного класса обслуживания установлено и составляет, например, 28 дней (4 недели). Идея задавать целевое время выполнения вместе с показателем выполнения в срок – это альтернатива индивидуальному подходу ко всем элементам, который предполагает оценку и обязательство успеть к определенному моменту для каждого из них. Соглашение об уровне обслуживания позволяет избежать дорогостоящих (например, оценки) и не пользующихся доверием (например, принятие на себя обязательств) мероприятий и распределить риск, собрав большое количество запросов и дав обещания только об общей производительности в форме доли работ в процентах, завершенных в срок. Не пообещав то, что вряд ли сможем выполнить, мы не рискуем потерять доверие потребителей. Таким образом, важно донести до клиентов, что целевое время выполнения для стандартного класса обслуживания – это именно цель!
Чтобы определить целевое время выполнения, следует опираться на предыдущие данные. Если их нет, то постарайтесь сделать предположение, близкое к истине. После этого внесите сроки выполнения (от изначального выбора до релиза) в статистический пакет управления процессами или инструмент отслеживания в канбане, который поддерживает статистическое управление процессами (например, Silver Catalyst), и установите верхнюю контрольную отметку (граница плюс 3-сигма) в качестве целевого времени выполнения. Так вы получите оптимальное время, в которое наверняка сможете уложиться в обычных условиях, а задержки связаны только с реальными проблемами, возникающими из-за систематических погрешностей (подробнее об этом – в главе 19).
Если предыдущий абзац показался вам трудным для понимания, то можно сформулировать иначе: необходимо, чтобы время выполнения было достижимым, но при этом планка должна быть задана достаточно агрессивно для сохранения командой концентрации. Скорее всего, ваши рабочие единицы будут отличаться по размерам, сложности, риску и уровню требуемой компетенции. Разным будет и время выполнения. Это совершенно нормально. Если, проведя анализ предыдущих данных, вы видите, что около 70 % заданий выполняется в течение 28 дней, а оставшиеся 30 % растягиваются еще на 100 дней, то вполне разумно сделать целевым временем именно 28 дней.
По опыту знаю, что использование классов обслуживания – это очень мощная техника. В 2007 году примерно 30 % всех запросов моей команды выполнялось позже целевого времени выполнения. Мы учитывали это в показателе «доля выполнения в срок». Он никогда не превышал 70. И несмотря на такое низкое соответствие дедлайнам, жалоб поступало очень мало. Причины очевидны: все важные элементы, сопряженные с высоким риском или большой ценностью, всегда выполнялись вовремя. Поэтому заказчики были уверены, что опаздывающие элементы будут готовы через 2–4 недели, поскольку релизы выходили регулярно.
Ускоренный класс обслуживания и класс с фиксированной датой поставки обеспечивали постоянное своевременное выполнение важных элементов. В то же время элементы, имевшие стандартный класс, обычно отставали всего на 1–2 релиза (14 или 28 дней соответственно). Клиенты чувствовали доверие к каденции релизов, и оно было вполне заслуженным. Мы неизменно выпускали релиз каждую вторую среду. Поскольку издержки из-за отсрочки выполнения многих элементов стандартного класса (а также нематериального класса, который в то время еще не был выделен) были невелики, клиенты сосредоточивались на уже сделанном и планировали будущие элементы, не беспокоясь из-за того, что работа над ними все еще идет.
Результат был значительный, поскольку Канбан и классы обслуживания серьезно изменили психологию клиента и природу взаимоотношений и ожиданий. Теперь клиенты были настроены на долгосрочное сотрудничество и производительность всей системы, а не на своевременность доставки одного или нескольких элементов. Это дало команде разработки возможность сосредоточиться на самом важном и не тратить время на решение проблем, порожденных низким уровнем доверия между ними и клиентами.
Назначение класса обслуживания
Класс обслуживания для элемента должен быть назначен, когда этот элемент поступает во входящую очередь. Если речь идет об ускоренном запросе, то это должно быть очевидно: элемент поступает вместе с явным требованием обработать его как можно быстрее. Обосновывать это призвана модель, демонстрирующая возможности или иллюстрирующая существенные убытки, которые возникнут, если запрос не обработать в срок. Не исключено, что такие убытки уже были, что типично для серьезных производственных ошибок.
Если для элемента установлена фиксированная дата поставки, то это тоже должно быть очевидно. Возможно, этот запрос связан с новыми требованиями регулятора, выдвинутыми соответствующим независимым органом, или с сезонной природой бизнеса клиента. Если элемент относится к классу с фиксированной датой поставки, то дедлайн обычно известен, выглядит реалистично (например, время выполнения вдвое превосходит типичное целевое время выполнения для стандартного класса), а элемент уже подвергнут оценке, чтобы запустить его в работу в оптимальный срок для обеспечения сдачи вовремя.
Сложнее, если элемент относится к стандартному или нематериальному классу. У элементов стандартного класса обычно имеются функции стоимости упущенной возможности, которые вступают в силу немедленно, – например, если бы сегодня у нас была такая-то функция, то уже завтра мы начали бы получать прибыль. Поэтому желательно реализовать эти элементы как можно быстрее. Но отсрочка не грозит такими же потерями, как для элементов с фиксированной датой поставки или для ускоренных запросов.
Нематериальные элементы обычно бывают важными и ценными, но цена упущенной возможности для них относится не к ближайшему будущему. Момент, когда расходы начинают ощущаться, наступает через несколько кварталов или лет. Таким образом, он выходит за рамки непосредственного планирования, составляющего два или три цикла разработки: например, если наше текущее время выполнения – 28 дней, то горизонт планирования – примерно три месяца. Элементы, грозящие упущенной возможностью или ощутимыми издержками в течение этого срока, должны относиться к стандартному классу, а элементы, связанные с выгодами или издержками, величина которых будут понятна только через несколько кварталов или лет, поступают в нематериальный класс.
Читать дальшеИнтервал:
Закладка: