Прочитал статью Тима Евграшина “Когда подстилать соломку или планирование Спринта с учетом вашей реальности” и понял, что в этом вопросе наши мнения и опыт сильно расходятся. 🙂 Мои комментарии были слишком большими и я решил вынести их в отдельную статью.

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

А вот по поводу буферов я категорически не согласен. На мой взгляд, данная техника является чуть ли не самой опасной. Во-первых, это попытка не учиться на своих ошибках, а обложиться буферами, чтобы минимизировать их влияние. Вспомните как раньше делали оценки – менеджер закладывал буфер в магические X% от оценки команды, чтобы “обезопасить себя от этих имбицилов”. Мы же в Scrum пытаемся научиться давать надежные оценки на короткий срок. Спрятавшись за буферами, трудно будет найти свои ошибки и их исправить. Для этого понадобится анализ использования буфера, что приведет к дополнительной работе над сбором и анализом метрик.

Во-вторых, буфер на исправление ошибок в спринте – одна из самых нелогичных вещей в IT. Вводя такой буфер, мы как бы говорим: “Мы заранее знаем, что напишем код с багами!”. А как же критерий готовности, забота о качестве (quality assurance), инженерные практики и надежная поставка? Неужели кто-то может оценить с такой позиции сколько займет фикс багов для задач в спринте? Это же оценки пальцев в небо! Нельзя оценить то, объем чего тебе неизвестен. Зато можно попытаться оценить усилия на предотвращение багов и включить их в изначальную оценку задачи. Ведь на планировании мы все задачи разобрали в деталях и знаем о них все!

Еще любой буфер приводит к усилению действия закона Паркинсона, который гласит: «Работа заполняет время, отпущенное на неё». Так как в спринте использование буфера размазывается по всей итерации (ведь баги же постепенно появляются), то буфер будет использован целиком в любом случае. Даже если багов не будет, его найдут чем заполнить, причем явно не дополнительными задачами из бэклога.

Буфер на выплату технического долга также противоречит идее “разноцветному бэклогу”. Для выплаты технического долга должны создаваться такие же задачи на спринт как и для других элементов бэклога. И их тоже нужно оценивать. Фиксированный буфер приведет к тому, что работа может быть недоделана либо занята часть времени из основного времени спринта. Ни один из этих исходов не является позитивным.

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

Еще один способ обезопасить себя с оценками – “принцип 80 на 20”. Но применять его стоит только если вы уж так неточно делаете оценки и хотите выделить несколько спринтов на адаптацию. Для этого на митинге по планированию выделите 80% задач, для которых вы на 100% уверены в готовности к концу спринта. Оставшиеся 20% задач будут вашим буфером на случай неудачного стечения обстоятельств. Но тем буфером, о котором будет знать заказчик и который вы сможете обсудить на ретроспективе.

А вообще, Agile подходы несут в себе прозрачность, предсказуемость и постоянный самоанализ в качестве основных ценностей. Любой буфер идет в разрез с этими принципами и пытается “замазать” проблемы и скрыть их. Поэтому будьте осторожны и не используйте их в своей работе!

Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!