Бэклог agile что это
Бэклог продукта — совершенный список задач
Бэклогу продукта, как и человеку, нужны уход и внимание. А еще он должен быть открыт для других.
Просмотр тем
Agile-бэклог с правильно расставленными приоритетами не только упрощает планирование релизов и итераций. Из него команда узнает, над чем она будет работать. Вся внутренняя кухня скрыта от глаз клиента. Работа становится для заинтересованных лиц и других команд более предсказуемой, что особенно полезно, когда они ставят перед вами дополнительные задачи. Время на разработку становится фиксированным ресурсом.
Что такое бэклог продукта?
Бэклог продукта — это перечень рабочих задач, расположенных в порядке важности, для команды разработчиков. Его составляют на основе дорожной карты и требований в ней. Наиболее важные задачи расположены в начале бэклога продукта, чтобы команда понимала, какую работу следует выполнить в первую очередь. Скорость, с которой команда выполняет задачи бэклога, не зависит от желаний владельца продукта, а он, в свою очередь, не оказывает давления на команду. Напротив, команда разработки самостоятельно выбирает задачи из бэклога продукта, когда у нее есть необходимые ресурсы, выполняя их непрерывно (Kanban) или итерациями (Scrum).
Храните все в одном трекере задач. Не используйте несколько систем для отслеживания багов, требований и рабочих задач по разработке. Есть задача для команды разработчиков? Тогда информация о ней должна быть в одном бэклоге.
Два столпа бэклога продукта
В основе бэклога продукта находятся дорожная карта команды и требования. Инициативы дорожной карты делятся на несколько эпиков, а каждый эпик содержит несколько требований и пользовательских историй. Рассмотрим дорожную карту для вымышленного продукта «Команды в космосе».
Веб-сайт «Команды в космосе» — первая инициатива на дорожной карте, поэтому нам нужно разбить ее на эпики (обозначены на рисунке зеленым, синим и бирюзовым цветами) и пользовательские истории для каждого эпика.
Владелец продукта составляет из этих пользовательских историй единый список для команды разработчиков. Владелец продукта может упорядочить истории так, чтобы команда сначала выполнила один эпик полностью (слева). Как вариант, может быть важнее сначала протестировать бронирование билетов со скидкой, а для этого нужно реализовать истории из нескольких эпиков (справа). Оба варианта представлены ниже.
Что может повлиять на то, как владелец продукта расставляет приоритеты?
Хотя расстановкой приоритетов занимается владелец продукта, в процесс вовлечены и другие стороны. Успешность бэклога зависит от вклада и обратной связи, предоставленной клиентами, дизайнерами и командой разработчиков. Совместными усилиями они должны добиться оптимальной рабочей нагрузки между всеми участниками и обеспечить поставку продукта.
Правильное ведение бэклога
После создания бэклога важно регулярно корректировать его по мере выполнения программы. Владельцы продукта должны пересматривать бэклог перед каждым собранием по планированию итерации, чтобы уточнить расстановку приоритетов и внести изменения на основе выводов, сделанных в результате последней итерации. Регулярный пересмотр бэклога в кругах специалистов по Agile часто называют «грумингом» или «ведением бэклога» (некоторые используют термин «уточнение бэклога»).
Когда бэклог становится достаточно большим, владельцам продукта приходится выделять в нем группы краткосрочных и долгосрочных задач. Краткосрочные задачи нужно досконально проработать, прежде чем присвоить им этот статус. Для этого нужно составить полноценные пользовательские истории, обсудить все детали совместной работы с дизайнерами и разработчиками и оценить сложность разработки. Долгосрочные задачи могут быть продуманы не до конца, однако если команда разработчиков даст им приблизительную оценку, это поможет расставить приоритеты. Ключевое слово здесь — «приблизительная». Оценки поменяются, когда команда получит полное понимание долгосрочных задач и приступит к их выполнению.
Бэклог служит связующим звеном между владельцем продукта и командой разработчиков. Владелец продукта может в любое время поменять приоритеты в работе на основе обратной связи от клиентов, более точных прогнозов и новых требований. И все же следует избегать изменений в ходе работы, потому что они мешают команде разработчиков, негативно влияя на концентрацию, рабочий процесс и моральный дух.
Когда бэклог становится слишком большим, чтобы на него хватало ресурсов команды даже в долгосрочной перспективе, задачи, до которых никогда не дойдет очередь, можно закрывать. Помечайте такие задачи специальной меткой, например «Вне объема работ», в трекере задач команды, чтобы изучить их позднее.
Плохие примеры, которые лучше не повторять
Бэклоги продукта и верность команды принципам agile
Опытные владельцы продукта со всей ответственностью подходят к ведению бэклога продукта, чтобы он был надежным источником рабочих задач по проекту, которые предназначены для совместной работы.
Заинтересованные стороны будут оспаривать принятую очередность задач — и это хорошо. В результате обсуждения того, какие работы важнее, все приходят к общему представлению о приоритетности задач. Такие обсуждения способствуют формированию культуры, в которой приоритеты расставляются групповыми усилиями и все участники объединены общим взглядом на программу.
Кроме того, на основе бэклога продукта планируются итерации. В бэклог должны быть включены все рабочие задачи: пользовательские истории, баги, изменения в дизайне, технический долг, запросы клиентов, действия, намеченные по итогам ретроспективы, и т. д. Так рабочие задачи каждого участника будут рассмотрены на общем обсуждении перед каждой итерацией. Затем участники команды и владелец продукта с полным пониманием объемов задач и учетом обоюдных интересов принимают решения до начала итерации.
Владельцы продукта определяют важность рабочих задач в бэклоге, в то время как команда разработчиков определяет скорость работы над ними. Новым владельцам продукта, которые привыкли торопить команду, такой подход может оказаться не по душе. Подробнее см. в нашей статье о лимитах объема незавершенной работы и рабочем процессе.
Для чего и как проводят backlog grooming в продуктовых командах?
Бэклог продуктовых задач является одним из основных и обязательных артефактов Agile. Фактически, это набор требований, полученных от бизнеса и сформулированных в виде задач для разработки. Что нужно делать для того, чтобы эти задачи всегда были в порядке? И как это связано с концепцией backlog grooming?
Набор таких задач не несет ценности, если не приносит системной или структурной оптимизации. Очень важно правильно уметь управлять очередью задач, чтобы получить актуальный материал для работы. Как раз это и является целью такого процесса или активности, как backlog grooming.
Еще один тип встреч в Scrum
Backlog grooming — это собрание представителей Scrum-команды, во время которого обсуждаются детали бэклога продукта и готовится очередное планирование спринта.
Наверняка, большинство менеджеров и собственников продуктов благодаря опыту и практике знают, как превратить рутинное управление бэклогом в приятный процесс. Чтобы достичь этого, необходимо тщательно ухаживать за бэклогом, “чистить” и оптимизировать его. Это то, что называется grooming или product backlog refinement.
Согласитесь, любой продукт, как и человек, требует внимания и заботы.
Стратегический смысл груминга в управлении продуктом
Поскольку бэклог представляет собой очередь из пользовательских историй, то, часто, такой список может быстро стать перегруженным. Многие не знают, как справляться с такой перегрузкой, а бэклог продолжает расти.
Когда это случается, члены команды могут потерять фокус на важных задачах, а статус пользовательских историй может утратить ясность. Также могут возникнуть проблемы с оценкой времени и ресурсов.
Уход за бэклогом — это активность с участием менеджера проекта (менеджера продукта/ собственника продукта) и представителя клиента, направленная на то, чтобы разбить бэклог на истории пользователей, переориентировать их и задать новые приоритеты. Backlog grooming в управлении продуктом должен стать постоянным событием, основанном на глубоком анализе и четких действиях.
Этот процесс необходим для того, чтобы задачи, представленные в бэклоге, были актуальными, а те, которые представлены в верхней части списка, были готовы к планированию в спринте, реализации и релизу.
Груминг бэклога часто называют предварительным планированием. Обычно собственник продукта и представители команды организуют его в середине спринта.
Процесс не считается формальный частью Scrum. Тем не менее, рекомендуется, чтобы владелец продукта и представители команды выделяли до 15% каждого спринта для такой активности.
Главные цели процесса backlog grooming
Иногда собрание по backlog grooming называют story time session. В любом случае, цель этого мероприятия — обсудить текущий бэклог, определить и предложить действия по его оптимизации. Это может включать следующее:
Результат хорошего груминга
Результатам grooming является здоровый вид бэклога:
Какие инструменты использовать для backlog grooming?
Поскольку определение приоритетов — ключевой момент во время проведения backlog grooming, то очень важно грамотно визуализировать важность и взаимосвязь задач для дальнейшей работы с ними. Для упорядочивания идей и задач менеджеры продуктов используют параметры Value и Efforts. Сравнение этих значений для каждой задачи помогает лучше определить приоритеты и выбрать наиболее важные задачи.
В качестве заключения
Важно помнить, что grooming должен стать постоянным событием в управлении продуктом, которым не стоит пренебрегать. Этот процесс — это норма для качественного развития продукта. Самое главное в нем — оптимизировать задачи бэклога для последующей работы с ними.
Backlog grooming помогает прояснять релевантность задач, представленных в бэклоге, анализировать существующие вопросы и получать дополнительную информацию о задачах, которые пока не до конца ясны.
Подытоживая, отметим основные преимущества backlog grooming:
Backlog в управлении продуктом: что делать, когда идеи нарастают «как снежный ком»
В условиях высокой конкуренции важно концентрироваться на самом приоритетном. Конкуренты постоянно выпускают новые фичи. Их так много, что просто не хватает времени на их изучение. Клиенты в развитии продукта также играют важнейшую роль, предлагая улучшения, конструктивную критику и свежие советы. В общем, идеи растут «как снежный ком».
В любом продукте, скорее всего, хотят внедрять те функции, которые поднимут на новый уровень доходы, увеличат возвраты (retention) или виральность (virality).
Здорово, если вы уже внедрили какой-либо количественный фреймфорк, например, Pirate Metrics (AARRR). Он помогает сконцентрироваться на самых важных этапах вашей воронки продаж, а именно на AARRR (acquisition, activation, retention, referral, revenue).
Однако вернемся к большому скоплению идей и инициатив.
Определяем проблему
Итак, проблема следующая — у вас скопилось много идей из разных источников: из Intercom, Zendesk, Satismeter, из личных бесед с клиентами, от сотрудников. Вам становится все сложнее выбирать идеи для очередного спринта. Причем, цена ошибки очень высока: вы рискуете сделать такую фичу, которая будет невостребованная аудиторией и не принесет ожидаемых бенефитов. Например, она не увеличит конверсию в регистрацию или ARPD.
Backlog постоянно растет и управлять им становится все сложнее — менеджер продукта тратит много времени на его аудит, во время которого он просматривает идеи, расставляет приоритеты, выбрасывает то, что перестало быть актуальным. Каждый раз нужно мониторить все идеи. Самое время “перелопатить” известные техники приоритизации и найти свое решение.
Находим решение
Мы в Hygger.io предлагаем системное решение этой проблемы выбора. Решение состоит из трех основных блоков:
Структурирование бэклога
Как правило, Backlog — это обычный список. В Hygger бэклог — это двухмерная Kanban доска. Более того, пользователя предлагаются Labels (тэги) и Swimlanes. Этого более чем достаточно, чтобы структурировать ваш бэклог любого размера.
Например, колонками на этой Kanban доске могут быть этапы работы над идеями:
Вместо процесса вы можете сделать в колонках релизы, чтобы распределить идеи. Кстати, Hygger умеет считать Capacity для колонок — чтобы вы могли равномерно распределять задачи по релизам.
С помощью Swimlanes вы можете разделить идеи. Например, так:
Лейблы можно использовать для чего угодно, например, для того, чтобы отметить идеи конкретных клиентов. Или идеи конкретных сотрудников. Или отметить особо важные идеи. Или отметить Сandies — мелкие фичи, которые делают продукт “вкуснее” для пользователей. Эти Сandies усилий практически не требуют, на скорость работы не влияют. Но замечая их, пользователи чувствуют заботу о них и больше доверяют.
Идеи упорядочены по полочкам, теперь можно приступать к их оценке. Оценка поможет вам в будущем сделать правильный выбор.
Оценка идей по Value и Effort
Оценить все идеи удобно с помощью двух критериев: Value или Impact и Effort.
Говоря абстрактным языком, Value — этот вклад, который идея или фича может дать в ваш продукт. Для корректной оценки вам нужно сначала понять, что вы хотите улучшать с помощью этой фичи.
Допустим, что вы внедрили Pirate Metrics (AARRR), тогда ваши цели могут быть такими:
Процесс оценки идей по Value в компании такой:
Когда вы оценили все идеи, вы можете переходить к этапу выбора идей. Не обязательно делать это сразу после окончания оценки — иногда лучше взять паузу и дать идеям отлежаться. Вы можете получить новые данные, например, из внешней среды, которые могут повлиять на оценку Value или Efforts.
У нас в компании процесс пересмотра идей является постоянным и фоновым. Но мы это делаем на графике, а не на Kanban доске, потому что на графике самые важные идеи четко отделены от всякой ненужной мелочи. Вы можете пересматривать идеи от самых важных до ненужных, если вам позволяет время. Главное то, что важные идеи вы пересматриваете вначале, и на них у вас всегда найдется 5 минут.
Выбор идей с помощью визуального инструмента Backlog Priority Chart
Те идеи, которые вы оценили, вы можете увидеть на графике.
На графике есть две шкалы — Value и Efforts, а также 4 квадранта:
График удобен тем, что позволяет оценивать идеи друг относительно друга. Во время оценочной сессии идеи оцениваются, как правило, независимо друг от друга. Но когда мы начинаем сравнивать идеи, которые оценены одинаково, друг с другом, явно какая-то идея будет более полезной или менее трудозатратной. Исходя из этого, мы можем скорректировать оценки идеи, их Values или Efforts.
Итак, вы оценили идеи, отобрали с помощью графика самые полезные идеи, и теперь вы можете отправлять их в разработку — на Kanban доску или на Спринт-доску.
Заключение
Подводя итог, кратко выделим главное:
Что такое бэклог продукта: основы
Узнайте, как создать и вести бэклог продукта
Бэклог продукта — это один из инструментов agile-разработки, который представляет собой перечень требований к продукту и задач, расставленных по приоритету.
Разделы
Как вести бэклог продукта
За составление бэклога продукта отвечает product owner (владелец продукта). В его формировании может также принимать участие scrum-мастер и другие напрямую заинтересованные лица, например, вовлеченные стейкхолдеры. Список задач составляют на основании дорожной карты и требований к продукту. Product owner регулярно пересматривает и обновляет бэклог если это необходимо, чтобы команда разработчиков на его основании могла выполнять свою работу и продвигаться к поставленной цели.
Согласно методологии скрам требования из бэклога продукта служат основой для проработки задач в спринтах, которые представляют собой временные интервалы для выполнения работ. Перед каждым этапом разработки команда проводит встречу со scrum-мастером, чтобы обсудить план работ и сформировать бэклог спринта.
Для того, чтобы процесс был максимально прозрачным для всех участников команды, используют виртуальные или физические доски. Посмотрите пример ниже. По вертикали расположен бэклог и основные этапы разработки. Цифрами отображены задачи, требующие решения. Чтобы изменить статус какой-либо из них, необходимый стикер перемещают из одного столбца в другой. Количество этапов (вертикальных столбцов) зависит от продукта, над которым работает команда и специфики ее работы.
Похожие доски используют и в методологии канбан. Однако, в этом подходе работу над продуктом не разбивают на спринты, а создают только один бэклог. В scrum процесс разработки продукта делят на этапы, поэтому возникает путаница между такими понятиями как «бэклог продукта» и «бэклог спринта». В следующем разделе вы ознакомитесь с отличиями этих двух инструментов.
Чем бэклог продукта отличается от бэклога спринта
Главное отличие заключается в том, что бэклог продукта представляет собой полный перечень требований и задач для разработки того самого продукта. Это основа, которая ведет к достижению главной поставленной цели.
Бэклог спринта помогает визуализировать процесс работы на пути к достижению краткосрочных целей. Он представляет собой список задач, которые необходимо выполнить на конкретном этапе разработки, чтобы реализовать один из элементов продукта. Созданием бэклога спринта руководит скрам-команда, а не владелец продукта. Участники формируют перечень задач в начале каждого этапа работы.
В следующем разделе вы узнаете, что собой представляет бэклог продукта и как его создать.
Как создать бэклог продукта
Бэклог требует регулярного обновления, поскольку в процессе работы могут появиться новые конкуренты, измениться требования на рынке, цены и прочие факторы, влияющие на функционал создаваемого продукта. Для разработки бэклога продукта используют product roadmap, user stories и customer journey map. Давайте подробнее разберем, для чего необходим каждый из этих инструментов.
Следуйте пошаговому плану ниже, чтобы разработать бэклог продукта при помощи этих трех инструментов.
На скриншоте ниже вы видите, как может выглядеть бэклог продукта. В таблице указана приоритетность задач и их описание, объем и сложность работ по каждой из них в цифровом эквиваленте — story points.
Для постановки задач в своем бэклоге используйте методику SMART. Обязательно пропишите подробно элементы, которые необходимы для работы во время ближайших одного или двух спринтов. Задачи для последующих этапов скорее всего необходимо будет корректировать на основании полученных результатов и обратной связи. Главное, тщательно собирайте и анализируйте всю информацию, чтобы регулярно обновлять и актуализировать свой бэклог продукта.
Как использовать Agile и Scrum для управления проектами
Agile и Scrum для руководителя проекта — основы гибких методологий, инструкция по ведению бэклога и спринтам, контроль процессов и организация работы.
Для чего внедрять гибкие методологии
Есть два подхода к разработке крупных проектов. Классический, или каскадный — это механика, в которой заранее готовится громадное техническое задание, учитываются все мелочи, предсказываются риски и затраты. И только потом начинается разработка. В digital такой метод работает неэффективно — когда команда разрабатывает большой проект, невозможно спрогнозировать все риски и проблемы.
Неожиданности появляются не только из-за бизнес-процессов, здесь работает и человеческий фактор. Например, представители заказчика могут намеренно затягивать внедрение ПО, преследуя личные цели. Сбор требований на этапе аналитики тоже не дает стопроцентной точности — заказчики не расскажут вам все сразу. Плюс сейчас ПО требует мгновенной реакции на отзывы пользователей — подход с долгой тщательной подготовкой не работает.
Управление проектами в стиле Agile и Scrum — иной подход. В основе — итерации, небольшие задачи с минимумом функций. Можно разработать основные функции, запустить ПО и постепенно дополнять его.
Agile — это подход к разработке большого проекта. Философия, которая позволяет создавать продукт с постоянно меняющимися требованиями.
Начните с бэклога
Scrum — это метод управления проектами, он входит в философию Agile. Ключевое отличие от классической, водопадной схемы создания ПО заметно сразу — для начала разработки не нужно техническое задание.
Вместо проектного задания используется бэклог — список функций, требований к системе, желаний заказчика. В Scrum они сортируются по приоритету. Это живой документ, добавляйте в него новые задачи по ходу работы.
Лайфхак — обратите внимание на столбец Приоритет на примере. Используйте не привычный список 1, 2, 3, 4. Попробуйте четырехзначные цифры — так вы сможете просто добавить строку между ними и выставить подходящий приоритет. Например, между 1 000 и 2 000 напишите 1 050.
Не нужно прорабатывать и продумывать полностью все функции сразу. Все «хотелки» и то, что появляется в процессе, добавляются в бэклог. Решайте, что делать сразу, а что стоит отложить на следующую версию.
Внедряйте спринты
Scrum создавался в первую очередь для гибкости и ускорения разработки. Для этого появилась механика спринтов — весь процесс делится на отрезки, обычно от одной до четырех недель.
Как это работает? Команда забирает из бэклога часть задач. Каждая разбивается на максимально мелкие тикеты. Теперь нужно оценить время на задачу, и вот здесь проявляется особенность Scrum.
Дело в том, что люди плохо считают процессы в абсолютных величинах. Сложно сказать, сколько часов что займет. Поэтому в Scrum используется относительная оценка. За основу берется простая функция, которую все оценивают одинаково — например, понятно, что ее сделают за час. Остальные тикеты вычисляются так — «это мы будем делать раз в пять дольше по времени».
Сделайте список версий продукта — от ПО с минимумом функций до полностью реализованного. Укажите к каждой версии прогноз по сроку выполнения.
Ключевая идея — до тех пор, пока команда не забрала задачи на спринт, их можно бесконечно видоизменять в бэклоге. В разработку уходит согласованная часть. Каждый спринт — это небольшой релиз, в конце которого команда показывает работающую функцию ПО.
Распределите роли в команде
В идеальном мире на ключевые роли в scrum-команде назначаются люди, выращенные на проекте. Такой человек будет знать процессы изнутри, лучше ориентироваться в оценках и понятнее ставить задачи.
Cвязующее звено между командой разработки и пользователями. Этот человек собирает общую концепцию продукта из мнений заказчиков и других заинтересованных в выпуске ПО людей. Он формирует задачи и расставляет приоритеты.
Член команды разработки, отвечающий за выполнение ежедневных процедур и за соблюдение интересов команды. Этот человек фиксирует дедлайны и начало спринта, добавляет оценки, отчитывается перед заинтересованными лицами об этапах проекта. Растите scrum-мастера внутри команды.
Люди, которые непосредственно создают и тестируют код.
К разработчикам есть несколько требований:
У такого принципа формирования команды есть минус — сложно заменить неожиданно выпавшего человека. Но скорость разработки на практике все равно выше, чем у других подходов.
Контролируйте процессы
Диаграмма сгорания — это наглядная демонстрация того, как команда «переваривает» все задачи проекта. Красная линия — план. Синяя — то, что делает команда. Диаграмма обновляется каждый день. Вы сразу видите, когда есть отклонения от плана: можно спокойно «крутить гайки» или менять приоритеты в бэклоге.
Контролируйте работу команды с помощью двух scrum-показателей:
Организуйте работу команды
В Scrum от сотрудников требуется минимальная отчетность. Каждый день человек должен ответить на три вопроса:
Задача руководителя — выяснить и устранить трудности, которые мешают разработчику добиться прогнозируемого результата. Для сотрудников это три-пять минут — ответили на вопросы, поставили оценки, разбежались работать дальше. Никаких решений или дискуссий.
В конце каждого спринта проводится ретроспектива. Команда встречается, озвучивает мнение, что в отрезке было хорошо, что плохо. Спросите у сотрудников идеи — что поможет им работать быстрее и эффективнее, что исправит проблемы. Запишите их в отдельный план — забирайте туда только те идеи, которые возможно сделать за следующий спринт.
Все идеи должны быть измеримы — например, «Ребята, давайте добавим серверов». Предложение просто работать лучше — не идея.
На следующей ретроспективе обсудите идеи из плана, отсортируйте их по категориям «плохо» и «хорошо». Повторите процесс — получается ретроспектива на ретроспективу.
Формируйте организацию процесса постепенно. Разбивайте день — например, шесть часов люди работают по спринтам, два часа остаются на срочные и случайные моменты. Если все пойдет без неожиданностей, ничего страшного, продолжайте спринт, сделайте больше тикетов.
Первый спринт команда всегда «факапит», потому что слишком оптимистично смотрит на дедлайны и задачи. Второй — берет очень мало задач и делает больше. Третий — снова плохая оценка, но уже чуточку лучше. Потом все выравнивается. Это рабочий процесс.
Демонстрируйте проект
Не затягивайте с первой версией продукта. Демонстрацию лучше проводить после каждого спринта — пусть даже релиз не пойдет к пользователям. Не копите внутри команды много функций — покажите их заинтересованным лицам и получите обратную связь. После — сразу измените бэклог.
В этом основное преимущество Scrum — гибко менять список задач во время разработки, не делать лишнего и не получать тысячи правок после завершения проекта, как в каскадной методологии разработки.
Изучите инструменты для контроля
Работать по системе можно даже на бумаге. Отлично подходит и таблица в Google Docs. Создайте свою рабочую область вручную или попробуйте специальные сервисы:
Чек-лист — как начать использовать Agile и Scrum на проекте
Теперь вы знаете основы Agile и Scrum и можете начать внедрять их в реальные проекты. Но для эффективной работы с командой этого мало — нужно уметь делать это осмысленно, знать тонкости методологий и не теряться в сложных моментах. Всему этому учат на курсе Skillbox. Одновременно с обучением сможете использовать полученные навыки в работе.
Делает из вебинаров статьи, пишет про все и даже немного больше.