Рассказываем, что такое бэклог в Scrum, какие разновидности существуют, кто за что отвечает и как с ним работают.
Бэклог — это список всех требований к проекту: и желания пользователя, и строго необходимые вещи. Сразу нужно сказать, что бэклог — это не список спецификаций на листочках. Понятие шире.
Бэклог в Scrum может быть бэклогом продукта, релиза или спринта.
Бэклог продукта
Бэклог продукта, или главный бэклог, — это ядро проекта. Это функции, которые нужно реализовать, и ошибки, которые требуется устранить.
Элементы бэклога в Scrum называются PBI — Product Backlog Items.
Обычно в их основу берутся «user story» они же пользовательские истории. Это позволяет использовать человеческий язык и не ограничивать команду в выбранном решении. Еще помогают лучше представлять использование продукта.
Несколько пользовательских историй объединяются в Epic’и. С эпиками — группами историй — удобнее составлять бэклог.
Так определяется, что нужно реализовать и какими функциями наделить продукт, чтобы его было удобно использовать:
Как превратить работу на себя в БИЗНЕС. Простая инструкция
Я, как пользователь приложения, хочу получить аккаунт с последними методами защиты.
Я, как посетитель сайта, хочу удобный поиск на сайте, чтобы быстро находить нужный товар.
Я, как оператор техподдержки, хочу легко находить заявки пользователей.
Бэклог продукта — единственный источник работ для команды разработки. Все, что находится в бэклоге, достаточно для запуска проекта. Он создается до начала первого спринта , на стадии планирования работы, но не раз и навсегда:
- если добавленный элемент не способствует достижению цели, его нужно удалить;
- если появляется новая функция, которая сделает проект лучше/конкурентнее/безопаснее и т. д., ее нужно добавить;
- элементы внутри бэклога могут переставляться местами: менять приоритет и прочее.
В активном проекте бэклог постоянно пополняется. Это происходит по ходу выпуска ПО, когда выясняются новые условия и требования.
Ответственность за заполнение бэклога несет владелец продукта, но с возможными идеями может помогать команда, бизнес, сторонние аналитики, конечные пользователи.
Что попадает в бэклог продукта
Может показаться, что это список дел. Но в Scrum это не так. В бэклог попадают такие задачи, функции, что отвечают требованиям:
- Ценность для пользователя
Каждая запись в бэклоге должна иметь какую-то ценность для клиента. Обязательно будут записи, которые влияют на это опосредованно. Они не добавят конкретные функции, но помогают в долгосрочной перспективе (решение проблем безопасности, устранение багов, описание требований и т. д.)
На самом деле, определить ценности и составить исчерпывающий список PBI сложно: практически для каждой программы предполагается несколько групп пользователей. У них свои представления, что нужно получить от ПО.
Банально, интернет-магазин. Это могут быть частные покупатели, оптовые клиенты, менеджеры по продажам и операторы, аналитики, владельцы бизнеса. И у каждого свой самый важный аспект: для покупателя хорошо бы увидеть подробное описание товара и много способов оплаты без аккаунта, а для аналитика ценность в статистике.
- Высокоуровневые задачи
В общий бэклог не попадает излишняя информация по каждому требованию. Элементы детализируются позже, уже в рамках спринта появляются задачи низкого уровня и рутина.
- Возможность оценить и проверить
Несмотря на некоторую абстрактность, нужно понимать, сколько усилий от разработчиков потребуется для ее реализации. После создания функционала его нужно проверить: это также должно отражаться в истории.
Я, как пользователь сайта, хочу загружать аватарку пользователя в аккаунт. Требуется место для хранения фото, интерфейс загрузки и т. д. На проверке — можно добавить изображение, и оно отобразится в аккаунте.
Удобнее для разработки, когда PBI автономны, минимально зависят друг от друга. От взаимосвязи не избавиться, но она должна быть горизонтальной: предыдущая история может служить отправной точкой для следующей. Когда зависимостей не избежать, их нужно представлять и строить работу с этим пониманием, чтобы не было задержек всего процесса.
Расстановка приоритетов и оценка пользовательских историй
В зависимости от стадии развития проекта по-разному детализируются задачи.
Все требования к проекту отбираются и фиксируются, но детально продумываются те, что быстрее отправятся в работу. Если каждый эпик или историю разобрать далеко наперед, это быстро потеряет актуальность.
Чтобы присвоить приоритет истории, нужно соотношение минимум двух показателей: насколько она важна для бизнеса и сколько усилий стоит ее разработка.
Первый показатель определяет владелец продукта, а оценку работы дает команда уже на этапе планирования спринта. Например, для бизнеса задача важна на 8 очков, а по сложности работы это 5 story point (это очки сложности работы, которые вычисляют в сравнении с другими задачами). На самом деле, система оценок намного сложнее и часто остается спорным местом, этой теме мы посветим отдельную статью.
Так в спринт отбираются самые приоритетные задачи и учитывается общая нагрузка. В Scrum это происходит на груминге, или разборе бэклога, — мероприятии, которое специально выделено на оценку задач и их отбор на следующий цикл.
Источник: dzen.ru
Из рутины в приятный процесс: что такое бэклог продукта и как им управлять?
Менеджеры продукта и его собственники не могут не уделять серьезного внимания продуктовому бэклогу. Не только для облегчения планирования релизов и итераций, но и для оптимизации всего жизненного цикла продукта, над которым намерена работать команда.
Бэклог продукта (product backlog) — это упорядоченный набор элементов, очередь задач, перечень всех функций, которые заинтересованные люди хотят получить от продукта. Этот список содержит краткие описания всех желаемых возможностей продукта.
Product manager или product owner представляют бэклог команде и управляют им, описывает его главные элементы во время митинга по планированию спринта. Описание бэклога следует производить на простом и доступном языке, без технических спецификаций, чтобы оно было понятно каждому в команде. Любые изменения и требования по продукту должны быть своевременно отражены в этой очереди задач.
Бэклог продукта vs бэклог спринта
Эти два компонента Scrum несут разный смысл, но их часто путают.
Бэклог спринта — это список определенных задач по воплощению в жизнь выбранных элементов бэклога продукта. Это список для оптимизации, которой команда займется в ближайший спринт, а также описание, каким образом они эту оптимизацию будут реализовывать.
Оба бэклога можно представить в обычной таблице Excel, однако сегодня для этих целей опытные менеджеры и собственники продуктов пользуются специальными инструментами для управления продуктом, позволяющими грамотно визуализировать состояние дел.
Бэклог продукта составляет product owner, а за бэклог спринта отвечает команда разработчиков. Еще одним важным отличием является время создания бэклога: Product backlog создается на самом первом планировании спринта, а Sprint backlog должен создаваться командой на каждом планировании нового спринта. Таким образом, первый бэклог живет на протяжении всей разработки продукта, а Sprint backlog — на протяжении 1-4 недель, то есть, в течение одного спринта.
В чем смысл бэклога продукта?
Работа над Agile-проектами не предполагает долгого документирования всех требования. Обычно product owner и другие члены команды начинают работу над проектом, отмечая все, что им нужно, для приоритизации бэклога. Уже такого бэклога достаточно для первого спринта. Затем его можно растить и менять.
Обычный бэклог продукта включает следующие пункты:
- Функции продукта (например, формы пользовательских историй — описания желаемой функциональности)
- Разные баги
- Получение новых знаний (например, обновление рабочих мест)
- Технические работы (например, любые полезные исследования)
Элементы бэклога — это «пользовательские истории» или user stories. Такие элементы упорядочены в зависимости от их бизнес «веса». Чем выше в бэклоге конкретный элемент, тем скорее разработчики будут работать над ним. Верхние позиции будут более подробно описанными и четкими по сравнению с нижними элементами. Все они должны быть понятны для нетехнических членов команды и заинтересованных сторон.
Каждый элемент в product backlog имеет свою оценку, которую делают разработчики. Система оценивания используются для определения количества элементов, которые будут выбраны для определенного спринта.
Обычно команда добавляет нужные детали и оценки в элементы бэклога во время специального проекта, который называется backlog grooming или refinement.
Для чего нужен backlog refinement?
Backlog refinement (улучшение, оптимизация, «чистка») — это действие или мероприятие, во время которого команда добавляет детали, оценки и порядок в элементы продукта. Процесс не должен охватывать более 10% рабочего времени команды разработчиков.
Этот постоянный процесс означает сотрудничество собственника продукта и разработчиков, когда ими рассматриваются и пересматриваются все элементы продукта.
Чем бэклог продукта в Agile отличается от простого списка дел?
У бэклога продукта есть определенные свойства:
- Любая отметка в backlog продукта добавляет ценности для клиентов.
- Все записи в бэклоге продукта оцениваются.
- Все отметки получают свой приоритет и порядок.
- Уровень детализации зависит от позиции отметки в Scrum backlog.
- Бэклог продукта — это живой документ без каких-либо бездействий или задач низкого уровня приоритета.
Что делать, если бэклог неустанно растет?
Фокус на ключевых приоритетах — одна из ключевых задач менеджера продукта или product owner. Однако очень часто у них нет времени изучать и отслеживать все новые возможности конкурентов. Пользователи постоянно предлагают улучшения и дают советы, члены команды предлагают новые идеи, происходят обновления. Когда бэклог продукта увеличивается, становится сложно его контролировать. Как успевать отслеживать приоритеты, если идеи в бэклоге нарастают как снежный ком?
Решение можно найти в современных платформах для управления продуктами, таких как Hygger.io. Функционал платформы помогает справиться со следующими вопросами:
- Структурирование бэклога на основе Kanban-досок, лейблов и горизонтальных Swimlanes.
- Оценка идей (с помощью удобных критериев Value and Effort).
- Визуализация и приоритезация важных идей на основе диаграммы Backlog Priority Chart.
Структурирование бэклога
В бэклоге Hygger простой список идей представлен на двухмерной доске. Здесь вы найдете полезные ярлыки (Labels) и горизонтальные колонки (Swimlanes). Вы можете использовать столбцы на бэклог-панели, чтобы визуализировать рабочие этапы для идей:
- Collect Ideas — для сбора всех идей.
- Review Ideas — для изучения идей и прояснения непонятных моментов. Детально описывать идеи на старте не нужно, так как неизвестно, будет ли точно идея выбрана для разработки.
- Score Ideas — для оценивания идеи.
- Approval — для проверки идеи Scrum-мастером или менеджером проекта.
- Developing — для отправления идеи в разработку.
- Done — для реализованных идей. Это означает, что функция «залита» на продакшн.
Опция Labels может использоваться для обозначения идей от конкретных пользователей или от конкретных сотрудников.
Оценка идей
В Hygger вы можете оценить все свои идеи, используя 2 критерия: Value and Efforts. Сопоставление этих значений для каждой задачи помогает лучше определить приоритеты и выбрать наиболее важные из задач для ближайшей разработки.
- Value показывает, какую бизнес-ценность может принести ваш продукт или бизнес.
- Efforts измеряют ресурсы, необходимые для выполнения задачи.
Backlog Priority Chart
Все оцененные идеи могут быть показаны на графике Backlog Priority Chart. Этот график полезен для оценки идей относительно друг друга. Помимо шкал Value and Effort, здесь предлагаются 4 квадранта:
- Quick Wins для идей с действительно высокой ценностью и низкими усилиями.
- Big Bets для идей, имеющих большие ценность и усилия.
- Maybes для идей с низкими ценностью и усилиями.
- Time Sinks для идеи с низким преимуществом, но высокими ресурсными затратами.
Каков бы ни был разрабатываемый продукт, услуга или сервис, оптимизация бэклога — это неотъемлемая часть функционала в управлении. Профессиональный product owner может запросто перейти с бэклогом на «ты», в том числе, благодаря профессиональным инструментам для управления бэклогом, которые превращают его из рутины в приятный процесс.
- бэклог
- управление продуктом
- управление продуктами
- оптимизация
- задачи
- менеджмент продукта
- Блог компании Hygger
- Управление разработкой
- Управление проектами
- Управление продуктом
Источник: habr.com