Как пишется бэклог

Всё, что вы хотели знать, но боялись спросить про самый эффективный скрам-инструмент

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

Что такое бэклог

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

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

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

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

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

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

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

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

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

Развернутое описание задач и хотелок

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

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

Предварительная трудоемкость

Может измеряться в часах, но чаще — в условных единицах, Story Point-ах: за 1 балл принимается самая простая задача из списка, а остальные оцениваются относительно неё.

Тип элемента

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

Инициатор или хозяин задачи

Бэклог продукта — длительно развивающийся организм, который со временем только прирастает в объёме. Поэтому спустя 2−3 месяца довольно сложно бывает вспомнить, кто, когда и зачем предложил перекрасить кнопку в другой цвет, убрать из формы поле с описанием или прикрутить ещё один тип доставки. Такая колонка — как раз в помощь. Можно пойти ещё дальше и указывать дату добавления в бэклог и конкретного исполнителя задачи, но помните: чем больше колонок, тем сложнее содержать бэклог актуальным.

Статус

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

Обязательных полей — нет: всё зависит от проекта и процессов. Поэтому, если нужно добавить своих колонок — на здоровье. Лишь бы было удобно всегда держать их в актуальном состоянии.

Кто пишет бэклог

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

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

Какими бывают бэклоги

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

Бэклог как Customer Journey Map

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

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

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

А если он хочет искать товар на сайте, то был бы рад, если там будет:

Карту пользовательских историй для зрелого продукта имеет смысл раскладывать на отдельные пользовательские персоны, цели, работы (JTBD) или проблемы пользователей.

Например, с точки зрения владельца интернет-магазина в сценарии оформления заказа покупателем в бэклоге важны следующие элементы:

Или, например, сайт, где публикуются статьи — для разных ролей будут разные сценарии и разные задачи для реализации:

Работая с пользовательскими историями, есть соблазн расписать их до уровня технических деталей. Но тогда теряется контекст и происходит дублирование:

Хорошая пользовательская история должна приносить пользу конечному пользователю и затрагивать весь стек технологий (или такой его объём, чтобы функционал был рабочим). Истории, распотрошенные на технические детали, не представляют никакой ценности для пользователей: так, например, веб-интерфейс для них бесполезен, пока не соединен с базой данных.

Бэклог как воронка идей

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

Всё, что нужно — два поля:

Фактически это сочетание канбана с дорожной картой, которое может быть очень удобным: вместо двух артефактов у вас всего один.

Бэклог возможностей

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

Бэклог, основанный на типах (или классах) работ

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

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

Древовидный бэклог

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

Бэклог как карта влияния (Impact Mapping)

В дереве решений каждая ветка — элемент незавершенной работы, здесь же под каждой веткой — ответы на вопросы: почему → кто → что → как.

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

Круговой бэклог

Круговой бэклог помогает наглядно категоризировать задачи и при этом сохранить целостность общей картинки. А экспериментируя с размером фрагментов можно физически ограничивать work in progress. Фактически, это такой же гибрид канбана с бэклогом как бэклог в виде воронки — только вид сверху

Бэклог в виде воронки конверсии

Идеален для продуктов, где есть чёткая конверсия — например, в е-коммерс. Всё, что нужно — структурировать элементы согласно воронке конверсии. При таком формате бэклог объединяет количественные данные об отказах или потенциальных барьерах в воронке с потенциальными возможностями их улучшения. В таком виде бэклог сам по себе определяет приоритеты задач: на каком этапе воронки больше всего проблем — там и надо работать.

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

Что такое груминг бэклога и зачем он нужен

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

Признаки, что бэклог пора пересмотреть

1. Количество добавленных элементов значительно превышает количество уже отработанных

Можете собрать статистику вручную, а можете использовать встроенные инструменты в Jira или Trello. Установите пороговые значения, когда количество задач станет для вас избыточным, и отслеживайте регулярно. Порог превышен — пора навести красоту.

Для этой цели, кстати, отлично подойдёт методика MoSCoW: сопоставляя объёмы работ из разных групп задач (must have, should have, could have, would like), легко понять, где список задач на данный момент избыточен.

