Бэклог продукта в SCRUM в 2022 году. Бэклог что это такое

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

Бэклог: ликбез

Бэклог — это то, что кажется нам таким же привычным в студии, как наш утренний кофе или ежедневные встречи. Но в последнее время мы с ужасом думаем: а вдруг это только для нас? ‘Я что-то слышал’, ‘ну, отставание просто…’., «Backlog. Что?» И для тех, кто не в курсе последних событий. А если вы знаете об отставаниях, освежите свои знания. Возможно, вы никогда в жизни не сталкивались с круговой порукой, или вы не знаете, когда стоит проводить плановый сеанс ухода (нет, сейчас мы не говорим о стрижке домашних животных).

Составьте список дневной работы (есть ли он у вас?). : у вас, вероятно, есть важные приоритетные задачи на день. Вероятно, у вас также есть месячный или годовой список задач, из которого вы можете «вытащить» свои ежедневные задачи. Если да, то можно сказать, что вы действительно поддерживаете отставание.

Без особых подробностей, бэклог — это список всех задач и желаний в порядке приоритета, которые вы планируете реализовать. Элемент списка является гибким. По ходу дела вы можете изменять, отклонять или добавлять новые. Именно поэтому плотная, утомительная и, как правило, техническая работа вызывает отставание.

Что о бэклоге говорит руководство по Скраму

Авторы Scrum Gade описывают бэклог следующим образом

Бэклог продукта представляет собой классифицированный список всего необходимого для продукта и является единственным источником требований для изменений продукта. Ни одно дело не бывает полным. Изначально он содержит самые основные и простые требования. По мере обновления и разработки продуктов, изменения рыночных условий и технологий, бэклог меняется и становится более обширным и всеобъемлющим.

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

В течение некоторого времени отставание ограничивалось группами роста, но этот простой и понятный инструмент полезен для любого сектора. От списка технической поддержки до списка задач, которые необходимо выполнить за определенный промежуток времени (привет, программирование!).. Истории продукта могут даже иметь отдельные бэклоги для проблем, даже если их много, когда важно управлять каждой из них и расставлять приоритеты.

Из чего состоит бэклог

Минимальный набор джентльмена: задачи и его приоритеты. Чем выше номер, тем выше приоритет, но большой промежуток между номерами (100, 200, 500, 1000, 10 000) дает запас для маневра. Между двумя другими задачами всегда можно уместить еще одну. Обычные факторы иерархии — это ценность для бизнеса, стоимость (или требуемые усилия) и сопутствующие риски (положительное влияние внедрения функции или отрицательное влияние ее неприменения).

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

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

Чем меньше отставание в работе, тем меньше сложности. Обратное тоже верно. Чем выше по списку, тем четче должна быть формулировка и тем выше подготовка к работе.

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

Работа может быть добавлена в бэклог по разным причинам. Иногда это идея или проблема, которую стоит попробовать, иногда — отзывы пользователей, иногда — технические моменты, требующие улучшения. Поэтому всегда рекомендуется сортировать по типу, например, используя условное форматирование.

Бэклог лидеров проектов или продуктов загрузки — это долгосрочный организм, развивающийся и увеличивающийся в объеме с течением времени. Поэтому трудно вспомнить через два-три месяца, когда и почему кто-то предложил перекрасить кнопку в другой цвет, или удалить поле описания из формы, или добавить другой тип доставки. Эта колонка может только помочь. Однако помните, что вы можете пойти дальше и определить дату добавления к отставанию и этой выполнимой задаче. Чем больше у вас столбцов, тем сложнее поддерживать актуальность Up -to -Date.

Опять же, эта колонка полезна для быстрой фильтрации, а также для выбора работы текущего спринта и отслеживания прогресса.

Бэклог крупных, постоянно развивающихся продуктов может быть очень объемным. Например, в SingularityApp уже более 500 линий, и мы не планируем останавливаться на достигнутом. Всегда много работы над интерфейсом и новыми функциями для различных платформ. Некоторые идеи и задачи добавляются в бэклог нами в ходе стратегического анализа и сессий. Некоторые из них добавляются по просьбе пользователей.

Мы пробовали создавать файлы в разных системах, но до сих пор мы создавали таблицы в простом формате в GoogleDoc. Причина проста. Столы работают очень быстро. Без лишних декоративных элементов в интерфейсе, нет вопросов, отнимающих время. Иерархии поиска, классификации, фильтры и математические типы — это то, что вам нужно. В этом бэклоге задачи имеют различные детали. Это могут быть небольшие конкретные задачи или огромные задачи. Для каждого из них определите тип, платформу и область, к которой относится задание. Используйте технику льда для иерархии.

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

• Items (запланированная работа). К items относят функции, требования, усовершенствования, данные по исправлению дефектов.
• User stories (пользовательские истории). Важный компонент стандартного бэклога, подразумевающий описание желаемых опций.

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

Часто дизайн детализируется в виде описаний и комментариев. Бэклог оценивается менеджерами, которые могут вносить изменения и дополнения.

Среди необъяснимых критериев качества:.

• Детализация. Приоритетные элементы имеют ясное описание и раньше попадают в работу.
• Анализ. Задания проходят оценку, после которой могут быть перенесены в другие категории или отменены. Владелец продукта проверяет работу команды, оценивает технические риски. Вносятся сведения о ценности запросов, учитываются бизнес риски. Предпринимаются операции для сокращения издержек.
• Актуальность. Бэклог непрерывно меняется и дополняется новыми пояснениями. Разделы можно создавать, удалять или изменять в зависимости от реальных обстоятельств. Допускается смена приоритетности задач, внедрение новых идей в связи с техническими неполадками, изменением рыночных условий и другими значимыми факторами.

