Давайте представим, что есть пользовательская история, ваша команда разработчиков не знает как ее решать или она требует предварительной подготовки. Участникам команды будет назначена задача по добыче знаний, чтобы у них появилось понимание, как подойти к разработке этойпользовательской истории и всех аналогичных историй в будущем. Когда делаешь бэклог продукта в первый раз, то хочется заполнить его требованиями, которые команда знает лучше всего, и которые соответствуют концепции, целям и инициативам. Если применяются гибкие подходы, то у проекта тоже может быть Бэклог.
Владелец продукта на основе пожеланий клиентов формирует список задач, которые необходимо выполнить по ходу работы над проектом. Необходимо вносить в этот список только те цели, которые имеют ценность для проекта. Бэклог продукта — это перечень задач, которые необходимо выполнить в ходе работы над проектом, и список функций, которые хотят получить пользователи и заинтересованные лица.
Что Такое Бэклог И Зачем Его Вести
Работает на всех цифровых платформах, в том числе, в режиме оффлайн, без интернета. На ближайшей планерке важно вместе с командой превратить бэклог продукта в актуальный todo-список — спринт. Продакт-менеджер или Scrum-master (или руководитель разработки) вместе решают, какие пункты из бэклога войдут в следующий спринт.
Большие элементы Бэклога декомпозируются на более мелкие, иногда до атомарных конкретных задач для разработчика, тестировщика или дизайнера. Для того, чтобы процесс был максимально прозрачным для всех участников команды, используют виртуальные или физические доски. По вертикали расположен бэклог и основные этапы разработки.
Однако в бэклоге указываются более частные задачи, которые раскрывают, как именно должен идти рабочий процесс над целями, отмеченными в дорожной карте. Дорожная карта проекта — это визуализация стадий разработки проекта. С ее помощью владельцы продукта устанавливают сроки реализации.
Как Структурировать Расширяющийся Бэклог
Бэклог продукта — это перечень задач, расположенных в порядке важности, для команды разработчиков. Его составляют на основе дорожной карты продукта и требований в ней. Наиболее важные элементы расположены в начале бэклога, чтобы команда понимала, чем следует заняться в первую очередь. Скорость, с которой участники выполняют задачи бэклога, не зависит от желаний владельца продукта, и он не должен оказывать давление на команду. Напротив, разработчики самостоятельно выбирают задачи из бэклога продукта с учетом доступных ресурсов.
Сам по себе термин Agile действительно отражает способность изменять направление движения без потери скорости. Для каждой пользовательской истории в модуле User Story map можно создавать карточки — добавлять описание, присваивать метки, статусы и размер. А главное — привязывать к ним конкретные задачи на рабочих пространства. Техдолг — это задачи, отложенные в угоду скорости исполнения или из-за неправильного планирования.
За составление бэклога продукта отвечает product owner (владелец продукта). В его формировании может также принимать участие scrum-мастер и другие напрямую заинтересованные лица, например, вовлеченные стейкхолдеры. Список задач составляют на основании дорожной карты и требований к продукту. Product owner регулярно пересматривает и обновляет бэклог если это необходимо, чтобы команда разработчиков на его основании могла выполнять свою работу и продвигаться к поставленной цели.
Что Важно Учитывать При Груминге И Рефайменте Бэклога
Чем больше колонок в бэклоге, тем сложнее поддерживать его актуальность. Еще одна обязательная колонка, которая поможет при фильтрации, — статус. Она поможет сформировать список заданий на текущий спринт и для контроля общего прогресса.
Так называемый Agile-уход за бэклогом гарантирует, что он останется актуальным, подробным и будет соответствовать текущей стратегии проекта. Стоит учитывать, что бэклог работает таким образом только в том случае, если он грамотно составлен и постоянно обновляется. Бэклоги подталкивают к обсуждениям и решениям, которые благотворно влияют на состояние программы. Они помогают понять, что не каждая задача может быть главной.
Модернизация Бэклога
Количество и содержание требований в данном списке зависит от опыта команды и сложности поставленных перед ней задач. Они составляются к началу каждого спринта, чтобы команда ориентировалась, какие ей нужно сделать шаги на данном этапе. Коррективы в документ вносят исключительно участники команды проекта. Большая часть задач product backlog пример из наиболее важных элементов в вашем бэклоге будет представлена в виде пользовательских историй. Как мы уже говорили, пользовательские истории — это элементы разработки, которые описывают функциональность (features) продукта с позиции пользователя. А еще бэклог продукта — надежный источник информации для всей команды.
- Он не вдается в мелкие детали, но помогает понять, когда и что нужно делать.
- Неотъемлемой частью непрерывного совершенствования является регулярный груминг (анализ и упорядочивание) бэклога.
- В результате обсуждения того, какие работы важнее, все приходят к общему представлению о приоритетности задач.
- В этой статье мы разберем основные правила систематизации требований и порядок работы с договоренностями, а также то, почему нельзя допускать беспорядка в имеющихся данных.
- В этом контексте бэклог – ваш персональный библиотекарь, который отбирает наиболее важные и актуальные «книги» на текущий момент.
Бэклог проекта – это список, который в отличие от плана проекта задаёт только текущую последовательность выполнения элементов согласно приоритету. Путем изменения приоритетов Владелец продукта управляет созданием продукта. В продуктовой разработке Бэклог продукта — это некий аналог интерфейса взаимодействия с командой продукта. Конкретную фичу в Бэклог может поместить любой член команды или стейкхолдер, но назначить приоритет или убрать элемент из Бэклога может только Владелец продукта (Product Owner, PO). Наверху Бэклога должны находиться самые ценные и видимые элементы, они четко определены и приносят реальную ценность, как, например, разработка функционала для пользователей. В свою очередь, невидимые и не ценные элементы могут быть менее очевидными, например, к ним относятся исследования перед началом разработки или исправление незначительных ошибок.
Составные Части Бэклога
Кроме того, проработанные элементы бэклога гораздо проще оценивать и реализовывать. Ради простоты можно создать в папке Backlog набор плашек под названием Priority и присвоить ему значения Mo – High, S – Medium, Co – Low, W – None. В таком случае элементы без приоритета попадут в папку On Hold, а остальные будут претендентами на реализацию в спринте. Вы узнаете, как улучшить процесс разработки продуктов и попробуете основные инструменты на практике. Иногда с целью ускорения или руководствуясь другими причинами, команды решаются на снижение качества кода.
По сравнению с традиционным планом проекта, от которого нельзя отступать, такой способ более гибкий. Если появилась новая задача, ей назначают приоритет и добавляют в бэклог. Отдельно выделяют рефайнмент (refinement) — оптимизацию проекта. Эта процедура не должна занимать более 10% рабочего времени команды.
Разработка продукта невозможна без предварительного изучения информации. Эта задача не имеет отношения к пользователю, однако для полного понимания функций перед началом работы, необходимо проводить предварительные исследования и включать их в бэклог продукта. Team Lead также может давать рекомендации по техническим аспектам и архитектурным решениям, которые могут повлиять на приоритизацию задач. Заинтересованные стороны (Stakeholders) К заинтересованным сторонам относятся все лица и организации, которые имеют интерес или влияние на продукт. Это могут быть заказчики, конечные пользователи, бизнес-аналитики, эксперты предметной области и другие участники проекта.
Бэклог Продукта: Что Он Из Себя Представляет И Как Его Создать
Владелец продукта (Product Owner) отвечает за бэклог продукта. Это означает, что он контролирует, какие задачи и требования включаются в список и как они приоритизируются в соответствии с целями проекта. Бэклог спринта — это список задач для оптимизации продукта, над которой команда будет работать в ближайший спринт и описание этого рабочего процесса.
По ходу работы приоритеты могут меняться, именно поэтому владельцу продукта необходимо вовремя обновлять бэклог. На скриншоте ниже вы видите, как может выглядеть бэклог продукта. В таблице указана приоритетность задач и их описание, объем и сложность работ по каждой из них в цифровом эквиваленте — story factors. Для обеспечения непрерывного совершенствования процесса и своевременного выявления областей для улучшения необходимо регулярно оценивать эффективность управления бэклогом. Появляется из-за переноса задач ради ускорения работы или из-за ошибок в планировании. Например, это может быть написание дополнительного кода, который позволит ускорить работу продукта, хотя первоначально такой код был проигнорирован в угоду скорости выполнения задачи.
Чем дольше идет работа над проектом, тем ценнее сбор такой информации, потому что полноценное развитие проекта без обратной связи невозможно. Бэклог спринта — это заранее оговоренные моменты, которые попадают в обновления продукта после завершения спринта. Требования к ним зависят от содержательной части, а их количество — от опыта команды и сложности поставленных задач.
Баг появляется в бэклоге обычно после получения жалобы от пользователя или обнаружения его кем-то из команды. Один из основных принципов Agile – это непрерывное совершенствование продукта, поэтому бэклог никогда не бывает законченным. Существует миф, что в Agile нет планирования, а вместо плана проекта какой-то «бэклог задач». Ноги этого мифа растут из неверной интерпретации одной из ценностей Agile Manifesto – «Готовность к изменениям важнее следования первоначальному плану».