Дорожная карта (Product Roadmap) — это полный стратегический план, включающий все этапы взаимодействия команды с проектом. В идеале в нем должны быть отражены конкретные сроки по проекту. Технические подробности работы могут здесь не расписываться, но обязательно должно присутствовать общее видение продукта, а также цели и миссия. Наиболее важные этапы прописываются в самом начале, чтобы и команда, и клиент могли иметь четкое представление о работе. Структура проекта может быть разбита на несколько ключевых составляющих — пользовательских историй. Заказчик со своей стороны может заниматься упорядочиванием этих историй, управляя деятельностью команды.
Продакт-менеджер или Scrum-master (или руководитель разработки) вместе решают, какие пункты из бэклога войдут в следующий спринт. Различают бэклог продукта (продакт-оунер) и бэклог спринта (это временной промежуток от 7 до 30 дней). Во втором случае команда разработчиков забирает из бэклога часть задач, которые согласованы и должны быть выполнены за определённое время, и приступает к их выполнению. А бэклог продукта представляет собой полный перечень общих задач разработки, часто не столь детально конкретизированных. Бэклог продукта – это список задач, требований, изменений и пожеланий, которые необходимо выполнить для разработки. Этот список обычно создается и управляется менеджером или владельцем, и он служит основой для планирования, приоритизации и управления работой разработчиков и команды.
Каждому присваивается оценка сложности и времени, необходимого для ее выполнения. Это помогает команде понимать, сколько времени потребуется на разработку. Это помогает команде понимать, что ожидает их в будущем и какие ресурсы им потребуются. Составляется для нескольких, объединенных между собой, спринтов, которые, при необходимости, могут разделяться на отдельные составные части. Каждое его обновление сопровождается пользовательской историей, на основании которой у заказчика, пользователей и исполнителей формируется обратная связь. Это упрощает и совершенствует работу над проектом, особенно, если он продолжается длительное время.
В большинстве случаев для качественной работы над проектами минималистичного бэклога недостаточно. В этом случае бэклог будет состоять не только из списка задач и их приоритетов, но и будет содержать подробное описание каждого задания. Бэклог помогает эффективно управлять процессами по проекту и контролировать команду.
Специализируется на дизайне интерфейсов промышленных устройств. Исследует актуальные практики разработки и организации процессов основные термины в Scrum создания интерактивных систем (UX/UI). На больших проектах часто бэклог разрабатывают как Customer Journey Map.
Релиз также может делиться на части и разбираться в отдельные спринты. Каждое обновление бэклога содержит свежую историю, на основе которой заказчик или пользователи могут давать свою обратную связь. Чем дольше идет работа над проектом, тем ценнее сбор такой информации, потому что полноценное развитие проекта без обратной связи невозможно. Заказчик играет ключевую роль в формировании этапов работы, но мнение команды также должно учитываться. Команда исходит из внутренних ресурсов, задействованных в реализации.
Успешность бэклога зависит от вклада и обратной связи, предоставленной клиентами, дизайнерами и командой разработчиков. Совместными усилиями они должны добиться оптимальной рабочей нагрузки между всеми участниками и обеспечить поставку продукта. Чтобы бэклога продукта оставался актуальным, к нему нужно регулярно возвращаться. По мере разработки и обновления ПО некоторые задачи потеряют значимость, зато образуются новые. Отслеживание рассмотренного компонента – это ускорение релиза с минимальными затратами на совершенствование продукции в будущем. Оценка работы дается командой во время формирования спринта.
Единого формата, регулирующего создание и ведение бэклога, не существует. Он может быть представлен в виде гугл-таблицы, специализированной программы или даже блокнота и магнитной доски в офисе. У каждого из форматов есть свои преимущества и недостатки. Например, общие облачные документы позволяют отслеживать правки в реальном времени и обсуждать корректировки.
Главное, тщательно собирайте и анализируйте всю информацию, чтобы регулярно обновлять и актуализировать свой бэклог продукта. В моменте, когда вы будете решать какие элементы бэклога перейдут в следующий спринт, эти факторы будут иметь решающее значение. Поэтому это важно – иногда у вас есть задача со средним или низким приоритетом, https://deveducation.com/ которая не связана с риском, не требует особых затрат и очень проста в реализации. В таком случае можно подумать о включении этого пункта в спринт, потому что это будет простой, но приятной доработкой к следующему релизу. Хотя расстановкой приоритетов занимается владелец продукта, в процесс вовлечены и другие стороны.
Это позволяет быстро адаптироваться к изменяющимся условиям и потребностям рынка. Менеджер и команда могут определить, что нужно для достижения целей. Это позволяет лучше распределить ресурсы и сосредоточить усилия на наиболее значимых задачах.
В следующем разделе вы ознакомитесь с отличиями этих двух инструментов. Согласно методологии скрам требования из бэклога продукта служат основой для проработки задач в спринтах, которые представляют собой временные интервалы для выполнения работ. Перед каждым этапом разработки команда проводит встречу со scrum-мастером, чтобы обсудить план работ и сформировать бэклог спринта. В самом начале статьи я уже упоминал, что в Agile много планирования, просто речь не о предварительном планировании в начале проекта, как в классическом предиктивном подходе. В начале каждого спринта Владелец продукта с командой определяют цель на 1-4 недели (в зависимости от продолжительности спринта). После чего на Планировании спринта команда детально планирует свою работу на спринт.