2. Большой средний возраст задач

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

3. Элементы в работе спорят с долгосрочными целями

Если не иметь взгляда «сверху», то легко застрять на выполнении задач, которые важны, но не глобально — из-за этого общий прогресс по бэклогу будет мизерным. Чтобы такого избежать, стоит классифицировать уже отработанные элементы бэклога за последние 120 дней, и посмотреть, насколько равномерно распределялась нагрузка. Категории могут быть такими:

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

Что включает груминг

Деление сложных элементов на более мелкие

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

Удаление неактуальных элементов

Элементы бэклога могут устаревать по разным причинам:

Список — не исчерпывающий.

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

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

Чтобы навсегда распрощаться с элементом в бэклоге, задайте себе эти три вопроса:

Беспощадно избавляйтесь от всего, что:

Добавление новых элементов

Новые элементы могут добавляться в ответ на изменение бизнес-среды или рынка, появление нового видения продукта или новых комментариев от пользователей. А могут — потому что команда способна отработать больше элементов за спринт, чем предполагалось изначально. Если скорость работы — 20 элементов за спринт, то в бэклоге их должно быть хотя бы вдвое больше — чтобы было, из чего выбирать.

Переоценка приоритетов или корректировка оценок

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

Также груминг бэклога может включать:

Когда нужен груминг и сколько времени на него выделить

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

Если груминг вошёл в привычку, потребуется не больше 1,5 часов для 4-недельных спринтов (если ваши спринты короче — справитесь ещё быстрее). Но если груминг проводится впервые за несколько месяцев, готовьтесь выделить гораздо больше времени.

Если кратко

Ну вот, теперь вы настоящий бэклоговый гуру

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

Любой бэклог стоит начинать с составления дорожной карты, включающей базовые функции и требования. Дорожная карта (Product Roadmap) — это полный стратегический план, включающий все этапы взаимодействия команды с проектом. В идеале в нем должны быть отражены конкретные сроки по проекту. Технические подробности работы могут здесь не расписываться, но обязательно должно присутствовать общее видение продукта, а также цели и миссия. Наиболее важные этапы прописываются в самом начале, чтобы и команда, и клиент могли иметь четкое представление о работе. Структура проекта может быть разбита на несколько ключевых составляющих — пользовательских историй. Заказчик со своей стороны может заниматься упорядочиванием этих историй, управляя деятельностью команды.

Какими могут быть приоритеты работы с командой проекта?

1. Важность задачи для заказчика.
2. Потребность в регулярной обратной связи.
3. Сложность осуществления работы.
4. Зависимость одной части задач от другой.

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

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

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

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

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

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

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

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

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

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

Некорректным считается бэклог, в котором:

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

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

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

Решение можно найти на специализированных сервисах (например Hygger). С помощью их инструментов можно:

• структурировать бэклог на основе Kanban-досок;
• оценить идеи с помощью критериев Value и Effort;
• визуализировать и приоритизировать идеи.

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

Бэклог продукта (backlog product) — это список задач, которые необходимо выполнить во время работы над проектом. Также бэклогом называется список функций, которые в результате должны получить пользователи. Изначально термин backlog использовался в экономике и обозначал задолженность. Но сейчас его чаще применяют в разработке. В статье рассказываем, из чего состоит идеальный бэклог.

Бэклог: что это такое простыми словами

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

Чем качественнее он, тем глубже команда сможет погрузиться в проект.

В основе бэклога лежат два документа:

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

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

Бэклог помогает эффективно управлять процессами по проекту и контролировать команду. Участники самостоятельно берут в работу задачи из бэклога. Так обеспечивается непрерывная работа над продуктом.

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

Составляет бэклог руководитель проекта, иногда аналитик или разработчик, если речь идет о конкретном элементе. Актуальность и приоритетность задач контролирует владелец продукта. Бэклог эффективен в работе, только если его правильно составили и регулярно обновляют.

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

В минималистичном бэклоге должны быть указаны задачи и их приоритеты. У заданий с высокими приоритетами выше число (100, 300, 700, 1000). Большие зазоры между числами дают возможность вписать еще одну задачу между двумя уже запланированными.

