![](https://bychko.ru/wp-content/uploads/2024/05/Бэклог.jpg)
Pone eam in backlog
Впервые я столкнулся с чем-то, напоминающим протобэклог, в 2011 году, в Utimate Guitar. У руководителя отдела был текстовый файл с перечнем доработок, которые мы должны сделать в разных продуктах. Он открывал файлик в Notepad+ и при помощи горячих клавиш ловко менял строки местами, делая что-то вроде приоритизации.
Потом я пришёл в «Системные технологии» и там уже увидел более полноценный бэклог в виде системы Microsoft TFS, в которой было свалено в кучу множество запросов на доработку. В разных продуктах запросы имели разные типы, везде за приоритет отвечали разные поля, которые назывались по разному, приоритеты тоже выставлялись по разному, где-то сотнями, где-то единицами, в общем, каждый продакт выстраивал свою систему приоритизации бэклога. Но это уже было что-то, по крайней мере, система была доступна для сотрудников компании и хранилась централизованно.
В процессе работы эта система дорабатывалась, создали единое пространство для верхнеуровневых запросов, сделали одно поле для приоритета. В общем, ситуация стала лучше.
Потом я видел и даже внедрял разные системы ведения бэклога, от экселя до джиры. В этой статье мне хотелось бы систематизировать знания об этой сущности и рассказать о наиболее эффективных приёмах работы с ней.
Бэклогом называется структурированный и приоритизированный список актуальных задач, которые команда разработки должна реализовать в ближайшем будущем.
Бэклог может присутствовать в любой системе управления разработкой, необязательно применять его только в скраме или канбане. При работе по ватерфолу, вы можете закидывать в бэклог задачи, которые придумывает заказчик по мере того, как вы ему демонстрируете требования и куски функциональности. Более того, вы можете соорудить себе личный бэклог и использовать для организации жизни. Например, у меня есть список тем, на которые было бы здорово написать статью.
Ключевое слово в определении выше — «актуальных». Не нужно держать в бэклоге свалку, его нужно регулярно вычищать при помощи процесса под названием «груминг бэклога».
Если линкадиновский блок не отображается, включите vpn или автоматические прокси:
Чтобы отобразить линкадиновский блок, включите впн или автоматические прокси.
По-хорошему, нужно выстроить процесс для работы с бэклогом. Как и от кого туда могут попадать запросы, как часто проводится процедура оценки, кто и когда его приоритизирует, как часто проводится груминг.
Бэклог обязательно должен быть в виде, понятном людям, поставляющим вам задачи. В продуктовой разработке, это продакт-овнер. Поэтому локальный файлик не подходит. Наиболее комфортным для себя способом представления я считаю джиру.
Какие виды бэклогов существуют?
Бэклог продукта
В скраме под бэклогом обычно понимается именно этот. Содержит, по большей части, пришедшие от продакт-овнера задачи. Также там могут быть обработанные продактом пожелания пользователей продукта или задачи, пришедшие от разработчиков, в том числе существенные куски технического долга.
Бэклог спринта
Это список задач, который команда взяла в спринт и обязуется выполнить. Фактически — применённый к предыдущему бэклогу фильтр. У спринта обязательно должен быть айдишник. Применяется в скрамоподобных методологиях. Но и при ватерфоле вы можете работать итерациями, делая бэклог итерации.
Бэклог гипотез
Инструмент продакта. Продакт-менеджер в течение всего жизненного цикла продукта генерирует и проверяет различные гипотезы. Этих гипотез может быть до сотни и чтобы ими нормально управлять, тоже нужен бэклог.
Бэклог обращений
Инструмент техподдержки. Обычно ведётся в каком-то специализированном инструменте. Так как техподдержка может генерить запросы на изменение для продуктовой команды, есть смысл шарить этот бэклог также на разрабов.
Какие поля должны быть в элементе бэклога
- Айдишник. Называть элемент бэклога в общении с коллегами по заголовку или краткому наименованию неудобно. Нужно иметь постоянные идентификаторы.
- Приоритет. Поле, по которому бэклог будет упорядочиваться.
- Инициатор. Наличие этого поля очень здорово помогает на старте работы с элементом — становится понятно, к кому идти за уточнением требований.
- Дата добавления в бэклог. Чтобы понимать, насколько документ старый, очень полезное поле.
- Краткое наименование. Заголовок, как при создании бага.
- Детальное описание. Я считаю, что продакт обязан составлять детальное описание фичи, хотя бы на бизнес-языке. Более формальное описание уже позже подготовят аналитики.
- Критичность. Можно в виде «да/нет». Помечать особо важные истории.
- Комментарий. Для всего, на что не хватило остальных полей.
Обслуживание бэклога
В том же «Систехе» я время от времени занимался тем, что открывал бэклог, переходил к самым нижним элементам и связывался с инициаторами, задавая им один и тот же вопрос: «Насколько актуальна эта доработка?» Очень часто получал ответ, что доработка потеряла актуальность и её можно исключить.
В «Инвитро» мы собирались с тимлидом, ведущим аналитиком и тестлидом, просматривали бэклог в джире, искали там заведомо неактуальные вещи самостоятельно, потому что из-за текучки найти инициатора было почти невозможно. Например, в один прекрасный момент руководство Инвитро решило закрыть интернет-магазин и, как следствие, все доработки интернет-магазина стали неактуальными.
В процессе груминга можно вчитываться в описания доработок и по ходу действия вырабатывать вопросы к продакт-овнеру. Можно их фиксировать там же.
Есть смысл проверять элементы бэклога на дубли. В некоторых случаях запросы можно объединить или удалить однозначно дублирующие.
В целом, это всё, что вам нужно знать о бэклоге. Приоритизируйте, держите актуальным, делитесь с коллегами, регулярно чистите.