Груминг задач в мобильной разработке: суть, цели и процесс проведения

Что такое груминг задач?

Backlog Grooming (refinement) — процесс подготовки задач Product Backlog к будущим спринтам. Встреча, на которой Product Owner и команда разработки проходят по задачам: уточняют требования, добавляют Acceptance Criteria, оценивают сложность, выявляют зависимости и риски. В Scrum Guide нет обязательного события «груминг» — это дополнительная практика, которую Scrum-команды вводят для снижения неопределённости на Sprint Planning. Рекомендуемая частота — 1 раз в спринт, длительностью не более 60 минут.

Термин «причёсывание» (grooming) отражает суть: команда «расчёсывает» бэклог, убирая устаревшие задачи, уточняя неясные и разбивая слишком крупные. В мобильной разработке груминг особенно важен из-за платформенной специфики: задача для Android может отличаться от iOS-версии по сложности, нужно учитывать targetSdk, compileSdk, совместимость с API уровнями. Без груминга Sprint Planning превращается в хаос: команда впервые видит задачи и не может их оценить, что ведёт к непредсказуемости и срыву сроков.

Результат груминга — несколько задач, готовых к Sprint Planning: они имеют описание, Acceptance Criteria, оценку и соответствуют Definition of Ready. Product Owner должен грумить задачи в порядке приоритета: ближайшие к текущему спринту — самые детализированные. Задачи на 3-4 спринта вперёд — только на уровне эпиков. Техника Progressive Refinement: чем ближе задача к спринту, тем детальнее её описание. Для задач в текущем спринте — full refinement (AC, дизайн, API спецификация). Для задач через 2 спринта — story-level (user story без деталей реализации). Для задач через 3+ спринта — epic-level (только название и бизнес-ценность).

Definition of Ready: когда задача готова к спринту

Definition of Ready (DoR) — чек-лист критериев, которым должна соответствовать задача перед включением в Sprint Backlog. DoR — контракт между Product Owner и командой: PO гарантирует, что вся информация для разработки есть, команда гарантирует, что может оценить и выполнить задачу. DoR не универсален — каждая команда определяет свой набор критериев. Без DoR задача может попасть в спринт с неясными требованиями, что приведёт к переработкам и срыву сроков.

Типовой DoR для мобильной разработки: 1) Acceptance Criteria описаны (критерии приёмки в формате Given-When-Then). 2) Дизайн-макет готов в Figma (для UI-задач) со всеми состояниями: default, loading, error, empty state. 3) API спецификация утверждена (OpenAPI/Swagger, примеры запросов и ответов). 4) Оценка в стори-поинтах есть. 5) Зависимости от других задач выявлены. 6) Задача не зависит от неготовых внешних компонентов. 7) Мобильная специфика: определены целевые версии ОС, необходимость feature flag, поддержка старых API уровней.

Техники оценки задач

Planning Poker — самая популярная техника оценки на груминге. Каждый разработчик получает колоду карт с числами Фибоначчи (1, 2, 3, 5, 8, 13, 21). PO показывает задачу и поясняет её. После обсуждения все одновременно показывают карту. Если оценки сильно различаются (например, 3 и 13) — разработчики объясняют свою оценку, после чего голосуют снова. Итерации повторяются до консенсуса. Смысл Planning Poker не в точной оценке, а в выявлении расхождений в понимании задачи.

T-Shirt Sizing — упрощённая техника для быстрой оценки: XS (1 SP), S (2), M (3), L (5), XL (8), XXL (13). Подходит для начальной сортировки бэклога, когда задач много и нужно быстро оценить порядок величины. После T-Shirt Sizing проводится более точная оценка через Planning Poker для задач следующего спринта. Affinity Estimation — групповая сортировка задач по относительной сложности без чисел; задачи раскладываются на столе от самых простых к самым сложным, затем группируются по кластерам, каждый кластер получает оценку.

В мобильной разработке оценка должна учитывать платформенную сложность. Android-задача может быть оценена в 5 SP, а та же задача для iOS — в 3 SP (или наоборот). Это нормально: разные платформы имеют разную сложность реализации. Совет: оценивайте каждую платформу отдельно если команда кросс-платформенная. Используйте относительную шкалу: базовая задача (например, экран с текстом и кнопкой) = 1 SP. Всё остальное — относительно неё. По данным Scrum.org (2025), через 3-4 спринта точность оценки команды достигает ±20% от фактической сложности.

Декомпозиция: как дробить крупные задачи

Задачи размером больше 8 SP должны быть декомпозированы на более мелкие. Крупные задачи невозможно выполнить за один спринт, их сложно оценивать, и они не дают ощущения прогресса. Техника декомпозиции: разделите задачу по горизонтальным слоям (UI → ViewModel → Repository → Network/DB) или по вертикальным срезам (feature: один экран целиком). Горизонтальная декомпозиция больше подходит для мобильной разработки: Sub-task 1 — вёрстка UI (XML/Jetpack Compose/SwiftUI), Sub-task 2 — ViewModel + State, Sub-task 3 — Repository + Network, Sub-task 4 — Unit tests.

Вертикальная декомпозиция — разрезать юзер-стори на более мелкие истории с независимой ценностью. Пример: Epic «Корзина покупок» → Story 1 «Добавление товара в корзину», Story 2 «Отображение корзины», Story 3 «Удаление товара из корзины», Story 4 «Оформление заказа». Каждая Story имеет свою бизнес-ценность и может быть выпущена независимо. SPoK (Story Points on Kano): ранжируйте Stories по бизнес-ценности (Must-have, Should-have, Could-have) и реализуйте в порядке ценности.

