Как грумить задачу: чек-лист с примерами

Наша разработка постоянно растет, поэтому приходится онбордить по несколько человек в месяц и каждому рассказывать, как правильно грумить задачи. Обучать груму «вручную» больно, потому что это отнимает много времени, какие-то знания теряются по дороге и выскакивают ошибки, которых можно было избежать. Чтобы облегчить жизнь лидам и новичкам, мы собрали чек-лист с описанием этапов грума и примерами. Он будет полезен разработчикам продуктовых компаний, которые онбордят или которых недавно приняли в штат. Чек-лист поможет разбивать задачи на этапы, чтобы ничего не терялось и результат соответствовал ожиданиям.

Все примеры ниже — специфичные и подойдут не каждому, они построены в основном на продуктах Mindbox «Рассылки» и «Программа лояльности». Продукты помогают нашим клиентам запускать автоматические рассылки по триггерам (действиям или событиям), чтобы не спамить пользователей, выдавать промокоды и выстраивать бонусные системы. Если поймете, что чек-лист полезен, можете заменить примеры на свои и использовать.

Ниже подробнее о том, как сделать качественный грум:

цель грума,
необходимый минимум,
уточнение требований и контекста,
типичные этапы,
особенности при доработке механик.

Цель грума

Цель грума — провалидировать решение с командой перед тем, как брать задачу в работу. Для этого нужно:

снять технические риски,
уточнить требования,
разбить грум на небольшие части, которые можно ревьюить и мержить отдельно,
уточнить оценку задачи,
сохранить информацию о решении и его мотивации.

Необходимый минимум

Контекст

Зачем задача нужна бизнесу:

какую потребность бизнеса решает,
какие сервисы затрагивает,
как реализовано сейчас и что меняем.

Список этапов

Краткое описание этапов реализации — минимум по одному предложению на каждый этап. Желательно, чтобы каждый этап можно было ревьюить и мержить отдельно. При этом этапы нужно добавлять по необходимости и не пытаться во всех задачах разгрумить все аспекты.

Приемочные критерии

Недвусмысленное описание того, как должна работать система по завершении задачи.

Уточнение требований и контекста

Валидация проблемы

Какую проблему решаем? Точно ли нужно ее решать именно так? Не нужно ли более общее решение?

Консистентность системы

Не позволяем ли мы создавать один и тот же функционал двумя способами без особых на то причин?

Пример, как не надо. Обычно все страницы списков сущностей стандартные и в них используется стандартный контрол фильтра для поиска. При этом на странице проблем нет стандартной подгрузки батчами и контрола фильтра, потому что ПО решил, что нужен другой UX. В результате написали кастомный код, еще и страница тормозит:

Страница проблем в админке Mindbox. Фильтр не такой, как на других страницах, в нем всего один параметр — статус проблемы

Сценарии приемки

Как проверить, что приемочные критерии выполнены?

BDD-тест (behavior driven development)

В задаче сложная бизнес-логика с большим количеством неочевидных сценариев? Если да, нужен BDD-тест.

При этом нужно учесть, что мы пишем тесты в коде, — у бизнес-аналитика нет фреймворка для тестов.

Примеры, когда понадобилась детальная подготовка тестовых сценариев от бизнес-аналитика:

Кейсы дедубликации и безопасности операций

Кейсы фильтров по времени относительно текущего из контекста

Фича-тоггл

Как тестировать новые изменения на части клиентов: с помощью фичи-тоггла или другим способом?

Объем железа

Начинаем ли хранить терабайты новых данных или расходовать много CPU? Если да, то нужно обновить модель железа.

Поведение в случае отказов

Как ведем себя в случае отказов, если сервис недоступен, LRT лежал, был регулярный даунтайм БД?

LRT (long running task) — обработчик фоновых задач.

Проблемы

Нужно ли заводить проблемы в каком-то из сценариев?

Под проблемами мы понимаем сообщения для клиентов о том, что какие-то автоматические механики в админке работают неправильно, в чем ошибка и как ее исправить. Например:

настроена автоматическая выдача промокодов, а промокоды в пуле закончились;
настроено списание бонусов по событию, а у клиента нет баллов, и баланс станет отрицательным;
в шаблоне письма что-нибудь делим на количество заказов, а заказов ноль — получается, что делим на ноль.

Ограничение доступа

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

Типичные этапы

Two-phase-миграция

Как именно будет происходить миграция: изменения в базе данных, контрактах сервисов, наборе топиков Kafka? Не сломается ли обратная совместимость?

UI и бэкенд

Отдельно ли редактируем метаданные и рантайм, который их использует? Стандартный пример задачи на блоки в сценариях: UI, бэкенд для UI, рантайм — все отдельно.

Примеры подэпиков в эпике сценариев: