День 266. Канбан (IV)

Продолжим выдержки из книги Дэвида Андерсена «Канбан»:

ПОПОЛНЕНИЕ ОЧЕРЕДИ

Оптимальный размер бэклога должен соответствовать пропускной способности (нет смысла работать над аналитикой и проектированием задач, если у разработчиков не будет времени это реализовать)

Пополнять очередь можно с определенным периодом (как в скраме), либо в свободной форме (вплоть до ежедневного)

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

Очевидно, что особенно актуально это для удаленных команд — ибо в этом случае необходимо помнить о разнице во времение (утром мы можем начать работать над какой-то задачей, у нас возникают вопросы, которые не могут быть быстро решены, поскольку в США сейчас ночь — ответ приходит поздним вечером или ночью и мы продолжаем работу на следующий день), о праздниках и выходных.

Как у нас в piano:

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

В других командах ситуация более сбалансированная: команда работает и над продуктовыми фичами, и над приходящими клиентскими багами, и над техническим долгом и над задачами по перфомансу, приходящими от system lead engineers. Очень интересно обсуждать приоритеты и сроки.

Объем бэклога таких команд обычно содержит несколько десятков задач:

  

УСКОРЕННЫЕ КЛАССЫ ОБСЛУЖИВАНИЯ

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

Выделим следующие классы задач:

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

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

— стандартный класс (это все остальные задачи, они в очереди сортируются по приоритету)

Заметим, что приоритет задачи определяется критичностью и глобальностью ошибки. Под критичностью понимается ценность затрагиваемой функциональной единицы, например,

если пользователь даже не может авторизоваться — критичная

если пользователь не может делать какую-то стандартную функцию — высокая

если функция редко используется (например, отправить новогодний подарок другу или закрыть годовой баланс) — низкая

Глобальность ошибки определяется массовостью ошибки и количеством затронутых пользователей:

глобальная повторяется у многих пользователей (возможно у всех),

локальная ошибка имеет место для какого-то узкого кейса (например, если эта бухгалтерская система — для пользователей, родившихся в определенный месяц. Если это система подписок — для пользователей, подаривших доступ другому в определенный день)

Понятно, что самые критичные ошибки — те, которые повторяются массово и затрагивают важнейший функционал.

СОГЛАШЕНИЯ ПО УРОВНЮ ОБСЛУЖИВАНИЯ

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

Очевидно, что необходимо установление различных сроков в зависимости от приоритетов задач.

Как у нас в piano: для закрытия клиентских багов установлены следующие лимиты:

— блокер должен быть зарелизен в течение двух суток,

— критикал в течение 7 дней,

— major в течение 14 дней.

Кроме того, желательно ставить цель — какой % должен быть выполнен за указанный лимит (например, 95% критикалов закрывается за 7 дней)

Обсудить у себя 0
Комментарии (0)
Чтобы комментировать надо зарегистрироваться или если вы уже регистрировались войти в свой аккаунт.

Войти через социальные сети:

Сахаров Денис
Сахаров Денис
Был на сайте вчера в 17:34
Читателей: 17 Опыт: 537.013 Карма: 2.54599
все 18 Мои друзья