7 351 
Оставить комментарий
Сохранить статью:
В статье рассказывается:
- Что такое бэклог
- Отличия бэклога продукта от бэклога спринта
- Составляющие бэклога
- Приоритизация задач в бэклоге
- Порядок составления бэклога
- Груминг и рефаймент бэклога
- Уменьшение бэклога
-
Пройди тест и узнай, какая сфера тебе подходит:
айти, дизайн или маркетинг.Бесплатно от Geekbrains
Для оптимальной работы над проектом необходимо знать, что такое бэклог, его составляющие и правила ведения. Простыми словами, это список предстоящих задач, составленный с учетом приоритета каждого пункта.
Звучит просто, однако на деле нередки ситуации, когда бэклог принимает огромные размеры, а время, необходимое для решения всех задач в нем, составляет даже не месяцы, а годы. В нашей статье мы расскажем, каковы задачи бэклога, что в нем должно быть и как правильно его оптимизировать, чтобы работа была эффективной.
Что такое бэклог
Этот термин разработчики используют для обозначения списка заданий, который ранжирован по рейтингу их важности. Он составляется на основании «дорожной карты» проекта и его требований. В начале бэклога продукта идут самые важные задачи, которые команда должна выполнить первыми.
При этом, на скорость их выполнения не влияют пожелания собственника. Участники рабочей группы сами выбирают для работы задачи бэклога, как только у них появляются соответствующие ресурсы. Они могут осуществлять выполнение заданий итерациями (Scrum) или безостановочно (Kanban).
Все задачи бэклога следует сохранять в одном трекере. Для поиска багов, отслеживания требований владельца и выполненных пунктов списка должна применяться только одна система. Если появляется новая задача для участников рабочей группы, она должна попадать в один и тот же бэклог.
Отличия бэклога продукта от бэклога спринта
Бэклог продукта (product backlog) представляет собой структурированный перечень компонентов, задач и список функций, которые необходимо реализовать в рамках разработки проекта.
Product owner или продакт-менеджер представляет бэклог команде разработчиков, обеспечивает описание его основных элементов в ходе встречи, где осуществляется планирование спринта. Такой специалист управляет работой команды.
Для описания элементов перечня задач важно использовать понятные всем термины, избегая узкоспециальных названий. Важно, чтобы задания были понятны всем, кто работает над проектом. В перечне задач должны отражаться все изменения и новые требования к продукту.
входят в ТОП-30 с доходом
от 210 000 ₽/мес
Скачивайте и используйте уже сегодня:
Топ-30 самых востребованных и высокооплачиваемых профессий 2023
Поможет разобраться в актуальной ситуации на рынке труда
Подборка 50+ бесплатных нейросетей для упрощения работы и увеличения заработка
Только проверенные нейросети с доступом из России и свободным использованием
ТОП-100 площадок для поиска работы от GeekBrains
Список проверенных ресурсов реальных вакансий с доходом от 210 000 ₽
В свою очередь, бэклог спринта представляет собой список конкретных заданий по реализации уже отобранных для работы элементов. Здесь находится перечень задач по оптимизации, которые разработчики будут выполнять в течение ближайшего спринта, а также описание вариантов их реализации.
Оба эти элемента могут быть отображены в форме стандартной таблицы Excel. Опытные продакт-менеджеры для представления бэклогов продукта и спринта чаще используют специальные приложения для управления проектами. Такие инструменты обеспечивают эффективную визуализацию процесса разработки.
Отметим также, что бэклог продукта разрабатывает продакт-менеджер, а перечень задач спринта находится в зоне компетенций команды разработчиков. Есть еще одно важное отличие в рассматриваемых понятиях. Product-бэклог оформляется уже в ходе первого планирования спринта. В свою очередь Sprint-бэклог необходимо создавать в ходе проработки плана для каждого отдельного спринта.
Таким образом, бэклог продукта будет жить в течение всей работы над проектом, а перечень задач Sprint существует лишь 7 – 14 дней, пока идет работа над очередным спринтом.
Составляющие бэклога
Стандартный набор бэклога – задачи и их приоритетность. Чем выше цифра — тем больше приоритет, а существенные пробелы между числами (100, 300, 600, 2000 и т.д.) дают возможность различных комбинаций: в любое время можно вставить дополнительную задачу между имеющимися.
Классическими критериями приоритизации бэклога могут являться преимущества для бизнеса, затраты (или необходимые ресурсы) и возможные риски (положительное воздействие внедрения определенной части продукта или же негативное влияние отсутствия фичи).
Для всего процесса создания продукта двух разделов в бэклоге будет недостаточно, поэтому здесь вносятся и другие поля.
Подробное описание целей и желаний
Совершенный перечень рабочих задач – это тот, где в каждой строчке обозначено определенное задание. При неполном представлении конкретных пожеланий владельца продукта сложно понять их смысл, поэтому, чем выше приоритетность задания, тем детальнее должно быть его представление.
Скачать файлЧем ниже уровень задачи бэклога, тем менее детализированным будет ее описание. Есть и обратная сторона: чем выше задание в списке, тем более развернутым необходимо сделать его представление, чтобы повысить подготовленность к дальнейшей работе.
Возможные сложности
Могут измеряться в часах, но часто разработчики прибегают к условным единицам измерения — в часах, Story Point-ах: один балл – классическая задача бэклога, а все остальные будут оцениваться сравнительно с ней.
Категория компонентов
Задачи в список могут быть добавлены по различным обстоятельствам: как правило, это мысли и предположения, а иногда и отклики от клиентов и технические параметры, требующие модернизации. В этом случае было бы неплохо распределять задания по определенным категориям при помощи, например, переформатирования.
Инициатор или владелец задачи
Пример бэклога продукта – это медленно формирующаяся система, которая через некоторое время начинает значительно разрастаться. Таким образом, после нескольких месяцев бывает очень сложно вспомнить, кто, в какое время, а, главное, для чего посоветовал «покрасить кнопку в красный цвет», удалить из формы поле с представлением задачи или прибавить ещё одну категорию доставки.
Подобный раздел будет очень полезен. В связи с этим стоит задать дату внесения задачи в список и ее инициатора, но нужно учитывать, чем больше число колонок, тем сложнее поддерживать актуальность бэклога.
Статус
Колонка может пригодиться для процесса быстрой фильтрации, а ещё для отбора определенных задач спринта и удобства наблюдения за развитием.
Необходимых полей нет, многое зависит от самого проекта и действий по его разработке. Следовательно, если есть необходимость добавить индивидуальные колонки, то такая возможность есть всегда. Главная цель – поддерживать их актуальность.
Приоритизация задач в бэклоге
В зависимости от этапа работы над проектом, задачи могут подлежать разной степени детализации.
на курсы от GeekBrains до 28 апреля
Большинство запросов к проекту фильтруются и регистрируются, но детальному описанию подлежат те, которые отправятся в работу в ближайшее время. Если каждая задача будет детально разбираться, то она в скором времени потеряет всю свою актуальность.
Чтобы назначать приоритет задания, необходимо соответствие как минимум двух идентификаторов: насколько оно важно с точки зрения бизнес-процессов, и сколько затрат потребуется на его создание.
ТОП-100 площадок для поиска работы от GeekBrains
20 профессий 2023 года, с доходом от 150 000 рублей
Чек-лист «Как успешно пройти собеседование»
Первый показатель будет определять хозяин продукта, а анализ общей работы оценивает команда на начальном этапе планирования спринта. К примеру, для коммерческой деятельности задача на девять баллов будет носить очень значимый характер, а по сложности работы это четыре story point (баллы сложности, вычисляемые по сравнению с иными задачами). В действительности, процедура оценивания намного труднее, чем кажется, и зачастую носит спорный характер.
Порядок составления бэклога
Так как в ходе работы над проектом не исключено появление конкурентов в рыночной нише, изменение стоимости, рыночных требований и других условий, оказывающих влияние на конечный продукт, бэклог должен постоянно обновляться.
Как было отмечено ранее, существует ряд инструментов, который продакт-менеджеры используют для создания backlog. Это product roadmap, user stories и customer journey map. Рассмотрим каждый из них в отдельности:
- «Продакт роудмэп» визуализирует задачи и общие свойства продукта, пути его развития и стадии создания. В большинстве случаев этот документ не содержит отдельных деталей, но включает сроки выполнения заданий, а также позволяет рассчитывать время их выполнения.
- «Юзер сторис» упрощает составление требований и способствует более точному пониманию пользователей. Этот инструмент имеет вид сжатого описания тех моментов, которые связаны с хотелками пользователя, и объяснения, почему ему это необходимо.
- «Кастомер Джорни Мэп» визуализирует цели, эмоции клиента и преграды, возникающие на его пути. Такую карту клиентского пути необходимо формировать под каждую «Юзер сторис». Customer journey map способствует выявлению слабых мест продукта и позволяет более точно расставить приоритеты в работе разработчиков. Также, как и предыдущие документы, Джорни Мэп необходимо постоянно корректировать и обновлять.
Рассмотрим алгоритм действий по разработке бэклог продукта с использованием трех представленных выше инструментов:
- Составьте перечень функций, планируемых для реализации в продукте, и расставьте их в порядке важности с использованием «продакт роудмэп».
- Сформулируйте user stories (истории пользователей) по каждой отдельной функции и сделайте анализ их ценности для потенциального клиента.
- Определите основные функции, которые будет иметь будущий продукт, расставьте их в порядке важности и внесите в product backlog.
- Проставьте планируемые сроки выполнения заданий и определите ответственных членов команды по каждому из них.
- Организуйте проведение встречи с командой разработчиков, проведите обсуждение составленного бэклога и внесите необходимые корректировки.
Дальнейшие задачи, вероятнее всего, будут требовать корректировок с учетом итогов первых спринтов и обратной связи. Важно скрупулезно собирать все необходимые данные и помнить о необходимости постоянного анализа и обновления product backlog.
Груминг и рефаймент бэклога
Груминг бэклога представляет собой процесс постоянного уточнения и корректировки проекта. В переводе с английского «grooming» — это «причесывание». Это слово раскрывает суть процесса, связанного с исследованием, систематизацией компонентов проекта и расстановкой приоритетов.
Рефаймент бэклога – мероприятия по его оптимизации. Их цель состоит во внесении новых элементов, оценок и обеспечении упорядоченности этапов плана. На рефаймент уходит до 10% времени разработчиков.
Кто может вносить правки в существующий план работ?
- Члены рабочей группы, создающей продукт.
- Собственник продукта, участник команды, выступающий в качестве эксперта и контролирующего органа. Такие лица могут корректировать направление разработки и приоритетность задач.
- Скрам-мастер решает вопросы повышения производительности членов рабочей группы.
- Стейкхолдеры – другие участники процесса, заинтересованные в проекте.
В мероприятиях по актуализации перечня задач могут участвовать и другие специалисты.
Что включает grooming бэклога?
- Детальный обзор требований владельца продукта.
- Расстановку необходимых опций продукта в зависимости от их сложности и приоритетности.
- Повторный анализ утвержденных и новых задач.
- Дополнение бэклога новыми описаниями и элементами.
- Группировка деталей плана.
- Разделение масштабных задач на отдельные стадии.
- Проработка несоответствий и элементов, не соответствующих логике задач.
Бэклог refinement предполагает удаление из существующего плана «лишних» элементов. Обновление перечня задач дает возможность оптимизировать занятость разработчиков и снимает лишние задания. Этот процесс позволяет упростить планирование занятости рабочей группы и избавиться от неопределенности в хотелках владельца продукта.
Благодаря постоянной актуализации задач удается предотвратить повторную работу над отдельными пунктами плана и их дальнейшую переделку. Таким образом оптимизируется работа разработчиков и ускоряется процесс реализации всего проекта.
Чтобы оптимизировать деятельность рабочей группы, следует предусмотреть организацию груминга в виде коротких собраний с периодичностью, которая определяется, исходя из имеющихся условий работы и потребностей процесса. Как правило, такие встречи участников команды разработчиков проводятся один-два раза в неделю перед тем, как перейти к новому этапу работы над продуктом.
Уменьшение бэклога
Стоит отметить, что чрезмерно расширенный активный список бэклога может свидетельствовать о неумении расставлять приоритеты и является признаком непрофессионального подхода к организации процесса. Мнение о том, что это следствие нехватки ресурсов, является ошибочным.
Опытный специалист всегда сможет компенсировать недостаток ресурсов точными расчетами, договориться с участниками об удалении элементов бэклога, последующем анализе объемов задач с учетом принципов разработки, о привлечении дополнительных членов в рабочую группу. Рассматривать на каждом собрании огромные объемы информации бэклога, включающего сотни пунктов, о которых уже давно забыли инициировавшие их участники – это не лучшее решение.
Единого совета для всех ситуаций не существует, но есть моменты, которые следует сделать, чтобы упростить работу с бэклогом:
- Провести анализ актуальности задач. Возможно их инициировали те участники, кто уже давно покинул проект или они потеряли к этому всякий интерес.
- Сделать проверку на наличие дублей. Есть примеры, когда в списке присутствует много одинаковых, но по-разному сформулированных пунктов.
- Сделать расчеты по трудозатратам и продолжительности реализации бэклога, учитывая статистику появления новых задач. Возможно, перечень заданий только выглядит большим, а на практике вашей команде, с учетом профессионального планирования работ, удастся справиться за несколько месяцев. Отдельно остановимся на динамике прироста задач. Цифры – упрямая вещь, и с ними не поспоришь. Нужно получить максимально подробную информацию по источникам заданий. Возможна ситуация, когда инициатором почти всех задач выступает один не ключевой «отдел администрирования» и для оптимизации процесса его на время следует «забанить».
- Установить четкие правила по удалению элементов из бэклога. Возможно, до момента, когда получится «разбросать» наиболее важные пункты из длинного списка задач, стоит приостановить все вопросы в отношении дизайна и дополнительных функций. Да, здесь понадобится умение объяснить владельцу продукта такое решение и рассказать, что над «оттенком кнопок» можно поработать и позже. Это не всегда просто, но это тоже работа менеджера бэклога.
- Используйте инструменты приоритезации на подобие MoSCoW, Kano и т.д. Такая система должна позволять сделать максимальную очистку списка от задач с низкой приоритетностью. В самом простом варианте можно для начала сделать анализ Value/Effort и отталкиваться от полученного результата.
Оптимизация бэклога, независимо от того, какой продукт подлежит разработке, является обязательным элементом управленческого инструментария.
Опытный специалист по управлению проектами, используя специальные инструменты, всегда сможет разобраться с бэклогом и превратить рутинное управление проектом в интересный процесс.
Ищете самую востребованную и высокооплачиваемую профессию? Станьте DevOps-инженером с нуля. Присоединяйтесь к нашему курсу, где вы освоите все необходимые навыки для работы в индустрии разработки программного обеспечения. Получите практический опыт в автоматизации процессов, контейнеризации, управлении конфигурациями. Научитесь автоматизировать процессы разработки и внедрения ПО, организовать непрерывную интеграцию и доставку (CI/CD), работать с облачными сервисами, Docker и Kubernetes. Запишись сейчас и открой двери в мир возможностей DevOps.
Разберем 11 самых важных жизненных вопросов
Только до 
Эксклюзивные лекции по основам программирования
