Что включает разбиение эпиков и что должно быть в их описании
Что проверяют
Умеете ли вы резать крупную задачу так, чтобы каждый кусок можно было выпустить и проверить, и что вы кладёте в описание. Вопрос поведенческий, поэтому оценивают ещё и то, как вы договаривались с командой, а не только знание терминов.
Как отвечать
Эпик это задача, которая не влезает в спринт и требует декомпозиции. Главный принцип разбиения: вертикальные срезы вместо слоёв. Каждая история должна доводить пользователя до результата целиком, а не «бэкенд отдельно, экран отдельно».
Рабочие приёмы:
- по шагам сценария: сначала основной путь, дальше остальные шаги;
- по вариантам данных: один тип документа, потом остальные;
- по бизнес-правилам: базовое правило сначала, исключения отдельными историями;
- по ролям и платформам;
- по операциям над сущностью: создание отдельно, редактирование и удаление отдельно;
- вынести обработку ошибок и нефункциональные требования в свои истории, если основной путь уже даёт ценность.
Что должно быть в описании эпика: проблема и для кого она, бизнес-цель с измеримой метрикой, границы с явным «что не входит», ключевые сценарии, ограничения и зависимости от смежных команд, риски и открытые вопросы, критерии приёмки верхнего уровня и состав историй с порядком выпуска.
Заканчивайте примером из практики: какой эпик резали, как проводили разбор с разработчиком и тестировщиком, что делали, когда история всё равно не влезала в спринт.
Где спотыкаются
Режут по техническим слоям. Через два спринта готовы база и сервис, но пользователь ничего не увидел, и проверить ценность нельзя.
Пишут в описании решение вместо задачи: экраны, таблицы, названия полей. Команда лишается возможности предложить дешёвый вариант, а цель остаётся ненаписанной.
Не фиксируют границы и зависимости. Эпик разрастается по ходу работы, а на демо выясняется, что смежная команда не успела, потому что с ней никто не договаривался.