Рефайнмент бэклога и как это повышает эффективность работы

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

Привет, это Илья, CTO 2people IT. Бэклог – ваша кухня, а рейфайнмент (груминг) – генеральная уборка. Как бы тщательно вы за ним не следили, периодически необходимо его чистить и адаптировать к планируемым спринтам. Если вы склонны обдумывать задачи на ходу и перетаскивать их из бэклога продукта в спринт по наитию, то эта статья для вас.  

Когда проводить рефайнмент?

Рефайнмент проводится регулярно до начала каждого спринта. Главный выходной артефакт рефайнмента – список User Stories (далее – US), планируемых к выполнению в течение спринта. Такой список позволяет разработчикам (или их лиду) запланировать время на детализацию этих US. Результатом детализации является список атомарных задач для разработчиков (dev-tasks). Именно этими задачами наполняется спринт в процессе планирования. 

А кто чем занимается?

В команде всё должно быть поровну:

- ПМ/owner планирует US к выполнению,

- Лид с командой (или без) раскладывает их на dev-task’и

- Разработчики выполняют их в соответствии с приоритетом


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

ПМ/owner не из головы выбирает US, включаемые в спринт, не случайно назначает им приоритеты. Лид и команда не рандомайзером оценивают dev-task’и. Для каждого из этих процессов существуют множества методов (MoSCoW для owner’a и US, planning poker для команды и dev-задач), о них мы расскажем в одном из следующих выпусков. Рефайнмент же выступает здесь в качестве отправной точки.

Вне собраний с командой ПМ обрабатывает информацию в бэклоге. Основное – определение приоритета каждой задачи. Важно учесть каждый фактор, для этого существует несколько систем. Например, MoSCoW для линейной приоритетности. Или PAST/FUTURE – BUSINESS/TECHNICAl. Они подразумевают распределение задач на 4 категории, две из которых (future) существуют для планирования, а две других (past) для анализа сделанного.

Team Lead занимается декомпозицией задач. Это даёт ясность, позволяет распределять их внутри команды и повышать эффективность работы.  

Бэклог – не верхушка айсберга, он очень DEEP

Это характеристики хорошего бэклога продукта. DEEP = Detailed appropriately, Estimated, Emergent and Prioritised, то есть: Детализированный, Оцененный, Развивающийся и Приоритезированный. 

  • Детализированный – от общего к частному, но без фанатизма. Достаточно четкой формулировки из нескольких слов. Наличие слишком большого количества деталей обычно приводит к потере времени, поскольку требования, скорее всего, изменятся к моменту работы.

  • Оцененный – это означает, что все элементы в бэклоге должны быть оценены командой, которая будет их создавать.

  • Развивающийся – бэклог продукта должен изменяться с течением времени. Новые требования возникают по мере того, как развивается продукт.

  • Приоритезированный – важной характеристикой задачи в бэклоге является то, что она имеет приоритетность, обычно по бизнес-ценности.

И небольшой блиц, FAQ по бытовым вопросам:

Как рефайнмент влияет на эффективность работы?

Позволяет сделать спринт более четким и понятным. Помогает при планировании спринта не забыть важные задачи, которые могут потеряться в бэклоге из-за его объема. Если его разбирать регулярно, то в бэклоге будут только актуальные, релевантные задачи, которые следует взять в ближайший спринт.

Чем рефайнмент отличается от рутинной работы с бэклогом?

Рейфайнмент – чуть более глубокая и основательная, но такая же рутинная часть работы.

Особенности нашей работы с бэклогом

Мы стараемся планировать спринты одинаковой длительности. Обычно они отличаются только на разных проектах, внутри каждого отдельного – они одинаковые. Чаще всего это зависит от длительности самого проекта, чем он короче – тем короче спринт. Рефайнмент мы совмещаем с планированием спринтов, если они короткие. И проводим отдельно, когда необходимо дополнительное время для оценки других задач между работой с бэклогом и планированием следующего спринта.

Часто ли меняется приоритет задач, удаляются задачи с низким приоритетом?

Да, когда появляется блокер или в бэклог попадает большое 

количество задач. С течением времени приоритет каждой задачи может может быть изменен кардинально. 

Дело привычки

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

Источник: https://habr.com/ru/post/692084/


Интересные статьи

Интересные статьи

Добро пожаловать  на 2-й день челленджа #30DaysOfPlaywright!Материал первого дня обучения содержал информацию о том, как настраивать и проверять нашу локальную среду для тестирования. П...
Привет, Хаброжители! Когда дело доходит до выбора, использования и обслуживания базы данных, важно понимать ее внутреннее устройство. Как разобраться в огромном море доступных сегодня распределенных ...
Приглашаем всех желающих посетить бесплатный вебинар. Мероприятие пройдет 2 февраля в 11:00 по московскому времени. Мониторинг и отслеживание полезной работы оборудования...
В 1С Битрикс есть специальные сущности под названием “Информационные блоки, сокращенно (инфоблоки)“, я думаю каждый с ними знаком, но не каждый понимает, что это такое и для чего они нужны
Сегодня мы поговорим о перспективах становления Битрикс-разработчика и об этапах этого пути. Статья не претендует на абсолютную истину, но даёт жизненные ориентиры.