pbi что это scrum
Из рутины в приятный процесс: что такое бэклог продукта и как им управлять?
Менеджеры продукта и его собственники не могут не уделять серьезного внимания продуктовому бэклогу. Не только для облегчения планирования релизов и итераций, но и для оптимизации всего жизненного цикла продукта, над которым намерена работать команда.
Бэклог продукта (product backlog) — это упорядоченный набор элементов, очередь задач, перечень всех функций, которые заинтересованные люди хотят получить от продукта. Этот список содержит краткие описания всех желаемых возможностей продукта.
Product manager или product owner представляют бэклог команде и управляют им, описывает его главные элементы во время митинга по планированию спринта. Описание бэклога следует производить на простом и доступном языке, без технических спецификаций, чтобы оно было понятно каждому в команде. Любые изменения и требования по продукту должны быть своевременно отражены в этой очереди задач.
Бэклог продукта vs бэклог спринта
Эти два компонента Scrum несут разный смысл, но их часто путают.
Бэклог спринта — это список определенных задач по воплощению в жизнь выбранных элементов бэклога продукта. Это список для оптимизации, которой команда займется в ближайший спринт, а также описание, каким образом они эту оптимизацию будут реализовывать.
Оба бэклога можно представить в обычной таблице Excel, однако сегодня для этих целей опытные менеджеры и собственники продуктов пользуются специальными инструментами для управления продуктом, позволяющими грамотно визуализировать состояние дел.
Бэклог продукта составляет product owner, а за бэклог спринта отвечает команда разработчиков. Еще одним важным отличием является время создания бэклога: Product backlog создается на самом первом планировании спринта, а Sprint backlog должен создаваться командой на каждом планировании нового спринта. Таким образом, первый бэклог живет на протяжении всей разработки продукта, а Sprint backlog — на протяжении 1-4 недель, то есть, в течение одного спринта.
В чем смысл бэклога продукта?
Работа над Agile-проектами не предполагает долгого документирования всех требования. Обычно product owner и другие члены команды начинают работу над проектом, отмечая все, что им нужно, для приоритизации бэклога. Уже такого бэклога достаточно для первого спринта. Затем его можно растить и менять.
Обычный бэклог продукта включает следующие пункты:
Элементы бэклога — это «пользовательские истории» или user stories. Такие элементы упорядочены в зависимости от их бизнес «веса». Чем выше в бэклоге конкретный элемент, тем скорее разработчики будут работать над ним. Верхние позиции будут более подробно описанными и четкими по сравнению с нижними элементами. Все они должны быть понятны для нетехнических членов команды и заинтересованных сторон.
Каждый элемент в product backlog имеет свою оценку, которую делают разработчики. Система оценивания используются для определения количества элементов, которые будут выбраны для определенного спринта.
Обычно команда добавляет нужные детали и оценки в элементы бэклога во время специального проекта, который называется backlog grooming или refinement.
Для чего нужен backlog refinement?
Backlog refinement (улучшение, оптимизация, «чистка») — это действие или мероприятие, во время которого команда добавляет детали, оценки и порядок в элементы продукта. Процесс не должен охватывать более 10% рабочего времени команды разработчиков.
Этот постоянный процесс означает сотрудничество собственника продукта и разработчиков, когда ими рассматриваются и пересматриваются все элементы продукта.
Чем бэклог продукта в Agile отличается от простого списка дел?
У бэклога продукта есть определенные свойства:
Что делать, если бэклог неустанно растет?
Фокус на ключевых приоритетах — одна из ключевых задач менеджера продукта или product owner. Однако очень часто у них нет времени изучать и отслеживать все новые возможности конкурентов. Пользователи постоянно предлагают улучшения и дают советы, члены команды предлагают новые идеи, происходят обновления. Когда бэклог продукта увеличивается, становится сложно его контролировать. Как успевать отслеживать приоритеты, если идеи в бэклоге нарастают как снежный ком?
Решение можно найти в современных платформах для управления продуктами, таких как Hygger.io. Функционал платформы помогает справиться со следующими вопросами:
Структурирование бэклога
В бэклоге Hygger простой список идей представлен на двухмерной доске. Здесь вы найдете полезные ярлыки (Labels) и горизонтальные колонки (Swimlanes). Вы можете использовать столбцы на бэклог-панели, чтобы визуализировать рабочие этапы для идей:
Опция Labels может использоваться для обозначения идей от конкретных пользователей или от конкретных сотрудников.
Оценка идей
В Hygger вы можете оценить все свои идеи, используя 2 критерия: Value and Efforts. Сопоставление этих значений для каждой задачи помогает лучше определить приоритеты и выбрать наиболее важные из задач для ближайшей разработки.
Backlog Priority Chart
Все оцененные идеи могут быть показаны на графике Backlog Priority Chart. Этот график полезен для оценки идей относительно друг друга. Помимо шкал Value and Effort, здесь предлагаются 4 квадранта:
Каков бы ни был разрабатываемый продукт, услуга или сервис, оптимизация бэклога — это неотъемлемая часть функционала в управлении. Профессиональный product owner может запросто перейти с бэклогом на «ты», в том числе, благодаря профессиональным инструментам для управления бэклогом, которые превращают его из рутины в приятный процесс.
Что такое бэклог продукта: основы
Узнайте, как создать и вести бэклог продукта
Бэклог продукта — это один из инструментов agile-разработки, который представляет собой перечень требований к продукту и задач, расставленных по приоритету.
Содержание
Как вести бэклог продукта
За составление бэклога продукта отвечает product owner (владелец продукта). В его формировании может также принимать участие scrum-мастер и другие напрямую заинтересованные лица, например, вовлеченные стейкхолдеры. Список задач составляют на основании дорожной карты и требований к продукту. Product owner регулярно пересматривает и обновляет бэклог если это необходимо, чтобы команда разработчиков на его основании могла выполнять свою работу и продвигаться к поставленной цели.
Согласно методологии скрам требования из бэклога продукта служат основой для проработки задач в спринтах, которые представляют собой временные интервалы для выполнения работ. Перед каждым этапом разработки команда проводит встречу со scrum-мастером, чтобы обсудить план работ и сформировать бэклог спринта.
Для того, чтобы процесс был максимально прозрачным для всех участников команды, используют виртуальные или физические доски. Посмотрите пример ниже. По вертикали расположен бэклог и основные этапы разработки. Цифрами отображены задачи, требующие решения. Чтобы изменить статус какой-либо из них, необходимый стикер перемещают из одного столбца в другой. Количество этапов (вертикальных столбцов) зависит от продукта, над которым работает команда и специфики ее работы.
Похожие доски используют и в методологии канбан. Однако, в этом подходе работу над продуктом не разбивают на спринты, а создают только один бэклог. В scrum процесс разработки продукта делят на этапы, поэтому возникает путаница между такими понятиями как «бэклог продукта» и «бэклог спринта». В следующем разделе вы ознакомитесь с отличиями этих двух инструментов.
Чем бэклог продукта отличается от бэклога спринта
Главное отличие заключается в том, что бэклог продукта представляет собой полный перечень требований и задач для разработки того самого продукта. Это основа, которая ведет к достижению главной поставленной цели.
Бэклог спринта помогает визуализировать процесс работы на пути к достижению краткосрочных целей. Он представляет собой список задач, которые необходимо выполнить на конкретном этапе разработки, чтобы реализовать один из элементов продукта. Созданием бэклога спринта руководит скрам-команда, а не владелец продукта. Участники формируют перечень задач в начале каждого этапа работы.
В следующем разделе вы узнаете, что собой представляет бэклог продукта и как его создать.
Как создать бэклог продукта
Бэклог требует регулярного обновления, поскольку в процессе работы могут появиться новые конкуренты, измениться требования на рынке, цены и прочие факторы, влияющие на функционал создаваемого продукта. Для разработки бэклога продукта используют product roadmap, user stories и customer journey map. Давайте подробнее разберем, для чего необходим каждый из этих инструментов.
Следуйте пошаговому плану ниже, чтобы разработать бэклог продукта при помощи этих трех инструментов.
На скриншоте ниже вы видите, как может выглядеть бэклог продукта. В таблице указана приоритетность задач и их описание, объем и сложность работ по каждой из них в цифровом эквиваленте — story points.
Для постановки задач в своем бэклоге используйте методику SMART. Обязательно пропишите подробно элементы, которые необходимы для работы во время ближайших одного или двух спринтов. Задачи для последующих этапов скорее всего необходимо будет корректировать на основании полученных результатов и обратной связи. Главное, тщательно собирайте и анализируйте всю информацию, чтобы регулярно обновлять и актуализировать свой бэклог продукта.
SCRUM: Гибкое управление продуктовыми направлениями
Статья раскрывает тему гибкости управления продуктом в части доставки бизнес-ценности и мобильность в адаптации к изменяющимся внешним условиям. Чёткое понимание видения продукта помогает синхронизировать разработку продукта с бизнес-стратегией компании для достижения стратегических целей. Понимание ценности задаёт темп непрерывного развития продукта. Ценность продукта включает в себя улучшенную транспарентность для применения и развития ценностно ориентированного подхода для принятия решений. Ключевые постулаты предмета включают в себя непрерывное определение ценности, измерение актуальной доставленной ценности, валидация гипотез и анализ трендов.
В статье предложена система метрик для измерения и дальнейшего анализа атрибутов гибкого управления продуктовыми направлениями.
Прогнозирование и планирование релиза
Разработка программного обеспечения является процессом создания продукта и дальнейшего его вывода на рынок потребителей. Сам процесс разработки программного обеспечения живёт в эмпирическом мире, которому свойственно иметь большую неопределённость и хаос. С целью организации бережливого производства для среды с неопределённостью и хаосом, прогнозирование релиза сводится к следующим ключевым идеям:
Конечным результатом прогнозирования является приверженность команды к объёму работ, а не конечная абстрактная оценка по трудозатратам. Процесс организации разработки вокруг оценки трудозатрат внедряет избыточный объём работ, результаты которого либо не используются, либо не нужны клиенту.
Фокусом прогнозирования является добавочная ценность новых функций продукта. В том случае если фокусом является трудозатраты, то возникают сложности в обосновании целесообразности реализации новых функций продукта для клиента.
Клиент платит не за отдельно взятые функции продукта, клиент платит за ценность продукта. Производителем ценности является продуктовая команда, спонсируемая клиентом. Соответственно, при таком подходе отпадает необходимость проведения оценки трудозатрат, так как есть команда, которая гарантирует доставку инкремента с ценностью каждый релизный цикл. Данная идея будет более подробно рассмотрена в рамках ценностной модели обоснования трансформации, так как является системообразующей.
Наблюдение за наличием ответственного лица, который принимает решение о включении доработки в бэклог спринта.
ответственное лицо на уровне компании не выделяется — 0 баллов.
существуют несколько ответственных лиц за одно продуктовое направление — 1 балл.
есть единственное лицо на продуктовое направление, ответственность доставки ценности инкремента не осознаётся — 3 балла.
есть единственное лицо на продуктовое направление, ответственность доставки ценности инкремента осознаётся — 5 баллов.
Участники планирования содержания продукта
Наблюдение за присутствуем стейкхолдеров и ответственных лиц продуктовых направлений на планировании содержания продукта.
при планировании присутствуют только стейкхолдеры — 0 баллов.
при планировании присутствуют стейкхолдеры и часть ответственных лиц продуктовых направлений — 1 балл.
при планировании присутствуют стейкхолдеры и все ответственные лица продуктовых направлений — 3 балла.
при планировании присутствуют стейкхолдеры и все ответственные лица продуктовых направлений, а также смежные представители по интеграционным вопросам — 5 баллов.
Участники планирования содержания спринта
Наблюдение за присутствуем функциональных исполнителей (разработчиков) на планировании спринта.
исполнители отсутствуют на планировании — 0 баллов.
на планировании присутствуют представители (тимлиды) исполнителей — 1 балл.
на планировании присутствуют исполнители, не объединённых общей командой — 3 балла.
на планировании присутствуют исполнители, объединённые командой — 5 баллов.
Принцип планирования содержания спринта
Наблюдение за принципом включения доработки в состав спринта.
учитываются только приоритеты стейкхолдеров — 0 баллов.
учитываются приоритеты стейкхолдеров и трудозатраты — 1 балл.
учитываются приоритеты стейкхолдеров, полнота существующих знаний — 3 баллов.
учитываются приоритеты стейкхолдеров, полнота существующих знаний, готовность постановок — 5 баллов.
Наблюдение за применяемой техникой при прогнозировании допустимого объёма спринта
прогнозирование не проводится — 0 баллов.
прогнозирование проводит тимлиды функциональных групп — 1 балл.
прогнозирование проводит команда продуктового направления без определённой техники — 3 балла.
прогнозирование проводит команда продуктового направления, используется техника pokerpointing — 5 баллов.
0–17 баллов — низкий результат, характеризующий отсутствие гибкости производства в части синхронизации объёма работа стейкхолдеров и продуктовой команды. Данные ограничения обусловлены наличием нескольких рабочих групп с дублирующими функциями, а также размытой зоной ответственности продуктовой команды. Рекомендуется предусмотреть мероприятия по сокращению рабочих групп с дублирующими функциями и выделить единого ответственного лица за продуктовое направление. В дополнении рекомендуется провести тренинг сессии со стейкхолдерами.
18–21 баллов — средний результат, характеризующий ограниченную гибкость производства в части синхронизации объёма работа стейкхолдеров и продуктовой команды. Данные ограничения обусловлены маршрута объёма работ по принципу «глухого телефона», на этапах которого происходит искажение общего информационного поля. В плане улучшения характеристик рекомендуется рассмотреть мероприятия, направленные на оптимизацию маршрута объёма работ.
22–25 баллов — высокий результат, характеризующий гибкость и устойчивость производства программного обеспечения с точки зрения управления ожиданиями. Стейкхолдеры и продуктовые команды синхронизированы относительно содержания инкрементов. Отсутствуют изолированные от продуктового бэклога работы, что предотвращает производство ненужных результатов.
Видение продукта
Видение продукта, или общая концепция продукта, определяет долгосрочную миссию продуктового направления в части маршрута развития. Видение должно выполнять функцию ориентира для всех стейкхолдеров, вовлечённых в разработку программного обеспечения, для достижения общих целей с выпуском инкремента продукта. Продуктовое видение отвечает на вопрос, почему создаётся данный продукт и что компания надеется достигнуть в ближайшем будущем.
Структура видение может быть описана по следующему шаблону:
Для кого: целевая аудитория продукта.
Потребности: потребности и проблемы клиента для решения.
Продукт: брендовое название продукта.
Категория: описание продукта.
Преимущества: ключевые преимущества продукта, причины приобретения.
Сравнение: особенности от конкурентов.
Характеристика
Метод исследования
Метрика
Наблюдение за наличием единственного сотрудника, владеющего видением продукта (продуктового направления).
отсутствует владелец видения — 0 баллов.
существуют несколько владельцев видения — 1 балл.
существует единственный сотрудник в качестве носителя видения, который его не разделяет — 3 балла.
существует единственный сотрудник в качестве носителя видения, который его разделяет — 5 баллов.
Наблюдение за принципом распространения видения среди стекйхолдеров и продуктовой команды.
видение распространяется только среди продуктовой команды — 0 баллов.
видение распространяется только среди стейкхолдеров — 1 балл.
видение распространяется среди стекйхолдеров и продуктовой команды с использованием одинаковых материалов — 3 балла.
видение распространяется среди стекйхолдеров и продуктовой команды с использованием разных материалов — 5 баллов.
Инкрементность и итеративность видения
Наблюдение за принципом этапного развития и доставки видения.
видение доставляется в виде продукта без промежуточных этапов — 0 баллов.
видение доставляется инкрементно без итеративности — 3 балла.
видение доставляется инкрементно с итеративностью — 5 баллов.
Наблюдение за проявлением свойства адаптировать видение к изменяющимся внешним условиям по мере изучения нового.
видение сложно меняется и является идеологическим монолитом — 0 баллов.
изменение видения продуктового направления ограничено корпоративными бюрократическими барьерами — 1 балл.
изменение видения продуктового направления проводится по регламентированной процедуре — 3 балла.
видение продуктового направления может легко меняться, в компании отсутствуют административные барьеры — 5 баллов.
Наблюдение за проявлением свойства позиционировать видение относительно бизнес-ценности.
позиционирование видения насыщено техническими деталями — 0 баллов.
позиционирование видения находится в плоскости решения проблемы и/или доставки добавочной ценности для бизнеса — 5 баллов.
Наблюдение за механизмами валидации видения продукта со стекйхолдерами, продуктовой командой и рынком.
валидация видения не проводится — 0 баллов.
валидация видения проводится только со стейкхолдерами — 1 балл.
валидация видения проводится со стейкхолдерами и командой — 3 балла.
валидация видения проводится со стейкхолдерами, командой и рынком — 5 баллов.
Отношение видения к стратегии компании
Наблюдение за проявлением принципа соответствия видения продукта со стратегией компании.
отсутствует сопоставление видения продуктового направления со стратегическими целями компании — 0 баллов.
существует косвенное сопоставление видения продуктового направления со стратегическими целями компании — 3 балла.
существует прямое сопоставление видения продуктового направления со стратегическими целями компании (увеличение дохода, рост объёма продаж, увеличение доли рынка, улучшение имиджа) — 5 баллов.
0–24 баллов — низкий результат, характеризующий отсутствие продуктового видения как инструмента определения стратегического вектора развития продуктового направления. Данный результат свойственен компаниям с контрактной моделью предоставления сервиса по заказной разработке. Проявляются высокие риски закрытия целых продуктовых направлений. Рекомендуется разработать полноценную программу развития культуры продуктового видения, включив стратегические сессии, коучинг руководителей и тренинги сессии продуктовых команд.
25–29 баллов — средний результат, характеризующий слабую степень развития продуктового видения, которое выражается в рассинхронизации общего представления вектора движения между стекйхолдерами: заказчик, акционеры, руководство и продуктовая команда. При данном результате преобладает низкая культура корреляции стратегических целей компаний с концепцией продуктовых направлений.
30–35 баллов — высокий результат, характеризующий уверенную степень развития продуктового видения, которое обеспечивает разработку дорожной карты по принципу декомпозиции высокоуровневой концепции на тактические задачи в вид бэклога продукта для продуктовой команды. Наблюдается проявление принципа принятия решений на основании стратегических ориентиров. Продуктовая команда и стейкхолдеры синхронизированы в понимании стратегического вектора движения продукта.
Ценность продукта
Ценность продукта — выгоды, приобретаемые пользователем продукта для удовлетворения потребностей с определёнными затратами на них. Ценность продукта является агентом сделки между пользователем и разработчиком программного обеспечения, при котором происходит перераспределение финансовых благ. Ценность, обеспечиваемая продуктом, зависит от двух аспектов:
Важность цели, которую пользователь собирается достигнуть при использовании продукта. Данный аспект определяет абсолютную ценность, характеризующую степень соответствия потребностям пользователя.
Доступные альтернативные решения на рынке для сравнения конкурентных преимуществ. Данный аспект демонстрирует относительную ценность, которая определяет конкурентные правила и векторы роста продукта.
Характеристика
Метод исследования
Метрика
Наблюдение за проявлением проектного или продуктового мировоззрения.
преобладает мировоззрение в контексте проектного треугольника (состав работ, сроки и ресурсы) — 0 баллов.
выделяется как проектное, так и продуктовое мировоззрение — 3 балла.
преобладает продуктовое мировоззрение в контексте доставки ценности продукта — 5 баллов
Наблюдение за признанием ценностей продуктового направления в разрезе выделенных элементов ценности (The 30 Elements of Consumer Value: A Hierarchy).
продуктовые направления не имеют систему элементов ценности — 0 баллов.
продуктовые направления имеют систему элементов ценности, которые не признаны на всех уровнях компании — 1 баллов.
продуктовые направления имеют систему элементов ценности, которые признаны на всех уровнях компании — 3 баллов.
продуктовые направления имеют систему элементов ценности, которые признаны на всех уровнях компании. Проведено маркетинговое исследование для подтверждения — 5 баллов.
Наблюдение за техникой целеполагания в контексте ценности продуктового направления.
техника отсутствует, целеполагание не проводится — 0 баллов.
техника отсутствует, целеполагание проводится — 1 баллов.
присутствует техника impact mapping, ограниченное использование — 3 балла.
Определение интегральной шкалы оценки свойства «ценность продукта» не целесообразно так, как каждый атрибут является самодостаточной характеристикой и требует индивидуального подхода в интерпретации и разработки мероприятий для развития. Рекомендуется в программе предусмотреть мероприятия стратегических сессий руководителей компании и владельцев продуктовых направлений, тренинг сессии владельцев продуктов для развития культуры целеполагания.
Управление продуктовым бэклогом
Эффективное управление продуктовым бэклогом гарантирует разработку продукта согласно видению с целью доставки добавочной ценности. Более того, повышается транспарентность информационного поля, выстраивается эмпирический механизм валидации ценности и сокращаются зависимости.
Характеристика
Метод исследования
Метрика
Наблюдение за единым местом хранения всех задач, направленных на развитие продукта.
бэклог продукта отсутствует — 0 баллов.
бэклог продукта имеет вид разбросанных задач — 1 балл.
бэклог имеет вид отфильтрованного списка по предмету — 3 балла.
бэклог единое место хранения всех задач по продукту — 5 баллов.
Наблюдение за наличием единственного сотрудника, являющимся владельцем бэклога продуктового направления.
отсутствует владелец бэклога — 0 баллов.
существуют несколько владельцев бэклога — 1 балл.
существует единственный сотрудник в качестве владельца бэклога, на уровне компании не признаётся — 3 балла.
существует единственный сотрудник в качестве владельца бэклога, на уровне компании признаётся — 5 баллов.
Наблюдение за проявлением принципа доступности бэклога всем заинтересованным сторонам.
бэклог не доступен команде продуктового направления и стейкхолдерам или существуют ограничения в части получения доступа — 0 баллов.
бэклог доступен команде продуктового направления и стейкхолдерам по ссылке — 5 баллов.
Наблюдение за принципом организации структуры элементов бэклога.
бэклог включает в себя элементы, отличные от Agile-подхода — 0 баллов.
бэклог включает в себя: EPIC (эпик), user story (пользовательская история), task (задача), subtask (подзадача), bug (дефект) — 5 баллов.
Определение интегральной шкалы оценки свойства «управление продуктовым бэклогом» не целесообразно так, как каждый атрибут является самодостаточной характеристикой и требует индивидуального подхода в интерпретации и разработки мероприятий для развития. Рекомендуется в программе предусмотреть мероприятия с включением коучинг и тренинг сессий владельцев продуктов для развития культуры целеполагания.