Груминг скрам что это
Для чего и как проводят 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:
Технический груминг
Backlog Grooming — понятие из scrum, смысл которого в том, что команда собирается и решает что будет делать дальше и ставит эстимейты задачам. Проводится 1–2 раза в спринт в назначенное время. Но к сожалению, у нас, в какой-то момент возникли проблемы с PR:
Решение проблем оказалось банальным, появились “technical groomings” (название взято из головы, если вы знаете как этот процесс называется официально — пишите в личку). Смысл в том, чтобы позволить технической стороне обсудить формальный алгоритм задачи, разбить задачи на атомарные задачи и заэстимейтить каждую из задач.
Идея в том, чтобы у разработчиков было понимание того, как задача будет сделана. Тут спасает что угодно, текст с пошаговым выполнением задачи, блок схемы или просто рисунки в блокноте. Главное, что стоит держать в голове — нет понимания бизнес цели — не будет работающего алгоритма. Поэтому не спешите и задавайте вопросы бизнесу, даже если есть хоть малейшее недопонимание задачи.
Разбивка на атомарные задачи Правила, которых стараюсь придерживаться:
Также, планируйте рефакторинг и закрытие технических долгов либо перед началом работы, либо после. Если одна задача из списка блокирует другую — стоит задуматься и попробовать вынести то, что блокирует — в отдельную задачу. Яркий пример такой задачи: добавить эндпоинт для фронтенда. Минимум два варианта, так решить проблему:
С таким подходом будет проще сделать документацию по проекту, а также, больше разработчиков будет понимать логику приложения. Кроме того, плохие решения будут отсеиваться быстрее, а значит цена ошибки будет меньше.
Так как результат такого груминга — проработанный алгоритм выполнения задачи, написание кода превращается в рутину. А составленный список минимальных задач помогает побороть фрустрацию и прокрастинацию перед неизведанным.
Главная проблема — трата времени на обсуждение задачи. Этого могут не понять менеджеры, которые считают “нет кода — нет работы”. Старайтесь говорить с менеджерами и объяснять смысл таких обсуждений.
Такой подход не работает в команде из одного человека. А сам процесс груминга энергоемок, поэтому не ждите, что сможете загрумить все за один день.
И главное — груминг требует командной дисциплины.
Уточнение бэклога (Backlog Refinement): кому на него ходить и как увеличить его ценность
Скрам-команды не так давно называли уточнение бэклога Product backlog grooming. Другой термин, Backlog Refinement, случался намного реже.
Сегодня термин Product backlog grooming убрали изо всех официальных источников. Причина — двойное значение слова grooming (в British English его используют как определение совращения несовершеннолетних, и слово это имеет достаточно грубый оттенок).
Итак, никаких Backlog grooming — только Backlog Refinement. А лучше по-русски — уточнение бэклога.
Уточнение бэклога (Backlog Refinement) пока что не считается официальной встречей в скраме, но очень многим помогает продуктивнее провести планирование спринта.
Так что такое рефайнмент в скраме?
Груминг, или же “причесывание” бэклога (как его называли), это анализ историй пользователей. Его цель — уточнить, отвечает ли количество и размер историй временным рамкам спринта, проверить определение готового и узнать, есть ли в команде достаточное понимание каждой пользовательской истории.
Так как лучше всего провести сессию уточнения бэклога (Backlog или Scrum Refinement Session)? Рассказывает Майк Кон.
Кому стоит присутствовать?
Возможно, через несколько лет уточнение бэклога будет принято как один из общих обязательных скрам-процессов, но пока эта встреча не регламентирована. А значит, нет консенсуса относительно того, кто должен на нее приходить.
Хотя в целом я очень верю в вовлечение всей команды, для этой встречи собирать всех непрактично. И вот почему:
Как максимизировать ценность?
Увеличение ценности встречи по Scrum backlog refinement в реальности мало чем отличается от простых приемов улучшения любой встречи:
Помните, что обсуждение бэклога не должно сводиться к конкретному отрезку времени или одной встрече — каждый может участвовать в процессе в любое время. Хотя я упоминал, что обычно уточнение бэклога проводят за два-три дня до окончания спринта, на самом деле время встречи или вообще активности стоит выбирать так, чтобы было удобно конкретной команде.
Когда уточняете бэклог, помните, что не все его элементы (обычно в форме пользовательских историй, user stories) должны быть понятны до наименьших деталей в начале спринта. Команде стоит выработать всего лишь достаточное понимание фич, чтобы иметь серьезные шансы выполнить работу за спринт.
Можно ли сделать уточнение бэклога нескучным?
Мне в принципе сложно представить рабочую встречу, которая была бы воплощением безудержного веселья. Однако я уверен, что с адекватными коллегами встречи можно рассматривать как здоровые перерывы в более плотном рабочем потоке.
Хорошие команды могут выработать ритм, в котором насыщенная умственная работа в одиночку или в парах чередуется со встречами. Эти встречи могут быть хорошим поводом пообщаться, пошутить с коллегами или просто ненадолго прерваться перед новым погружением в интенсивную работу.
Я слышал о самых разных способах сделать скрам-встречи интереснее. Большинство этих идей созданы для случаев, когда кто-нибудь опаздывает на ежедневный скрам (например, таких сотрудников просят кинуть пожертвования в специальный горшок, спеть песню перед коллегами или рассказать анекдот). Эти идеи противоречивы, но почему бы не вдохновиться ими и не облегчить атмосферу встречи по уточнению бэклога? Например, поговорите несколько минут о том, как у кого дела, о ваших семьях или о чем угодно еще, что сделает встречу менее напряженной.
В целом, уточнение бэклога продукта не должно происходить в каждом спринте, но иногда следует закладывать на него время. Это поможет поддерживать в верхней части бэклога небольшие элементы, которые лучше всего впишутся в спринт, так что вы сможете запастись усилиями для последующих задач.
Переведено и адаптировано командой BrainRain по материалу Майка Кона.
Этапы и мероприятия Scrum
7.2. Ежедневные встречи (daily)
Знание о том, чем занимаются коллеги по команде, помогает в:
Длительность дэйли строго ограничена и не должна превышать 15 минут. Эта встреча не предназначена для решения проблем. Все требующие специального обсуждения вопросы должны быть вынесены за ее пределы.
Встреча проводится каждый день всегда в одно и то же время, чаще всего это утро, но в распределенных командах это может быть день или вечер.
Scrum-мастер ведет эту встречу, задавая каждому члену команды по три вопроса:
Каждый член команды должен отвечать на необходимые вопросы.
Важно, чтобы все, отвечая на вопросы, не вдавались глубоко в детали и, боже упаси, уж точно не пытались тут же их решать.
С одной стороны, это кажется не такой уж и большой проблемой, но по факту оказывается, что отвлечение сотрудников от плана встречи приводит к тому, что через какое-то время многие не видят в ней необходимости. В тот момент, когда кто-то углубляется в повествование о деталях, большинство незаинтересованных начинает скучать, погружаться в серфинг социальных сетей посредством мобильных гаджетов и т. д.
Для того чтобы перебороть неправильное развитие Scrum-процесса и направить дэйли в нужное русло, нужно:
7.3. Груминг бизнес-задач
Груминг стоит проводить до или в начале спринта, с тем чтобы детально разобрать подготавливаемые задачи к реализации разработчиками. Периодичность его проведения должна быть один раз в спринт. Время, затрачиваемое на груминг, должно составлять 10% от общей продолжительности спринта.
Сначала, для вновь собранной команды, на груминг может уходить немало времени. Это связано с «притиранием» разработчиков и владельца продукта друг к другу, более глубинным пониманием бизнес-смысла разрабатываемого программного обеспечения, осознанием деталей и взаимосвязей влияния автоматизируемых процессов и т. д. Но это нужно делать. Как результат появится прогресс в работе над задачами, члены команды уйдут от «слепого» анализа требований к осознанному совершенствованию системы.
Чтобы груминг прижился в операционной деятельности каждой команды, необходимо следовать нескольким простым правилам:
Эти характеристики, в соответствии с которыми задачу можно брать в работу на спринт.
Backlog refinement (grooming): чем полезна регулярная актуализация бэклога
Запросы бизнеса всегда превышают возможности команд по их реализации. Практика backlog refinement помогает контролировать постоянно растущий бэклог.
Потребностей бизнеса всегда больше, чем ресурсов для их реализации. В Scrum за обработку запросов и формирование бэклога отвечает владелец продукта. Но идеи накапливаются, бэклог становится перегруженным и продолжает расти, а команде сложнее держать фокус и эффективно планировать время на выполнение самых полезных задач.
Чтобы брать в работу самое важное — с учетом новых идей и приоритетов — бэклог следует регулярно пересматривать. Для этого проводится Backlog refinement (grooming) — встречи с участием владельца продукта и скрам-команды, в ходе которой содержимое бэклога актуализируется для следующего спринта.
В чем польза?
Актуализация бэклога помогает оптимизировать встречи по планированию спринта. Цель — гарантировать, что бэклог заполнен самыми нужными элементами, в должной степени декомпозированными и приоритизированными в соответствии с текущим видением продукта. А также подготовить почву для следующего спринта: проверить, что есть все данные для работы над элементами, которые войдут в будущий спринт.
Иными словами, это точка командной синхронизации в непрерывном процессе работы с бэклогом, повод еще раз вместе просмотреть его содержимое и задать себе вопросы: эти элементы точно самые важные? их все еще нужно делать именно в этом варианте? они точно принесут ту ценность, которую мы вкладываем, и достаточно ли данных, подтверждающих это?
Основные выгоды актуализации бэклога:
Кто и когда проводит
Согласно Scrum Guide, актуализация бэклога может занимать до 10% времени от спринта. Это может быть одна встреча или несколько более коротких. Некоторые команды предпочитают проводить ее за 2-3 дня до планирования следующего спринта, другие собираются раз в неделю. В этом случае встречи по планированию и уточнению бэклога чередуются, и если проводить их в один и тот же день каждую неделю, формируется четкий ритм, который помогает команде работать эффективно. Тем не менее, владелец продукта может обновлять элементы бэклога в любое время.
На что обратить внимание
Актуализация бэклога — ценная практика, которая позволяет сделать работу более продуктивной. Поскольку команда и так проводит много встреч, важно организовывать их так, чтобы они не занимали много времени и приносили максимум пользы. Вот несколько рекомендаций, которые могут в этом помочь:
Элементы бэклога декомпозируют до такой степени, чтобы их выполнение помещалось в спринт. По результатам backlog refinement’а команда должна убедиться, что есть все исходные условия для реализации элемента бэклога в спринте. А по тем, для которых недостаточно, запланировать шаги, необходимые для подготовки.
Результативность встречи во многом зависит от того, насколько хорошо владелец продукта и скрам-мастер организуют обсуждение. Подробнее их влияние на работу команды мы рассматривали в материале «Product owner и скрам-мастер: почему важно разделять эти роли».