груминг задач что это
Для чего и как проводят 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” (название взято из головы, если вы знаете как этот процесс называется официально — пишите в личку). Смысл в том, чтобы позволить технической стороне обсудить формальный алгоритм задачи, разбить задачи на атомарные задачи и заэстимейтить каждую из задач.
Идея в том, чтобы у разработчиков было понимание того, как задача будет сделана. Тут спасает что угодно, текст с пошаговым выполнением задачи, блок схемы или просто рисунки в блокноте. Главное, что стоит держать в голове — нет понимания бизнес цели — не будет работающего алгоритма. Поэтому не спешите и задавайте вопросы бизнесу, даже если есть хоть малейшее недопонимание задачи.
Разбивка на атомарные задачи Правила, которых стараюсь придерживаться:
Также, планируйте рефакторинг и закрытие технических долгов либо перед началом работы, либо после. Если одна задача из списка блокирует другую — стоит задуматься и попробовать вынести то, что блокирует — в отдельную задачу. Яркий пример такой задачи: добавить эндпоинт для фронтенда. Минимум два варианта, так решить проблему:
С таким подходом будет проще сделать документацию по проекту, а также, больше разработчиков будет понимать логику приложения. Кроме того, плохие решения будут отсеиваться быстрее, а значит цена ошибки будет меньше.
Так как результат такого груминга — проработанный алгоритм выполнения задачи, написание кода превращается в рутину. А составленный список минимальных задач помогает побороть фрустрацию и прокрастинацию перед неизведанным.
Главная проблема — трата времени на обсуждение задачи. Этого могут не понять менеджеры, которые считают “нет кода — нет работы”. Старайтесь говорить с менеджерами и объяснять смысл таких обсуждений.
Такой подход не работает в команде из одного человека. А сам процесс груминга энергоемок, поэтому не ждите, что сможете загрумить все за один день.
И главное — груминг требует командной дисциплины.
Менеджмент в ИТ
Agile in IT: Backlog Grooming
Один из основных и обязательных артефактов в Scrum, это бэклог задач. Фактически это список требований полученных от бизнеса и сформулированных в виде задач на разработку. Однако, сам по себе список всех задач еще не несет большой ценности, если он не привносит какой-то системы и структуры. Очень важным будет грамотная работа с бэклогом с тем, чтобы задачи в нем были актуальными, можно было провести их сравнения с точки зрения размеров и важности. Именно для этого и необходим Backlog Grooming, далее в статье разберемся как его организовать и провести.
Что такое Backlog Grooming?
Дословно, это «ухаживание» за продуктовым бэклогом. Grooming, это регулярное мероприятие, в рамках которого Product Owner совместно с командой проводят анализ и «перетряхивание» бэклога. Grooming проводиться, чтобы убедиться в том, что представленные в бэклоге задачи актуальны, имеют приоритет, а представленные в верхней части списка задачи, готовы к планированию в Sprint, реализации и выпуску.
Основные цели Backlog Grooming:
1. Самое главное – подготовить задачи в бэклоге для последующей работы с ними. Перед тем как та или иная задача будет запланирована в Sprint ее необходимо декомпозировать на пользовательские истории, оценить и определить приоритет;
2. Уточнить актуальность задач, представленных в бэклоге с точки зрения развития продукта. В том числе пройти по отложенным задачам с низким приоритетом – возможно они стали более важными, либо их напротив можно окончательно исключить из списка;
3. Прояснить имеющиеся вопросы, получить дополнительную необходимую информацию по задачам, которые пока непонятны и поэтому не могут быть приняты в работу.
Организация встречи для проведения Grooming.
Чаще всего для Grooming проводиться отдельная встреча. Она может проводиться как регулярно, всегда в один и тот же день, так и по мере необходимости – требуется список оцененных и приоритезированных историй.
Важно не совмещать проработку бэклога с планированием спринта. В рамках Sprint Planning мы уже должны иметь список подготовленных задач, чтобы сосредоточиться только на вопросах реализации историй и формировании скоупа (состава задач) для ближайшей итерации. Задача Grooming выполнить этот необходимый предварительный шаг и подготовить набор задач для планирования в работу.
Участники Backlog Grooming это владелец продукта, остальные члены Scrum команды и некоторые стейкхолдеры, чье участие будет полезным. Владелец продукта играет ведущую роль в организации встречи, он определяет цели и повестку для Grooming сессии.
Довольно важно ограничить число заинтересованных сторон, участвующих во встречи. Слишком большое количество участников будет снижать общую эффективность. Владелец продукта должен приглашать только тех участников, чья обратная связь, знания, информация необходима для проведения Grooming.
На встречу по Grooming должны быть приглашены все члены Scrum команды, т.к. их вклад ценен для реализации задач. Если сессия обработки бэклога приводит к какому-либо изменению приоритетов важно, чтобы команда была согласна с этими изменениями.
Этапы и активности в рамках Backlog Grooming:
1. Удаление существующих задач:
2. Добавление новых задач:
3. Декомпозиция задач:
4. Приоритезация задач:
5. Оценка задач:
6. Применение результатов\уроков предыдущих итераций разработки:
В целом, Grooming помогает гарантировать, что требования будут уточнены, а пользовательские истории будут подготовлены к работе заранее до планирования в Sprint. В этом случае команда во время планирования очередной итерации имеет хорошо проанализированный и четко определенный набор историй, которые разбиты атомарные и независимые составляющие, оценены и приоритезированы. Основываясь на результатах выполненной итерации (прошлый Sprint), могут быть скорректированы требования или выполнена переориентация направления развития продукта, которые будут учтены в последующих спринтах. Таким образом Grooming поддерживает и повышает гибкость Scrum процесса за анализа полученных знаний и фидбэков и включения соответствующих изменений (например, новый функционал и\или технические задачи) в будущие спринты.
Этапы и мероприятия Scrum
7.2. Ежедневные встречи (daily)
Знание о том, чем занимаются коллеги по команде, помогает в:
Длительность дэйли строго ограничена и не должна превышать 15 минут. Эта встреча не предназначена для решения проблем. Все требующие специального обсуждения вопросы должны быть вынесены за ее пределы.
Встреча проводится каждый день всегда в одно и то же время, чаще всего это утро, но в распределенных командах это может быть день или вечер.
Scrum-мастер ведет эту встречу, задавая каждому члену команды по три вопроса:
Каждый член команды должен отвечать на необходимые вопросы.
Важно, чтобы все, отвечая на вопросы, не вдавались глубоко в детали и, боже упаси, уж точно не пытались тут же их решать.
С одной стороны, это кажется не такой уж и большой проблемой, но по факту оказывается, что отвлечение сотрудников от плана встречи приводит к тому, что через какое-то время многие не видят в ней необходимости. В тот момент, когда кто-то углубляется в повествование о деталях, большинство незаинтересованных начинает скучать, погружаться в серфинг социальных сетей посредством мобильных гаджетов и т. д.
Для того чтобы перебороть неправильное развитие Scrum-процесса и направить дэйли в нужное русло, нужно:
7.3. Груминг бизнес-задач
Груминг стоит проводить до или в начале спринта, с тем чтобы детально разобрать подготавливаемые задачи к реализации разработчиками. Периодичность его проведения должна быть один раз в спринт. Время, затрачиваемое на груминг, должно составлять 10% от общей продолжительности спринта.
Сначала, для вновь собранной команды, на груминг может уходить немало времени. Это связано с «притиранием» разработчиков и владельца продукта друг к другу, более глубинным пониманием бизнес-смысла разрабатываемого программного обеспечения, осознанием деталей и взаимосвязей влияния автоматизируемых процессов и т. д. Но это нужно делать. Как результат появится прогресс в работе над задачами, члены команды уйдут от «слепого» анализа требований к осознанному совершенствованию системы.
Чтобы груминг прижился в операционной деятельности каждой команды, необходимо следовать нескольким простым правилам:
Эти характеристики, в соответствии с которыми задачу можно брать в работу на спринт.
Гибкие методы разработки
В вакансиях большинства IT-компаний востребованы гибкие методы разработки. В этой статье рассказываем, что такое Agile, Scrum и какие преимущества есть у подхода в целом.
В основе всего Agile — манифест, который чётко формулирует основные ценности процессов:
Гибкие методы позволяют сделать командную работу, с одной стороны, более динамичной и адаптивной, а с другой — комфортной для всех участников.
Один из инструментов для эджайл (Agile) — это скрам (Scrum). Это фреймворк (framework) для реализации основных принципов гибкой разработки.
Посмотрим, из чего он состоит, чтобы понять, как его применять.
Как устроен скрам
Начнём с основных инструментов, при помощи которых можно организовать рабочий процесс. Для иллюстраций будем использовать сервис Trello, который хорошо подходит для небольших команд.
Доска — это список задач, распределённых по этапам. Она может быть виртуальной, как в нашем примере, или реальной: нарисованной на флипчарте и со стикерами.
У доски есть несколько колонок:
У задач всегда есть исполнитель, который за них отвечает. Например, в Trello в карточке можно указать участника команды и уточнить, к какому направлению относится задача (например, фронтенд, бэкенд, дизайн и т. д.).
Доска — необязательный элемент, заимствованный из канбана. Некоторые команды могут вести свой бэклог и в Excel. Тем не менее доска наглядно иллюстрирует динамику процессов, поэтому ею часто пользуются.
Бэклог (backlog) — список задач проекта. Они попадают туда от продакт-оунера (product owner), который приоритизирует их исходя из бизнес-целей, технического долга или пожеланий пользователей. Главное правило — один продакт-оунер на один бэклог.
В этой статье мы не будем рассматривать методы приоритизации, а поступим просто: расположим самые важные задачи сверху. Но стоит отметить, что у Trello есть система меток, и мы можем добавлять нужные к самым критичным задачам.
Спринт (sprint) — это промежуток времени (месяц или меньше, например 2 недели), за который создаётся инкремент продукта.
Инкремент продукта — это определённый ощутимый результат, к которому должна прийти команда в течение спринта. Например, если мы делаем сервис для репетиторов, то инкрементом спринта может быть бронирование уроков, для которого у нас есть 6 задачек в бэклоге.
Бэклог спринта — задачи, которые нужно выполнить в текущем спринте для достижения инкремента. Как задачки попадают сюда из бэклога, мы разберём чуть позже.
Роли в команде скрама
Помимо инструментов скрам чётко регламентирует роли в команде.
Участники команды — это исполнители: например, разработчики, дизайнеры, копирайтеры.
Скрам-мастер (Scrum master) — сердце и душа скрам-команды. Он помогает организовать основные процессы: планирование, ежедневные митинги, ретроспективы, следит за скрам-доской (но не за бэклогом, за который отвечает продакт-оунер). Также скрам-мастер, как правило, фасилитирует встречи, то есть следит за тем, чтобы участники не отходили от темы и чувствовали себя комфортно. В идеале задача скрам-мастера — организовать процесс таким образом, чтобы команда могла работать без него. Но на практике, к сожалению, это редко реализуется.
Продакт-оунер (product owner) — это владелец продукта. Он видит полную картину и отвечает за приоритизацию задач и ведение бэклога, иногда формулировку и детализацию, а также решает, какой инкремент будет у спринта в соответствии с планированием и ресурсами команды.
Церемонии, они же встречи
Перед каждой встречей заранее определяется её цель и участники.
Планирование — перед стартом спринта продакт-оунер обозначает цели (инкремент), и встреча проходит с фокусом на этом инкременте спринта. Команда оценивает задачи, например в сторипойнтах (Story Points). Сама оценка может происходить на этапе планирования или заранее, в рамках груминга (см. ниже). После оценки команде нужно понять, какие она берёт задачи для выполнения инкремента. Если это невозможно в рамках спринта, то продакт-оунер меняет инкремент или принимает решение об увеличении длительности спринта.
Груминг — уточнение и формулировка задач, возможно, декомпозиция. В отличие от планирования и митингов, для этих встреч нет конкретных указаний, в какой момент их стоит проводить. Тем не менее основная цель — сделать задачи более прозрачными и лучше подготовится к планированию.
Митинги (стендапы) — ежедневная встреча, на которой команда разбирает текущие задачи, чтобы выявить проблемы в процессе. Длятся такие церемонии, как правило, 10–15 минут. Каждый участник рассказывает, что делал вчера и что планирует сегодня. Чаще митинги проводятся утром, но иногда команды их смещают на день или вечер. Такие встречи также фасилитирует скрам-мастер, чтобы участники чувствовали себя комфортно и встреча не затягивалась. Если, например, специалисты по бэкенду и фронтенду начинают детально обсуждать методы, то им предлагают назначить для этого разговора отдельную встречу.
Ретроспектива спринта — на этой встрече команда обсуждает, достигла ли инкремента, что получилось хорошо и не очень, а также что сделать, чтобы улучшить процесс. Цель ретроспективы — понять и проанализировать процессы и ошибки, подумать, как их предупреждать.
Демо — показ инкремента за один спринт или несколько. Демо может быть внутренним, с участниками близких команд (чтобы все понимали, что делают коллеги), или внешним — перед заказчиком.
Когда полезен скрам
Скрам хорош, когда нужно постоянное улучшение продукта. Например, у нас есть мобильное приложение и мы работаем над ним: исправляем баги и добавляем новые фичи. Цель нашего процесса — сделать продукт ещё лучше.
Скрам не подойдёт, когда не нужно ничего нового в процессах, а всё идёт по алгоритму. Например, мы делаем лендинги и процесс у нас выглядит так:
Мы хорошо представляем, сколько занимает каждый процесс. А ещё нам сложно приоритизировать задачи. Так что нет нужды в таком подробном планировании, как в скраме. В этом случае лучше применить другой подход — канбан.
Если вы решитесь внедрить скрам, то стоит знать о возможных сложностях:
Скрам — это относительно молодой подход к разработке, который постоянно развивается. У вас получится его внедрить, несмотря на все трудности, если он действительно подходит для ваших процессов. Он сделает работу команды удобнее, а процессы — прозрачнее.
В вакансиях большинства IT-компаний востребованы гибкие методы разработки. В этой статье рассказываем, что такое Agile, Scrum и какие преимущества есть у подхода в целом.
В основе всего Agile — манифест, который чётко формулирует основные ценности процессов:
Гибкие методы позволяют сделать командную работу, с одной стороны, более динамичной и адаптивной, а с другой — комфортной для всех участников.
Один из инструментов для эджайл (Agile) — это скрам (Scrum). Это фреймворк (framework) для реализации основных принципов гибкой разработки.
Посмотрим, из чего он состоит, чтобы понять, как его применять.
Как устроен скрам
Начнём с основных инструментов, при помощи которых можно организовать рабочий процесс. Для иллюстраций будем использовать сервис Trello, который хорошо подходит для небольших команд.
Доска — это список задач, распределённых по этапам. Она может быть виртуальной, как в нашем примере, или реальной: нарисованной на флипчарте и со стикерами.
У доски есть несколько колонок:
У задач всегда есть исполнитель, который за них отвечает. Например, в Trello в карточке можно указать участника команды и уточнить, к какому направлению относится задача (например, фронтенд, бэкенд, дизайн и т. д.).
Доска — необязательный элемент, заимствованный из канбана. Некоторые команды могут вести свой бэклог и в Excel. Тем не менее доска наглядно иллюстрирует динамику процессов, поэтому ею часто пользуются.
Бэклог (backlog) — список задач проекта. Они попадают туда от продакт-оунера (product owner), который приоритизирует их исходя из бизнес-целей, технического долга или пожеланий пользователей. Главное правило — один продакт-оунер на один бэклог.
В этой статье мы не будем рассматривать методы приоритизации, а поступим просто: расположим самые важные задачи сверху. Но стоит отметить, что у Trello есть система меток, и мы можем добавлять нужные к самым критичным задачам.
Спринт (sprint) — это промежуток времени (месяц или меньше, например 2 недели), за который создаётся инкремент продукта.
Инкремент продукта — это определённый ощутимый результат, к которому должна прийти команда в течение спринта. Например, если мы делаем сервис для репетиторов, то инкрементом спринта может быть бронирование уроков, для которого у нас есть 6 задачек в бэклоге.
Бэклог спринта — задачи, которые нужно выполнить в текущем спринте для достижения инкремента. Как задачки попадают сюда из бэклога, мы разберём чуть позже.
Роли в команде скрама
Помимо инструментов скрам чётко регламентирует роли в команде.
Участники команды — это исполнители: например, разработчики, дизайнеры, копирайтеры.
Скрам-мастер (Scrum master) — сердце и душа скрам-команды. Он помогает организовать основные процессы: планирование, ежедневные митинги, ретроспективы, следит за скрам-доской (но не за бэклогом, за который отвечает продакт-оунер). Также скрам-мастер, как правило, фасилитирует встречи, то есть следит за тем, чтобы участники не отходили от темы и чувствовали себя комфортно. В идеале задача скрам-мастера — организовать процесс таким образом, чтобы команда могла работать без него. Но на практике, к сожалению, это редко реализуется.
Продакт-оунер (product owner) — это владелец продукта. Он видит полную картину и отвечает за приоритизацию задач и ведение бэклога, иногда формулировку и детализацию, а также решает, какой инкремент будет у спринта в соответствии с планированием и ресурсами команды.
Церемонии, они же встречи
Перед каждой встречей заранее определяется её цель и участники.
Планирование — перед стартом спринта продакт-оунер обозначает цели (инкремент), и встреча проходит с фокусом на этом инкременте спринта. Команда оценивает задачи, например в сторипойнтах (Story Points). Сама оценка может происходить на этапе планирования или заранее, в рамках груминга (см. ниже). После оценки команде нужно понять, какие она берёт задачи для выполнения инкремента. Если это невозможно в рамках спринта, то продакт-оунер меняет инкремент или принимает решение об увеличении длительности спринта.
Груминг — уточнение и формулировка задач, возможно, декомпозиция. В отличие от планирования и митингов, для этих встреч нет конкретных указаний, в какой момент их стоит проводить. Тем не менее основная цель — сделать задачи более прозрачными и лучше подготовится к планированию.
Митинги (стендапы) — ежедневная встреча, на которой команда разбирает текущие задачи, чтобы выявить проблемы в процессе. Длятся такие церемонии, как правило, 10–15 минут. Каждый участник рассказывает, что делал вчера и что планирует сегодня. Чаще митинги проводятся утром, но иногда команды их смещают на день или вечер. Такие встречи также фасилитирует скрам-мастер, чтобы участники чувствовали себя комфортно и встреча не затягивалась. Если, например, специалисты по бэкенду и фронтенду начинают детально обсуждать методы, то им предлагают назначить для этого разговора отдельную встречу.
Ретроспектива спринта — на этой встрече команда обсуждает, достигла ли инкремента, что получилось хорошо и не очень, а также что сделать, чтобы улучшить процесс. Цель ретроспективы — понять и проанализировать процессы и ошибки, подумать, как их предупреждать.
Демо — показ инкремента за один спринт или несколько. Демо может быть внутренним, с участниками близких команд (чтобы все понимали, что делают коллеги), или внешним — перед заказчиком.
Когда полезен скрам
Скрам хорош, когда нужно постоянное улучшение продукта. Например, у нас есть мобильное приложение и мы работаем над ним: исправляем баги и добавляем новые фичи. Цель нашего процесса — сделать продукт ещё лучше.
Скрам не подойдёт, когда не нужно ничего нового в процессах, а всё идёт по алгоритму. Например, мы делаем лендинги и процесс у нас выглядит так:
Мы хорошо представляем, сколько занимает каждый процесс. А ещё нам сложно приоритизировать задачи. Так что нет нужды в таком подробном планировании, как в скраме. В этом случае лучше применить другой подход — канбан.
Если вы решитесь внедрить скрам, то стоит знать о возможных сложностях:
Скрам — это относительно молодой подход к разработке, который постоянно развивается. У вас получится его внедрить, несмотря на все трудности, если он действительно подходит для ваших процессов. Он сделает работу команды удобнее, а процессы — прозрачнее.