В данной статье будет рассказано о том, что собой на самом деле представляет backlog продукта. Предстоит разобраться в его особенностях, составе и нюансах формирования. Соответствующие сведения пригодятся как новичкам, так и опытным IT-специалистам, включая скрам-мастеров и project/product-менеджеров.
Определение
Бэклог продукта – это список требований, выдвинутых относительно проекта. Чем лучше он заполнен, тем эффективнее получится организовать работу всей команды.
Соответствующий компонент включает в себя и пожелания клиентов, и то, что непосредственно необходимо для формирования грамотного продукта. Не стоит относить бэклог к перечню спецификаций на листочках. Соответствующее понятие намного шире.
При использовании Scrum рассматриваемый компонент представлен тремя составляющими: бэклогом продукта, спринта или релиза. Каждый вариант будет изучен более подробно.
Product Backlog
Бэклог продукта – это главные backlog. Он представлен ядром проекта. Включает в себя:
- функции, которые требуется реализовать;
- ошибки, необходимые для дальнейшего устранения.
Элементы здесь носят название PBI или Product Backlog Items.
В основе заложены users story – информация, базирующаяся на основании пользовательских историй. Данный прием дает возможность использовать обычный человеческий язык, не ограничивая команду в выбранном ранее решении. А еще такой подход способствует более грамотному представлению о применении итогового контента.
Пользовательские истории будут объединяться в Epics. Это – группы «рассказов». Они помогают более быстро и качественно создавать бэклог продуктов.
Особенности
При работе с бэклогом соответствующего типа нужно помнить – он является единственным источником информации для всей команды. То, что написано в нем – достаточные сведения для успешного запуска проекта. Создание осуществляется до первого спринта. А именно – во время планирования предстоящих дел. В процессе реализации возможны корректировки.
Вот так выглядит перечень основных нюансов внесения изменений в бэклог проекта:
- Добавленный элемент не помогает добиться желаемого результата. Его необходимо удалить.
- Появилась новая функция или возможность, способная улучшить проект или сделать его безопаснее. Такой компонент добавляют в «план».
- Компоненты в пределах бэклогов можно переставлять местами. Пример – изменение приоритетов.
При активной разработке соответствующий «план действий» пополняется на постоянной основе. Процесс обеспечивается по ходу релиза ПО, когда начинают появляться новые требования и условия.
Задумываясь над тем, кто управляет бэклогом, нужно запомнить – это делает один человек. А именно – непосредственный владелец продукта. Ему могут помогать участники команды, а также аналитики, пользователи и даже текущий рынок, где планируется реализация контента.
Что включает в себя
Бэклог продукта в Scrum – это его «база», основа. Она обеспечивает успех реализации контента и будущих продаж, если составлена правильно. Включает в себя разнообразные элементы. Сначала кажется, что соответствующее ядро – это список дел. В Scrum данное утверждение не является верным. Сюда будут включены задачи и функции, отвечающие конкретным критериям:
- Ценность для клиентов (пользователей). Каждая запись бэклога продукта значима. Обязательно ядро проекта предусматривает пункты, которые будут влиять на это опосредованно. Они не добавляют новые функции, зато помогают в долгосрочных перспективах. Пример – решение вопросов, связанных с безопасностью, устранением багов, описание требований. Составить исчерпывающий список задач (элементов) проблематично – каждая программа предусматривает несколько пользовательских групп. У всех свои представления относительно того, что должно делать ПО.
- Задачи являются высокоуровневыми. Общий бэклог продукта не предусматривает лишних данных по выдвинутым требованиям. Детализация обеспечивается позже. Во время спринтов появляются задачи низкого уровня и рутинные действия.
- Возможность провести оценку и проверку. Несмотря на то, что ядро обладает некой абстрактностью, важно осознавать хотя бы примерные усилия для реализации продукта. После того, как создан функционал, он подлежит тестированию. Соответствующие операции обязательно отображаются в истории.
- Независимость. Каждый элемент бэклога должен быть автономным. Это упрощает разработку. Полную автономию обеспечить не получится, но зависимость должна быть горизонтального типа: предыдущие истории иногда выступают отправными точками для следующих.
Все это способствует грамотному управлению командой и процессом разработки. Соблюдение перечисленных требований является важным моментом, без которой добиться итоговых целей не представляется возможным.
Приоритеты и оценка пользовательских историй
Создание бэклога продукта предусматривает разную детализацию задач. Этот момент находится под управлением стадии развития проекта.
Все требования к ПО отбираются и фиксируются. Детализации подлежат те, что быстрее отправятся в работу. Каждый эпик или история не должны разбираться далеко наперед. Если так поступать, процесс утратит актуальность.
Для присваивания приоритета огромную роль играет понимание важности концепции для бизнеса. А еще – предстоящих усилий, которые может потребовать разработка.
Проектом управляет его владелец. Он же определяет важность задачи. Оценка работы дается командой во время формирования спринта. Пример – для бизнеса задача важна на 8 очков, по сложности – 5 point story (очки сложности работы, которые должны вычисляться наравне с другими задачами). Подобная система оценок – вопрос спорный, поэтому он рассматривается поверхностно.
В спринт продукции включены задачи, которые получили высший приоритет. Во внимание в управляемом проекте принимается общая нагрузка. Скрам предусматривает ее на груминге – разработке бэклога продукта. Так называют мероприятие, где обычно выделяется время на оценку задач, их отбор на последующие циклы.
Спринты
Из главного «бэк» в sprint бэклог попадают несколько требований. Их количество зависит от опыта команды и сложности имеющихся задач. Содержательная часть напрямую зависит от цели спринта.
Spint Backlog – это бэклог спринта (команды). Он представлен обещаниями группы разработчиков относительно того, что будет добавлено в очередном обновлении по окончании «летучки».
Здесь стоит учитывать следующее:
- список требований выглядит абстрактно;
- эпик включает в себя пользовательские истории;
- user’s stories разбиваются на отдельные, самостоятельные задачи.
Рассматривает бэклог команды, нужно понимать – в самом начале спринта есть детали (задачи), которые необходимо выполнить. Этим элементом продукта управляет только команда, если backlog ранее принят. Владелец и клиенты могут увидеть, над чем сейчас будет работать группа разработчиков.
О релизе
Рассматривая бэклог продукта, стоит обратить внимание на последнюю его составляющую – realize backlog. В процессе выполнения намеченного плана по производству ПО иногда несколько спринтов объединяются в релиз. Он обладает одно целью и бэклогом для выполнения. Разделяется на части путем внедрения отдельных спринтов.
Каждое обновление – это верхние этапы (истории) бэклога продукта. На основании соответствующих сведений заказчики и пользователи дают обратную связь. Данный прием способствует дополнению, совершенствованию проекта.
Формат ведения
Бэклог – только те задачи, что важны для команды и итоговых товаров (продуктов). Единого формата его ведения нет. Бэклог команды может быть представлен:
- электронными таблицами;
- обычной доской в офисе компании;
- специализированной программой.
Второй вариант наиболее распространен. Он позволяет визуализировать задачи и представить бэклог команды в удобной форме. Обладает одной версией. Подходит для стендапа. Способствует лаконичному фиксированию информации.
Часто бэклог проекта предусматривает две формы представления – в виде доски с вкладками и детализации в документах.
Как собрать
Рассматриваемый элемент выглядит как перечень важных для ПО сведений, а также обозначенных целей и задач. Чтобы собрать бэклог продукта, потребуется:
- Составить список функций. По возможности сразу задать приоритеты.
- Прописать пользовательские истории для каждого выдвинутого предложения. На этом этапе проводится анализ ценности.
- Расставить компоненты, прошедшие отбор, согласно приоритетам. Их нужно записать в backlog.
- Обсудить предстоящие работы с командой – кто как понял цели, функции и способы реализации. Здесь предстоит назначить ответственных лиц и определить сроки, отведенные на воплощение задумок в жизнь.
- По мере завершения задач проводить их обновления.
Чтобы бэклога продукта оставался актуальным, к нему нужно регулярно возвращаться. По мере разработки и обновления ПО некоторые задачи потеряют значимость, зато образуются новые. Отслеживание рассмотренного компонента – это ускорение релиза с минимальными затратами на совершенствование продукции в будущем.
Быстро вливание в тему
Что такое бэклог продукта, понятно. И как его формировать – тоже, в общих чертах. Чтобы customer journey map, user story и иные понятия, связанные с backlog, не пугали, рекомендуется пройти дистанционные компьютерные курсы. Пример – от образовательного центра OTUS.
Компания находится в Москве, но предоставляет услуги по всей России и не только. Здесь можно получить IT-профессию, обучиться программированию и разработке, системному администрированию, верстке и пр. Срок учебы – до 12 месяцев. Уровни – от «новичка» до «опытного специалиста». В конце будет выдан электронный сертификат, которым можно документально подтвердить приобретенные навыки и знания в выбранной области.
Хотите знать про Agile больше? Добро пожаловать на курс «Agile Project Manager» в Otus!