Чек-лист декомпозиции на груминге: 1) Задача больше 8 SP? → Декомпозировать. 2) Есть Acceptance Criteria? → Если нет — добавить. 3) Зависит от других задач? → Выявить и записать зависимости. 4) Содержит неопределённость? → Добавить Spike (исследование) перед основной задачей. 5) Нужен дизайн? → Проверить готовность макетов. Правило INVEST: Independent (независима от других), Negotiable (можно обсудить), Valuable (ценна для бизнеса), Estimable (можно оценить), Small (маленькая), Testable (тестируема). Если задача не проходит INVEST — она не готова к спринту.

Процесс груминга: шаг за шагом

Шаг 1: Разогрев (5 минут). Scrum Master напоминает цель груминга и DoR. Команда смотрит на доску, PO показывает, какие задачи будут обсуждаться. Шаг 2: Обзор задач (30 минут). PO последовательно представляет задачи из конца текущего и начала следующего спринта. Для каждой задачи: название, описание, Acceptance Criteria (если есть), ссылка на дизайн, API спецификация. Команда задаёт уточняющие вопросы: «Есть ли макет для пустого состояния?», «Какой HTTP метод?», «Какой iOS minimum deployment target?».

Шаг 3: Оценка (15 минут). Команда оценивает задачу через Planning Poker или T-Shirt Sizing. Если расхождение > 2 SP — обсуждают причины и голосуют повторно. Правило: если задача не может быть оценена (непонятны требования, нет дизайна) — она отправляется на доработку PO и придёт на следующий груминг с уточнениями. Не оценивайте задачи с неизвестными — это гарантированно приведёт к ошибке в спринте. Шаг 4: Запись результатов (10 минут). PO фиксирует оценки в Jira/Linear, обновляет Description задачи и расставляет приоритеты.

Результаты груминга: 3-7 полностью готовых к Sprint Planning задач (с DoR, оценкой, дизайном, API). PO обновляет бэклог: удаляет устаревшие задачи, объединяет дублирующиеся, уточняет приоритеты. Важно: груминг не заканчивает работу PO — между грумингами он должен подготовить следующие задачи. Рекомендуемый темп: PO готовит 3-4 задачи для груминга, команда прорабатывает их. Если задач в бэклоге больше 50 — PO должен провести приоритизацию (MoSCoW или Weighted Shortest Job First) до груминга.

Чем груминг отличается от Sprint Planning

Груминг — это подготовка. На нём нет обязательств — задача просто уточняется и оценивается. Sprint Planning — это обязательство. Команда выбирает задачи из подготовленных на груминге и берёт на себя обязательство выполнить их за спринт. Основные различия: груминг не привязан к конкретному спринту (refinement бэклога в целом), на груминге нет Sprint Goal, груминг может проводиться в любое время спринта. Sprint Planning — строго в начале спринта и всегда приводит к Sprint Goal.

На груминге задачи только оцениваются, но не берутся в спринт. На Planning задачи выбираются из подготовленного пула. Без груминга Sprint Planning занимает 6-8 часов (вместо 4), потому что команда впервые видит задачи и не может быстро их оценить. Правило 80/20: 80% задач на Sprint Planning должны быть полностью готовы (прошли груминг), 20% — могут быть новыми (срочные баги, hotfix). Если на Planning больше 20% неоценённых задач — груминг был недостаточным.

Типичные ошибки груминга

Ошибка 1: груминг раз в месяц. Команда копит 3-4 спринта задач, пытается всё уточнить за 2 часа. Результат: половина задач остаётся неоценённой, Planning занимает весь день. Решение: груминг должен быть регулярным — 1 раз в спринт, 60 минут. Если задач много — добавьте второй груминг в середине спринта. Лучше грумить меньше задач, но качественно, чем много — но поверхностно. Темп: 3-5 задач за один груминг, каждая получает полноценное обсуждение и оценку.

Ошибка 2: оценка без контекста. PO показывает задачу «Реализовать экран корзины» без дизайна, без API, без AC. Команда оценивает «на глаз» — 13 SP. В Planning выясняется, что на самом деле это 5 SP (потому что экран простой). Решение: задача не оценивается, если нет дизайна или API. PO обязан подготовить материалы до груминга. Правило: «Нет макета — нет оценки». Исключение: Spike-задачи — исследование неопределённости, они оцениваются отдельно без дизайна (2-5 SP в зависимости от сложности исследования).

Ошибка 3: груминг превращается в Planning. Команда начинает распределять задачи по исполнителям и обсуждать, кто что будет делать. Решение: напомнить, что груминг — про уточнение, а не про распределение. Распределение — на Daily после начала спринта. Груминг отвечает на вопрос «что делать?», Planning — на «когда делать?», Daily — на «кто делает?». Смешение этих вопросов в одной встрече снижает эффективность каждой из них. Scrum Master должен остановить Planning-обсуждение и перенаправить фокус на уточнение задачи.

Ошибка 4: игнорирование Tech Debt. На груминге обсуждают только новые фичи, технические задачи игнорируются. Через 3-4 спринта техдолг накапливается до критического уровня. Решение: на каждом груминге минимум 1 Tech-задача должна пройти оценку. Пропорция: на 3 фичи → 1 тех. задача. Используйте метрику Tech Debt Ratio: отношение Tech задач к Feature задачам в спринте. Целевое значение: 0.25-0.3 (25-30% времени на техдолг). Если ratio ниже 0.2 — скорость разработки будет падать в следующих спринтах.