Что такое бэклог продукта

При работе над проектом важно планировать и определять приоритет задач в проекте.

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

• В бэклог продукта включаются только первоочередные задачи и требования клиентов к качеству. Первыми в списке располагаются приоритетные цели, благодаря чему команда всегда знает, на чем стоит сосредоточиться в первую очередь.
• Бэклог гибок и постоянно адаптируется под текущий рабочий процесс. По мере работы над проектом, Agile-команда сверяется с бэклогом продукта и редактирует его в зависимости от выполненной работы и потребностей клиента.
• Владельцу продукта нет необходимости раздавать задачи исполнителям, так как участники берут их из бэклога самостоятельно, что обеспечивает непрерывную работу над проектом.

Стоит учитывать, что бэклог работает таким образом только в том случае, если он грамотно составлен и постоянно обновляется.

Чем бэклог в Agile отличается от простого списка задач

Бэклог имеет свои уникальные особенности:

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

Из чего состоит бэклог продукта

Бэклог — это модульный документ, который состоит из четырех групп. У каждой из них свое назначение и специфика.

Функции

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

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

Ошибки и баги

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

Выделяют три вида багов:

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

Технический долг

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

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

Исследования

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

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

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

На чем основан бэклог продукта

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

Дорожная карта проекта — это визуализация стадий разработки проекта. С ее помощью владельцы продукта устанавливают сроки реализации. Дорожная карта ориентирована на глобальные задачи, она отображает концепцию продукта, его стратегию и достигнутые цели.

Дорожную карту нередко путают с бэклогом продукта. Однако в бэклоге указываются более частные задачи, которые раскрывают, как именно должен идти рабочий процесс над целями, отмеченными в дорожной карте.

Пользовательские истории — описание функций продукта простыми, общими словами, составленное с точки зрения пользователя. Благодаря им участники Agile-команды понимают, какими преимуществами будет обладать продукт после нововведений и что получит пользователь. Это позволяет работать более целенаправленно.

В Kaiten есть специальный модуль — User Story map. Он помогает увидеть большую картину продукта в формате Roadmap и структурировать пользовательские истории.

Для каждой пользовательской истории в модуле User Story map можно создавать карточки — добавлять описание, присваивать метки, статусы и размер. А главное — привязывать к ним конкретные задачи на рабочих пространства.

Как собрать бэклог продукта

В рамках Agile владелец продукта отвечает за создание и управление бэклогом. Для этого необходимо выполнить четыре шага:

1. Составить четкую дорожную карту проекта

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

2. Создать элемент невыполненной работы

Владелец продукта на основе пожеланий клиентов формирует список задач, которые необходимо выполнить по ходу работы над проектом. Необходимо вносить в этот список только те цели, которые имеют ценность для проекта.

3. Приоритизировать задачи

Для понимания, на чем конкретно необходимо сосредоточить свое внимание, стоит правильно оценивать важность каждой задачи по критериям:

• Ценность
• Сложность и риск
• Ожидания клиентов
• Усилия по развитию

По ходу работы приоритеты могут меняться, именно поэтому владельцу продукта необходимо вовремя обновлять бэклог.

4. Постоянная доработка бэклога продукта

Список невыполненных задач необходимо актуализировать, убирать уже выполненное, редактировать старые пользовательские истории, добавлять новые и разбивать те, что стали слишком большими, переоценивать приоритеты и обновлять их.

Так называемый Agile-уход за бэклогом гарантирует, что он останется актуальным, подробным и будет соответствовать текущей стратегии проекта.

Бэклог спринта vs бэклог продукта

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

Бэклог спринта — это список задач для оптимизации продукта, над которой команда будет работать в ближайший спринт и описание этого рабочего процесса. Над ним работает команда Agile, тогда как бэклог продукта составляет его владелец. Бэклог спринта команда составляет перед каждой новой итерацией, таким образом он живет от одной до четырех недель, то есть всё время спринта.

Тогда как бэклог продукта создается во время планирования первого спринта и существует на протяжении всей работы над проектом.

Вывод

Бэклог продукта помогает команде следовать принципам Agile. Он позволяет:

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

Есть 2 важных условия, при которых бэклог продукта будет приносить пользу:

1. Он должен быть грамотно составлен на основе пользовательских историй;
2. Его нужно регулярно чистить и обновлять.

Kaiten позволяет удобно управлять бэклогом продукта:

• Фиксировать элементы невыполненной работы на отдельной доске на одном рабочем пространстве с остальными функциональными досками;
• Распределять задачи по приоритетам;
• Вести коллективную оценку задач в бэклоге;
• Создавать пользовательские истории и связывать их с карточками на рабочем пространстве;
• Видеть прозрачную отчетность по задачам и следить за прогрессом их выполнения.