В видосе я про это рассказываю, но у меня есть ощущение, что текст не помешает. Слишком неочевидная тема.
Главная мысль: если вы хотите, чтобы разработчик перестал справляться с работой, загрузите его фичами до отказа. Чем больше у человека задач, тем хуже он справляется с работой.
Пример: вспомните случай, когда вы ждали выполнения задачи несколько дней, хотя сама задача была всего лишь на 30 минут. К примеру, ваша заявка на доступ к ресурсу ждет неделями и затягивает свежий релиз. Если такое было -- читайте дальше, я расскажу, почему.
Представим график. На оси X у нас будет процент рабочего времени работника, а на оси Y -- время простоя. Допустим, Никита работает 50% времени, а 50% отдыхает. Время Ожидания Выполнения считается по формуле
busy / idle. Для Никиты это 0.5 / 0.5 == 1. Запомним.Но вообще-то 50% отдыха -- это многовато. Другой сотрудник Вася (синий) работает 80%, а 20% отдыхает. Для него ВОВ равен
0.8 / 0.2 == 4.Попробуем загрузить еще одного человека, Виктора (фиолетовый), на 95% и получим ВОВ
19. А ведь я еще видел менеджеров, которые стремятся к загрузке 99% и ВОВ такого сотрудника будет равен 99.Все эти цифры ВОВ не значат ничего: важно сравнение. Разница в ВОВ показывает, насколько дольше задача будет ждать своего исполнителя. Так, если вы отдадите задачу Никите (рыжий) он возьмет ее в работу в среднем через одну условную единицу. Давайте предположим, что это час -- но это может быть и день, и стори поинт. Если же мы отдадим задачу Васе (синий) -- то задача будет ждать в четыре раза дольше. Чем больше ВОВ, тем медленнее делается работа.
Отсюда вывод: если вы хотите, чтобы ваша система работала, вам необходимо оставлять людям свободное время, хотя бы 10% в условном спринте. Как это время выделить и что с ним делать я обязательно расскажу, но -- потом.
P.S. Изначальная идея принадлежит Элияху Голдратту, книжка "Цель". Или "Проект Феникс", если хочется более про IT.