В этой статье мы разберем основные правила систематизации требований и порядок работы с договоренностями, а также то, почему нельзя допускать беспорядка в имеющихся данных. Занимается разработкой, ведением и обновлением https://deveducation.com/ бэклога продукта Project Manager. Он отвечает за то, чтобы бэклог продукта был актуальным и отражал значимые для продукта элементы, которые ведут к достижению бизнес–ценности, в том числе прибыли.
- Элементы для последующих спринтов можно описывать с меньшей степенью детализации — скорее всего, они потребуют доработки с учетом обратной связи.
- Чем успешнее становится продукт, тем быстрее он обрастает сложным функционалом, увеличивается число пользователей и обратная связь от них, растет объем технического долга.
- Управление бэклогом может сопровождаться серьезными трудностями даже у бывалых менеджеров, потому что иногда задачи нарастают как снежный ком.
- Бэклог продукта разрабатывает и ведет Project Manager (или Product Owner, если рассматривать фреймворк Scrum).
- Желательно, чтобы участники были заинтересованы в заданиях, над которыми будут работать.
Затем, узнав больше о продукте, пользователях и проанализировав обратную связь, бэклог можно будет актуализировать. Бэклог продукта позволяет четко следовать принципам Agile. Бэклог спринта — это заранее оговоренные моменты, которые попадают в обновления продукта после завершения спринта. Требования к ним зависят от содержательной части, а их количество — от опыта команды и сложности поставленных задач. К началу выполнения спринта нужно иметь список того, что предстоит сделать.
Инициатор или владелец задачи
Изменения в бэклог могут вносить только члены команды, а заказчик имеет возможность лишь наблюдать за изменениями. Заказчик играет ключевую роль в формировании этапов работы, но мнение команды также должно учитываться. Команда исходит из внутренних ресурсов, задействованных в реализации.
Бэклог продукта — краткий и понятный всем нужным лицам перечень функций и свойств продукта, которые должны быть разработаны. Именно бэклог продукта решает задачи, связанные с ориентировкой команды в том, что будет реализовано в продукте. Первый показатель будет определять хозяин продукта, а анализ общей работы оценивает команда на начальном этапе планирования спринта.
Структура бэклога
Важно внимательно собирать информацию из разных источников, оценивать её и на основе данных фильтровать задачи и брать их в работу. User Story (пользовательская история) — это упрощённый список требований клиента в виде истории, рассказанной на языке пользователя. По сути, это доходчивое описание, которому должны соответствовать новые фичи продукта, в противовес объёмной и сложной документации. В основе требований — удобство и ценность для пользователей. На скриншоте ниже вы видите, как может выглядеть бэклог продукта. В таблице указана приоритетность задач и их описание, объем и сложность работ по каждой из них в цифровом эквиваленте — story points.
За составление бэклога продукта отвечает product owner (владелец продукта). В его формировании может также принимать участие scrum-мастер и другие напрямую заинтересованные лица, например, вовлеченные стейкхолдеры. Список задач составляют на основании дорожной карты и требований к продукту. После того как бэклог создан и согласован с заказчиком, он корректируется по мере выполнения отдельных задач.
Отличия бэклога продукта от бэклога спринта
В минималистичном бэклоге должны быть указаны задачи и их приоритеты. У заданий с высокими приоритетами выше число (100, 300, 700, 1000). Большие зазоры между числами дают возможность вписать еще одну задачу между двумя уже запланированными. Составляет бэклог бэклог спринта руководитель проекта, иногда аналитик или разработчик, если речь идет о конкретном элементе. Актуальность и приоритетность задач контролирует владелец продукта. Бэклог эффективен в работе, только если его правильно составили и регулярно обновляют.
Рассмотрим дорожную карту для вымышленного продукта «Команды в космосе». Каждая задача должна быть конкретной, конечной и достижимой — например, исправление конкретной ошибки или внедрение определённой фичи. Именно поэтому в бэклоге собирают только те задачи, которые закрывают среднесрочные и краткосрочные цели проекта.
Значимость — важность функций или зависимость бизнес-показателей. Чтобы показать, как выглядит бэклог, я придумала разобрать планы Альбуса Дамблдора. Давай представим, что он многое знал наперёд и составил бэклог проекта по уничтожению Тёмного Лорда.
Не используйте несколько систем для отслеживания багов, требований и рабочих задач по разработке. У наших задач много зависимостей от бэка, они затрагивают больше 10 команд. Чтобы задача попала в их бэклог с правильным приоритетом, нужно комплексно оценить ее.