Приоритетность оценивается по следующим условиям: ценность для проекта, стоимость, требуемые усилия и т.д.

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

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

Также в нем указывается предварительная трудоемкость. Ее можно измерять в часах или в условных единицах. В последнем случае за 1 балл берется самая простая задача.

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

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

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

Какими бывают бэклоги

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

На больших проектах часто бэклог разрабатывают как Customer Journey Map.

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

Например, для реализации сайта с текстовым контентом необходимо разработать разные сценарии пользования для разных ролей, у каждой из которых — свои цели. Например:

• Пользователи — хотят читать свежие новости. Им нужны будут функции поиска, добавления в закладки, комментирования.
• Журналисты — хотят публиковать свои статьи. Им нужен удобный редактор для верстки.
• Редактор — проверяет материалы перед публикацией. Ему необходим инструмент с режимом предпросмотра.
• Администратор — модерирует комментарии, удаляет статьи. Ему необходим специальный функционал на административной панели.

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

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

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

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

Универсального формата бэклога не существует, все зависит от конкретного проекта.

Структура идеального бэклога

Чем больше и сложнее проект, тем больше элементов в бэклоге. Но существуют универсальные элементы для каждого бэклога.

Функционал. В этом разделе описываются технические возможности для заказчика и для пользователя. Их расставляют по приоритетности.

Ошибки. Если задача была поставлена неправильно, могут появиться баги. Они бывают:

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

Технический долг. Может появиться, когда задачи переносят, чтобы ускорить работу, или из-за неправильного планирования.

Исследования. Перед началом работы над проектом необходимо обработать информацию о нем.

Как не должен выглядеть бэклог

Неправильным считается документ, в котором:

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

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

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

В процессе пересмотра бэклога:

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

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

Отдельно выделяют рефайнмент (refinement) — оптимизацию проекта. В рамках рефайнмента добавляют новые детали и оценки. Эта процедура не должна занимать более 10% рабочего времени команды. Иначе с бэклогом что-то не в порядке.

Чем бэклог отличается от обычного списка задач

У бэклога продукта есть свойства:

• любая отметка должна добавлять ценность для владельца продукта;
• все записи проходят оценку;
• все отметки имеют свои приоритет и порядок;
• постоянно меняется.

Итоги

• Бэклог — список задач, отсортированный по приоритетности, который необходимо выполнить в рамках проекта. Чем важнее задача, тем детальнее описание по ней должно быть.
• В минималистичном варианте в бэклоге два поля: задача и приоритет. Но в крупных проектах они в несколько раз объемнее.
• Составляет бэклог руководитель проекта, разработчик или аналитик. За приоритетность и актуальность элементов отвечает владелец продукта.
• Бэклог может быть в разных форматах. Самый распространенный — электронные таблицы.
• Периодически нужно проверять на актуальность. Эта процедура называется груминг.
• Груминг проводят в конце каждого спринта. В процессе проверяется актуальность и приоритетность задач.

Русский[править]

Морфологические и синтаксические свойства[править]

падеж	ед. ч.	мн. ч.
Им.	бэкло́г	бэкло́ги
Р.	бэкло́га	бэкло́гов
Д.	бэкло́гу	бэкло́гам
В.	бэкло́г	бэкло́ги
Тв.	бэкло́гом	бэкло́гами
Пр.	бэкло́ге	бэкло́гах

бэкло́г

Существительное, неодушевлённое, мужской род, 2-е склонение (тип склонения 3a по классификации А. А. Зализняка).

Корень: -бэклог-.

Произношение[править]

• МФА: [bɛˈkɫok] 

Семантические свойства[править]

Значение[править]

1. интернет. список дел, которые кто-либо планирует сделать или завершить ◆ У меня дикий бэклог непросмотренных фильмов. «Живой Журнал», 2005 г. ◆ За ссылку спасибо — пополню ей свой книжный бэклог. «Живой Журнал», 2009 г. ◆ C началом зимы активность разработчиков игр снижается примерно до нуля, поэтому все, что остается геймерам — разгребать бэклог и допроходить то, на что не хватило времени. «Каникулы на одном дыхании» // «lenta.ru», 2017 г. [НКРЯ]

