pbr agile что это
Уточнение Бэклога Продукта [Груминг Бэклога] (Product Backlog Refinement)
Уточнение Бэклога Продукта — это активность, которая проводится Владельцем Продукта при участии всех членов Скрам-команды. Включает добавление деталей, оценку и упорядочивание элементов в Бэклоге Продукта.
Не относится к официальным Мероприятиям Скрама, однако зачастую проходит в виде мероприятия (встречи).
В русском жаргоне адептов Скрама для этой практики прижилось название Груминг Бэклога (а также такие переводы слова Grooming как Уход за бэклогом и Причесывание бэклога). Это связано с тем, что в Scrum Guide до 2013 года использовался термин Grooming, а не Refinement.
В Скраме рекомендуется от 5 до 10 процентов времени каждого Спринта выделять на Уточнение Бэклога Продукта. Этот процесс включает:
Уточнение Бэклога Продукта проводится не для того, что уже взято в работу в текущем спринте, а для будущих спринтов. Хорошей практикой считается иметь в Бэклоге Продукта детально проработанные элементы как минимум на два Спринта вперёд. В этом случае Планирование Спринта существенно упрощается, поскольку Владелец Продукта и Скрам-Команда начинают планирование с понятным, прошедшим этап анализа и аккуратно оцененным набором пользовательских историй. Если же груминг Бэклога не был проведён (или был проведён недостаточно хорошо), Планирование Спринта растянется во времени, вызовет большое количество вопросов, потребует уточнений и/или выявит несоответствия.
Для пользовательских историй существует два критически важных этапа: «Готово к разработке» и «Сделано». Для них должны быть, соответственно, критерии готовности к разработке (Definition of Ready) и Критерии готовности (критерии завершения работы над историей, Definition of Done). И Уточнение Бэклога — это процесс или встреча, в ходе которого Владелец Продукта удостоверяется в том, что пользовательские истории «Готовы к разработке», то есть команда может немедленно взять их в работу и перевести их в «Сделано».
Одно из 5 Мероприятий Скрама. Эта встреча длится не более пятнадцати минут и проводится каждый рабочий день в одном и том же месте в одно и то же время. В нем принимают участие все разработчики. На нем озвучивается информация для оценки прогресса и отмечаются препятствия. В результате разработчики могут прийти к необходимости перепланирования работы внутри Спринта.
Одно из 5 Мероприятий Скрама. Проводится в конце Спринта, чтобы клиенты и заинтересованные лица провели инспекцию Инкремента и дали обратную связь по нему, а Скрам-команда, при необходимости, сделала адаптацию Бэклога Продукта. Для Спринта длиной в месяц Обзор Спринта длится не более 4 часов.
Одно из 5 Мероприятий Скрама. На этой встрече Скрам-команды происходит планирование работы на следующий Спринт. Для Спринта длиной в месяц встреча длится не более 8 часов. Она завершается созданием Бэклога Спринта и включает обсуждение 3-х тем:
Одно из 5 Мероприятий Скрама. Ретроспектива Спринта дает Скрам-команде возможность провести инспекцию своей работы и создать план улучшений на следующий Спринт. Ретроспектива проходит после Обзора Спринта, перед Планированием Спринта. Для Спринта длиной в месяц эта встреча ограничивается 3 часами.
Одно из 5 Мероприятий Скрама, которое является контейнером для других мероприятий. Спринты — это короткие регулярные циклы длиной не более четырех недель. Итерации работы должны быть достаточно короткими, чтобы команда не теряла концентрацию, и при этом достаточно длинными, чтобы поставлять значимый инкремент работы. Все остальные Мероприятия Скрама проводятся в рамках Спринта. Следующий Спринт начинается сразу же по окончании предыдущего.
Мы хотим, чтобы компании были крутыми, а люди в них — счастливыми
Планирование за час и другие оптимизации scrum ивентов
Чистый скрам — как единорог на музыкальном фестивале: вроде бы он существует, все о нём говорят, только вот показать тебе его никто не может. Так же сложилось и у нас в команде, об этом и поговорим. А если конкретнее — о том, как мы сократили время на встречи и не потеряли пользу от них.
Ясное дело, в Интернете полно статей о том, кто и как этот скрам у себя взращивал, что получилось, а что нет. Я не претендую на уникальность и всего не читал, ибо писателей таких статей гораздо больше, чем у меня свободного времени. Однако хочу рассказать, как мы в команде Android-разработки выстроили (и еще строим) процесс, практически не тратя время на встречи и обсуждения. Получилось так именно потому, что моё время (я PO) и время команды сильно ограничено, и я стремлюсь сделать всё, чтобы не заниматься процессами ради процессов и при этом сохранять производительность и прозрачность на высоком уровне.
Дам небольшое представление о себе, чтобы у читателя начал складываться портрет человека, от чьего лица идет повествование.
Я — продуктовый менеджер Android-команды в компании Wrike. Кроме этого мне выпала почётная роль скрам-мастра.
Мы — satellite app, а большая часть наших клиентов выполняет работу в офисе и использует web-версию продукта. Ключевых релизов у нас около 3-х в квартал, но приходится уделять много времени на поддержку улучшений из web-версии. Из-за активного развития веба мы релизимся раз в две недели. Функция приложения — не терять связь с командой и следить за рабочими процессами. Настраивать окружение можно только в web-версии. Стратегия развития продукта — увеличить аудиторию и её активность на мобильных устройствах. Наша команда состоит из пяти Android-разработчиков, двух QA, одного UX-дизайнера, одного продуктового менеджера. Все ребята очень скиловые.
Теперь, когда у читателя сложилось некоторое представление о команде, я перейду к сути статьи — процессам. Сегодня речь пойдёт про такие элементы скрама, как: PBR, Retro, Planning, Daily. Моя основная цель как скрам-мастера — использовать ценность этих встреч и одновременно тратить на них минимум времени. Кроме того, что это просто логично с точки зрения оптимизации ресурсов, у нас есть еще одно ограничение: наша команда должна поддерживать изменения двадцати продуктовых команд. Мы не поддерживаем все изменения, но те, что затрагивают существующий функционал, требуют нашего участия. В статье я расскажу подробнее о том, сколько времени мы выделяем на каждый из этих четырёх ритуалов и какие плоды приносят такие временные рамки.
Подсмотрел в интернете такое определение: «PBR (Product Backlog Refinement) — это процесс добавления деталей, оценок и порядка к элементам в списке невыполненных работ». По своему опыту знаю, что на таком событии часто присутствует вся команда, чтобы увидеть задачу заранее, подсветить неочевидные моменты. Но такая встреча требует много времени, а у нашей команды его нет, потому что изменений с web-версии прилетает много. Поэтому мы изменили формат встречи.
Как показала практика, есть список задач, которые могут быть очень сложными или нехарактерными, на первый взгляд, для продукта. Перед исследованием таких задач я собираю всех желающих и рассказываю суть происходящего — это у нас называется Forum. Происходит такое крайне редко, однако порядочно сплачивает команду и подогревает интерес к задаче, вызывает привыкание причастность к продукту. И растёт эта причастность именно из-за своей нерегулярности. Такое собрание становится чем-то особенным, нерутинным и потому значимым.
Разбор работы происходит следующим образом: каждая задача (story) планируется на одного человека (давайте назовём его «чемпион»), и он проводит исследование того, что конкретно нужно по ней сделать. Добавляет описание, уточняет у UX-дизайнера, как должны работать какие-то моменты, если этого не хватает в доке, советуется с бэкендом и пишет подробный план. На самом деле получается нечто вроде Spike’а.
Такой подход себя хорошо зарекомендовал по следующим причинам:
Retro
Тут я хвастаться не буду, просто скажу, что в команде есть правило: вместе с проблемой предлагай решение. Ребята в команде ответственные, хотят работать хорошо и не отвлекаться на неприятные мелочи, поэтому они заинтересованы, чтобы процессы были понятные и надёжные.
Позвольте мне привести пример задачи (проблемы), что встала перед нами на Retro — забываем добавлять аналитику. Может показаться, что она касается скорее PM’a, чем разработчиков, но, как я сказал, ребята в команде мотивированы и хотят делать свою работу хорошо. Из-за ограниченного ресурса аналитики вести этот процесс идеально не удаётся, потому прямо на retro мы выстроили конкретный процесс и разделили обязанности между членами команды так, что каждый вносит свою пользу на определённом этапе. Также важное замечание: если за час мы не успели придумать, как решить проблему, мы соглашаемся попробовать предложенные идеи и корректировать их по ходу.
Но случаи бывают и пограничными, когда профессиональные цели несколько расходятся, и между членами команды могут появляться шероховатости, иначе говоря, инженеры больше сфокусированы на технической части, PM на продукте, а дизайнер на удобстве и графике. Но поскольку наша главная общая цель — создать хороший продукт, то мы не стесняемся обсуждать моменты на стыке интересов членов команды. И тут стоит сказать, что у нас принято быть открытым и честным. Если же в команде кто-то стесняется высказать свою точку зрения, то высока вероятность, что в команде существует неравноправие или есть скрытые конфликты. Лишь равноправие в системе позволяет быть открытым. Если интересно, как нам это удалось, дайте знать в комментариях, а пока поехали дальше.
Planning
Моя любимая часть скрама. Нравится она мне по двум причинам:
На первый взгляд может показаться кашей, однако из-за того, что команда сама планирует, она хорошо разбирается в происходящем и оперативно вносит изменения
Daily
В первую очередь, это про синхронизацию, но хочу отдельно подчеркнуть мою роль как продакт-менеджера в этом событии. Я уже говорил о том, что в команде важно равноправие. Климат должен быть такой, чтобы ребята чувствовали себя командой, а не индивидуальными контрибьюторами. Потому, будучи продакт-менеджером, я рассказываю новости компании, а также чем я занимался, что узнал и что меня ждёт. Перед командой секретов у меня нет, хотя крайне редко возникают исключения: некоторые вещи нас просят придержать до официального анонса. Но такие анонсы — это прям что-то из ряда вон выходящее.
Spike на 1 день + редкие встречи в формате Forum для введения в курс дела ребят по необычным задачам дают хорошее понимание о том, какая работа нам предстоит. Планирование занимает всего час и проходит в свободной форме, все люди прекрасно договариваются о том, что им нужно делать. Retro проходит всегда в одном формате, но очень продуктивно, и мелочи в процессах обтачиваются регулярно. А открытость продакт-менеджера в дейли формирует в команде равноправие и доверие.
Для меня, в конечном счёте, лишь три показателя имеют смысл: уровень удовлетворённости команды, чтобы ребята не выгорели, качество продукта и скорость исполнения задач.
И эти показатели в нашей команде довольно высоки:
Icing on the cake
Немного математики. За двухнедельный спринт получается:
Ясное дело, что это число стоит умножить на количество людей в команде, чтобы понять, во сколько человеко-часов вам обходятся скрам ивенты. Мой показатель — 5.6% ±2.5% при размере команды в 9 человек. Чем больше будет команда, тем выше будет расти это значение. Но давайте не забывать, что скрам-команда имеет рекомендуемые размеры, а значит и показатель времени, которое тратится на командные события, тоже имеет разумный предел.
В общем-то, пока всё. Будет идеально, если поделитесь цифрами: сколько времени занимают скрам ивенты у вас. Ну и чтобы сделать статью более ценной, давайте обсудим пользу и вред, который, по вашему мнению, могут принести такие оптимизации.
Что такое Уточнение Бэклога Продукта
Уточнение Бэклога Продукта — это встреча для прояснения будущих задач Команды Разработки. Владелец Продукта и Команда собираются, когда не до конца понимают, с какой стороны подступиться к задачам в следующем Спринте. После встречи они чётко представляют, что предстоит cделать, сколько сил затратить и к чему это приведёт.
Сам Бэклог Продукта — это список возможных улучшений. Записаны они бывают по-разному, например, одни улучшения полностью понятны Команде, другие — всего лишь хотелки без конкретики. И если сразу взяться за такие хотелки, есть риск не уложиться в Спринт или вовсе не выпустить Продукт. На встрече их конкретизируют.
Встреча Владельца Продукта и Команды Разработки
На уточнение приходят Владелец Продукта и Команда. Приглашают и клиентов с экспертами, если без их мнения нельзя обойтись. Скрам-мастер тоже может прийти, чтобы помочь провести встречу, сформулировать задачи или упорядочить Бэклог Продукта.
Собраться без Владельца Продукта нельзя — только он вносит изменения в Бэклог. А вот Команде собираться всем составом необязательно. Цель встречи известна заранее, и каждый сам определяет, будет ли он полезен и нужно ли ему вообще присутствовать на уточнении задач.
Студия пирсинга год работает по Скраму. Сейчас она планирует запустить новую услугу: купить оборудование, найти ещё одного мастера и дать рекламу в социальных сетях. Хочется также создать блог и открыть франшизу. Но если первые три задачи понятны, то что делать с блогом и франшизой — студия толком не знает.
Решили сначала разобраться с блогом. На встречу пришли Владелец Продукта, маркетолог и два мастера пирсинга. Маркетолог пришёл вместе с редактором.
Помогает детально проработать Бэклог Продукта
На встрече участники разбивают задачи на маленькие, объединяют в большие или меняют порядок Бэклога. Владелец Продукта и Команда Разработки проясняют задачи до готового к работе состояния, когда их можно сразу включить в план и реализовать к концу следующего Спринта.
Для доведения задач до ума участники встречи определяют, насколько ценна каждая задача, как она зависит от других и по каким критериям её принимать. Все задачи записывают максимально коротко, чтобы не превратить Бэклог Продукта в многостраничного монстра.
На встрече маркетолог рассказал, как раскрутить блог, что для этого потребуется и что в итоге получит студия. Мастера пирсинга поделились, чем интересуются клиенты, чего боятся и какие советы им нужны. Редактор объяснил, как организовать работу над статьями и сколько человек к этой работе привлечь.
Прямо во время встречи участники дополняли Бэклог Продукта. В итоге стало понятнее: не создать блог, а придумать дизайн, составить список тем и разработать стратегию продвижения. Эти задачи уже можно поручать и планировать на следующий Спринт.
Длительность и частоту встречи определяют участники
Уточнение Бэклога Продукта — полезная, но не обязательная встреча, и нигде не описано, сколько и как часто она должна идти. Владелец Продукта с Командой Разработки определяют её длительность и частоту сами — и отводят обычно не больше 10% своего рабочего времени.
Студия работает недельными Спринтами по 30 часов, а на Уточнение Бэклога Продукта собирается дважды в неделю по 1,5 часа — это как раз 10% рабочего времени.
Одной встречи хватило, чтобы полностью разобраться с блогом, поэтому на следующей встрече обсудят уже открытие франшизы.
Уточнение Бэклога Продукта — хоть и необязательная, но часто необходимая встреча. Благодаря ей Владелец Продукта и Команда Разработки детализируют задачи Бэклога — в итоге они понимают, над чем работать в следующем Спринте, и планирование проходит эффективнее.
Мы уже рассказали, как в Скраме собирают обязательные встречи. Кроме Планирования Спринта есть Ежедневный Скрам, Обзор Спринта, Ретро.
Сергей Васин Редактор Unusual Concepts
Для чего и как проводят backlog grooming в продуктовых командах?
Бэклог продуктовых задач является одним из основных и обязательных артефактов Agile. Фактически, это набор требований, полученных от бизнеса и сформулированных в виде задач для разработки. Что нужно делать для того, чтобы эти задачи всегда были в порядке? И как это связано с концепцией backlog grooming?
Набор таких задач не несет ценности, если не приносит системной или структурной оптимизации. Очень важно правильно уметь управлять очередью задач, чтобы получить актуальный материал для работы. Как раз это и является целью такого процесса или активности, как backlog grooming.
Еще один тип встреч в Scrum
Backlog grooming — это собрание представителей Scrum-команды, во время которого обсуждаются детали бэклога продукта и готовится очередное планирование спринта.
Наверняка, большинство менеджеров и собственников продуктов благодаря опыту и практике знают, как превратить рутинное управление бэклогом в приятный процесс. Чтобы достичь этого, необходимо тщательно ухаживать за бэклогом, “чистить” и оптимизировать его. Это то, что называется grooming или product backlog refinement.
Согласитесь, любой продукт, как и человек, требует внимания и заботы.
Стратегический смысл груминга в управлении продуктом
Поскольку бэклог представляет собой очередь из пользовательских историй, то, часто, такой список может быстро стать перегруженным. Многие не знают, как справляться с такой перегрузкой, а бэклог продолжает расти.
Когда это случается, члены команды могут потерять фокус на важных задачах, а статус пользовательских историй может утратить ясность. Также могут возникнуть проблемы с оценкой времени и ресурсов.
Уход за бэклогом — это активность с участием менеджера проекта (менеджера продукта/ собственника продукта) и представителя клиента, направленная на то, чтобы разбить бэклог на истории пользователей, переориентировать их и задать новые приоритеты. Backlog grooming в управлении продуктом должен стать постоянным событием, основанном на глубоком анализе и четких действиях.
Этот процесс необходим для того, чтобы задачи, представленные в бэклоге, были актуальными, а те, которые представлены в верхней части списка, были готовы к планированию в спринте, реализации и релизу.
Груминг бэклога часто называют предварительным планированием. Обычно собственник продукта и представители команды организуют его в середине спринта.
Процесс не считается формальный частью Scrum. Тем не менее, рекомендуется, чтобы владелец продукта и представители команды выделяли до 15% каждого спринта для такой активности.
Главные цели процесса backlog grooming
Иногда собрание по backlog grooming называют story time session. В любом случае, цель этого мероприятия — обсудить текущий бэклог, определить и предложить действия по его оптимизации. Это может включать следующее:
Результат хорошего груминга
Результатам grooming является здоровый вид бэклога:
Какие инструменты использовать для backlog grooming?
Поскольку определение приоритетов — ключевой момент во время проведения backlog grooming, то очень важно грамотно визуализировать важность и взаимосвязь задач для дальнейшей работы с ними. Для упорядочивания идей и задач менеджеры продуктов используют параметры Value и Efforts. Сравнение этих значений для каждой задачи помогает лучше определить приоритеты и выбрать наиболее важные задачи.
В качестве заключения
Важно помнить, что grooming должен стать постоянным событием в управлении продуктом, которым не стоит пренебрегать. Этот процесс — это норма для качественного развития продукта. Самое главное в нем — оптимизировать задачи бэклога для последующей работы с ними.
Backlog grooming помогает прояснять релевантность задач, представленных в бэклоге, анализировать существующие вопросы и получать дополнительную информацию о задачах, которые пока не до конца ясны.
Подытоживая, отметим основные преимущества backlog grooming:
Эффективный PBR
PBR не является официальным событием в Скраме, но он снижает вариативность элементов Бэклога Продукта (PBI) перед тем как они попадут в Спринт.
В этой статье я опишу что, с моей точки зрения, может обеспечить эффективность PBR в Скрам.
Почему PBR важен
PBR не является официальным событием в Скраме, но он снижает вариативность элементов Бэклога Продукта (PBI) перед тем как они попадут в Спринт. Когда верхние элементы Бэклога Продукта приходят в состояние “ready”, то в Спринте у команды возникает меньше “сюрпризов”, а вероятность достижения Цели Спринта возрастает.
Разработчики общаются с клиентами напрямую
Очень часто замечаю дисфункциональные имплементации Скрама, когда между разработчиками и рынком стоят промежуточные лица, препятствующие прямой коммуникации и являющиеся источником потерь. Примеры потерь:
Стейкхолдеры (внутренние, клиенты, пользователи) в хорошем Скраме общаются с Командой Разработки напрямую. Интервью с пользователями, уточнение требований напрямую со стейкхолдерами является нормальной активностью Команды Разработки.
Такой подход лежит в основе масштабируемого Скрама. Когда продукт разрабатывают много команд, то у Владельца Продукта не хватает времени на прояснение элементов Бэклога Продукта. Он делегирует эту активность командам и оставляет за собой упорядочивание Бэклога Продукта.
В масштабируемом Скраме команды выясняют детали требований напрямую со стейкхолдерами. Владелец Продукта оставляет за собой упорядочивание Бэклога Продукта.
Команда в полном составе присутствует на PBR
Некоторые команды высылают на PBR представителей. Несмотря на то, что такой подход работает в некоторых контекстах, у него есть побочные эффекты. Создаются вынужденные передачи и потери. Знания об элементах Бэклога Продукта находятся в головах лишь у нескольких лиц. Этого можно избежать, если на PBR присутствуют все участники команды.
Анализом занимается вся команда, не бизнес-аналитики
Еще один анти-паттерн, который я часто наблюдаю — выделенные бизнес-аналитики, занимающиеся только бизнес анализом. Они служат прокси между стейкхолдерами и командой. Часто в такой структуре в Спринте N-1 проводится бизнес-анализ, а в Спринте N непосредственно сама разработка (код, тестирование и т.д.).
Бизнес-анализ является одной из функций в команде и за нее отвечают все, а не выделенный бизнес-аналитик. Более того, возвращаясь к оригинальной концепции Скрама, Команда Разработки выполняет все активности, начиная от интервью с пользователями до поставки на рынок ценности и поддержки продукта. Работы максимально распараллеливаются. Для этого команда самоорганизуется и использует различные техники. Например, парное программирование, Swarming, моб-программирование.
Пример эффективного PBR
Ниже я детально опишу, как мы проводили один из PBR-ов. Контекст — продуктовая группа (≅30 человек), разрабатывающая один продукт. Соответственно, имеем один Бэклог Продукта и одного Владельца Продукта. На встречу приглашены две команды разработчиков (14 человек), стейкхолдеры из смежных подразделений, которые выступали главными заказчиками функциональности. Мы хотели, чтобы разработчики напрямую уточнили требования со стейкхолдерами.
Цель, желаемые результаты, рабочие договоренности. (5 мин)
Любая эффективная встреча начинается с определения ее цели и желаемых результатов. В нашем случае цель звучала так: “декомпозировать огромную фичу, приоритезировать полученные элементы, определить минимальный необходимый набор функциональности (MVP) для реализации”. Мы договорились о том, что встреча займет не более 2х часов и через час сделаем перерыв.
Верхнеуровневое выравнивание (10 мин)
В открытой дискуссии мы потратили не более 10 мин на обсуждение фичи в формате: Кто, Что и Зачем.
Формируем смешанные группы (5 мин)
Общение в малых группах проходит эффективно, когда в них есть как минимум один стейкхолдер и представители разных команд. Нам удалось сформировать 3 такие смешанные группы. Каждая группа сформировала станцию в общем помещение и продолжила работу.
Первый раунд: разбиение (20 мин)
Мы попросили команды на выходе получить дерево с вариантами разбиения. Сверху помещается изначальное требование. Затем подбираем подходящий паттерн разбиения, получаем следующий уровень. И так далее.
Второй раунд: переход на соседнюю станцию (5 мин)
Так как в предыдущем раунде все группы работали над одним и тем же заданием, то мы попросили команды оставить одного представителя на месте, а остальных перейти по часовой стрелке к следующей станции. Это нужно для того, чтобы узнать, что делали другие команды, а также для получения обратной связи.
Перерыв (10 мин)
Вовлеченно работать более 50-60 минут тяжело. Даже если участники говорят нам о том, что они не устали и готовы работать дальше, мы настаиваем на небольшом перерыве. Чай, кофе и глюкоза (конфеты, печенье) очень полезны. Тем ни менее, хороший знак, если кто-то остается на станциях и продолжает работать. Это сигнал высокой вовлеченности. Значит PBR эффективен.
Третий раунд: завершение разбиения (20 мин)
После перерыва мы дали еще 20 минут на то, чтобы завершить разбиение. Цель в том, чтобы получить небольшие элементы Бэклога Продукта, которые могут быть завершены в Спринте (“ready”). Ниже один из вариантов разбиения, который получился у одной из групп:
Четвертый раунд: представление результатов (20 мин)
Группы по очереди представляют свои варианты разбиения в открытой дискуссии. Интересно, что они пришли к аналогичным результатам. Минимальный набор фич (MVP) оказался на удивление мал. Главным инсайтом PBR оказалось то, что основную бизнес-ценность можно достичь относительно небольшими усилиями. Все согласились с тем, что формат проведения PBR оказался очень эффективным. Когда разработчики напрямую общаются с представителями бизнеса, работая со стикерами и маркерами, фиксируя результаты на листах бумаги, результаты оказываются просто удивительными.