Перечислите обязанности команды в порядке важности и сложности.

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

Лечение блогингом — это регулярное рассмотрение и улучшение проекта. На английский язык груминг переводится как парикмахерское искусство. Он включает в себя анализ, систематизацию элементов и трансформацию приоритетов.

Совершенство подразумевает оптимизацию и улучшение проекта. Он подразумевает действия, направленные на добавление новых деталей и оценок для рационализации элементов проекта. Этот процесс занимает примерно 10% времени команды.

Следующие категории людей могут изменять дизайн

• Участники команды разработчиков, которые создают программный продукт.
• Владелец продукта, играющий роль эксперта и органа контроля. Может задавать направление работы, менять значимость заданий.
• Скрам-мастер. Помогает повысить эффективность работы специалистов.
• Стейкхолдеры. Иные заинтересованные в проекте лица.

В обновлении плана участвуют исполнительные агентства и другие лица.

Процесс лечения может включать: a.

• Подробный анализ требований заказчика.
• Группировку желаемых опций софта по сложности, важности.
• Повторную оценку существующих и новых заданий.
• Добавление деталей и описаний.
• Упорядочивание элементов плана.
• Декомпозицию, то есть деление крупных заданий на этапы.
• Устранение несоответствий, нелогичных моментов в заданиях.

Улучшение бэклога означает «очистку» дизайна от ненужных элементов. Улучшение рабочего блога снижает нагрузку на исполнителей и сокращает ненужную работу. Упрощается планирование работы разработчиков и устраняется неопределенность в отношении требований заказчика.

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

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

Пример Бэклога продукта

Вот несколько ярких примеров

Спринты являются важным этапом разработки и делятся на более мелкие пронумерованные задачи. Они указывают на степень готовности и приоритетность задачи.

Пример нереализованного.

Второй пример описан на примере более конкретного списка дел для разработчиков. Варианты оцениваются с учетом их сложности и важности.

Дорожная карта и требования команды формируют основу бэклога требований к продукту. Дорожная карта инициативы разбита на несколько эпопей, каждая из которых имеет несколько требований и пользовательских историй. Посмотрите на дорожную карту замечательного продукта под названием TeamsinSpace.

Два столпа бэклога продукта

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

Веб-сайт «Команды в космосе» является первой инициативой в дорожной карте, поэтому его необходимо разбить на Эпохи (показанные на диаграмме зеленым, синим и бирюзовым цветом) и пользовательские истории для каждой Эпохи.

Владелец продукта составляет единый список этих пользовательских историй для команды разработчиков. Владелец продукта может организовать истории так, чтобы группа сначала выполнила «Эпопею» как единое целое (слева). Или же, возможно, важнее сначала забронировать билеты со скидкой. Это требует применения нескольких эпических историй (справа). Оба варианта показаны ниже.

Что может повлиять на расстановку приоритетов владельцем продукта?

• Важность для клиента
• Необходимость в обратной связи
• Относительная сложность реализации
• Тесная взаимосвязь между рабочими задачами (например, сделать «Б» будет проще, если сначала сделать «А»)

За расстановку приоритетов отвечает владелец продукта, но в процесс вовлекаются и другие заинтересованные стороны. Успех бэклога зависит от вклада и обратной связи, предоставляемых клиентом, дизайнерами и командой разработчиков. Сотрудникам необходимо обеспечить оптимальную нагрузку на всех участников и доставку продукта.

Правильное ведение бэклога

После создания бэклога важно регулярно корректировать его по мере выполнения программы. Владельцы продуктов должны просматривать бэклог перед каждым собранием по планированию итераций, чтобы улучшить ранжирование и внести изменения на основе результатов последней итерации. Регулярные обзоры бэклога в кругах гибких специалистов часто называют «уходом» или «поддержанием бэклога» (иногда используется термин «расширение бэклога»).

Когда бэклог достаточно велик, владельцам продуктов необходимо определить краткосрочные и долгосрочные группы внутри бэклога. Прежде чем этот режим будет возвращен, необходимо детально разобраться с краткосрочными задачами. Для этого необходимо создать комплексные пользовательские истории и обсудить все детали совместной работы с дизайнерами и разработчиками, чтобы оценить сложность роста. Долгосрочные задачи могут быть не до конца изучены, но они могут помочь иерархии, если команда роста даст общую оценку. Ключевое слово здесь — «грубый». Как только команда полностью осознает долгосрочные обязательства и начинает их выполнять, смета меняется.

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

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

Плохие примеры лучше не повторять

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

Бэклоги продукта и верность команды принципам agile

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

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

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

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

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

Как список необходимых требований (backlog) продукта поддерживает гибкость команды?

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

TWIIT: В бэклоге представлены аргументы и решения, которые поддерживают программное обеспечение в хорошем состоянии, но не все является приоритетным.

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

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

Это гарантирует, что вся информация о работе будет включена в общее обсуждение для каждой итерации. Затем члены команды могут координировать свои действия с владельцем продукта, имея полную информацию обо всем, что необходимо сделать, до начала итерации.

Владелец продукта определяет приоритеты рабочих данных через список требований (backlog), а команда разработчиков определяет скорость через список требований (backlog). Это может быть сложной позицией для новых владельцев продуктов, которые хотят «протолкнуть» проект в свою команду. Подробнее читайте в нашей статье об отложенных границах и прогрессе.