Синонимы[править]

Антонимы[править]

Гиперонимы[править]

Гипонимы[править]

Родственные слова[править]

Ближайшее родство

Этимология[править]

От англ. backlog.

Фразеологизмы и устойчивые сочетания[править]

Перевод[править]

Список переводов

Библиография[править]

Для улучшения этой статьи желательно: Добавить синонимы в секцию «Семантические свойства» Добавить гиперонимы в секцию «Семантические свойства» Добавить хотя бы один перевод в секцию «Перевод»

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

Бэклог продукта (product backlog) – часть Скрама (SCRUM), то есть методологии управления проектами. Он представляет собой журнал пожеланий проекта по функциональности. Каждый пункт систематизируется по степени важности, от чего зависит порядок его реализации.

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

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

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

Читайте здесь как выбрать ноутбук для бизнеса

Что такое Бэклог продукта

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

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

Основная цель ведения backlog заключается в упрощении работы команды разработчиков. Система планирования обеспечивает:

• Четкое выставление заданий с указанием сроков и описаний.
• Рациональное распределение времени работы.
• Классификацию задач в порядке важности.
• Формирование требований к готовому продукту.
• Систематизацию всех пожеланий заказчика.
• Эффективную связь между разработчиками и владельцем продукта.

Как составлять бэклог

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

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

Сложности при подготовке и исполнении backlog

Не всегда работа идет четко по плану. Часто внешние обстоятельства заставляют продлевать сроки реализации.

Среди ошибок, которые можно допустить при формировании бэклога:

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

Структура бэклога

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

Читайте здесь про отличия Scrum от Канбан

Для его составления рекомендуется:

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

Что входит в бэклог продукта

Элементы backlog:

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

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

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

Среди критериев качества backlog:

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

Читайте здесь что такое Agile

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

Груминг бэклога – это регулярный пересмотр или уточнение проекта. С английского grooming переводится как причесывание. Он включает в себя анализ, систематизацию элементов, трансформацию приоритетов.

Рефаймент (refinement) предполагает оптимизацию, улучшение проекта. Означает действия, направленные на добавление новых деталей и оценок, упорядочение компонентов плана. Процедура занимает около 10% рабочего времени команды.

Вносить поправки в план могут следующие категории лиц:

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

Процедура grooming может включать в себя:

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

Backlog refinement означает «чистку» плана от лишних компонентов. Актуализация бэклога позволяет сократить занятость исполнителей, избавляя их от лишних задач. Упрощается планирование действий разработчиков, уходит неопределенность в требованиях клиента.

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

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

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

Предлагаем пример backlog

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

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

В данной статье будет рассказано о том, что собой на самом деле представляет backlog продукта. Предстоит разобраться в его особенностях, составе и нюансах формирования. Соответствующие сведения пригодятся как новичкам, так и опытным IT-специалистам, включая скрам-мастеров и project/product-менеджеров.

Определение

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

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

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

Product Backlog

Бэклог продукта – это главные backlog. Он представлен ядром проекта. Включает в себя:

• функции, которые требуется реализовать;
• ошибки, необходимые для дальнейшего устранения.

Элементы здесь носят название PBI или Product Backlog Items.

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

Пользовательские истории будут объединяться в Epics. Это – группы «рассказов». Они помогают более быстро и качественно создавать бэклог продуктов.

Особенности

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

Вот так выглядит перечень основных нюансов внесения изменений в бэклог проекта:

1. Добавленный элемент не помогает добиться желаемого результата. Его необходимо удалить.
2. Появилась новая функция или возможность, способная улучшить проект или сделать его безопаснее. Такой компонент добавляют в «план».
3. Компоненты в пределах бэклогов можно переставлять местами. Пример – изменение приоритетов.

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

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

Что включает в себя

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

