fbpx

Бэклог Продукта – Объяснение

Бэклог Продукта

 

Что такое Бэклог Продукта?
Если вы делаете свои первые шаги в Agile-среде, то это один из базовых вопросов на которые необходимо обратить внимание. В этой статье и сопровождающем видеоматериале мы рассмотрим, что такое Бэклог Продукта или другими словами “Журнал невыполненных работ по продукту” в контексте четырех основных вопроса:

  1. Что такое Бэклог Продукта?
  2. Зачем нужен Бэклог Продукта?
  3. Кто управляет Бэклогом Продукта?
  4. Как наполняется Бэклог Продукта?

Итак, начнем…

1️⃣ Что такое Бэклог Продукта?
Бэклог Продукта это артефакт, получивший свое происхождение в Agile Scrum. Однако в наши дни этот артефакт нашел применение во многих областях применения выходя далеко за рамки только лишь гибкого подхода. Простыми словами, Бэклог Продукта можно сравнить с коробкой или контейнером, в котором содержится все, что известно о продукте, в порядке приоритета. Это “все” включает в себя пользовательские истории, технические задачи, баги / дефекты, проблемы, гипотезы требующие исследования и т. д. Ключевое слово здесь – “все”!

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

2️⃣ Зачем нужен Бэклог Продукта?
Журнал невыполненных работ по продукту необходим, чтобы продемонстрировать то, как будет развиваться продукт. Элементы журнала представляют собой по сути элементы поставки аналогичные тем, что используются в проектных планах тогда как приоритизация отвечает на вопрос когда предположительно тот или иной элемент будет взят в работу и вероятно поставлен.

По сути Бэклог Продукта выполняет роль плана в гибкой среде разработки.

3️⃣ Кто управляет Бэклогом Продукта?
Владелец Продукта управляет Бэклогом Продукта и отвечает, в том числе и за определение приоритетов элементов бэклога. Хотя Владелец Продукта может позволить членам команды или другим заинтересованным сторонам вносить изменения в Бэклог Продукта, необходимо убедиться, что существую понятные и прозрачные правила которые регламентируют подобною деятельность со стороны других лиц, и что эти правила предусматривают информирования Владельца Продукта о наличии новых элементов в бэклоге.

4️⃣ Как наполняется Бэклог Продукта?
Бэклог наполняться из всевозможных источников, однако в качестве основных можно выделить три источника:
– Пользователи
– Бизнес
– Разработчики

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

Груминг бэклога Рефанмент бэклога

Поговорим о понятии известном как груминг или, другими словами, рефайнмент бэклога.

Итак, что же это за мероприятие Груминг бэклога / Рефайнмент бэклога?

Груминг или рефайнмент бэклога это скорее даже ряд мероприятий в гибкой среде (Agile Scrum) во время активного спринта направленные на подготовку команды заранее к следующему спринту. В русскоязычной среде это мероприятие также известно как проработка бэклога.

Зачем нужны эти встречи и какие проблемы они решают?
Эти встречи нужны как для владельца продукта там и для команды разработчиков.

Владелец продукта получая вопросы от команды разработчиков сможет лучше понять в каком направлении развивать продукт, который будет наилучшим образом удовлетворять потребности пользователей. Даже очень опытный владелец продукта (эксперт в нише, в которой создается продукт) как и любой человек может допускать ошибки и не учитывать целесообразность тех или иных вопросов. А на мероприятии груминг / рефайнмент или, другими словами, проработка бэклога, команда разработчиков в хорошем смысле “преподаст” владельцу продукта мозговой штурм, чтобы последний убедился в правильности своих решений и грамотно сформировал требования.

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

Итого:
Выигрывает вся команда. Владелец продукта лучше понимает что нужно делать, а команда разработчиков ощущает себя звеном в принятии бизнес решений и заранее может проработать технические вопросы гребущие анализа.

Мероприятия в Scrum

Краткий обзор мероприятий в Scrum.

В Scrum фреймворке есть всего четыре предписанных или другими словами обязательных мероприятия. Итак, давайте их рассмотрим.

1️⃣ Daily Scrum (Планерка)
Продолжительность: 15 минут;
Роли: DevTeam (Команда Разработчиков)
Цель: проверить прогресс (пульс) относительно достижения цели Спринта и выявить проблемы если таковы имеются.
Заметка: Это событие также известно как Standup или планерка. В частности, название Standup (стендап), происходит от слова “стоять”, поскольку зачастую во многих организациях принято стоять на этом мероприятии, чтобы оно проходило максимально оперативно.

2️⃣ Sprint Planning (Планирование спринта)
Продолжительность: 2 часа / неделю спринта;
Роли: Scrum Team (Скрам Команда)
Цель: это мероприятие предназначено для всей Скрам Команды, основной целью которого является постановка цели на предстоящий Спринт и планирование работ, необходимых для достижения поставленной цели.

3️⃣ Sprint Review (Обзор Спринта)
Продолжительность: 1 час / неделю спринта;
Роли: Scrum Team (Скрам Команда + гости),
Цель: это мероприятие предназначено для всей Скрам Команды, а также гостей (обычно представленных заинтересованными сторонами). Цель состоит в том, чтобы проанализировать последний спринт на предмет достижения цели (целей) и в целом проанализировать прогресс, чтобы определить следующим шаги.

4️⃣ Sprint Retrospective (Ретроспектива Cпринта)
Продолжительность: до 3 часов;
Роли: Scrum Team и только!
Цель: Внутреннее мероприятие Скрам Команды, гости не приветствуются. Команда обсуждает все аспекты своей жизни, включая процессы, отношения, окружающую среду и т. Д., Цель осознать свои сильный стороны и понять, что “получается хорошо”, а с другой стороны выявить вопросы и проблемы, которые нужно обсудить и исправить/улучшить.

Четыре рассмотренных Scrum митинга или мероприятия это, тот минимум, который необходим для создания Скрам среды. Здесь не учитываются, митинги, которые могут носить спонтанный характер, а также мероприятия направленные на проработку бэклога продукта (груминг/рефайнмент сессии).

Хотите глубже познакомится с мероприятиями в Scrum да и в целом с подходом Scrum Agile?
Обратите внимание на курс Scrum за 60 минут, в котором мы подробнее рассмотрим все Скрам церемонии и в целом рассмотрим основы Скрам фреймворка. Курс будет полезен для все, кто хочет углубить свои знания в данном вопросе и подготовится к сертификации на роль Скрам Мастера.

× Shopping Cart

Your cart is empty.

Будьте первыми!

Эксклюзивный доступ к материалам и спец предложениям.