1. Ценность для клиентов (пользователей). Каждая запись бэклога продукта значима. Обязательно ядро проекта предусматривает пункты, которые будут влиять на это опосредованно. Они не добавляют новые функции, зато помогают в долгосрочных перспективах. Пример – решение вопросов, связанных с безопасностью, устранением багов, описание требований. Составить исчерпывающий список задач (элементов) проблематично – каждая программа предусматривает несколько пользовательских групп. У всех свои представления относительно того, что должно делать ПО.
2. Задачи являются высокоуровневыми. Общий бэклог продукта не предусматривает лишних данных по выдвинутым требованиям. Детализация обеспечивается позже. Во время спринтов появляются задачи низкого уровня и рутинные действия.
3. Возможность провести оценку и проверку. Несмотря на то, что ядро обладает некой абстрактностью, важно осознавать хотя бы примерные усилия для реализации продукта. После того, как создан функционал, он подлежит тестированию. Соответствующие операции обязательно отображаются в истории.
4. Независимость. Каждый элемент бэклога должен быть автономным. Это упрощает разработку. Полную автономию обеспечить не получится, но зависимость должна быть горизонтального типа: предыдущие истории иногда выступают отправными точками для следующих.

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

Приоритеты и оценка пользовательских историй

Создание бэклога продукта предусматривает разную детализацию задач. Этот момент находится под управлением стадии развития проекта.

Все требования к ПО отбираются и фиксируются. Детализации подлежат те, что быстрее отправятся в работу. Каждый эпик или история не должны разбираться далеко наперед. Если так поступать, процесс утратит актуальность.

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

Проектом управляет его владелец. Он же определяет важность задачи. Оценка работы дается командой во время формирования спринта. Пример – для бизнеса задача важна на 8 очков, по сложности – 5 point story (очки сложности работы, которые должны вычисляться наравне с другими задачами). Подобная система оценок – вопрос спорный, поэтому он рассматривается поверхностно.

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

Спринты

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

Spint Backlog – это бэклог спринта (команды). Он представлен обещаниями группы разработчиков относительно того, что будет добавлено в очередном обновлении по окончании «летучки».

Здесь стоит учитывать следующее:

• список требований выглядит абстрактно;
• эпик включает в себя пользовательские истории;
• user’s stories разбиваются на отдельные, самостоятельные задачи.

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

О релизе

Рассматривая бэклог продукта, стоит обратить внимание на последнюю его составляющую – realize backlog. В процессе выполнения намеченного плана по производству ПО иногда несколько спринтов объединяются в релиз. Он обладает одно целью и бэклогом для выполнения. Разделяется на части путем внедрения отдельных спринтов.

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

Формат ведения

Бэклог – только те задачи, что важны для команды и итоговых товаров (продуктов). Единого формата его ведения нет. Бэклог команды может быть представлен:

• электронными таблицами;
• обычной доской в офисе компании;
• специализированной программой.

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

Часто бэклог проекта предусматривает две формы представления – в виде доски с вкладками и детализации в документах.

Как собрать

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

1. Составить список функций. По возможности сразу задать приоритеты.
2. Прописать пользовательские истории для каждого выдвинутого предложения. На этом этапе проводится анализ ценности.
3. Расставить компоненты, прошедшие отбор, согласно приоритетам. Их нужно записать в backlog.
4. Обсудить предстоящие работы с командой – кто как понял цели, функции и способы реализации. Здесь предстоит назначить ответственных лиц и определить сроки, отведенные на воплощение задумок в жизнь.
5. По мере завершения задач проводить их обновления.

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

Быстро вливание в тему

Что такое бэклог продукта, понятно. И как его формировать – тоже, в общих чертах. Чтобы customer journey map, user story и иные понятия, связанные с backlog, не пугали, рекомендуется пройти дистанционные компьютерные курсы. Пример – от образовательного центра OTUS.

Компания находится в Москве, но предоставляет услуги по всей России и не только. Здесь можно получить IT-профессию, обучиться программированию и разработке, системному администрированию, верстке и пр. Срок учебы – до 12 месяцев. Уровни – от «новичка» до «опытного специалиста». В конце будет выдан электронный сертификат, которым можно документально подтвердить приобретенные навыки и знания в выбранной области.

Хотите знать про Agile больше? Добро пожаловать на курс «Agile Project Manager» в Otus!